avcodec_receive_frame - get number of bytes consumed

[jannis_wth]

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:
​https://www.ffmpeg.org/doxygen/4.1/group__lavc__encdec.html

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?

[Carl Eugen Hoyos]

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?

[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?

[Carl Eugen Hoyos]

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.