CMS for VP50 Pro coming? - Page 7 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #181 of 216 Old 01-07-2009, 04:26 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
....I see DVDO may have something cooking for the up coming CES Event of Jan 8-11 2009. This could mean either A new product or A long awaited upgrade for the VP 50pro...

It's a refrigeration kit for those customer that were "concerned" about the unit chassis temperature (just kidding).
fastl is offline  
Sponsored Links
Advertisement
 
post #182 of 216 Old 01-07-2009, 06:56 PM
Wireless member
 
pepar's Avatar
 
Join Date: Jul 2002
Location: Quintana Roo ... in my mind
Posts: 24,932
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 30 Post(s)
Liked: 131
Quote:
Originally Posted by fastl View Post

....I see DVDO may have something cooking for the up coming CES Event of Jan 8-11 2009. This could mean either A new product or A long awaited upgrade for the VP 50pro...

It's a refrigeration kit for those customer that were "concerned" about the unit chassis temperature (just kidding).

Anybody ever hear of a company using CES to announce a firmware upgrade?
pepar is offline  
post #183 of 216 Old 01-07-2009, 08:11 PM
AVS Club Gold
 
HogPilot's Avatar
 
Join Date: Jun 2006
Location: Good Ol' US of A
Posts: 2,870
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 19
Quote:
Originally Posted by pepar View Post

Anybody ever hear of a company using CES to announce a firmware upgrade?

Hey now, firmware upgrades are a big deal for DVDO - they only happen once, maybe twice a year for a given product, so you better change your attitude there mister!

There are 10 types of people: those who understand binary, and those who don't.

HogPilot is online now  
post #184 of 216 Old 01-07-2009, 10:26 PM
Member
 
John Bennett's Avatar
 
Join Date: Sep 2001
Location: Gilbert, Arizona
Posts: 34
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by pepar View Post

Anybody ever hear of a company using CES to announce a firmware upgrade?

Not one with features that actually exist yet, no...

--John
John Bennett is offline  
post #185 of 216 Old 01-08-2009, 05:46 AM
Wireless member
 
pepar's Avatar
 
Join Date: Jul 2002
Location: Quintana Roo ... in my mind
Posts: 24,932
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 30 Post(s)
Liked: 131
Quote:
Originally Posted by John Bennett View Post

Not one with features that actually exist yet, no...

--John

well, the suspense can't last much longer.
pepar is offline  
post #186 of 216 Old 01-09-2009, 02:04 PM
AVS Special Member
 
SJHT's Avatar
 
Join Date: May 2002
Posts: 1,926
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Anything from CES?
SJHT is offline  
post #187 of 216 Old 01-10-2009, 10:10 AM
AVS Addicted Member
 
Gary Murrell's Avatar
 
Join Date: Jul 2003
Location: Kentucky
Posts: 10,927
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by HogPilot View Post

Hey now, firmware upgrades are a big deal for DVDO - they only happen once, maybe twice a year for a given product, so you better change your attitude there mister!

before the edge was in development and released this was not entirely accurate Hog

they are not Lumagen though, that is for sure

-Gary
Gary Murrell is offline  
post #188 of 216 Old 01-10-2009, 10:16 AM
AVS Club Gold
 
jackox's Avatar
 
Join Date: Jan 2003
Location: France
Posts: 633
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
You have work to do Gary !
jackox is offline  
post #189 of 216 Old 01-10-2009, 12:43 PM
AVS Club Gold
 
HogPilot's Avatar
 
Join Date: Jun 2006
Location: Good Ol' US of A
Posts: 2,870
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 19
Quote:
Originally Posted by Gary Murrell View Post

before the edge was in development and released this was not entirely accurate Hog

they are not Lumagen though, that is for sure

-Gary

VP50 users like myself waited for a firmware update for a significant period of time when there were known issues with the unit's 1080p24 conversion as well as several other items. DVDO chose to work on the VP50Pro in lieu of bringing the VP50 up to advertised spec. This seems to have repeated itself now with the VP50Pro's firmware being put off while the Edge was under development. Whether or not that is the whole story is irrelevant - DVDO has demonstrated a pattern to its customers that has kept me and others from buying another one of their products. Now I'm a Lumagen owner and don't regret paying a premium for it one bit.

And my comment was partially tongue and cheek, hence the wink.

There are 10 types of people: those who understand binary, and those who don't.

HogPilot is online now  
post #190 of 216 Old 01-11-2009, 02:14 PM - Thread Starter
Newbie
 
AVFORME's Avatar
 
Join Date: Dec 2006
Posts: 12
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
[quote=fastl;15479218]

...another area of concern is bit errors, bit errors exist in a HDMI signal and often go undected...

This sounds like "audiophile logic" and reasoning. While it is true that bit errors -can- exist, it isn't necessarily true that they -do- exist. Furthermore, even if they exist in systems that you have dealt with, the number of systems that you deal with doesn't constitute a statistically significant sampling size to make the generalizations that you are implying. If you have access to an HDMI protocol analyzer that can show these types of anomalies, we'd like to see some screen shots showing the actualities.
QUOTE]

The fact is that there are surely bit errors (if we are talking about HDMI), it is just the number of bit errors that can be debated.

I don't intend to disparage anyone involved in the development of the HDMI standard, but I do disparage the final quality of the standard and its intent, all done by commitee. My understanding is that the standard was sort of an invention of the industry to quickly apease the content creators/providers (lawyers) so that the content could be protected.

HDMI/HDCP is what they came up with. The problem is that the standard was not, ultimately about the best picture quality, it was about content protection and cost. You see HDMI is not a robust protocol, it contains no provision for error detection or correction as do modern digital data protocols. In fact, if what I have read is correct, errors are simply passed through as spurious data. Therefore, if the data contains enough errors, it will degrade the final picture in various ways.

HDMI was about cost (and getting something approved quickly to protect content) so the addition of error detection and correction, which in my opinion would have made HDMI an interface for the ages, was not considered a priority. It would have taken longer to agree on a standard and the HDMI interfaces would have been more expensive. So, without error detection and correction, and without a really strong well defined standard, there are most certainly problems with data accuracy.

Even the connectors were not well thought through. Does it make any sense that a single cable carrying high def video AND audio use such weak and flimsy connectors and sockets that seem to fall out if slightly jostled. I know these HDMI cables work really well on articulated mounts....NOT!

But I cannot say that analog is the answer, all I'm saying is that some of the digital standards are somewhat weak. Also, SDI does not suffer the engineering confusion of including a content protection scheme. And it has to live up to the VERY high standard of the broadcast industry. (Although sometimes I think the industry needs to see their work on regular Joe's Sony LCD, here I'll make more friends: I hate the current LCDs compared to plasma's)

I have been considering using SDI sources, but not because I would notice the .05% difference. But, because I hate content protection, I want to store my movies and content on my computer in full high def. for convienence (maybe use a Black Magic card and some other goodies to get there).

This information is out there on the web, and in fact people have gone to the trouble to measure the signal degradation and resulting errors of various types of cables or certain distances. In addition, HDMI interfaces do not always play well together further complicating the issue.

Sorry I don't have time to look up those links, but a little searching will yield you some info.

Just my opinion.
AVFORME is offline  
post #191 of 216 Old 01-11-2009, 03:16 PM
Wireless member
 
pepar's Avatar
 
Join Date: Jul 2002
Location: Quintana Roo ... in my mind
Posts: 24,932
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 30 Post(s)
Liked: 131
Quote:
Originally Posted by AVFORME View Post

. . In addition, HDMI interfaces do not always play well together further complicating the issue . .

Well, that pretty much *is* the issue. Handshake issues annoy, but incompatibility issues aggravate.
pepar is offline  
post #192 of 216 Old 01-11-2009, 05:49 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
... The fact is that there are surely bit errors (if we are talking about HDMI), it is just the number of bit errors that can be debated....

How many? How frequently? In how many systems? With what interconnect lengths? With what equipment? If you want to claim that it is a FACT, then prove it! There sure aren't any HDMI errors in my system. When video goes to black, that's all I see. If there were bit errors, I would see sparklies.

Incidently, you obviously don't know that much about SDI, if you think it handles bit errors better than HDMI. Although SDI includes a checksum feature that allows the -presence- of errors to be detected with the appropriate monitoring equipment, the checksum has no effect in reducing or eliminating the actual error. So, bit errors on SDI basically have the same effect on image quality as on HDMI. If you want to read the EDH status, you're looking at spending $7K upwards.
fastl is offline  
post #193 of 216 Old 01-12-2009, 05:24 AM
Newbie
 
u006852's Avatar
 
Join Date: Jul 2006
Posts: 9
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Back on topic,

During some recent comms with DVDO about a continuing HDMI handshaking problem I have, these comments were made.

I believe the compatibility issue can be addressed with firmware. But the main roadblock is that we don’t have access to these receivers in our lab.
I am not certain if the next firmware will address HDMI issues. I do know that it will include improvements with certain formats.
We are still working on CMS… it will not be ready for the next release.
We hope to have the next release very very soon.

Regards,

Ken Nguyen


I have become disillusioned with the product, it's bugs and DVDOs lack of interest in releasing fixes in a timely manner. This is not to mention new features such as CMS, something very desirable in a high end product like this.
u006852 is offline  
post #194 of 216 Old 01-17-2009, 03:43 PM - Thread Starter
Newbie
 
AVFORME's Avatar
 
Join Date: Dec 2006
Posts: 12
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by fastl View Post

... The fact is that there are surely bit errors (if we are talking about HDMI), it is just the number of bit errors that can be debated....

How many? How frequently? In how many systems? With what interconnect lengths? With what equipment? If you want to claim that it is a FACT, then prove it! There sure aren't any HDMI errors in my system. When video goes to black, that's all I see. If there were bit errors, I would see sparklies.

Incidently, you obviously don't know that much about SDI, if you think it handles bit errors better than HDMI. Although SDI includes a checksum feature that allows the -presence- of errors to be detected with the appropriate monitoring equipment, the checksum has no effect in reducing or eliminating the actual error. So, bit errors on SDI basically have the same effect on image quality as on HDMI. If you want to read the EDH status, you're looking at spending $7K upwards.

fastl, I appreciate your passion and I don't want to get personal, but cool your jets. You may very well not have any visible problems, although the data errors may not show up as "sparkles" as is commonly assumed. In any case, the weaknesses of HDMI are known and the problems that manuafacturers are having with interface compatibility are acknowledged (witness post #193 above).

The number and effect of HDMI errors are dependent on the variables and that is the problem. Cable length and quality seem to be a major factor. But to say that there are no errors...

You seem to believe that HDMI is the very best solution, and that is fine I don't care. And it is a convienent way to connect devices, it is simply a fact that data transmission of this type does not occur without errors 100% of the time, and that is why error detection and correction is important. If you don't believe me talk to a computer engineer. The qualitative effect on video performance is not what you were arguing originally, but if you want to go down that path fine. For some people there will be a loss of quality. Will Joe Sony LCD recongnize it if there is? Maybe not, and that is what the HDMI people are banking on IMHO.

As far as SDI goes it was very clear in my post that the reason I would choose SDI over HDMI is primarily because I don't like the content protection. I don't like the HDMI standard either even though I use it.

I have not really studied the SDI interface from the standpoint of error detection and correction. However, SDI uses CRC error detection AND correction methodology. Effectiveness is dependent on the implementation however.

Here are some FACTS about SDI:
Line counter and CRC
In the high definition serial digital interface (and in dual-link HD), additional check words are provided to increase the robustness of the interface. In these formats, the four samples immediately following the EAV packets (but not the SAV packets) contain a cyclic redundancy check field, and a line count indicator. The CRC field provides a CRC of the preceding line (CRCs are computed independently for the Y and C streams), and can be used to detect bit errors in the interface. The line count field indicates the line number of the current line.

The CRC and line counts are not provided in the SD and ED interfaces. Instead, a special ancillary data packet known as an EDH packet may be optionally used to provide a CRC check on the data.


And here are some FACTS about CRC:
Cyclic Redundancy Checks
More complex error detection (and correction) methods make use of the properties of finite fields and polynomials over such fields.

The cyclic redundancy check considers a block of data as the coefficients to a polynomial and then divides by a fixed, predetermined polynomial. The coefficients of the result of the division is taken as the redundant data bits, the CRC.

On reception, one can recompute the CRC from the payload bits and compare this with the CRC that was received. A mismatch indicates that an error occurred.


Hamming distance based checks (This indicates the location of the errant bit)
If we want to detect d bit errors in an n bit word we can map every n bit word into a bigger n+d+1 bit word so that the minimum Hamming distance between each valid mapping is d+1. This way, if one receives a n+d+1 word that doesn't match any word in the mapping (with a Hamming distance x <= d+1 from any word in the mapping) it can successfully detect it as an errored word. Even more, d or fewer errors will never transform a valid word into another, because the Hamming distance between each valid word is at least d+1, and such errors only lead to invalid words that are detected correctly. Given a stream of m*n bits, we can detect x <= d bit errors successfully using the above method on every n bit word. In fact, we can detect a maximum of m*d errors if every n word is transmitted with maximum d errors.

OK, now you know that SDI uses CRC data error detection and correction. CRC is used to ensure data integrity in Information Technology data storage and transmission applications. This is a far superior way to ensure data integrity compared to HDMI.

Here are two links that were sent to me that sort of sum up the situation. I don't have any more time to waste on this debate, but this might be of interest:
http://www.bluejeanscable.com/articl...-with-hdmi.htm
http://www.bluejeanscable.com/articl...icomponent.htm
AVFORME is offline  
post #195 of 216 Old 01-17-2009, 05:25 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Part of what you said was:

... You see HDMI is not a robust protocol, it contains no provision for error detection or correction as do modern digital data protocols. In fact, if what I have read is correct, errors are simply passed through as spurious data...

Well, you didn't read correctly, because you seem to think that SDI has the ability to correct transmission errors (making it better than the HDMI). In fact, it passes errors through uncorrected. There is no redundant information included in a standard SDI data stream to perform error correction. Error -detection- does not imply error -correction-.

Because SDI uses bit scrambling to increase symbol transition density, it will actually increase the number of bit errors accumulated along a transmission path, as the signal ripples through the descrambling stage at the receiving end. Unless you are using professional equipment that has the capability of reading the embedded error checking code, you won't know if your SDI link is making errors or not. This would apply to simple home theater setups like modded DVD players into VP50pro's.

You also said:

... You seem to believe that HDMI is the very best solution, and that is fine I don't care...

Well, if you don't care than why did you bother responding to what I posted? I don't think that HDMI is the very best solution, nor do I think it is the worst, either. I don't have any bit error problems in my HDMI connections and neither do a lot of other people. If bit errors are being made in the data path, then you would most readily see them on a full black screen as sparklies. Usually, when there is an "HDMI problem" the interface just doesn,t work properly and it is a moot discussion as to how many bit errors there are.
fastl is offline  
post #196 of 216 Old 01-18-2009, 10:17 AM
AVS Special Member
 
Glimmie's Avatar
 
Join Date: Sep 2000
Location: Los Angeles, CA
Posts: 7,804
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 49 Post(s)
Liked: 170
The problem with HDMI and DVI is they they are not true serial interfaces. They are PARALLEL interfaces. Yes, the data streams are serial but there are three of them plus a clock. The skewing of these streams is what makes long distance transmission so difficult. SDI is a true serial stream. The data scrambling ensures the clock can be recovered by providing a fairly even mix of ones and zeros.

Now there is one advantage to HDMI/DVI. I can move more data over three links than I can over a single link.

A bit of history... Early SD digital television systems circa 1985-1992 were parallel interfaces. That is 11 pairs, 10bits plus a clock. Early HD interfaces were even worse, 21 pairs - 10bits Y. 10bits, C, and a clock pair.

Glimmie's HT Page
Being redone - comming soon!

Glimmie is online now  
post #197 of 216 Old 01-18-2009, 10:36 AM
AVS Addicted Member
 
Gary Murrell's Avatar
 
Join Date: Jul 2003
Location: Kentucky
Posts: 10,927
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
haven't you guys moved past this yet?

lets hear about CMS for VP50pro



-Gary
Gary Murrell is offline  
post #198 of 216 Old 01-18-2009, 02:55 PM
AVS Club Gold
 
jackox's Avatar
 
Join Date: Jan 2003
Location: France
Posts: 633
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
As far as I know no current CMS works good enough to get a perfect gamut.
So far Lumagen's seems to be the best around but not perfect though.

(HD750 / RS20 is not perfect, CII's I dunno, said to not so good ...)

Lets hope DVDO will get use the ultimate easy to use CMS !
We'll see about that ... not soon it seems.
jackox is offline  
post #199 of 216 Old 01-24-2009, 07:45 PM
AVS Special Member
 
TomHuffman's Avatar
 
Join Date: Jan 2003
Location: Springfield, MO
Posts: 6,357
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 204
Quote:
Originally Posted by jackox View Post

(HD750 / RS20 is not perfect, CII's I dunno, said to not so good ...)

That is a major understatement. The HD750 / RS20 CMS is not only not perfect, it is darn near useless. Some of the controls lack sufficient range of adjustment, others have profound interactive affects with others, and ANY use of the CMS results in pretty severe non-linear results when you start looking at different levels of stimulus.

Tom Huffman
ChromaPure Software/AccuPel Video Signal Generators
ISF/THX Calibrations
Springfield, MO

TomHuffman is offline  
post #200 of 216 Old 01-27-2009, 05:37 PM - Thread Starter
Newbie
 
AVFORME's Avatar
 
Join Date: Dec 2006
Posts: 12
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I suggest you seek comfort elsewhere.
AVFORME is offline  
post #201 of 216 Old 01-27-2009, 06:35 PM - Thread Starter
Newbie
 
AVFORME's Avatar
 
Join Date: Dec 2006
Posts: 12
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by fastl View Post

Part of what you said was:

... You see HDMI is not a robust protocol, it contains no provision for error detection or correction as do modern digital data protocols. In fact, if what I have read is correct, errors are simply passed through as spurious data...

Well, you didn't read correctly, because you seem to think that SDI has the ability to correct transmission errors (making it better than the HDMI). In fact, it passes errors through uncorrected. There is no redundant information included in a standard SDI data stream to perform error correction. Error -detection- does not imply error -correction-.

Because SDI uses bit scrambling to increase symbol transition density, it will actually increase the number of bit errors accumulated along a transmission path, as the signal ripples through the descrambling stage at the receiving end. Unless you are using professional equipment that has the capability of reading the embedded error checking code, you won't know if your SDI link is making errors or not. This would apply to simple home theater setups like modded DVD players into VP50pro's.

You also said:

... You seem to believe that HDMI is the very best solution, and that is fine I don't care...

Well, if you don't care than why did you bother responding to what I posted? I don't think that HDMI is the very best solution, nor do I think it is the worst, either. I don't have any bit error problems in my HDMI connections and neither do a lot of other people. If bit errors are being made in the data path, then you would most readily see them on a full black screen as sparklies. Usually, when there is an "HDMI problem" the interface just doesn,t work properly and it is a moot discussion as to how many bit errors there are.

-------------
First, you said that SDI uses a "Checksum" this is very different than a CRC and MAY REQUIRE "redundant information". A CRC is a diferent animal and does imply error correction. The beauty and elegance of CRC and the Hamming code is that you do not need "redundant information" to correct the errant word, all the information is included in the CRC. It also makes no difference how the data is coded in the word it will still be corrected.

So, since you like to cast dispersions at just about everyone who disagrees with you, I'll tell you that you have no idea what you are talking about with respect to the purpose and utilization of CRCs and apparently high def. SDI.

In any case, the algorithm for calculating CRCs is very fast, is usually performed in hardware, and is used extensively, as mentioned before, in information technology.

In addition, you mentioned that the SDI standard uses "bit scrambling" I don't think you know what this means, but I'd be happy to look up the standard in even more detail and explain it to you if you like.

I frankly don't like aguing with people by written word since so many things can be misunderstood, but some people just demand it.

Cheers!
AVFORME is offline  
post #202 of 216 Old 01-27-2009, 07:45 PM
Advanced Member
 
Dave G's Avatar
 
Join Date: Aug 2001
Location: Madison, WI
Posts: 949
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by TomHuffman View Post

That is a major understatement. The HD750 / RS20 CMS is not only not perfect, it is darn near useless. Some of the controls lack sufficient range of adjustment, others have profound interactive affects with others, and ANY use of the CMS results in pretty severe non-linear results when you start looking at different levels of stimulus.

Come on now - how do you really feel about it?
Dave G is offline  
post #203 of 216 Old 01-27-2009, 07:57 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
AVFORME, thanks for the dis-information.
fastl is offline  
post #204 of 216 Old 01-27-2009, 08:37 PM
Advanced Member
 
Dave G's Avatar
 
Join Date: Aug 2001
Location: Madison, WI
Posts: 949
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Just did some reading on Wikipedia.

For SD-SDI, the only error detection mechanism mentioned is EDH (error detection and handling) which is NOT an error correction mechanism. It's optional, i.e. not necessarily implemented.

HD-SDI on the other hand includes mandatory CRCs, which "can be used to detect bit errors in the interface". About CRCs, wikipedia says: "CRCs can be relied upon to verify integrity but not correctness."

Hmmm.
Dave G is offline  
post #205 of 216 Old 01-28-2009, 07:06 AM
Wireless member
 
pepar's Avatar
 
Join Date: Jul 2002
Location: Quintana Roo ... in my mind
Posts: 24,932
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 30 Post(s)
Liked: 131
Quote:
Originally Posted by Dave G View Post

Just did some reading on Wikipedia.

For SD-SDI, the only error detection mechanism mentioned is EDH (error detection and handling) which is NOT an error correction mechanism. It's optional, i.e. not necessarily implemented.

HD-SDI on the other hand includes mandatory CRCs, which "can be used to detect bit errors in the interface". About CRCs, wikipedia says: "CRCs can be relied upon to verify integrity but not correctness."

Hmmm.

Temporal "correctness?"
pepar is offline  
post #206 of 216 Old 01-28-2009, 12:43 PM
AVS Special Member
 
Glimmie's Avatar
 
Join Date: Sep 2000
Location: Los Angeles, CA
Posts: 7,804
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 49 Post(s)
Liked: 170
Quote:
Originally Posted by AVFORME View Post

-------------
In addition, you mentioned that the SDI standard uses "bit scrambling"

I'll try and make an IT analogy. A basic RS232 serial connection expects the transmitter and receiver clock frequency to be within 4%. That's fine even up to 115Kbs. That won't work at 270mbs and hardly at 1.5gbs*. So some means of transmitting the clock along with the data must be found. You could send the clock as a seperate wire such as done with DVI and HDMI but now you have more than a single connection and the envitable timing skew over long legnths of cable.

The clock can in fact be recovered from the data stream it's self. Such as with SMPTE time code but thats at 2400bps. PLLs can drift a long time at such a low data rate. For SDI a 27mhz PLL cannot drift very long before it loses framing with the data. The problem is obviously greatly compounded at 1.5gbs.The drift times are due to long periods of ones or zeros in the data stream caused by the data it's self. So we scramble the data to provide a near 50/50 mix of ones and zeros. In essence that data stream looks like a clock signal. Now it's not exactly an even mix of ones and zeros but that's where the PLL comes in to ride out the uneven mix. But it can only go so far. There rae even test signals called "pathological signals" the delibertly stress the PLLs by producing long strigs of ones and zeros to aid in system QOS testing.

This scrambling is a published algorithm and has nothing to do wiith any copy protection schemes.

*Well I guess you could install Cesium oscillators in every SDI device and they would stay on ferquency for a few months! Money can solve any problem!

Glimmie's HT Page
Being redone - comming soon!

Glimmie is online now  
post #207 of 216 Old 01-28-2009, 04:48 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
...Temporal "correctness?....No, political correctness. I've been trying to avoid rubbing are "expert's" nose in it but, since he already has stuck his foot in his mouth, here goes:

From "The Art of Digital Video" by John Watkinson, ISBN 978-0-240-52005-6

In chapter 8 on page 503, Basic Error Correction (which describes CRC technique): "Digital Interfaces such as SDI (see Chapter 10) do not employ error correction because the buildup of coding delays in large production systems is unacceptable."

From "A Guide to Standard and High-Definition Video Measurements", Tektronix

On page 9, The Digital Video Interface: "The deserializer unscrambles the data using an algorithm complementary to the encoder's scrambling algorithm and outputs a 10-bit data stream at 27 Mb/s. The embedded checksum is extracted by the receiver and compared with a new checksum produced from the received data and error is [reported] and an appropriate flag added to the data stream."

Note the use of terminology such as "checksum" and "scrambling". The Tektronix publication is available from the Tek website as a pdf and the Watkinson book you have to buy. Both highly recommended to the true video afficianado.

I believe SD-SDI embeds a checksum per field whereas HD-SDI embeds a checksum per frame as well as a checksum in each horz line. What truly amazes me is the way some people fact check their highly warped opinions before posting them as facts, here on the website.
fastl is offline  
post #208 of 216 Old 01-28-2009, 05:31 PM
Advanced Member
 
Dave G's Avatar
 
Join Date: Aug 2001
Location: Madison, WI
Posts: 949
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by fastl View Post

What truly amazes me is the way some people fact check their highly warped opinions before posting them as facts, here on the website.

Have to agree. I do love AVS but you have to be careful. Just because someone's using a couple big words and sounds like they know what they're talking about...

I don't know much about SDI, but this was the red flag for me:

Quote:


A CRC is a diferent animal and does imply error correction.

This is completely, absolutely, 100% wrong. You'd think in the age of google and wikipedia a little fact checking wouldn't be too hard to do.

For the curious: some exotic CRC implementations allow error correction, but in limited fashion (mostly limited to 1 bit errors). However, CRC is first and foremost an error detection mechanism - not correction.

In fact, if you read up wikipedia's entries on SDI/HDSDI, the error detection protocols are there so that defective devices (camera and such) can be spotted and replaced quickly. NOT so that error correction can take place. Fascinating stuff.
Dave G is offline  
post #209 of 216 Old 01-29-2009, 04:28 PM
Advanced Member
 
fastl's Avatar
 
Join Date: Sep 2007
Location: Boston
Posts: 571
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Primary reason that I was belaboring the point is because SDI had been promoted as being superior to DVI/HDMI because of its error correction - not true. To be fair to our "SDI expert", there is error correction utilized in the SDI transmission path, but only in the line synchronization header. The video data is NOT error corrected, which was the point I was trying to make.
fastl is offline  
post #210 of 216 Old 01-29-2009, 05:02 PM
Member
 
Christopher J's Avatar
 
Join Date: Sep 2006
Posts: 34
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
How in the heck did we go from CMS to issues over DVI/HDMI/SDI?

Is it because there is little more to say about CMS?
Christopher J is offline  
Reply Video Processors

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off