[FFmpeg-devel] [PATCH] AVCHD/H.264 parser: determination of frame type, question about timestamps
Sun Feb 1 15:20:45 CET 2009
On Sun, Feb 01, 2009 at 10:51:20AM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
> > On Sun, Feb 01, 2009 at 01:17:24AM +0100, Ivan Schreter wrote:
> >> Michael Niedermayer wrote:
> >>> On Mon, Jan 26, 2009 at 08:42:17AM +0100, Ivan Schreter wrote:
> >>> [...]
> >>>> We have a stream with pictures containing (T1/B1/T2==T1), (B2/T3/B3==B2)
> >>>> fields. That's two H.264 pictures, but 3 frames. Each av_read_frame()
> >>>> should return a packte containing exactly single frame. But we have just
> >>>> 2 packets, which need to be returned in 3 calls to av_read_frame(),
> >>>> according to API. Further, the DTS must be set correctly as well for the
> >>>> three AVPackets in order to get the timing correct. How do you want to
> >>>> handle this?
> >>> i dont see where you get 3 calls of av_read_frame(),
> >>> there are 2 or 4 access units not 3 unless one is coded as 2 fields
> >>> and 1 is a frame
> >> No, we don't have 3 calls. First of all, I meant two pictures with
> >> SEI_PIC_STRUCT_TOP_BOTTOM_TOP and SEI_PIC_STRUCT_BOTTOM_TOP_BOTTOM.
> >> This
> >> generates 3 frames in the display.
> > no, it generates 2 frames each with a duration of 1.5 each
> Maybe I didn't express myself correctly. There are two decoded frames (4
> decoded fields in total), but there are three _displayed_ frames (4
> fields + 2 fields, which are repeated).
> Look at H.264 standard, D.2.2, table D-1. For these two picture
> structures, three timestamps per picture are generated for the three
> fields (NumClockTS=3), so for the two pictures in total 6 timestamps.
> Each frame has two timestamps for appropriate top/bottom fields. In our
> case, T1/B1 could have timestamps 1/1 for progressive or 1/2 for
> interlaced. T2/B2 could have timestamps 2/2 for progressive or 3/4 for
> interlaced. T3/B3 could have timestamps 3/3 for progressive or 5/6 for
> In any case, there are _three_ display frames displayed with duration 1,
> not two frames displayed with duration of 1.5. I just wanted to point
> out that there is no way to express this yet.
there is and its called repeat_pict
> Current code setting the
> frame duration of 1.5 is a good workaround for now, but the application
it is not a workaround
> doesn't know the order of frames to display, which will most probably
> cause interlacing artefacts for interlaced video (progressive will be
> OK, even better than with constructing the frame in-between from two
> fields of first and third frame).
this stuff is used with progressive, its then called telecine and it
causes artifacts if implemented like you suggest
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel