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.
BTW I'm using 2.16.5 although the issue can be reproduced on trunk too with MiniBrowser.
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.
(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
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.
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 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.
> 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 :))
(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).
> 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
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
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.
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
(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.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1037 https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/585
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...
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
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.
(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.
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.
Pull request: https://github.com/WebKit/WebKit/pull/8100
Committed 258717@main (e2afda4dd0ab): <https://commits.webkit.org/258717@main> Reviewed commits have been landed. Closing PR #8100 and removing active labels.