[FFmpeg-devel] [PATCH] Fix return value for incomplete H264 frame packets
Mon Aug 23 20:37:53 CEST 2010
On Mon, Aug 23, 2010 at 08:05:56PM +0200, Laurent Aimar wrote:
> On Mon, Aug 23, 2010 at 06:50:38PM +0200, Reimar D?ffinger wrote:
> > On Mon, Aug 23, 2010 at 04:51:09PM +0200, Laurent Aimar wrote:
> > > > Laurent Aimar:
> > > > > Unless I misunderstood the current code, avcodec will consume the first
> > > > > field, properly decode it and return no pictures and no errors. If so, it
> > > > > seems the right behavior to me.
> > > >
> > > > You understood it correctly. The question is if it should be a task of the
> > > > decoder to call for more data.
> > > The current code already does it. It consumes all bytes and return no pictures.
> > > Obviously, more data are needed to have a frame ready.
> > Not really, it could be e.g. due to decoder delay.
> well, receiving a field is the same kind of issue: you need the following
> pictures to output a frame.
No, not really. With decoder delay you can feed NULL data
to indicated end of stream and you'll get a frame.
> > I suggested to make it return an error, because for the
> > FFmpeg API passing such an incomplete frame to the decoder
> > actually is an error.
> Well, the h264 standard defines an access unit as a picture, being a
> frame or a field. So, IMHO, returning an error would be the wrong move,
> forcing to 'merge' fields into frames before giving them to avcodec for
> .mp4 or .mkv for example.
Well, it would still "work" for that case, you'd just have to ignore that error.
However for the purpose some other way to indicate why we got no frame would
work as well, maybe a choice of "frame too badly damaged to do any concealment",
"encoded data indicates no change", "not enough encoded data available to return
a frame (e.g. due to reordering)"?
More information about the ffmpeg-devel