[FFmpeg-devel] [PATCH] AVCHD/H.264 parser: determination of frame type, question about timestamps
Sun Feb 1 01:48:10 CET 2009
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.
> generates 3 frames in the display.
no, it generates 2 frames each with a duration of 1.5 each
> But the caller has to call
> av_read_frame() only twice, so he doesn't get all required timestamps.
> First decoded frame will have timestamp 1, second decoded frame
> timestamp 2 or 3, depending on how it's handled in H.264 decoder. One
> frame has to be added in between, with fields from both frames. This is
> currently not possible to express.
> I suppose, there is the need to do something like repeat_pic on field
> level, but this means API change.
> >> And as already mentioned, the case with (T1), (B1), (T2), (B2), we are
> >> returning 4 packets via av_read_frame() for 2 frames, which is against
> >> API. How to handle this? My idea was delaying return from h264_parse,
> >> until second field also parsed
> > well, just consider the exampl that timestamps are always associated with
> > the second field instead of the first. You couldnt associate them with the
> > AVPackets
> I don't believe someone would produce such streams. Anyway, the standard
> _requires_ DTS/PTS coding for all frames having DTS != PTS, so even in
> this case, I- and P-slices would have to have timestamps. The timestamps
> of B-slices in between can be computed.
this sounds like utter nonsense
where is the standard supposed to require this?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel