[opendtv] Re: Interlace Artifacts
- From: "Tom McMahon" <TLM@xxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 12 Jan 2005 07:49:13 -0800
Sorry for being obtuse, Ron, I've been on too many airplanes....
1) I think the fact that Fox is broadcasting 480P at 10 Mbps a good thing.
Heck, I would do my program at the highest bitrate
possible if nothing else was using the channel. Why not? Professional VTRs
run over a hundred Mbits/sec - why shouldn't a consumer
get that. There is no police forces that says SDTV needs to be low bit rate.
Give 'em what the pros get (within the emission
channel constraints)!
2) Regarding sample-point, I meant a sample point in time. In other words the
entire frame was captured in an instant, as opposed
to what a scanning or interlaced camera would do. Some call this single time
sample "splat-scan". Or, and Emeril LaGasse would
say: BAM!
Now, there are issues with this of course, and film isn't splat-scan because
there is shutter angle and light integration time. So
there are even further variations on the theme. But interlaced scanning during
acquisition is definitely off in it's own dimension.
The upper left pixel gets sampled way earlier than the lower right pixel.
3) Regarding H.264, see: http://fastvdo.com/spie04/spie04-h264OverviewPaper.pdf
for a high level overview. Even then, a problem
with coding interlace is that the vertical frequencies can be higher due to the
non-uniform spatio-temporal mix. There is more
residue after the transform. Sure, the standards have ways of mitigating it,
but...
4) First there was Microsoft's streaming media, eventually we had Windows Media
9, then Microsoft subsetted WMv9 and pushed it into
SMPTE in an attempt to formalize the bitstream and decoder so that people could
make interoperable products without Microsoft help
or IP. During the subsetting and pushing process Microsoft added a new Profile
with interlace tools that didn't exist before -
"Advanced Profile". There was some thought given to interlace before that but
for real broadcast apps they needed to flesh this out
if they were ever to be taken seriously in DVB and ATSC for the broadcast
world. The transmogrified stuff became VC-9 and then it
was renamed VC-1 so that there would be no association with a proprietary
product line (WMv9). This new SMPTE thing is not a bad
thing, but neither is it done yet. They are still finding bugs in the codec
and there is a great lack of conformance (test) streams
generated by anyone other than Microsoft. This SMPTE process *will* finish at
some point but it is important to note that it ain't
done yet. Neither is the licensing for VC-1. So even if you build a VC-1
product you're totally exposed on what patents you tread
on and who you have to pay royalties to.
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Ron Economos
Sent: Wednesday, January 12, 2005 6:09 AM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: Interlace Artifacts
Comments in-line.
Tom McMahon wrote:
>This discussion treads on the usual apples and oranges problem. How do
>you comnpare these things when the parameters associated with the
>acquisition devices, the encoders, the storage media, the transmission media,
>the decoders and the display devices are all
different?
>
>
Agree that it's very much apples and oranges. I guess the reason I responded
was that most FOX 480p video bitstreams I've analyzed
(when they were doing 480p) were coded at around 10 Mbps. Quite a bit higher
than your typical 480i bitstream.
>A key concept in this is whether or not the original image was captured
>coherently as single sample point. In other words, whether or not it was
>"sampled" as a two dimensional array of image values or
whether it was scanned out as a sequence of intensity values.
>
>
To use a Tom Barry phrase, I couldn't parse that sentence. Can you give me
another clue as to what you were getting at?
>Interlace has many dimensions. (Most of them bad.)
>
>
I get the feeling that folks on this list consider the interlace tools in
MPEG-2 (field DCT, field predictions, alternate scan) to
be not adequate. In another post you said:
It is interesting to note that H.264/AVC has much improved interlace tools that
help mitigate the gas-guzzling problem, but improved
codec performance for the transmission channel does nothing for the display
problem.
As an old MPEG-2 guy, I haven't quite wrapped my head around
H.264 yet. Can you describe how the H.264 interlace tools have improved over
MPEG-2? I've also been told that the interlace tools in
VC-1 are a complete afterthought.
Ron
>-----Original Message-----
>From: opendtv-bounce@xxxxxxxxxxxxx
>[mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Birkmaier
>Sent: Tuesday, January 11, 2005 7:51 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Interlace Artifacts
>
>At 3:12 PM -0800 1/11/05, Ron Economos wrote:
>
>
>>480p@60 uses the same bitrate or less as 480i@30? That would be a very
>>magical MPEG-2 encoder.
>>
>>Ron
>>
>>
>
>I can point you to many tests done in the '90s that proved this
>exactly. But there is one caveat. Most of the tests used source with
>equal information content then measured the SNR at the output of the decoder.
>Thus, comparing an SDTV source with the same source
deinterlaced and coded as 480P the 480P signal would have a higher SNR than
the 480i encoding.
>
>As a 480P signal can carry more information, it is possible that you
>may need more bits to encode the source with the same SNR as the
>information content increases. I beleive that NHK was covering live
>sports in Japan with native 480P cameras with an emission encoded bitrate of
>about 8 Mbps. This compares with about 6-8 Mbps for
480i source, but the 480P was of significantly higher quality.
>
>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:
