On Tue, Jun 10, 2025, 07:39 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> 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 have several real (not crafted like 1_poc.mp4 is) .ts files where codec changes from mpeg2video to hevc, from mpeg2audio to eac3 -- while remaining on the same PIDs. I also have .ts files where codec switches between mpeg2video and h264. VLC was able to play such files, but my ffmpeg based player (apprenticevideo) could not even see that the codecs changed prior to 0021484d05f9b0f032fa319399de6e24eea0c04f. Reverting isn't really an option for me, not unless there is a better solution presented. As I am primarily a public ffmpeg API user -- I am well out of my depth when it comes to making non-trivial changes to ffmpegs internals. > I belive the patch should be reverted that causes this. I dont think > applications expect such mid stream changes either > I have 2 applications that expect such behavior. > 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. > In my player I support video/audio track selection. MPEG-TS tracks are associated with a PID. If the PID did not change but the codec changed -- it's still the same track, and I axpect my player to play it out -- I don't expect the user to go search for some new track because the codec changed. > If any stream as detected initially can become any other type later > this complicates user applications and filter graphs > I think this is mostly a issue with the crafted 1_poc.mp4 file. Also the management of AVPackets is probably rather non trivial > if the stream_index is not enough to identify which decoder it belongs to > In my player I monitor AVCodecParameters for changes, and I attach a shared_ptr to AVCodecParameters to each packet, so when time comes to decode a packet I can check if its codecpar matches the current decoder, and open a new decoder if the codec has changed. It's not trivial, but not complicated either. > 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. > _______________________________________________ > 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". > _______________________________________________ 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".