|
|
Post by frankv on Feb 7, 2010 13:37:28 GMT -5
Hi,
I noticed in the UMC-1 video on Emo's site that it seemed to take several seconds to switch between HDMI inputs (Lonnie referred to it as HDMI handshaking taking place). Is that "normal" for processors to take that long, or are there significant differences between different brands/models (kinda like loading a Blu-Ray disc)? My present receiver (Rotel) switches significantly faster between video inputs, but only has analog video circuitry.
Thx,
Frank
|
|
lonnie
Administrator 
GM
OZ- 'Pay no attention to the man behind the curtain'
Posts: 1,292
|
Post by lonnie on Feb 7, 2010 13:48:25 GMT -5
Hi, I noticed in the UMC-1 video on Emo's site that it seemed to take several seconds to switch between HDMI inputs (Lonnie referred to it as HDMI handshaking taking place). Is that "normal" for processors to take that long, or are there significant differences between different brands/models (kinda like loading a Blu-Ray disc)? My present receiver (Rotel) switches significantly faster between video inputs, but only has analog video circuitry. Thx, Frank Hey Frank, This is just one of the those things with HDMI and all units will have it. In the latest set of regulations it is basically a three step process. The source will talk to the processor and then the processor back to the source. Step two is the processor talking to the monitor or projector and the monitor talking back to the processor. Step three is the monitor talking through the processor all the way back to the source. Once all three steps have confrimed a lot of information then everything just runs. Now with analog, you can switch video in a matter of micro-seconds. But with HDMI, there is a lot going on and unfortunately what takes all the time is the DCP but this is just how the world is going. |
|
ratmice
Emo VIPs 
I'm not an actor, but I play one on TV.
Posts: 1,853
|
Post by ratmice on Feb 7, 2010 13:48:42 GMT -5
One of the "pleasures" of HDMI. Processors have a lag while the components identify themselves to each other - wouldn't want any non HDCP compliant devices to have any fun. You will not see that with analog connections, which are virtually instantaneous.
[Maxwell Smart] Missed it by "that" much [/Maxwell Smart]
|
|
|
|
Post by akbungle on Feb 7, 2010 14:03:18 GMT -5
Hey Frank, This is just one of the those things with HDMI and all units will have it. In the latest set of regulations it is basically a three step process. The source will talk to the processor and then the processor back to the source. Step two is the processor talking to the monitor or projector and the monitor talking back to the processor. Step three is the monitor talking through the processor all the way back to the source. Once all three steps have confrimed a lot of information then everything just runs. Now with analog, you can switch video in a matter of micro-seconds. But with HDMI, there is a lot going on and unfortunately what takes all the time is the DCP but this is just how the world is going. I thought one of the cool perks with the UMC-1 was that it saved the info from your equipment and that the HDMI handshake was very quick compared to others. Did this feature get dropped or something? |
|
|
|
Post by roadrunner on Feb 7, 2010 15:03:42 GMT -5
Hey Frank, This is just one of the those things with HDMI and all units will have it. In the latest set of regulations it is basically a three step process. The source will talk to the processor and then the processor back to the source. Step two is the processor talking to the monitor or projector and the monitor talking back to the processor. Step three is the monitor talking through the processor all the way back to the source. Once all three steps have confrimed a lot of information then everything just runs. Now with analog, you can switch video in a matter of micro-seconds. But with HDMI, there is a lot going on and unfortunately what takes all the time is the DCP but this is just how the world is going. I thought one of the cool perks with the UMC-1 was that it saved the info from your equipment and that the HDMI handshake was very quick compared to others. Did this feature get dropped or something? It is all relative. Compared to most other processors, the UMC-1 is very speedy when switching HDMI inputs. Compared to the time it takes to change analog video inputs the UMC-1 appears to be slow. Hollywood's paranoia strikes again. Their anti-piracy steps don't even slow done the big time pirates... the real impact is felt by the typical consumer who would never copy and resell the video content in the first place. Try comparing HDMI to HDMI video feeds on your previous AVR or Pre/Pro to the UMC-1's switching times. When I did that comparison the UMC-1 seemed to by down right fast -- 1 or 2 seconds versus 6 to 7 seconds. As long as the courts continue to side with the studios we are stuck to "glacial" speeds when switching between HDMI inputs.  |
|
lonnie
Administrator
GM
OZ- 'Pay no attention to the man behind the curtain'
Posts: 1,292
|
Post by lonnie on Feb 7, 2010 15:10:52 GMT -5
Hey Frank, This is just one of the those things with HDMI and all units will have it. In the latest set of regulations it is basically a three step process. The source will talk to the processor and then the processor back to the source. Step two is the processor talking to the monitor or projector and the monitor talking back to the processor. Step three is the monitor talking through the processor all the way back to the source. Once all three steps have confrimed a lot of information then everything just runs. Now with analog, you can switch video in a matter of micro-seconds. But with HDMI, there is a lot going on and unfortunately what takes all the time is the DCP but this is just how the world is going. I thought one of the cool perks with the UMC-1 was that it saved the info from your equipment and that the HDMI handshake was very quick compared to others. Did this feature get dropped or something? The original prototypes did but that is no longer allowed. In fact each piece of gear has to constantly ping all the other gear to make sure it wasn't disconnected and something else connected after startup. So saving the EDID is no longer allowed. |
|
|
|
Post by azemotiuser on Feb 7, 2010 19:20:57 GMT -5
I am trying to connect my HTPC to the UMC-1 instead of direct to the monitor. The HTPC's video card is an ATI HD4830 with HDMI port. At no time does the HTPC recognize that their a monitor attached when hooked through the UMC-1. When the HTPC is hook direct to my 8UK series Panasonic, the HTPC recognizes that it is a 1366x768 Panasonic.
The process I've been trying is to first turn on the Panasonic 8UK plasma, then the UMC-1, the power on the HTPC. I have also tried the 8UK first then the HTPC then the UMC-1. And the UMC-1 first then the 8UK then the HTPC. And every other sort of combination.
Is there a setting I'm missing to allow the particular UMC-1 HDMI port that I hook the HTPC to have a constant identifier to sent to the HTPC that it's on an is a monitor, specific resolution, etc?
|
|
|
|
Post by roadrunner on Feb 7, 2010 19:34:39 GMT -5
Lonnie
The constantly changing "playing field" must be very frustrating to you when you have worked so hard to create a fast HDMI handshake solution. It would drive me nuts. Are you allowed to comment on whether you think their latest paranoid move have any basis in fact? I just do see it... how does this benefit them? Penalizing the typical consumer, people like us, is not going to slow down the pirates.
|
|
|
|
Post by solidstate on Feb 7, 2010 21:09:02 GMT -5
I thought one of the cool perks with the UMC-1 was that it saved the info from your equipment and that the HDMI handshake was very quick compared to others. Did this feature get dropped or something? The original prototypes did but that is no longer allowed. In fact each piece of gear has to constantly ping all the other gear to make sure it wasn't disconnected and something else connected after startup. So saving the EDID is no longer allowed. no way that sucks... it's possible in software but for cert compliance they wouldn't allow you to ship with it working in this way? That really really sucks as I was looking for that feature-set of the HDMI receiver you're using. You can still use the EDID override register right? I guess so if you can turn "auto" to a specific rez global on output. This should speed it up some no? You just wait they'll request that be disabled as well for some loony-tune idea come 120Hz/3D 1.4... UGG What a mess and a pain in the butt HDMI has been for EEs building A/V gear!!! |
|
|
|
Post by solomente on Feb 7, 2010 22:29:14 GMT -5
When I did that comparison the UMC-1 seemed to by down right fast -- 1 or 2 seconds versus 6 to 7 seconds. Is this what others are experiencing? In my case I'd say 6 to 7 seconds is the best I see on my UMC... it's more commonly 12-15 seconds and frequently 1.5 to 2 MINUTES on my Blu Ray player. A couple times it just never locked in at all and gave me a static screen. |
|
|
|
Post by frankv on Feb 7, 2010 23:03:07 GMT -5
Thx for the explanation, I kind of figured it was something like that, but 5+ seconds seems to be a bit excessive (not blaming the UMC-1 here, it's probably just the inefficient protocol).
Fortunately, like loading a Blu-Ray disc, it's not something I do frequently in my HT, so it's not a huge deal even when I upgrade my projector.
I wonder, though, how does that affect receiving a video signal from a HTPC via HDMI - do all the major video cards play by the rules, and if you have one that doesn't (maybe an older card), would the UMC-1 get along with it?
|
|
|
|
Post by thisonekidmongo on Feb 8, 2010 12:18:35 GMT -5
5-10 seconds was normal for HDMI source switching on my UMC. Even component switching could take a few seconds--though I was outputting everything over HDMI anyway, which I imagine played a role.
I've since "downgraded" to a Yamaha RX-V661 AVR, and HDMI switching on that is instantaneous. Of course, this is an older AVR, made when standards were probably more lax. I'll be getting an Onkyo 885 soon, and I'm not terribly optimistic about the HDMI switching time on that.
|
|
|
|
Post by solidstate on Feb 8, 2010 16:51:13 GMT -5
It's way ridiculous and an obvious software flaw in the unit IMHO if it's taking 6-10 seconds for it to display. The data being communicated between TDMS transmitters is absolutely minuscule in terms of bytes and even over I²C it's nothing man... I wish we had a good picture of the video section on the unit. Anyone willing to open theirs up and take a picture?
|
|
|
|
Post by solidstate on Feb 8, 2010 17:00:39 GMT -5
Lonnie The constantly changing "playing field" must be very frustrating to you when you have worked so hard to create a fast HDMI handshake solution. It would drive me nuts. Are you allowed to comment on whether you think their latest paranoid move have any basis in fact? I just do see it... how does this benefit them? Penalizing the typical consumer, people like us, is not going to slow down the pirates. It's that HDMI/HDCP dongle thingie that nukes HDCP that's caused them to ditch EDID/BKSV/SHA-1 key buffering or however it works... what's it called again... anyone? And ya it's done nothing for piracy what so ever. It's like the jerks that turn on macrovision on DVDs. Doesn't nothing for security other than create macroblocking for endusers. I'd like to throttle the DVD author that turned the flag on when I encounter one of those disks. Attacks on the disc's encryption is where the community has found entry. Obviously totally makes the transport protection useless. |
|
|
|
Post by roadrunner on Feb 8, 2010 17:03:16 GMT -5
When I did that comparison the UMC-1 seemed to by down right fast -- 1 or 2 seconds versus 6 to 7 seconds. Is this what others are experiencing? In my case I'd say 6 to 7 seconds is the best I see on my UMC... it's more commonly 12-15 seconds and frequently 1.5 to 2 MINUTES on my Blu Ray player. A couple times it just never locked in at all and gave me a static screen. I am sorry to tell you that the timing figures I used in my previous post were based off of my notes from when I attended Emofest. I do not know what the "shipping version" will be able to do. I was unaware that the HDMI cops had disallowed storing the EDID data... which was responsible for the extremely fast handshakes the prototype was showing. I assumed the performance I witnessed at Emofest would be carried over in the shipping models. Sorry. Hollywood has screwed us again.  |
|
|
|
Post by solidstate on Feb 8, 2010 17:09:35 GMT -5
Is this what others are experiencing? In my case I'd say 6 to 7 seconds is the best I see on my UMC... it's more commonly 12-15 seconds and frequently 1.5 to 2 MINUTES on my Blu Ray player. A couple times it just never locked in at all and gave me a static screen. I am sorry to tell you that the timing figures I used in my previous post were based off of my notes from when I attended Emofest. I do not know what the "shipping version" will be able to do. I was unaware that the HDMI cops had disallowed storing the EDID data... which was responsible for the extremely fast handshakes the prototype was showing. I assumed the performance I witnessed at Emofest would be carried over in the shipping models. Sorry. Hollywood has screwed us again. It's not the EDID data, it's related to the SHA-1/KSV or BKSV in upstream device being buffered I think at the "repeater" controller. The EDID data isn't used for example if you set it to a fixed rez and not "auto". It still reads some of the data I guess to avoid sending a signal that's out of range for display device though and read encryption keys for HDCP but when autos off it doesn't use any of the data to determine rez, refresh and bit depth. There is a register for this in all the HDMI receivers I've seen the white paper for. But all this is determined to some extent by the EEs designing the equipment, the chips they use, and the feature set of those chips as well as the logic used for this process in their firmware/microcode. PS Is BKSV stored in EDID address space? must be... |
|
ratmice
Emo VIPs
I'm not an actor, but I play one on TV.
Posts: 1,853
|
Post by ratmice on Feb 8, 2010 17:15:07 GMT -5
Lonnie The constantly changing "playing field" must be very frustrating to you when you have worked so hard to create a fast HDMI handshake solution. It would drive me nuts. Are you allowed to comment on whether you think their latest paranoid move have any basis in fact? I just do see it... how does this benefit them? Penalizing the typical consumer, people like us, is not going to slow down the pirates. It's that HDMI/HDCP dongle thingie that nukes HDCP that's caused them to ditch EDID/SHA-1 key buffering or however it works... what's it called again... anyone? And ya it's done nothing for piracy what so ever. It's like the jerks that turn on macrovision on DVDs. Doesn't nothing for security other than create macroblocking for endusers. I'd like to throttle the DVD author that turned the flag on when I encounter one of those disks. Attacks on the disc's encryption is where the community has found entry. Obviously totally makes the transport protection useless. Are you thinking of the HDFury ? |
|
|
|
Post by solidstate on Feb 8, 2010 17:16:04 GMT -5
It's that HDMI/HDCP dongle thingie that nukes HDCP that's caused them to ditch EDID/SHA-1 key buffering or however it works... what's it called again... anyone? And ya it's done nothing for piracy what so ever. It's like the jerks that turn on macrovision on DVDs. Doesn't nothing for security other than create macroblocking for endusers. I'd like to throttle the DVD author that turned the flag on when I encounter one of those disks. Attacks on the disc's encryption is where the community has found entry. Obviously totally makes the transport protection useless. Are you thinking of the HDFury ? YUP |
|
markd
Emo VIPs
Posts: 182
|
Post by markd on Feb 8, 2010 18:05:06 GMT -5
PS Is BKSV stored in EDID address space? must be... EDID and HDCP stuff are separate, although they are accessed over the same I2C style bus. (DDC) |
|
|
|
Post by solidstate on Feb 8, 2010 18:06:14 GMT -5
I am trying to connect my HTPC to the UMC-1 instead of direct to the monitor. The HTPC's video card is an ATI HD4830 with HDMI port. At no time does the HTPC recognize that their a monitor attached when hooked through the UMC-1. When the HTPC is hook direct to my 8UK series Panasonic, the HTPC recognizes that it is a 1366x768 Panasonic. The process I've been trying is to first turn on the Panasonic 8UK plasma, then the UMC-1, the power on the HTPC. I have also tried the 8UK first then the HTPC then the UMC-1. And the UMC-1 first then the 8UK then the HTPC. And every other sort of combination. Is there a setting I'm missing to allow the particular UMC-1 HDMI port that I hook the HTPC to have a constant identifier to sent to the HTPC that it's on an is a monitor, specific resolution, etc? #1 Are you using the DVI to HDMI dongle that ATI included? You can't use a generic one as it's pinned out different and there is some electronics in the boxed ATI dongle unit. #2 Are you using port #1 on the back of the video card? It's the only one that supports HDMI. It's labeled on the backplate. #3 Sure your mapping/assigning the HDMI input # on the back of the UMC-1 to correct input "label". Set global to passthrough to start on UMC-1 and also passthrough for it's source option. #4 Is the computers current display set to a STANDARD spec rez and not some strange overscan resolution you made for your panasonic? If so set it to 720p 1280 x 720 to start before plugging it in to UMC-1 #5 I wish I had a unit in house so I could help guide you all better! |
|
