[FFmpeg-devel] Bugreport: mpegts-demuxer gives wrong pts/dts with avchd files

Michael Niedermayer michaelni
Fri Feb 29 16:28:27 CET 2008


On Fri, Feb 29, 2008 at 02:39:01PM -0000, M?ns Rullg?rd wrote:
> 
> Michael Niedermayer wrote:
> > On Fri, Feb 29, 2008 at 09:03:17AM +0100, Thorsten Jordan wrote:
> >> Michael Niedermayer schrieb:
> >> > On Thu, Feb 28, 2008 at 04:34:02PM +0100, Thorsten Jordan wrote:
> >> >> Thorsten Jordan schrieb:
> >> >>> Thorsten Jordan schrieb:
> >> >>>> M?ns Rullg?rd schrieb:
> >> >>>>> Thorsten Jordan <tjordan at macrosystem.de> writes:
> >> [...]
> >> >> Michael, why did you revert it? Couldn't the current utils.c a problem
> >> >> for mpeg2 too?
> >> >
> >> > For mpeg2 either of the 2 solutions (12156 and svn) solves the problem, for
> >> > H.264 neither works.
> >> >
> >> > The current mpeg2 parser does not return fields, but always merges 2 fields
> >> > into frames (and field picture mpeg2 is rare, interlaced frames are more
> >> > common). Either way H.264 does not gurantee paired fields, here frames and
> >> > fields can be mixed arbitrarily thus no merging will work.
> >> >
> >> > The second solution depended on mpeg2 sytle IPB reordering. H.264 allows much
> >> > more flexible frame orderings (b pyramid for example) the code would not have
> >> > been able to handle that at all.
> >> >
> >> > The h.264 parser will have to parse slice headers and SEI messages as far as
> >> > i understand.
> >> >
> >> > If you are interrested in fixing this, download te H.264 and H.222 specs
> >> > and read
> >> > 2.14 Carriage of ITU-T Rec. H.264 | ISO/IEC 14496-10 video
> >> > and
> >> > 2.7 Restrictions on the multiplexed stream semantics
> >> >
> >> > Also you will likely have to deal with streams being non compliant to the
> >> > AVC in mpeg restrictions, i doubt everyone conforms to them strictly.
> >
> >> well the particular problem arises with AVCHD material that uses a
> >> rather simple scheme (very mpeg2-like), 12 frames per GOP, usual IBB/PBB
> >> "packs", every frame consists of two fields etc.
> >> At least for such material a simple approach would work, extending the
> >> h264 parser to decode slice headers etc. I did that for some other
> >> project already and know the h264-specs so far, and such code already
> >> exists in h264.c already.
> >> The question is, if the h264 parser would be extended with that parsing
> >> (no fancy B-pyramid stuff) plus bringing back the changes of rev 12156
> >> of utils.c or similar code, would that be accepted into ffmpeg? It would
> >> solve the AVCHD problems, but maybe not all h264 parsing cases as you noted.
> >> I suppose the code in h264.c doing reference frame computing is needed
> >> for a fully correct parser and that code is complex.
> >
> > I am only interrested in spec compliant solutions. Also note IIRC
> > Carl Eugen Hoyos wanted to work on the h264 timestamp problem as well, maybe
> > you should contact him to avoid duplicate work.
> > And if someone (mans?) wants we can add a if(!h264) over the current timestamp
> > calculation code so it doesnt return wrong timestamps. But stream copy or
> 
> If correct timestamps can't be guaranteed, then IMHO returning no timestamp
> is better than an incorrect value.  A player can easily interpolate
> missing timestamps, but has a much harder time if none of the timestamps
> can be trusted.  A flag indicating computed (and possibly incorrect)
> timestamps might be an option too.

We could add a flag, we could also add a flag to disable the whole timestamp
computation, but i think you overestimate the players ability to make more
sense of things than the code in lavf. Also id like to repeat that the 
ts computation in lavf is not guessing but trying hard to set exact
timestamps. It will for example buffer packets until the first timestamp and
then use frame durations from a parser to fill in the previous timestamps.

In case of h.264 this all breaks down as the code assumes frames or paired
fields not H264 random frame field mix, and no complex frame reordering,
only mpeg2 IPB style.


> 
> > decoding, the timestamp calculation is needed or some frames will not have
> > timestamps at all. And thats fatal for variable framerate material.
> 
> Variable framerate material would have to have timestamps on every frame
> in the container, or nobody will be able to figure out the missing values.

Sadly the specs do not require this. Which is amongth other things why we
have this problem with h.264.
to quote H.222:
-----
The following applies to AVC access units in an AVC video stream carried in an ITU-T Rec. H.222.0 |
ISO/IEC 13818-1 stream. For each AVC access unit that does not represent an AVC 24-hour picture, a PES header with
a coded PTS and, if applicable, DTS value shall be provided, unless all conditions expressed under one of the following
four bullets are true:
           *    In the AVC video sequence the following SEI messages are present, as signalled by VUI parameters:
                a)   picture timing SEI messages providing the cpb_removal_delay and the dpb_output_delay
                     parameters; and
                b)   buffering period SEI messages providing                       the    initial_cpb_removal_delay    and   the
                     initial_cpb_removal_delay_offset parameters.
                    NOTE 2  When picture timing SEI messages are present in the AVC video sequence, then these messages are
                    present for each AVC access unit, as required by ITU-T Rec. H.264 | ISO/IEC 14496-10. When buffering period
                    SEI messages are present in the AVC video sequence, then these messages shall be present for each IDR access
                    unit and for each access unit that is associated with a recovery point SEI message, as required by ITU-T
                    Rec. H.264 | ISO/IEC 14496-10.
            *   An AVC timing and HRD descriptor is associated with the AVC video stream and in this descriptor the
                fixed_frame_rate_flag is set to '1' and the temporal_poc_flag is set to '1'.
            *   An AVC timing and HRD descriptor is associated with the AVC video stream and in this descriptor the
                fixed_frame_rate_flag is set to '1', the picture_to_display_conversion_flag is set to '1', the
                temporal_poc_flag is set to '0' and in the AVC video sequence picture timing SEI messages with the
                pic_struct field are present.
                    NOTE 3  In this specific case the pic_struct field is used to determine subsequent PTS values.
            *   An AVC timing and HRD descriptor is associated with the AVC video stream and in this descriptor the
                fixed_frame_rate_flag is set to '1' and the temporal_poc_flag is set to '0' and the
                picture_to_display_conversion_flag is set to '0'.
                    NOTE 4  In this case the POC information in the AVC video stream is used to determine the subsequent
                    PTS values.
-----
And note fixed_frame_rate_flag does not mean fixed frame rate, frame and
field doubling and trippling are still allowed.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080229/a5087fda/attachment.pgp>



More information about the ffmpeg-devel mailing list