Fedora 24 vlc 3.0.0 m3u URLs not encoded

[MASHtm]

Hi!

I used vlc until Fedora 23 vlc 2.2.4 to view livestreams from my Dreambox 7020HD. Since Fedora 24 vlc 3.0.0-git from rpmforge I've troubles to open streams which contain whitespace and " in the m3u file.

For example...
The link from the webinterface of my box points to:

Code: Select all

http://192.168.x.xx/web/stream.m3u?ref=1%3A134%3A1%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3AFROM%20BOUQUET%20%22alternatives.orf1_hd.tv%22%20ORDER%20BY%20bouquet

VLC is able to fetch the m3u file which contains:

Code: Select all

#EXTM3U #EXTVLCOPT--http-reconnect=true http://192.168.x.xx:8001/1:134:1:0:0:0:0:0:0:0:FROM BOUQUET "alternatives.orf1_hd.tv" ORDER BY bouquet

VLC ends up requesting

Code: Select all

[00007fbd94000d38] core input source debug: creating demux: access='http' demux='any' location='192.168.x.xx:8001/1:134:1:0:0:0:0:0:0:0:FROM BOUQUET "alternatives.orf1_hd.tv" ORDER BY bouquet' file='(null)' [00007fbd94000f18] core demux debug: looking for access_demux module matching "http": 21 candidates [00007fbd94000f18] core demux debug: no access_demux modules matched [00007fbd94009f38] core access debug: creating access: http://192.168.x.xx:8001/1:134:1:0:0:0:0:0:0:0:FROM BOUQUET "alternatives.orf1_hd.tv" ORDER BY bouquet [00007fbd94009f38] core access debug: looking for access module matching "http": 29 candidates [00007fbd94009f38] transport access debug: resolving 192.168.x.xx ... [00007fbd94009f38] transport access debug: connecting to 192.168.x.xx port 8001 ... [00007fbd94009f38] h1conn access debug: outgoing request: GET / HTTP/1.1 Host: 192.168.x.xx:8001 Accept: */* Accept-Language: en_US User-Agent: VLC/3.0.0-git LibVLC/3.0.0-git Range: bytes=0-

If I download the .m3u and URL encode the link VLC is able to open the stream correctly. It seems VLC 3.0.0 does not URL encode URLs in m3u files anymore.

Is this a bug or wanted behaviour in vlc 3.0.0?

[Rémi Denis-Courmont]

As a matter of fact, URLs cannot contain white spaces. Looks like your M3U is invalid.

[MASHtm]

As another matter of fact this worked until 2.2.4 since nothing was changed in the stream delivery process of DM since years. So it seems that VLC urlencoded the lines found unencoded in m3u files up until 2.2.4.

It would be nice if VLC could keep this "self healing" behaviour in future versions as well.

I'm not aware of a standard specification for M3U which specifies if URLs have to be URL encoded or not. I only see lots of M3U files containing WSP for filenames.

[Rémi Denis-Courmont]

URLs cannot contain white spaces; the URL specification is RFC3968. M3U is just a list of URLs so...

There is no such thing as "encoded" URLs. That's a misunderstanding of how encoding works.

[MASHtm]

URLs can contain whitespace:

Code: Select all

$ perl -MURI::Escape -e 'print uri_escape("http://192.168.x.xx:8001/1:134:1:0:0:0:0:0:0:0:FROM BOUQUET \"alternatives.orf1_hd.tv\" ORDER BY bouquet");' http%3A%2F%2F192.168.x.xx%3A8001%2F1%3A134%3A1%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3AFROM%20BOUQUET%20%22alternatives.orf1_hd.tv%22%20ORDER%20BY%20bouquet

Every server and client understands such URLs.

RFC 3986: 2.1: percent-encoding (aka escaping)
..."For example, "%20" is the percent-encoding for the binary octet
"00100000" (ABNF: %x20), which in US-ASCII corresponds to the space
character (SP). "

And that's exactly what VLC did up until 3.0.0.

[Rémi Denis-Courmont]

In other words, an URL cannot contain an unencoded white space, so your M3U file is invalid.

[MASHtm]

VLC 2.2.5 sends the following request:

GET /1:134:1:0:0:0:0:0:0:0:FROM+BOUQUET+"alternatives.orf1_hd.tv"+ORDER+BY+bouquet HTTP/1.1\r\n
fetched with wireshark.

Please fix this regression. That's all I'm asking for.

[Marseille07]

VLC 3.0.0 seems unstable still and I don't understand why rpmfusion folks decided to put it in the Fedora 24 repository when videolan.org site recommends 2.2.4. Is there a way to install 2.2.4 on Fedora 24 at this time? I'm somewhat inclined to grab RPMs from Fedora 23 and see what happens, though I haven't tested that yet.