Not sure why this is relevant; I am well aware of the NTSC specs, why
59.94 was used and all of the problems it creates.
Apparently nobody in this thread fully understand the problem.
Drop frame time code is, as John described in great detail, a way to
provide a meaningful nomenclature for editing of video sources that
are taken at a rate that is just shy of the integer values - e.g.
59.94 as opposed to 60. These sources must also be played out at this
non integer rate for NTSC to work properly, and this is the REAL crux
of the problem.
If we encoded a 60 fps stream using MPEG-2, and played it out at 60
fps, it would be "out of sync" immediately - that is, the second
frame would come too soon for an NTSC receiver to lock up properly.
You could not simply drop one frame out of 1001. So it was far easier
to stay with the legacy frame rates, as every broadcast facility uses
a sync generator that locks everything up to 59.94.
If we had switched to 60 fps for DTV, it would be necessary to have a
conversion box to feed the NTSC transmitter at 59.94. In essence this
box would need a frame buffer to slightly slow down the play out of
the 60 fps source, dropping one frame out of 1001; likewise, a DTV
set-top box for legacy receivers would need to have the same kind of
buffer to play out the incoming frames a bit slower , dropping a
frame every ~16.8 seconds.
This very small difference in frame rates makes more desirable
techniques such as motion compensated frame prediction difficult, if
not completely unworkable. Large differences between the source rate
and the playout rate make motion compensated prediction more
practical.
The good news is that this is a slight slowdown, not an accelerated
play out, so the MPEG frames would always arrive before they were
needed. Essentially the standard MPEG decoder buffers would feed
another buffer that would operate asynchronously with the 60fps
source, coming back into sync after 1001 frames, when one would be
dropped. This is quite feasible with the technology available today.
The only artifact would be the slight temporal jump for legacy
viewers when a frame was dropped.
Now, what would be different if we had moved to the 24/36/72 frame rate family?
For 24 fps there would be little difference. The frames would sill be
coming in slightly faster than needed for 59.94 play out with 3:2
pull-up. And a fancier box with motion compensated frame prediction
could deal with the 59.94 issue quite easily as there is a big
difference between 24 and 59.94.
For 36 fps it would be necessary to drop ~ 6 frames per second. Again
the frames would come in faster than needed so this would not be a
big problem. And for motion compensated frame prediction the
difference between 36 and 59.94 would be easy to deal with. Cheap
STBs would drop ~ 6 frames per second increasing the frequency of
temporal glitches, but this would only be the case for legacy
receivers.
The situation for 72 fps would be similar to 36 fps, but 12 frames
per second would need to be dropped, causing a temporal glitch every
~5 seconds. Once again, this would only be the case for legacy
receivers. With 24 frame GOPS it would be relatively easy to drop
four B-frames; motion compensated frame prediction would be possible,
but more computationally intensive.
So once again Bert, thanks for giving this proposal the "incredible"
designation!
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.
