From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 191904E57C for ; Tue, 10 Jun 2025 14:42:23 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 0D8E468D3F8; Tue, 10 Jun 2025 17:42:21 +0300 (EEST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id A39E068D3D7 for ; Tue, 10 Jun 2025 17:42:19 +0300 (EEST) Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-adb2e9fd208so1025887066b.3 for ; Tue, 10 Jun 2025 07:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749566538; x=1750171338; darn=ffmpeg.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=jCw05jpnqg7xg66iRJILzcN1pk3H6jauoseVJDVxGa4=; b=REpz/bgXAJO+dWurT5DoRI1lm/oTJwJdWAdd58K68XUJgU2O3krQMOud+nrSOMlrZz aGF1G465jKoFtmkuWQvxwRpLOfVVoqstEKOBz/eEm9q5XXly14AlSSFGK0JFBGS6PEeV x1FjgrE/avGKZgm5FP40jD4JpDOe7uNvIZa/nltIfB3cLraJLOTaa5zNdUzFRt95hBeT +B6By8e8bJh0O0xeo9q8xTXOQDsBOjGwE7BP1dcj4jVD6vOr3K3yNquTWfcbW0bXkkU3 Jj0WLM4CYg9FyXevxqMSsavTNqmDKQLJIQLaUKK7n3v4C4D5Wtwf+r9cMPlATgEHBYaF 2Q1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749566538; x=1750171338; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jCw05jpnqg7xg66iRJILzcN1pk3H6jauoseVJDVxGa4=; b=P8SDsS9tHp/THgsJrZkRAM4kWHwntdscfu/jHRYjXg1XjvHf78XmJuUyLVUMbzs50o D6/Kj/zZoBDHSvuTi57bMIaIf7UbOEkSFh17KOCcbmG3LcFT1LTtdMbD/ScJtdPsD/ey nU+v0LhjfdzQHEMhBAH3a81YSN/E1NKWw6Elix+ObuZ+yuZvTii7wacDBMitmQvZ+av6 Ijj7zsqjN/Zqi8Q4B2Pd2na3KszprDpWSZs4T+Z9vyjgQ1irjUR3nPYz1i0TqaAEgiZl qkKdM2nb7ymS0wPhRsb3VqbWxH5Jzk4Mgq8woPXSXxRu01DQ6CJrXoUCBvrFfdVeijoP 1Rsg== X-Gm-Message-State: AOJu0YxxjISEtL4h8D90XF+uHkoa8HhUM857TuZKiTQEgDvALkkQ2PA2 FBSyf+yPWpdc7si4P9qGvGnf/iEXR4Y1H6BtclxMhhnrSMZWZHlhpZG2GEj01uDOpC8GDU6Jjak hJKlcbLyKtj5kgsgXSzguYb0LNr2ryBOVSpTd X-Gm-Gg: ASbGncveUCBU1If0tq3Qb5t03DzKuIJk4Bo4VoF26uxnP/j9Vl6nbGOj6rklMELQbvU aWh3dQHywMExzFhr5UC1Tvl8NLthF9PNT2cAOx5EJ5jNjvRnrckYzBDpCa099WKVHLcDzKP8oSn FQUfl0izdDGjF2uJDnUigy7LVzlXe0G+sqKbPDJRO0Rsk= X-Google-Smtp-Source: AGHT+IEUjFYUv5eno+HUQoUc8vw1jsUBsuO/0z47QrFAfIzKmiPRHDKJk85iSSfbC0EfaRlTAwiRA5qm17cniYy9MKc= X-Received: by 2002:a17:907:940e:b0:ad8:96d2:f3a with SMTP id a640c23a62f3a-ade1aa0fc92mr1483915566b.8.1749566538287; Tue, 10 Jun 2025 07:42:18 -0700 (PDT) MIME-Version: 1.0 References: <20250610034528.30157-1-pkoshevoy@gmail.com> <20250610133859.GU29660@pb2> In-Reply-To: <20250610133859.GU29660@pb2> From: Pavel Koshevoy Date: Tue, 10 Jun 2025 08:42:08 -0600 X-Gm-Features: AX0GCFvUD35wn8kpAMnbPssDVzw8fpGrCVq5wFav9Oc2cbKvMa_DNhJMfDTHrSU Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2) X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, Jun 10, 2025, 07:39 Michael Niedermayer 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-request@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-request@ffmpeg.org with subject "unsubscribe".