Bug 182936 – [GStreamer] Seek broken on YouTube

• Component: Media
• Status: RESOLVED FIXED

[Michael Catanzaro]

Seeking on YouTube videos no longer works. When I click around on the seek bar, the loading animation plays, but the video does not seek. It works fine in 2.18, so it's a regression.

[Charlie Turner]

Note, this is not the case on master, the job for this is to bisect what regressed between now and 2.19.90 (e.g. Ephy Tech Preview), in which apparently seeking on YouTube is broken.

[Michael Catanzaro]

My trunk checkout is on r228497, and it indeed seems fixed there.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #2)
> My trunk checkout is on r228497, and it indeed seems fixed there.

I checked out r228089 and the issue does not occur there either, but that's actually 2.19.90. I've been testing in our JHBuild environment. Looks like this bug cannot be reproduced inside the JHBuild environment.

I can reproduce 100% of the time in Epiphany Technology Preview.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #3)
> I can reproduce 100% of the time in Epiphany Technology Preview.

Nope, I immediately proved myself wrong. I'm not sure what the trigger for this is.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> Nope, I immediately proved myself wrong. I'm not sure what the trigger for
> this is.

I still don't know what the trigger is, and it doesn't happen on every video, but it's extremely easy to reproduce in Epiphany Technology Preview. I've failed to reproduce in our JHBuild environment after several attempts with the same WebKit version (r228089).

I hope none of our GStreamer patches are important. ;)

[Philippe Normand]

I can't make it fail here. I use


flatpak info -c org.gnome.Epiphany/x86_64/master
e65b4310b18508709ab1736772962b2e6a480fbe4f412dbdefb7e50d987a62ea


Besides, how can set env vars in flatpak apps? a GST_DEBUG="webkit*:6" might be useful...

[Michael Catanzaro]

(In reply to Philippe Normand from comment #6)
> Besides, how can set env vars in flatpak apps?

$ flatpak run --command=/bin/bash org.gnome.Epiphany
bash-4.3$ GST_DEBUG="webkit*:6" epiphany -p

> a GST_DEBUG="webkit*:6" might be useful...

Coming right up... I'll attach a log where I was able to reproduce on my first attempt. I tried several seeks on one video, and all failed.

(In reply to Philippe Normand from comment #6)
> I can't make it fail here. I use
> 
> 
> flatpak info -c org.gnome.Epiphany/x86_64/master
> e65b4310b18508709ab1736772962b2e6a480fbe4f412dbdefb7e50d987a62ea
> 
> 
> Besides, how can set env vars in flatpak apps? a GST_DEBUG="webkit*:6" might
> be useful...

I get a30337eb2e6ee8f8a6a7df8dca16ac48764467b7a8f6d486928167fd77f1b680. Who knows which of us has a newer version. I assume your about dialog shows WebKitGTK+ 2.19.90.

[Michael Catanzaro]

Created attachment 334280 [details]
Debug log

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #7)
> I get a30337eb2e6ee8f8a6a7df8dca16ac48764467b7a8f6d486928167fd77f1b680. Who
> knows which of us has a newer version. I assume your about dialog shows
> WebKitGTK+ 2.19.90.

It does use git master versions of GStreamer. I wonder if there is any nice way to figure out exactly what commit is in use. I tried:

$ flatpak run --command=/bin/bash org.gnome.Epiphany
bash-4.3$ gst-launch-1.0 --version
gst-launch-1.0 version 1.13.0
GStreamer 1.13.0 (GIT)
Unknown package origin

But that's not very useful, all we know is that it's some git commit before 1.13.1.

[Michael Catanzaro]

Just now, I ran:

$ flatpak update
$ flatpak info -c org.gnome.Epiphany/x86_64/master
202cecbf9455e0b23e842dbd63be5d5ba1bd4ecafb29379757167b44a1fafca3

to make sure I have the absolute latest. Can still reproduce the issue.

[Philippe Normand]

I'll check tomorrow after updating my flatpak and also I'll check ToT with gst git master.

[Philippe Normand]

The log indicates MediaPlayerPrivateGStreamer::doSeek() returns too early. "[Seek] seek attempt" is logged but not "[Seek] seeking".

I suspect this is the faulty early return, https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.19.90/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L482

[Michael Catanzaro]

Oooh, logs are good!

I'm not testing live streams, so you think isLiveStream() is returning true improperly?

The check is also not at the right place in the function; it should be somewhere above the declaration of MediaTime time since the time variable isn't needed there.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #13)
> Oooh, logs are good!
> 
> I'm not testing live streams, so you think isLiveStream() is returning true
> improperly?

Yes because in the log:
MediaPlayerPrivateGStreamer.cpp:1389:totalBytes: totalBytes 0

Can you add webkitweb*:6 in the GST_DEBUG please?

> 
> The check is also not at the right place in the function; it should be
> somewhere above the declaration of MediaTime time since the time variable
> isn't needed there.

Sure, why not :)

[Philippe Normand]

(In reply to Philippe Normand from comment #14)
> (In reply to Michael Catanzaro from comment #13)
> > Oooh, logs are good!
> > 
> > I'm not testing live streams, so you think isLiveStream() is returning true
> > improperly?
> 
> Yes because in the log:
> MediaPlayerPrivateGStreamer.cpp:1389:totalBytes: totalBytes 0
> 
> Can you add webkitweb*:6 in the GST_DEBUG please?

Ah no need, it's already there.

[Philippe Normand]

tl;dr: r228603 should be added in the 2.19 branch

I can reproduce the issue in ToT if:

- I revert r228603
- I force Youtube to send us a vp8 asset by removing libgstlibav.so from my JHBuild root.

But with ToT and libgstlibav.so removed, seek works.

So, Charlie fixed this issue :)

[Philippe Normand]

There's also the issue that our httpsrc element invalidates its total bytes duration cache when seeking, I don't think that makes any sense... I'll upload a separate patch for that...

[Philippe Normand]

See https://bugs.webkit.org/show_bug.cgi?id=183002

I think this can be closed then?

[Michael Catanzaro]

Yes, thanks!

[Radar WebKit Bug Importer]

<rdar://problem/37755510>

[Michael Catanzaro]

(In reply to Philippe Normand from comment #16)
> tl;dr: r228603 should be added in the 2.19 branch

It's already on the proposed backports list for 2.19.92. Unfortunately it just missed 2.19.91.

[Philippe Normand]

Right, I added it in the list after commenting here.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #21)
> (In reply to Philippe Normand from comment #16)
> > tl;dr: r228603 should be added in the 2.19 branch
> 
> It's already on the proposed backports list for 2.19.92. Unfortunately it
> just missed 2.19.91.

This comment is wrong; r228603 really *did* get backported in time for 2.19.91. Unfortunately, seek on YouTube it's definitely still broken in Epiphany Tech Preview with 2.19.91. Of course, it doesn't use any local extra codecs (or any local anything). Reopening. :(

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #23)
> Unfortunately, seek on YouTube it's definitely still broken in
> Epiphany Tech Preview with 2.19.91.

Of course, I meant to say "seek on YouTube is definitely still broken"

[Philippe Normand]

Can you attach debug logs then?

[Michael Catanzaro]

Created attachment 334939 [details]
Debug log

I see "[Seek] seek attempt" is logged but not "[Seek] seeking", just like in comment #12. So r228603 definitely did not fix this.

[Michael Catanzaro]

Note: r228945 is not in 2.19.91 and has not been backported; is it possible you fixed it there?

[Philippe Normand]

(In reply to Michael Catanzaro from comment #27)
> Note: r228945 is not in 2.19.91 and has not been backported; is it possible
> you fixed it there?

Yes that's it. Added this patch in the 2.19.92 list.

[Michael Catanzaro]

OK, fingers crossed....

[Michael Catanzaro]

We finally got a new build... it's indeed fixed in 2.19.92. Thanks!