Summary: | [GStreamer] Another crash under gst_element_add_pad | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||||||||
Component: | Media | Assignee: | Philippe Normand <pnormand> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | aperez, bugs-noreply, calvaris, cgarcia, ews-watchlist, gustavo, mcatanzaro, menard, pnormand, vjaquez, webkit-bug-importer | ||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||
Version: | WebKit Nightly Build | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Linux | ||||||||||||
Attachments: |
|
Description
Michael Catanzaro
2021-05-13 07:05:56 PDT
Created attachment 428513 [details]
GStreamer log
Created attachment 428514 [details]
Full backtrace (all threads)
I think this happens because your openh264dec decoder can't handle the progressive-high profile: :00:00.024920765 1419 0x7f20ac001aa0 WARN basetransform gstbasetransform.c:1362:gst_base_transform_setcaps:<capsfilter0> transform could not transform video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, level=(string)3.2, profile=(string)progressive-high, width=(int)1366, height=(int)684, framerate=(fraction)24000/1001, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true in anything we support Plugin Details: Name openh264 Description OpenH264 encoder/decoder plugin Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstopenh264.so Version 1.16.3 License BSD Source module gst-plugins-bad Binary package GStreamer Bad Plug-ins source release Origin URL freedesktop-sdk ... SINK template: 'sink' Availability: Always Capabilities: video/x-h264 stream-format: byte-stream alignment: au profile: { (string)constrained-baseline, (string)baseline, (string)main, (string)high } Also this shouldn't happen: 0:00:00.033920128 1419 0x7f20ac001aa0 DEBUG webkitimagedecoder ImageDecoderGStreamer.cpp:242:connectDecoderPad:<image-decoder-1> New decodebin pad <decodebin3-1:audio_0> caps: audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)[ 8000, 96000 ], channels=(int)[ 1, 8 ] I'll try to reproduce the issue but I already suspect this might be a bug in your old gst 1.16.3 :) Can you backport this patch in your runtime? https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/8bf7816790aa4e963319f3333edec9646a558765 Without it I think the stream selection in the image decoder might not work because the collection owner might not be decodebin3 so the decoder is not sending the select-streams event aimed to select only video streams. If you can modify WebKit in your runtime, in ImageDecoderGStreamer.cpp line 332 after the gst_message_parse_stream_collection() call add some logging: gst_printerrln("collection: %p owner: %s", collection.get(), GST_MESSAGE_SRC_NAME(message)); I can't reproduce this with the WebKit SDK... Also this page is weird, it uses a <video> element that has the src and poster attributes set to the same (video) URL. Why on earth would you do that? (In reply to Philippe Normand from comment #5) > Can you backport this patch in your runtime? > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/ > 8bf7816790aa4e963319f3333edec9646a558765 > > Without it I think the stream selection in the image decoder might not work > because the collection owner might not be decodebin3 so the decoder is not > sending the select-streams event aimed to select only video streams. Will do. (In reply to Philippe Normand from comment #5) > If you can modify WebKit in your runtime, in ImageDecoderGStreamer.cpp line > 332 after the gst_message_parse_stream_collection() call add some logging: > > gst_printerrln("collection: %p owner: %s", collection.get(), > GST_MESSAGE_SRC_NAME(message)); It's possible, but it's a real pain. Will see if I find time for it next week.... (In reply to Philippe Normand from comment #5) > Can you backport this patch in your runtime? > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/ > 8bf7816790aa4e963319f3333edec9646a558765 Done. Sadly it didn't fix this crash. (In reply to Michael Catanzaro from comment #7) > It's possible, but it's a real pain. Will see if I find time for it next > week.... Still TODO for me. This was... hard. I built a modified runtime with WebKit, following the instructions at https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/README.rst. (Yes, it appears that I wrote those instructions, but I really just copied them from somewhere.) I couldn't figure out how to run it with an application, so had to rebuild the runtime to enable -DMINIBROWSER=ON because we have that off by default for some reason. Eventually I figured out the incantation to make MiniBrowser work: $ flatpak run --command=/bin/bash -d --socket=wayland --device=dri --share=ipc --share=network --socket=pulseaudio --filesystem=home org.gnome.Platform [📦 org.gnome.Platform ~]$ export GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 [📦 org.gnome.Platform ~]$ /usr/libexec/webkit2gtk-4.0/MiniBrowser https://www.warbyparker.com/eyeglasses/lenses collection: 0x7f4e8c01c030 owner: decodebin3-0 ** (WebKitWebProcess:160): WARNING **: 19:45:08.074: Warning: 11, not negotiated. Debug output: ../libs/gst/base/gstbasetransform.c(1423): gst_base_transform_reconfigure (): /GstPipeline:image-decoder-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstCapsFilter:capsfilter0: not negotiated ** (WebKitWebProcess:160): WARNING **: 19:45:08.075: Error: 1, Internal data stream error.. Debug output: ../gst/isomp4/qtdemux.c(6619): gst_qtdemux_loop (): /GstPipeline:image-decoder-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux0: streaming stopped, reason not-negotiated (-4) ** (MiniBrowser:3): WARNING **: 19:45:09.510: WebProcess CRASHED I'll attach the gst.log it produced as well, though I guess you probably don't need it, since in theory it should match the original log more or less? Except note that OpenH264 isn't present here (it's only present in my system install, but I followed the instructions to use my user install). Anyway, the most important point was the debug you requested: collection: 0x7f4e8c01c030 owner: decodebin3-0. It took several hours to get that, so I hope it was worth it. :P Created attachment 430460 [details]
GStreamer log from custom-built runtime
(Forgot to attach the log.)
After locally reverting these 2 in my -bad checkout: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1634 https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1789 I can reproduce the warnings (caps negotiation failing), but not the crash. In any case, I would advise to backport these 2 MRs in your runtime, if you can. I'll try to reproduce the crash... I could reproduce the crash after reverting: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/b41b87522f59355bb21c001e9e2df96dc6956928 This is not a WebKit bug. Please update your runtime :) I've confirmed the GNOME master runtime currently has gst-plugins-bad and gst-plugins-base 1.16.3, which is the latest 1.16 release. This is what GNOME will stick with until we update to freedesktop-sdk 21.08. That' Whoops. "That's probably coming soon." I'm a little concerned that the GStreamer release cycle has become quite disconnected with GNOME's, but that's not an issue to be solved on WebKit Bugzilla. One thing we could do though, avoid the RELEASE_ASSERT in case gst < 1.18 is found... (In reply to Philippe Normand from comment #16) > One thing we could do though, avoid the RELEASE_ASSERT in case gst < 1.18 is > found... Yeah let's do that, I suppose Debian could run into the same crash. Created attachment 431452 [details]
Patch
Committed r278892 (238834@main): <https://commits.webkit.org/238834@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 431452 [details]. |