[mythtv] H.264 field/frame counting revisited

John P Poet jppoet at gmail.com
Mon Oct 13 17:18:32 UTC 2008


With encouragement from Janne Grunau, I have started re-writing
h264utils, which is used to decode H.264 streams during the recording
process.  I have been using the "ITU-T Rec. H.264" document to
understand the "correct" way of interpreting the H.264 stream:

http://www.itu.int/rec/T-REC-H.264/e

That document describes the various flags in the data stream which
should be used to detect a new "coded slice".  Both ffmpeg and
avidemux follow the document, and "index" based on these "codes
slices".  One of the flags used to indicate a new "coded slice" is the
"bottom field flag".  This means that according to the spec, there
could be twice as many "indexes" for interlaced video compared to
progressive.

Before a couple of months ago, Myth followed the same steps, and would
also create an index for each field in the stream, if the "bottom
field falg" was present.  There was a problem during playback,
however, because Myth only expected "frames" to be indexed, not
fields, so the recording would show double length.  At that time, I
went in and modified the code to only create an index for the "top
field", and skip the "bottom field", which fixed the playback issue.

The problem with only indexing the "top field", though, is that Myth's
"cut list" cannot be used as input to other programs, such as
avidemux.  It also does not, technically, follow the spec.

So, while re-writing h264utils, do I "follow the spec", or do I
continue to leave out indexes for the "bottom field"?  If we go back
to including the indexes for the bottom field, how do we solve the
playback issue?

John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


More information about the mythtv-dev mailing list