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-requ...@ffmpeg.org with subject "unsubscribe".
