From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id BF8264619F for ; Mon, 8 May 2023 22:35:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7301F68BECA; Tue, 9 May 2023 01:35:17 +0300 (EEST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B1322687F5C for ; Tue, 9 May 2023 01:35:10 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id D747D60002 for ; Mon, 8 May 2023 22:35:09 +0000 (UTC) Date: Tue, 9 May 2023 00:35:08 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230508223508.GW1391451@pb2> References: <20230506132503.9524-1-michael@niedermayer.cc> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension 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: multipart/mixed; boundary="===============0225484646097668098==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0225484646097668098== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="21/Vc5rId7THQcsT" Content-Disposition: inline --21/Vc5rId7THQcsT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote: > On 08/05/2023 14:00, James Almer wrote: >=20 > > On 5/6/2023 10:25 AM, Michael Niedermayer wrote: > > > Its unexpected that a .avi or other "standard" file turns into a > > > playlist. > > > The goal of this patch is to avoid this unexpected behavior and possi= ble > > > privacy or security differences. > > >=20 > > > This is similar to the same change to hls > > >=20 > > > Signed-off-by: Michael Niedermayer > > > --- > > > =A0 libavformat/dashdec.c | 11 +++++++---- > > > =A0 1 file changed, 7 insertions(+), 4 deletions(-) > > >=20 > > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c > > > index 29d4680c68..294e14150d 100644 > > > --- a/libavformat/dashdec.c > > > +++ b/libavformat/dashdec.c > > > @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p) > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-li= ve:2011") || > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-li= ve:2012") || > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile:isoff-ma= in:2011") || > > > -=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) { > > > -=A0=A0=A0=A0=A0=A0=A0 return AVPROBE_SCORE_MAX; > > > -=A0=A0=A0 } > > > -=A0=A0=A0 if (av_stristr(p->buf, "dash:profile")) { > > > +=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "3GPP:PSS:profile:DASH1") || > > > +=A0=A0=A0=A0=A0=A0=A0 av_stristr(p->buf, "dash:profile")) { > > > +=A0=A0=A0=A0=A0=A0=A0 if (!av_match_ext(p->filename, "mpd")) { > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 av_log(NULL, AV_LOG_ERROR, "Not de= tecting dash with non > > > standard extension\n"); > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0; > > > +=A0=A0=A0=A0=A0=A0=A0 } > > > + > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 return AVPROBE_SCORE_MAX; > > > =A0=A0=A0=A0=A0 } > >=20 > > Failing because it didn't match an extensions sort of goes against the > > point of probing, which even has a low score return value that's > > basically "it matched extension" as a sort of last resort. > >=20 > > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the > > spec does state mpd must be the extension), but i think we have no > > access to the AVFormatContext here? >=20 > DASH is usually transferred over HTTP where file extensions are of minor > interest, the relevant type information is in the Mime-Type header. would anyone be opposed to return 0 from dash_probe() when both the mime_type and the extension are wrong ? Here both the server says its not dash as well as the extension not being t= he standard for dash example: a crafted image.jpeg uploaded somewhere is played as dash. or am i missing something that would stop that ? thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn --21/Vc5rId7THQcsT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZFl5FgAKCRBhHseHBAsP qyDWAJ0TEvU3SU2whxyFL4Mw/zF7iieJTACffUe9KV9NfzrHn2c2Yt9cD0zh9ZE= =LQk6 -----END PGP SIGNATURE----- --21/Vc5rId7THQcsT-- --===============0225484646097668098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============0225484646097668098==--