[FFmpeg-devel] [PATCH] Fix return value for incomplete H264 frame packets

Michael Niedermayer michaelni
Mon Aug 23 23:08:23 CEST 2010


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.

or these vp8 frames ...


> Or as for MPEG-4 it could be because it was a all-skip VOP.

we should indicate this case somehow because it differs from the others
sematically in that a frame is output just that it is identical to the
previous


> 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.

Thats not true
it is an error for some decoders but decoders can support more flexible
cases, also see CODEC_FLAG2_CHUNKS and CODEC_FLAG_TRUNCATED,CODEC_CAP_TRUNCATED

either way, iam not sure what actual problem people are trying to solve with
this EAGAIN error code ?



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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100823/0e3c4be6/attachment.pgp>



More information about the ffmpeg-devel mailing list