Bug 174458 – [Gstreamer][HLS] Unable to play TED videos

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Sergio Villar Senin]

Steps:
1- Go to https://www.ted.com/talks/nonny_de_la_pena_the_future_of_news_virtual_reality#t-134591
2- Press the plat button

The stream is not played.

[Sergio Villar Senin]

BTW I'm using 2.16.5 although the issue can be reproduced on trunk too with MiniBrowser.

[Carlos Alberto Lopez Perez]

Maybe its the same than bug 174414 ?
It plays fine with trunk as of today for me (r219449) and using the iternal jhbuild. It fails with Epiphany from Debian Stretch.

[Carlos Alberto Lopez Perez]

(In reply to Carlos Alberto Lopez Perez from comment #2)
> Maybe its the same than bug 174414 ?
> It plays fine with trunk as of today for me (r219449) and using the iternal
> jhbuild. It fails with Epiphany from Debian Stretch.

Sorr,y I mean bug 172240

[Charlie Turner]

Thanks for reporting this Sergio.

Just commenting to clear up the suggested triage,

Carlos, it's not the same issue, this is a new bug. I do have some very quick observations and will investigate this once I finish a separate task.

There's 27 subtitle tracks in this HLS manifest, which is a lot. My guess at the moment is that we're waiting for ages fetching those manifests before reporting progress events (causing the play button to reappear). If you click play after a while, playback does happen properly, but seeking causing funny things to happen and this will need investigation. I might be guessing at this because I'm currently investigated bugs related to progress events not working properly in live pipelines, but it seems feasible.

I will look at this when I can.

[Charlie Turner]

So, maybe Carlos has a really great network connection to the server serving this stream and it's not causing the stall inside MediaPlayer...

[Carlos Alberto Lopez Perez]

(In reply to Charlie Turner from comment #5)
> So, maybe Carlos has a really great network connection to the server serving
> this stream and it's not causing the stall inside MediaPlayer...

I have a good connection, indeed. 

Its also true that it don't really plays fine always, sometimes the image gets stalled and then it goes like fast-forward.

[Charlie Turner]

> Its also true that it don't really plays fine always, sometimes the image gets stalled and then it goes like fast-forward.

Right, this is a separate area of open bugs. Before #172240, this stream will have failed to even preroll and likely live-locked. There are other existing bugs to do with progress events in live streams, and also seeking in live streams (seeking on vid.me is also broken, but at least it plays now :))

[Sergio Villar Senin]

(In reply to Charlie Turner from comment #5)
> So, maybe Carlos has a really great network connection to the server serving
> this stream and it's not causing the stall inside MediaPlayer...

In my case my rural connection is far from being good, it's generally slow with a  lot of latency but usable (in comparison youtube works fine).

[Charlie Turner]

> In my case my rural connection is far from being good, it's generally slow with a  lot of latency but usable (in comparison youtube works fine).

That's the same as me :). In any case, it's a bug that we're stalling. I'm working on a separate bug that should resolve at least part of this issue which is tracked in https://bugs.webkit.org/show_bug.cgi?id=141469

[Charlie Turner]

This is a GStreamer bug in their adaptive streaming stack.
The video sort of plays if you're lucky, seeking around can fix the synchro, but in general there are issues with this particular flavour of HLS delivery that I'm tracking with https://bugzilla.gnome.org/show_bug.cgi?id=785129

[jena]

I can play that video just fine with Epiphany Nightly 3.37.1-16-g04b840c21 (flatpak, I've heard there is no gstreamer) as well as in [Ephemeral](https://github.com/cassidyjames/ephemeral) with webkitgtk 2.28.2 from Ubuntu repos.

[Alicia Boya García]

Doesn't work reliably for me. Even in gst-play (release 1.16.2) it tends to get stuck on the "TED" intro, audio clicks and sends hundreds of requests.

The manifest URL is https://hls.ted.com/talks/2376.m3u8

[Sergio Villar Senin]

(In reply to Alicia Boya García from comment #12)
> Doesn't work reliably for me. Even in gst-play (release 1.16.2) it tends to
> get stuck on the "TED" intro, audio clicks and sends hundreds of requests.
> 
> The manifest URL is https://hls.ted.com/talks/2376.m3u8

Any news regarding this? Not being able to play TED videos is pretty bad for user experience.

[Philippe Normand]

https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1037
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/585

[Philippe Normand]

I think we should disable HLS support. The current demuxer based on adaptivedemux is considered deprecated in favour of hlsdemux2, which we can't use in WebKit... The new demuxer uses libsoup directly, so it won't work if the WebProcess sandbox is enabled.

I just tried this TED video after disabling HLS, MSE was used as fallback and playback worked just fine...

[Philippe Normand]

We could make HLS support conditional on some env var, disabled by default. The adventurous HLS fans can re-enable it by setting, let's say, WEBKIT_GST_HLS_SUPPORT=1

[Michael Catanzaro]

I suspect we only need to support HLS on broken websites that assume they can use HLS because our user agent header looks like Safari. And maybe if we're lucky there are no such websites, or at least no such important websites.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #17)
> I suspect we only need to support HLS on broken websites that assume they
> can use HLS because our user agent header looks like Safari. And maybe if
> we're lucky there are no such websites, or at least no such important
> websites.

I'm sorry but with the current small team we have we can't afford to support every broken website of the wild web unable to do a proper feature check on the user-agent.

[Michael Catanzaro]

Hopefully it's not a problem for any website. I'd say go ahead.

If it turns out to be a problem for some website, then we can decide what to do about it based on how important that website is. But I bet it will be fine.

[Philippe Normand]

Pull request: https://github.com/WebKit/WebKit/pull/8100

[EWS]

Committed 258717@main (e2afda4dd0ab): <https://commits.webkit.org/258717@main>

Reviewed commits have been landed. Closing PR #8100 and removing active labels.