ggarr...@gmail.com:
> From: Gonzalo Garramuño <ggarr...@gmail.com>
>
> Moved the check inside and at the end of the if (pktl) as per Michael
> Niedermayer's suggestion.
> This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).
>
> The hanging in av_read_frame can be reproduced with an rtmp stream that is
> aborted midway and ffplay (for example) playing that stream.
> ---
> libavformat/utils.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..653918d5a5 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>
> &s->internal->packet_buffer_end, pkt);
> goto return_packet;
> }
> +
> + if (ff_check_interrupt(&s->interrupt_callback)) {
> + av_log(s, AV_LOG_DEBUG, "interrupted\n");
> + return AVERROR_EXIT;
> + }
> }
>
> ret = read_frame_internal(s, pkt);
>This patch makes it possible for pkt to be still uninitialised after
the call to av_read_frame() if I am not mistaken (namely if the packet
list was initially not empty and the interrupt was triggered before
read_frame_internal() has been called). If so, this clashes with a
recently proposed patch by me
(https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
One could either allow av_read_frame() to return unclean packets on
error or you would have to add the necessary initializations in your
code (or you would have to make sure that your code is not triggered
before the first call to read_frame_internal()).
- Andreas
_______________________________________________
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".
