This commit closes trac ticket 10679.
Signed-off-by: Timothy Allen
---
libavformat/hls.c | 9 +
libavformat/url.c | 35 +++
libavformat/url.h | 9 +
3 files changed, 53 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index c7b65
On Wed, 2025-05-21 at 19:25 +, softworkz . wrote:
> What I mean and what the comment in the ticket is probably
> suggesting,
> is that the HLS demuxer should URL-encode the URL after combining the
> base url with the segment file name before making a request for the
> segment.
Ah, sure. That
On Wed, 2025-05-21 at 18:56 +, softworkz . wrote:
> Why do you think it would require control over the server side?
The original ticket is referring to HLS, and specifically the manifest
of HLS, which means a remotely-hosted M3U playlist.
In principle, the user could download the playlist, co
On Tue, 2025-05-20 at 20:03 +, softworkz . wrote:
> I was just about to reply and suggest to replace those colons with
> %3A
> (url-encoded) when I read the ticket, which already suggests that.
>
> Have you tried it? It sounds like a much better way to me.
I think this would be a common-sense
This commit closes trac ticket 10679.
Signed-off-by: Timothy Allen
---
libavformat/tests/url.c | 8 +++-
libavformat/url.c | 8 +++-
tests/ref/fate/url | 7 ++-
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/libavformat/tests/url.c b/libavformat/tests/url.
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 @ 0x78dea40
