On 1/30/2019 3:43 PM, jannis_wth wrote:
> 30.01.19 18:30 - James Almer:
>> On 1/30/2019 2:19 PM, Nicolas George wrote:
>>> James Almer (12019-01-30):
>>>> compat_decode_consumed doesn't look to have any significance when using
>>>> the new API. It's working as an accumulator for all bytes consumed from
>>>> all frames and it's never cleared (sounds like a potential overflow for
>>>> that matter in long lasting decoding scenarios like streaming), whereas
>>>> for the old API it's effectively keeping track of bytes consumed in one
>>>> frame, and cleared after every avcodec_decode_* call. So I guess that's
>>>> why you're clearing it here even though this function should by no means
>>>> do that.
>>>>
>>>> Clearing compat_decode_consumed for the new API should be done somewhere
>>>> in decode.c where it doesn't break the logic for the old API, regardless
>>>> of using the AVCodec.decode() or AVCodec.receive_frame() callbacks.
>>> I have reservations about adding an API to query something that is
>>> considered deprecated.
>>>
>>> Regards,
>> I also don't think this is too good of an idea. The new API always
>> consumes and takes ownership of the full packet when you feed it to
>> avcodec_send_packet(), even if it ends up splitting it internally in
>> order to return more than one frame, so in theory just keeping track of
>> what you feed to it in your own code is enough, regardless of how many
>> frames avcodec_receive_frame() gives you back.
>>
>> What this function would do for some decoders however is giving the API
>> user knowledge of said internal splitting after each
>> avcodec_receive_frame() call (an example being VP9).
>> If that's useful or not for the user, i don't know.
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> Okay, so how about this one?
> This functionality is important if you don't know the packet size you
> are feeding. It allows you to reconstruct the size.
In what scenario you can't know the size of the AVPacket you're feeding
to avcodec_send_packet().
>
>
> 0001-avcodec-Allow-to-query-number-of-consumed-bytes-usin.patch
>
> From bad739e4f5e9e78cc6fa799287d758bf27db8208 Mon Sep 17 00:00:00 2001
> From: user <user@host>
> Date: Wed, 30 Jan 2019 19:33:08 +0100
> Subject: [PATCH 1/1] avcodec: Allow to query number of consumed bytes using
> the new API
>
> Currently the only way to get the number of consumed bytes is by using
> the deprecated decode_audio4() API. This patch adds a simple function
> to fix this.
>
> Signed-off-by: Jannis Kambs <jannis_...@gmx.de>
> ---
> libavcodec/avcodec.h | 9 +++++++++
> libavcodec/utils.c | 5 +++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index f554c53f0e..43bf84e58b 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5714,6 +5714,15 @@ int av_get_audio_frame_duration(AVCodecContext *avctx,
> int frame_bytes);
> */
> int av_get_audio_frame_duration2(AVCodecParameters *par, int frame_bytes);
>
> +/**
> + * This function allows to get the number of remaining bytes after
> + * avcodec_receive_frame() has been called.
> + *
> + * @param avctx the codec context
> + * @return number of remaining bytes from the input AVPacket.
> + */
> +int avcodec_get_remaining_size(AVCodecContext *avctx);
> +
> #if FF_API_OLD_BSF
> typedef struct AVBitStreamFilterContext {
> void *priv_data;
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index d519b16092..638154f974 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1727,6 +1727,11 @@ int av_get_audio_frame_duration2(AVCodecParameters
> *par, int frame_bytes)
> frame_bytes);
> }
>
> +int avcodec_get_remaining_size(AVCodecContext *avctx)
> +{
> + return avctx->internal->ds.in_pkt->size;
This is only used by decoders implementing the AVCodec.decode()
callback. It will always be zero for any decoder using
AVCodec.receive_frame(), like Bink Audio, libdav1d, etc.
For that matter, You sent this message to me alone. Make sure to send it
to the mailing list when you reply.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
