[FFmpeg-devel] [PATCH 1/2] examples: demuxing: do partial audio packet decoding

wm4 nfxjfg at googlemail.com
Sun Jul 14 14:43:13 CEST 2013


On Sun, 14 Jul 2013 11:43:46 +0200
Stefano Sabatini <stefasab at gmail.com> wrote:

> After re-reading the docs, avcodec_decode_video2 should return the
> consumed bytes as well, so we can assume that ret will contain
> pkt.size after decoding.

ffplay/ffmpeg do not use this value, so it might not be safe to use.
Also see what Reimar said. If you try to call the decoder function with
the remainder of the packet, you might just feed it garbage, and all
you win is having the decoder spam error messages.

I think it's better not to suggests such untested and fragile code to
users.

> > +         * Also, some decoders might over-read the packet. */
> > +        decoded = FFMIN(ret, pkt.size);
> 
> What decoders? This sounds as a bug, not something to band-aid in the
> application code.

I don't know. I have this idea from the mplayer2 sources. The original
commit is here and gives some clues:
http://repo.or.cz/w/mplayer.git/commit/b9b8aaf8a271ee20c90908ac47573f5ef0285782

> Also, even in this case the external check on pkt.size > 0 should work
> fine.

True. AVPacket.size is signed. But probably better to be explicit. If
such unexpected/unintuitive behavior is possible, it should be pointed
out. Maybe even add it to the avcodec docs? (Or maybe it's just a bug?)

In a way it's implicitly allowed by the documentation, because it says
that it _can_ read past the input buffer by
FF_INPUT_BUFFER_PADDING_SIZE.


By the way and unrelated to this: this example, as imperfect as it
already is, still doesn't handle format changes during decoding.


More information about the ffmpeg-devel mailing list