Bug 201602 – [GTK] Cannot build WebKitGTK 2.26.0 with MSE in Debian stable

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

Commit r249205 bumped the GStreamer dependency from 1.14 to 1.16 for ENABLE_MEDIA_SOURCE

Debian stable (buster) ships GStreamer 1.14.4, and because of this it is not possible to build WebKitGTK with Media Source Extensions enabled.

[Philippe Normand]

Can you revert this patch in 2.26 please? I thought we had agreed to finally not ship this with so little time for testing before the 2.26.0 release.

[Carlos Garcia Campos]

I didn't know anything. Which patch exactly should I revert?

[Philippe Normand]

r249257

[Carlos Garcia Campos]

(In reply to Philippe Normand from comment #3)
> r249257

Oh, I explicitly asked whether I had to merge that one. It's supposed to fix things, no? I'm afraid I also merged other fixes on top that I would need to revert too. Isn't it possible to make current code work with 1.14? We'll have to do it in any case in trunk.

[Alicia Boya García]

(In reply to Carlos Garcia Campos from comment #4)
> (In reply to Philippe Normand from comment #3)
> > r249257
> 
> Oh, I explicitly asked whether I had to merge that one. It's supposed to fix
> things, no? I'm afraid I also merged other fixes on top that I would need to
> revert too. Isn't it possible to make current code work with 1.14? We'll
> have to do it in any case in trunk.

It fixes things (mostly seek bugs) but it also depends on playbin3 working well with it... Investigating if something could be done to have it work with 1.14 (and still use playbin3) is a non-trivial effort but could be done if it's important enough.

[Alberto Garcia]

The problem in a nutshell is that I cannot provide security updates (nor backports) of WebKitGTK 2.26 for Debian stable unless I disable the Media Source Extensions.

This arguably breaks the dependencies policy:

https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

[Carlos Garcia Campos]

(In reply to Alicia Boya García from comment #5)
> (In reply to Carlos Garcia Campos from comment #4)
> > (In reply to Philippe Normand from comment #3)
> > > r249257
> > 
> > Oh, I explicitly asked whether I had to merge that one. It's supposed to fix
> > things, no? I'm afraid I also merged other fixes on top that I would need to
> > revert too. Isn't it possible to make current code work with 1.14? We'll
> > have to do it in any case in trunk.
> 
> It fixes things (mostly seek bugs) but it also depends on playbin3 working
> well with it... Investigating if something could be done to have it work
> with 1.14 (and still use playbin3) is a non-trivial effort but could be done
> if it's important enough.

Again, we have to do this in trunk in any case.

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #7)
> (In reply to Alicia Boya García from comment #5)
> > (In reply to Carlos Garcia Campos from comment #4)
> > > (In reply to Philippe Normand from comment #3)
> > > > r249257
> > > 
> > > Oh, I explicitly asked whether I had to merge that one. It's supposed to fix
> > > things, no? I'm afraid I also merged other fixes on top that I would need to
> > > revert too. Isn't it possible to make current code work with 1.14? We'll
> > > have to do it in any case in trunk.
> > 
> > It fixes things (mostly seek bugs) but it also depends on playbin3 working
> > well with it... Investigating if something could be done to have it work
> > with 1.14 (and still use playbin3) is a non-trivial effort but could be done
> > if it's important enough.
> 
> Again, we have to do this in trunk in any case.

I don't mean using playbin3 with 1.14, it could simply have a fallback impl when gst < 1.16. I don't mind the solution as long as we can still build with < 1.16 and no regressions.

[Carlos Garcia Campos]

Created attachment 378643 [details]
Patch

[Alicia Boya García]

Splitting the MSE player in two is a *huge* burden for future maintenance and forward work in MSE. I don't want that to happen.

Please check this alternative solution to make 1.14 work with the new playbin3-based MSE player, which does not have that pitfall. https://bugs.webkit.org/show_bug.cgi?id=201824

[Carlos Garcia Campos]

This is no longer an issue