REGRESSION(r243197): [GStreamer] Error playing redirected streams

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

I haven't tested it myself yet, but one Debian user reports this problem with WebKitGTK 2.24.1. Here are the steps to reproduce it:

1) Go to http://radio.dos.nl/

2) Go to settings (drop down in right top corner)

3) Click "Choose protocol" until it shows HLS

4) Click on arrow (back to radio)

5) Click on "Page menu" (bottom left corner) and choose "news"

6) Click "France Info", network stream starts, no audio (protocol: AAC)

7) Click "France Culture": works (same protocol: AAC)

This is the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928044

I had a short conversation with Michael and he thinks that the commit that caused this was r243197: https://trac.webkit.org/changeset/243197/webkit

The user confirms that version 2.24.0 works fine.

[Philippe Normand]

This is not related with HLS. The player uri differs from the one reported by the httpsrc element and this statement is logged:

GST_DEBUG_OBJECT(pipeline(), "Ignoring HTTP response headers for non-main URI.");

[Philippe Normand]

Created attachment 369369 [details]
Patch

[EWS Watchlist]

Comment on attachment 369369 [details]
Patch

Attachment 369369 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/12132285

New failing tests:
fast/visual-viewport/zoomed-fixed-scroll-down-then-up.html

[EWS Watchlist]

Created attachment 369377 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123  Port: ios-simulator-wk2  Platform: Mac OS X 10.14.4

[Philippe Normand]

(In reply to Build Bot from comment #3)
> Comment on attachment 369369 [details]
> Patch
> 
> Attachment 369369 [details] did not pass ios-sim-ews (ios-simulator-wk2):
> Output: https://webkit-queues.webkit.org/results/12132285
> 
> New failing tests:
> fast/visual-viewport/zoomed-fixed-scroll-down-then-up.html

False positive.

[Philippe Normand]

Committed r245054: <https://trac.webkit.org/changeset/245054>

[Alberto Garcia]

This bug is fixed now, but I got this feedback from a user:

                  ------------------------
The bug is fixed, but there is a small (cosmetical) issue with the new
2.24.1-2 version, compared to old 2.22.7: when clicking on a HLS
stream, it takes a few seconds for the radio to start playing while
the old version started to play instantly.

1) Go to http://radio.dos.nl/

2) Go to settings (drop down in right top corner)

3) Click "Choose protocol" until it shows HLS

4) Click on arrow (back to radio)

5) Click on "Page menu" (bottom left corner) and choose "news"

6) Click one of the BBC icons, e.g. "5 live"

The 2.22.7 version plays immediately, the 2.24.1-2 waits a few seconds.
                  ------------------------

[Philippe Normand]

(In reply to Alberto Garcia from comment #7)
> This bug is fixed now, but I got this feedback from a user:
> 
>                   ------------------------
> The bug is fixed, but there is a small (cosmetical) issue with the new
> 2.24.1-2 version, compared to old 2.22.7: when clicking on a HLS
> stream, it takes a few seconds for the radio to start playing while
> the old version started to play instantly.
> 
> 1) Go to http://radio.dos.nl/
> 
> 2) Go to settings (drop down in right top corner)
> 
> 3) Click "Choose protocol" until it shows HLS
> 
> 4) Click on arrow (back to radio)
> 
> 5) Click on "Page menu" (bottom left corner) and choose "news"
> 
> 6) Click one of the BBC icons, e.g. "5 live"
> 
> The 2.22.7 version plays immediately, the 2.24.1-2 waits a few seconds.
>                   ------------------------

That's a downside of using the network-process for HLS :( Not much I can do, unfortunately.

[Michael Catanzaro]

Really? Because the job of the network process is to load things really quickly. It shouldn't take seconds.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #9)
> Really? Because the job of the network process is to load things really
> quickly. It shouldn't take seconds.

"A few seconds" is too vague. More investigation is needed... But what I observed here is that there was a small delay indeed, at the time I assumed it was because of the IPC between the Web and Net processes.

Anyway, feel free to open a new bug :) This one is closed for good.

[Michael Catanzaro]

(In reply to Philippe Normand from comment #10)
> "A few seconds" is too vague. More investigation is needed... But what I
> observed here is that there was a small delay indeed, at the time I assumed
> it was because of the IPC between the Web and Net processes.

It should be really small though, insignificant compared to the delay of actually doing network requests.

> Anyway, feel free to open a new bug :) This one is closed for good.

Yes, this one is fixed.