Opened 2 years ago

Last modified 2 years ago

#7708 new enhancement

avcodec_receive_frame - get number of bytes consumed

Reported by: jannis_wth Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


There are use cases in which we don't know the exact size of the packet we want to decode. For example is if we try to recover a broken mp4, which misses its moov atom.
With ffmpeg it was possible to get the unknown size by looking at how many bytes 'avcodec_decode_audio4' consumed, assuming it's an audio packet.
However 'avcodec_decode_audio4' is now deprecated, and the new send/receive API is recommended:

The problem is that there seems to be no way to get the number of bytes consumed from the packet using this new (or any other non deprecated) API.
Is this correct? If so, making this number available would be as easy as adding following function, provided the user stores the previous size:

int av_get_internal_pkt_size(AVCodecContext *avctx) 
    return avctx->internal->buffer_pkt->size;

I understand that this might be an anti-pattern, but since tools like ponchio/untrunc depend on this kind of feature I think it would be a shame not to add it!

One additinal Question:
If we don't have the moov Atom, we have to gues which codec matches the current position in the mdat. For example some codecs start their raw packets with always the same sequence of bytes, but others codecs are harder to match.
Is there any functionality in ffmpeg which would help deciding which codec a given stream of bytes belongs to? Functions like 'av_probe_input_buffer' seem to not match this usecase, is this right?

Change History (3)

comment:1 Changed 2 years ago by cehoyos

  • Priority changed from normal to wish
  • Version changed from unspecified to git-master

Why didn’t you send a patch with the new function to the development mailing list?
And why don’t you use avcodec_decode_audio4() if it works better for you?

comment:2 follow-up: Changed 2 years ago by jannis_wth

I do use 'avcodec_decode_audio4', but I noticed that since ffmpeg 3.4 my code was broken.
It had to do with 'compat_decode' storing state and expecting its input packet to match it.
Additionally errors (ret < 0) are now expected to be handled by the user, basically resetting said state.

While I was trying to figure out why my code was not working anymore, I realised that 'compat_decode' basically just uses the new recive API + keeping problematic state.
So the natural thing for me was to directly use this new API.
On top of that I find the deprecated warning to be annoying :)
I will do as you say and send a patch to the mailing list.

What about my additional question though? Anyone has an idea?

comment:3 in reply to: ↑ 2 Changed 2 years ago by cehoyos

Replying to jannis_wth:

What about my additional question though?

(Didn't you discuss the question already on irc?)
This is a bug tracker, not an FFmpeg discussion forum, it is unlikely that your question will be answered here.

Note: See TracTickets for help on using tickets.