[FFmpeg-devel] [PATCH] Accept a colon in the path of a URI, instead of stripping preceding characters.
Timothy Allen
tim at treehouse.org.za
Tue May 20 18:27:55 EEST 2025
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.
Thank you,
Tim
More information about the ffmpeg-devel
mailing list