[GStreamer] Let playbin handle redirects for us when appropriate

• Component: Media
• Status: RESOLVED FIXED

[Philippe Normand]

Because in MediaPlayerPrivateGStreamer::loadNextLocation() the security-origin check fails.

[Philippe Normand]

Original url example: https://movietrailers.apple.com/movies/wb/shazam/shazam-trailer-2_480p.mov
Redirected url example: http://movietrailers.apple.com/movies/wb/shazam/shazam-trailer-2_h480p.mov

I suppose the origin check fails because the new url doesn't use https?

[Michael Catanzaro]

Yup, the different protocol means it's a totally different security origin with no permission to access the other. Security origin is <protocol, host, port> (except in Internet Explorer, where port is not considered).

[Thibault Saunier]

To me the issue is in the REDIRECT is incorrect, it should point to the `https` variant.

chrome or firefox are not able to play that stream either, for some reason Safari is.

I would just close the bug tbh.

[Philippe Normand]

Hi Eric,

Can you shed some light here, maybe?
Is this a server-side issue? Why is Safari not affected?

[Philippe Normand]

Trailers play fine in Chromium here.

[Thibault Saunier]

I proposed patches in GStreamer to allow a better handling of redirection in case of quicktime streams with no tracks so playbin can support it for us, see:

- https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/419/diffs
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/merge_requests/340

This makes thing simpler and cleaner for us, let's see how it goes there :-)

[Thibault Saunier]

Created attachment 379836 [details]
Patch

[Xabier Rodríguez Calvar]

Comment on attachment 379836 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=379836&action=review

> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:2170
> +        g_object_get(m_pipeline.get(), "current-uri", &playbinUrlStr.outPtr(), NULL);

nullptr

[Thibault Saunier]

Created attachment 380017 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 380017 [details]
Patch for landing

Rejecting attachment 380017 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 380017, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in Source/WebCore/ChangeLog contains OOPS!.

Full output: https://webkit-queues.webkit.org/results/13087437

[Thibault Saunier]

Created attachment 380018 [details]
Patch for landing

[Philippe Normand]

Comment on attachment 380018 [details]
Patch for landing

JHBuild bits missing?

[Thibault Saunier]

(In reply to Philippe Normand from comment #12)
> Comment on attachment 380018 [details]
> Patch for landing
> 
> JHBuild bits missing?

Oops, indeed, fixing that

[Thibault Saunier]

Created attachment 380047 [details]
Patch for landing

[Philippe Normand]

Comment on attachment 380047 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=380047&action=review

> Tools/gstreamer/jhbuild.modules:85
> +      <patch file="good-0001-qtdemux-Specify-REDIRECT-information-in-error-messag.patch" strip="1"/> <!-- Merged upstream, should be shipped in 1.16.1 -->

1.16.2 :)

[WebKit Commit Bot]

Comment on attachment 380047 [details]
Patch for landing

Clearing flags on attachment: 380047

Committed r250624: <https://trac.webkit.org/changeset/250624>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/55921354>