Re: [FFmpeg-devel] [PATCH] Accept a colon in the path of a URI, instead of stripping preceding characters.

[Timothy Allen via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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
_______________________________________________
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".