On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> 
> codec_close should not assume that the codec_id did not change.
> ---
>  libavformat/demux.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index ecd4f40da9..3749ab67a3 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
>  {
>      AVCodecContext *avctx_new = NULL;
>      AVCodecParameters *par_tmp = NULL;
> +    const AVCodec *new_codec = NULL;
>      int ret;
>  
> -    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
> +    new_codec =
> +      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
> +      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
> +      sti->avctx->codec;
> +
> +    avctx_new = avcodec_alloc_context3(new_codec);
>      if (!avctx_new) {
>          ret = AVERROR(ENOMEM);
>          goto fail;

This is not about request_probe
but about the mpegts demuxer randomly changeing codec id midstream

I belive the patch should be reverted that causes this. I dont think
applications expect such mid stream changes either

I hope andreas can take a look and correct me if iam missing something
but it looks a bit sketchy to me

If a codec changes mid stream i belive a new AVStream
should be created. It could be a audio stream switches to video
or data or subtitle.

If any stream as detected initially can become any other type later
this complicates user applications and filter graphs
Also the management of AVPackets is probably rather non trivial
if the stream_index is not enough to identify which decoder it belongs to

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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".

Reply via email to