Summary: | [GStreamer][MSE] Fix player private selection when MSE is enabled | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Enrique Ocaña <eocanha> | ||||
Component: | Platform | Assignee: | Enrique Ocaña <eocanha> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | calvaris, commit-queue, pnormand | ||||
Priority: | P2 | ||||||
Version: | WebKit Local Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 164022 | ||||||
Attachments: |
|
Description
Enrique Ocaña
2016-10-28 02:32:34 PDT
Created attachment 293131 [details]
Patch
Comment on attachment 293131 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293131&action=review Anyway, if this fix only the crashes, I would wait for a more complete solution unless the solution for other bugs is incremental. > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:275 > + // Properly fail so the global MediaPlayer tries to fallback to the next MediaPlayerPrivate. Make this comment a GST_TRACE. That way we can follow what is going on. > Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:129 > + // Properly fail so the global MediaPlayer tries to fallback to the next MediaPlayerPrivate. Ditto > Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:136 > + if (UNLIKELY(!initializeGStreamerAndRegisterWebKitMSEElement())) > + return; ASSERT_NOT_REACHED(). Maybe it could be interesting to do the same in other places, but it is not urgent and can be done in other bug. Comment on attachment 293131 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293131&action=review >> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:275 >> + // Properly fail so the global MediaPlayer tries to fallback to the next MediaPlayerPrivate. > > Make this comment a GST_TRACE. That way we can follow what is going on. Are you sure we can use GStreamer logging facilities (potentially) *before* having initialized GStreamer? gst_init() needs to be called before using the logging macros. (In reply to comment #4) > gst_init() needs to be called before using the logging macros. But in this case the logging is to be done before initializing GStreamer. Is it still worth to initialize GStreamer to log something that is supposed to be part of the normal behaviour of the player? (yield other players when the content isn't appropriate for this one). In the OWR player, for instance, nothing is logged: https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerOwr.cpp#L126 (In reply to comment #5) > (In reply to comment #4) > > gst_init() needs to be called before using the logging macros. > > But in this case the logging is to be done before initializing GStreamer. Is > it still worth to initialize GStreamer to log something that is supposed to > be part of the normal behaviour of the player? (yield other players when the > content isn't appropriate for this one). No. > > In the OWR player, for instance, nothing is logged: > > https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/ > graphics/gstreamer/MediaPlayerPrivateGStreamerOwr.cpp#L126 (In reply to comment #3) > Are you sure we can use GStreamer logging facilities (potentially) *before* > having initialized GStreamer? Forget it then. Does the patch needs an update then? It'd be great to re-enable MSE on the bots ASAP :) (In reply to comment #8) > Does the patch needs an update then? According to Quique, this only covers the crashes but there are still a couple of tests that fail so the patch is incomplete. We could land this, but then we would need another bug[s] to track the other failures that Quique reported. > It'd be great to re-enable MSE on the bots ASAP :) Oh yes, we could even make the option public so that you could see that it is enabled when you build it ;) The rest of the test fixes are going to be submitted in other bugs. Can this patch have r+ in its current state, even if it's cq+ later? Comment on attachment 293131 [details] Patch Clearing flags on attachment: 293131 Committed r209796: <http://trac.webkit.org/changeset/209796> All reviewed patches have been landed. Closing bug. |