[FFmpeg-devel] [PATCH] AVCHD/H.264 parser: determination of frame type, question about timestamps
Michael Niedermayer
michaelni
Sat Jan 31 23:50:09 CET 2009
On Mon, Jan 26, 2009 at 08:42:17AM +0100, Ivan Schreter wrote:
[...]
> >> [...]
> >>>> which is IMHO broken. Of course, we could communicate with it by setting
> >>>> pict_type to FF_I_TYPE for keyframes only (IDR frames and frames after
> >>>> recovery point), for other frames containing I- and P-slices to
> >>>> FF_P_TYPE and for B-frames to FF_B_TYPE. But I don't like it much. Any
> >>>> idea, how to do it correctly without the need to touch other codecs?
> >>>>
> >>>>
> >>> pict_type from the parse context should likely be split in pict_type and
> >>> keyframe
> >>>
> >>>
> >> Actually, we already have a flag field on AVPacket coming from the
> >> parser, but compute_pkt_fields() doesn't believe it and resets it based
> >> on pict_type from parse context instead.
> >>
> >
> > the parser works with char* buffers not AVPackets
> >
> Yes, sorry, I was referring to av_read_frame(), which returns AVPacket.
>
> However, why do we need pict_type at all? I/P/B-frames are
> MPEG-specific. Actually, I believe we should change it and return two
> flags - delayed and key frame. This would make it IMHO cleaner and more
> general than testing for pict_type.
i dont mind such a change if its tested a little and works
[...]
> > [...]
> >> Of course, we still have the problem of frame doubling/tripling and
> >> having 3 fields per picture, eventually with one of them repeated
> >> (pic_struct codes 5-8).
> >>
> >
> > no we do not have a problem with this, we do not and never will duplicate
> > anything we just export the information and the app can do with it what it
> > wants, thats also exactly what we do in mpeg2
> >
> We don't export the information, do we? But you are right, with frame
see repeat_pict
> doubling and tripling there is no problem - the application code will
> handle it by itself anyway by displaying last frame longer. As for
> having 3 fields per picture, I'm not so sure it will currently work. At
> least timing will be wrong. Consider following:
as ive said we support this stuff in mpeg2, i see nothing fundamentally
different in the h264 case just more obfuscated documentation of it.
>
> 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
>
> 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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20090131/e1c7804f/attachment.pgp>
More information about the ffmpeg-devel
mailing list