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 5680A4ABB5 for ; Tue, 20 May 2025 19:53:10 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 44A9268DBDC; Tue, 20 May 2025 22:53:06 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 3DCD968DA07 for ; Tue, 20 May 2025 22:52:58 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id C870CEBAB3 for ; Tue, 20 May 2025 21:49:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxQ8xmGF_TnQ for ; Tue, 20 May 2025 21:49:41 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id C7206EBAB2 for ; Tue, 20 May 2025 21:49:40 +0200 (CEST) Date: Tue, 20 May 2025 21:49:40 +0200 (CEST) From: Marton Balint To: Timothy Allen via ffmpeg-devel In-Reply-To: Message-ID: References: MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] Accept a colon in the path of a URI, instead of stripping preceding characters. 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 20 May 2025, Timothy Allen via ffmpeg-devel wrote: > Good day > > I wanted to offer a discussion of the referenced patch. > > I have found that, when a link in an extended M3U file (as used by HLS) > includes a colon, FFmpeg will fail to load the file. > > The bug has already been reported: https://trac.ffmpeg.org/ticket/10679 > > The error reads: > [hls @ 0x78dea4000c80] Failed to open segment 0 of playlist 0 [hls @ > 0x78dea4000c80] Segment 0 of playlist 0 failed too many times, skipping > > The referenced patch fixes the issue. However, it is worth noting that > the patch changes the behavior of one of the unit tests: > > - http://a/b/c/d;p?q g:h => g:h > + http://a:b/c/d;p?q e => http://a:b/c/e > > The original unit test derives from the following two trac tickets: > https://trac.ffmpeg.org/ticket/8813 > https://trac.ffmpeg.org/ticket/8814 > > This is a breaking change, and, in particular, violates one specific > example given in the rfc at > https://tools.ietf.org/html/rfc3986#section-5.4 (the first example). In > particular, it will affect cases where a URL consists only of > host:port, with no scheme or path, and the base URL links to an > unrelated host. Where before, the new link would take the form of > "host:port", the new link will now use "host:port" as the last element > of the path. > > I believe that this behaviour is more intuitive given modern use of > URIs (and is replicated in many browsers), but I recognise this is a > matter of taste. Sorry, but I'd rather not break RFC compliant parsing because of problematic files. Feel free however to add some more context to the ticket, like which browsers and/or media players support such a file, which don't. And how the ones which do support it distinguish between an URL scheme and a relative URL with a colon in the first path component, e.g. video:first.ts or http:first.ts Thanks, Marton _______________________________________________ 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".