[opendtv] Re: More Questions
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Sun, 20 Nov 2005 10:07:47 -0500
Perhaps padding is not the right term, but blanking is misleading as well.
The conventional approach with early digital interfaces was to
digitize the blanking intervals as well, so as to capture the rise
times at the transitions from active picture to blanking. As with
analog formats, the timing of these blanking intervals is equally
important to the timing for the active pictures for synchronous
operations.
From the info below that Ron posted, it is quite clear that the
number of "blanking" samples represents only the time until the next
active line info is delivered - this is critical when the 292M link
is used for synchronous (real-time) operation. But those blanking
samples do not contain any blanking information, but rather just null
values or padding until the next active line come along. The 292M
link can also be used without "blanking" to move more active image
samples through the link for asynchronous transfers such as file
downloads.
Blanking in digital formats is typically generated after the image is
reconstructed so that the samples can be delivered to the display
synchronously. There is little value in storing the bits in the
blanking intervals - all you need is a start of line and end of line
flag, which is what 292M uses.
Regards
Craig
At 3:11 AM -0800 11/19/05, Ron Economos wrote:
>Sorry, I meant to say "for every resolution/frame rate"
>
>1920x1080@30 = 2200 total samples per line, 280 blanking samples
>1920x1080@25 = 2640 total samples per line, 720 blanking samples
>1920x1080@24 = 2750 total samples per line, 830 blanking samples
>
>1280x720@60 = 1650 total sample per line, 370 blanking samples
>1280x720@50 = 1980 total sample per line, 700 blanking samples
>1280x720@30 = 3300 total sample per line, 2020 blanking samples
>1280x720@25 = 3960 total sample per line, 2680 blanking samples
>1280x720@24 = 4125 total sample per line, 2845 blanking samples
>
>Note that 720p@24 is an odd number of total samples per line, which can
>be a bit of a problem in 4:2:2.
>
>Also, an interface that runs at two different rates, 1.485 Gbps and
>1.485/1.001 Gbps, seems awfully video-centric to me.
>
>Ron
>
>Ron Economos wrote:
>
>>There's no "padding" in SMPTE 292M. For every resolution,
>>the amount of horizontal blanking changes.
>>
>>Ron
>>
>>Craig Birkmaier wrote:
>>
>>
>>
>>>Mark has already gone through the math for the two most demanding HD
>>>formats used in the ATSC system, but 292M can do many other tricks.
>>>In essence, 292M is one of the first SMPTE standards to decouple the
>>>transport from the payload. Earlier standards such as SMPTE-259 are
>>>synchronous digital transports including the blanking intervals and
>>>specific timing references that must occur at the right moment in
>>>time.
>>>
>>>With 292M we have moved into the real digital era, where the
>>>transport is just a big bit bucket that can carry anything that will
>>>fit. Thus you can also transport 720@30P, 720 @24P, 1080@30P,
>>>108@24P, by padding out the packets that are not used; or you could
>>>move them at 2X real time, or move virtually any digital file across
>>>the transport at ~1.5 Gbps. We also have many examples of using dual
>>>292M links to transport more information - for example some of the
>>>digital cinema cameras use dual links to transport 1920 x 1080 full
>>>bandwidth RGB signals to disk storage.
>>>
>>>Regards
>>>Craig
>>>
>>>
>
>
>
>----------------------------------------------------------------------
>You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
>- Using the UNSUBSCRIBE command in your user configuration settings
>at FreeLists.org
>
>- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the
>word unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
