Quoting Andreas Rheinhardt (2021-12-09 14:08:01)
> From: Ho Ming Shun <cyph1...@gmail.com>
>
> MMAL is an fundamentally an asynchronous decoder, which was a bad fit
> for the legacy dataflow API. Often multiple packets are enqueued before
> a flood of frames are returned from MMAL.
>
> The previous lockstep dataflow meant that any delay in returning packets
> from the VPU would cause ctx->queue_decoded_frames to grow with no way
> of draining the queue.
>
> Testing this with mpv streaming from a live RTSP source visibly reduced
> latency introduced by frames waiting in queue_decoded_frames from
> roughly 2s to 0.
>
> Signed-off-by: Ho Ming Shun <cyph1...@gmail.com>
> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
> ---
> libavcodec/mmaldec.c | 32 +++++++++++++++++++++++++-------
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 8c7d749742..d336f10350 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -83,6 +83,8 @@ typedef struct MMALDecodeContext {
> // libavcodec API can't return new frames, and we have a logical
> deadlock.
> // This is avoided by queuing such buffers here.
> FFBufferEntry *waiting_buffers, *waiting_buffers_tail;
> + /* Packet used to hold received packets temporarily; not owned by us. */
> + AVPacket *pkt;
Why is this needed? Seems to be you'd save three lines of code (and,
more importantly, a confusing pointer to an object you don't own) by
simply directly accessing avctx->internal->in_pkt in
ffmal_receive_frame().
--
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
