AVS Forum banner

21 - 40 of 1423 Posts

·
Premium Member
Joined
·
4,151 Posts
Does Lumagen have any patents on things like virtual inputs or other things that Envy might implement? Have been curious when I see a product implementing things that another has. Maybe in the niche world that these products live in, it doesn’t matter.... With all the HDMI fixes that Lumagen has done for specific sources/displays, I just can’t see having a VP that can’t handle source switching. I guess folks that get an Envy are just using their AVP for this. Some are likely better than others in obtaining HDMI improvements for sources and displays. SJ
 

·
Super Moderator
JVC RS4500 | ST130 G4 135" | MRX 720 | MC303 MC152 | 6.1.4: B&W 802D3, 805D3, 702S2 | 4x15 IB Subs
Joined
·
10,870 Posts
Does Lumagen have any patents on things like virtual inputs or other things that Envy might implement? Have been curious when I see a product implementing things that another has. Maybe in the niche world that these products live in, it doesn’t matter.... With all the HDMI fixes that Lumagen has done for specific sources/displays, I just can’t see having a VP that can’t handle source switching. I guess folks that get an Envy are just using their AVP for this. Some are likely better than others in obtaining HDMI improvements for sources and displays. SJ
I don't see how Lumagen can patent virtual inputs. It's not novel enough. Other processors use this also such as Anthem and Trinnov. It's "prior art".
 
  • Like
Reactions: seanbryan

·
Premium Member
Joined
·
798 Posts
I guess folks that get an Envy are just using their AVP for this.
Yes, that´s the usual use case for an Envy.
I´m also really curious how the virtual inputs work - i really, really expect this to be not trivial at all....
 
  • Like
Reactions: ARROW-AV

·
ABSOLUTE ULTIMATE AV
Joined
·
5,699 Posts
Discussion Starter · #24 ·
Yes, that´s the usual use case for an Envy.
I´m also really curious how the virtual inputs work - i really, really expect this to be not trivial at all....
I hate to say it but I will be amazed if they actually pull this off. I don't think it's even possible to automatically detect source devices in all instances. I foresee a situation wherein this feature will work with respect to certain items of source equipment but not others, and even then it will probably be glitchy given this is HDMI we are talking about. I really hope that I am wrong here but... 😬
 

·
Premium Member
Joined
·
11,987 Posts
I'm actually surprised that the Envy doesn't just handle it as selectable virtual inputs as opposed to trying to make it automatic. It isn't like the Radiance Pro does auto selection of input, you select the input. That could work virtually as well.

My biggest concern with the Envy for inputs is the fact that you are relying on a AVR/Pre-pro for HDMI switching and providing that signal unmolested. HDMI is crappy on its best day, so the least amount of devices in the chain the better. Never mind that most high end processors have rather crappy HDMI switching/support as is (don't get me started on the horror stories with Trinnov on this front). I've worked with several companies on video processors and HDMI and every one of them talked at nauseam about how bad HDMI is to work with. How it completely dominated all their service and support calls and sucked up all their time. I'm sure Madshi can relate at this point, I wouldn't be surprised at all to find out that most of the Envy delay is because of HDMI related issues.
 

·
Premium Member
Joined
·
798 Posts
I'm actually surprised that the Envy doesn't just handle it as selectable virtual inputs as opposed to trying to make it automatic. It isn't like the Radiance Pro does auto selection of input, you select the input. That could work virtually as well.
I don´t know exactly how madshi will implement it in detail, but that´s how i understood it:
He´s working on the detection of input devices and selectable profiles as one workpackage. As far as i understand, the ultimate goal is to identify connected sources even through an AVR in the chain to be able to automatically apply profiles with different settings for different source devices. This is because one of the major design principles for the Envy is ease-of-use.
However, if the auto-detection doesn´t work, it will still be possible to apply the profiles manually. Or, when using an automation system, switch profiles based on source selection via the automation system (utillizing the IP control API that will be implemented right after virtual inputs / profiles).
So there will be a fallback to manually select profiles.

I'm sure Madshi can relate at this point, I wouldn't be surprised at all to find out that most of the Envy delay is because of HDMI related issues.
Yes, that is sth madshi already confirmed. 😬
 

·
ABSOLUTE ULTIMATE AV
Joined
·
5,699 Posts
Discussion Starter · #27 ·
I'm actually surprised that the Envy doesn't just handle it as selectable virtual inputs as opposed to trying to make it automatic. It isn't like the Radiance Pro does auto selection of input, you select the input. That could work virtually as well.

My biggest concern with the Envy for inputs is the fact that you are relying on a AVR/Pre-pro for HDMI switching and providing that signal unmolested. HDMI is crappy on its best day, so the least amount of devices in the chain the better. Never mind that most high end processors have rather crappy HDMI switching/support as is (don't get me started on the horror stories with Trinnov on this front). I've worked with several companies on video processors and HDMI and every one of them talked at nauseam about how bad HDMI is to work with. How it completely dominated all their service and support calls and sucked up all their time. I'm sure Madshi can relate at this point, I wouldn't be surprised at all to find out that most of the Envy delay is because of HDMI related issues.
The latest madVR Envy firmware update cited aiming to improve some of the HDMI issues that people have been experiencing. As is typcial with HDMI some folks have experienced only intermittent HDMI issues, whereas others not so lucky. HDMI is a ***** that's for sure. Things are going to ger even more 'interesting' as and when HDMI 2.1 kicks off properly. Even more 'fun and games' on the horizon. LOL 😂
 

·
Registered
Joined
·
9,253 Posts
When you setup and calibrate video equipment you follow the same parameters with respect to targeting the same objective of optimum video performance. For example you should achieve a minimum of <= 2 dE color accuracy; wherein the color accuracy is not going to vary across content or from scene to scene. Same goes for other objectively measureable aspects of video performance, such as HD-->4K upscaling and HDR Dynamic Tone-Mapping (DTM) performance. Also, literally nobody is going to be pausing a movie and changing the settings on a scene-by-scene basis. You want the settings which achieve the best possible overall video performance with respect to the whole movie / video content.

With respect to different types of source content, yes there will be different sets of settings for the likes of HDR and SDR, however the particular video processor should be setup and calibrated properly and optimally with respect to each of these.
Hmm, there are a LOT of settings to operate on both the Lumagen and MadVR with respect to its tone mapping, going to be very difficult for you to truly equalize the baseline here. These are things that have nothing at all to do with calibration and there is no standard to adhere to. So in essense, yes they certainly are subjective. Me for eg, I dont like (At all) the current implementation of Highlight, Contrast and Shadow recovery within MadVR and I am of the opinion they should not be on, these when on will look OK for some scenes, but in others will aim to make things washed out, artificially edge sharpened, flatten, or bring a sense of unnaturalism to the image due to contrast boosting, this is on the PC side of course, but I know they are based on the same algorithms.

Now 🙂

Aiming to post the first lot of data within a week...
Unfortunately the data you collect if you do it now will be invalid by the time the Envy launches, if not in a matter of only a few weeks from now. If you played along with any of the HDR Tone Mapping progress you would know that things can, and do radically change from week to week as Madshi implements new things, and just how huge some of the changes can be (settings that were not great become MUST HAVE for eg).

The Envy is not final, so I really think its folly and unfair to do in depth comparisons on a pre-release unit unless you plan on doing it again when the unit is final, in which case that's of course up to you how you use your time.
 

·
Super Moderator
JVC RS4500 | ST130 G4 135" | MRX 720 | MC303 MC152 | 6.1.4: B&W 802D3, 805D3, 702S2 | 4x15 IB Subs
Joined
·
10,870 Posts
I hate to say it but I will be amazed if they actually pull this off. I don't think it's even possible to automatically detect source devices in all instances. I foresee a situation wherein this feature will work with respect to certain items of source equipment but not others, and even then it will probably be glitchy given this is HDMI we are talking about. I really hope that I am wrong here but... 😬
Is autodetecting ports a requirement? On my AVR when I want to switch inputs, I use my remote to do so. I would expect a virtual input to work the same way.
 
  • Like
Reactions: Archibald1

·
Premium Member
Joined
·
798 Posts
@ARROW-AV
Nigel, in your comparison - are you solely focusing on picture quality or are you also looking at general features?
 

·
.NET Solution Architect
Joined
·
979 Posts
Is autodetecting ports a requirement? On my AVR when I want to switch inputs, I use my remote to do so. I would expect a virtual input to work the same way.
That's exactly the problem case with Envy - for the very best video performance it's best to remove from the chain any other processors before routing source to your display, especially any type of AVR and you simply route Audio separately to your AVR and video to your video processor and then to your display.

Sent from my GM1913 using Tapatalk
 
  • Like
Reactions: Archibald1

·
Premium Member
Joined
·
798 Posts
That's exactly the problem case with Envy - for the very best video performance it's best to remove from the chain any other processors before routing source to your display, especially any type of AVR and you simply route Audio separately to your AVR and video to your video processor and then to your display.
In theory, yes - the shorter the chain, the better.
If it´s a problem in reality could be easily tested with doing a test with an AVR in the chain and one with source directly attached to the Envy. Of course outcome can vary depending on the AVR used in your installation.

EDIT: Perhaps we´ll see an Envy with multiple inputs in the future - but i guess atm madshi is happy the one input he has is running without flaws. ;)
 

·
Premium Member
Joined
·
2,484 Posts
That's exactly the problem case with Envy - for the very best video performance it's best to remove from the chain any other processors before routing source to your display, especially any type of AVR and you simply route Audio separately to your AVR and video to your video processor and then to your display.

Sent from my GM1913 using Tapatalk
Yes, i have always connected the VP directly to the display and run a separate Audio out to the AV processor....NEVER liked the idea of routing the image though AV Receivers/Processors .
 

·
Premium Member
Joined
·
798 Posts
Yes, i have always connected the VP directly to the display and run a separate Audio out to the AV processor....NEVER liked the idea of routing the image though AV Receivers/Processors .
So you use only one source with the Envy?
 

·
Super Moderator
JVC RS4500 | ST130 G4 135" | MRX 720 | MC303 MC152 | 6.1.4: B&W 802D3, 805D3, 702S2 | 4x15 IB Subs
Joined
·
10,870 Posts
That's exactly the problem case with Envy - for the very best video performance it's best to remove from the chain any other processors before routing source to your display, especially any type of AVR and you simply route Audio separately to your AVR and video to your video processor and then to your display.
This is sort of a misconception. It's not like you will get a better quality picture by removing the AVR from the chain. You instead may have less connection problems. But it's also quite possible that the connection problems don't become problems so it's no problem in the end. If it works, it works.
 

·
.NET Solution Architect
Joined
·
979 Posts
This is sort of a misconception. It's not like you will get a better quality picture by removing the AVR from the chain. You instead may have less connection problems. But it's also quite possible that the connection problems don't become problems so it's no problem in the end. If it works, it works.
I don't agree with you on that, this is not the misconception, although its not just about connectivity issues its about how the signal is processed with AVR and then feeded to your Video Processor, this involves bit depth color conversions and color space and etc, therefore it is always best to avoid using AVR in front of your main Video Processor, AVR should be behind that in the chain, the only downside is you are lacking of OSD from AVR.
 

·
Registered
Joined
·
9,253 Posts
I don't agree with you on that, this is not the misconception, although its not just about connectivity issues its about how the signal is processed with AVR and then feeded to your Video Processor, this involves bit depth color conversions and color space and etc, therefore it is always best to avoid using AVR in front of your main Video Processor, AVR should be behind that in the chain, the only downside is you are lacking of OSD from AVR.
Maybe in the year 2010 or so, but these days any half decent Avr will effectively pass unmolested video without conversion unless you specifically allow it to. There is certainly an option to disallow it on mine.

Sent from my SM-G988B using Tapatalk
 

·
Super Moderator
JVC RS4500 | ST130 G4 135" | MRX 720 | MC303 MC152 | 6.1.4: B&W 802D3, 805D3, 702S2 | 4x15 IB Subs
Joined
·
10,870 Posts
I don't agree with you on that, this is not the misconception, although its not just about connectivity issues its about how the signal is processed with AVR and then feeded to your Video Processor, this involves bit depth color conversions and color space and etc, therefore it is always best to avoid using AVR in front of your main Video Processor, AVR should be behind that in the chain, the only downside is you are lacking of OSD from AVR.
Don't all AVRs have a pass through mode? My Anthem doesn't change the signal at all.
 
21 - 40 of 1423 Posts
Top