| Summary: | [GStreamer] Crash in gstbuffer.c on meet.gnome.org | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | bugs-noreply, jan.brummer, mcatanzaro, pnormand, youennf |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Linux | ||
|
Description
Michael Catanzaro
2020-07-26 13:26:56 PDT
(In reply to Michael Catanzaro from comment #0) > I've hit this twice testing WebRTC in my Ephy jhbuild on > https://meet.gnome.org (virtual GUADEC) after fixing bug #214806, but > haven't figured out how to reproduce (hence no debug log). One time I think > it happened when I tried to enable my video stream but then immediately > afterwards cancelled it, but I failed to reproduce. Hit it a third time after closing a browser tab while it was running https://meet.gnome.org, but again I've failed to reproduce it. If I could reproduce, then I could try to get a GStreamer log. Did you enable the media-stream setting in Ephy? I'd advise not to, because that enables only access to capture devices currently, which isn't very useful without a working webrtc backend at runtime. GStreamer is used in the libwebrtc backend for accessing capture devices, and also for some encoders and decoders. libwebrtc (when enabled) is mostly used for the peer-connection handling (ICE, networking, RTP payloading, depayloading, data channel, etc). I think we can assume that Michael enabled media-stream as otherwise it wouldn't be possible to join a webrtc session. And this is actually our goal: Enable webrtc within Epiphany as MiniBrowser works fine here for GUADEC and jitsi sessions. It works in MiniBrowser built using developer build CMake configuration because that enables WebRTC indeed. LibWebRTC is not enabled in release tarballs for several reasons: - possible licensing issue due to BoringSSL - bundling libwebrtc in tarballs significantly increases the tgz size - on embedded devices libwebrtc currently doesn't support hw-decoding / encoding - there's no upstream alternative to libwebrtc yet. I have a downstream branch adding a gstwebrtc backend to WebKit but it's highly experimental currently... (In reply to Philippe Normand from comment #4) > It works in MiniBrowser built using developer build CMake configuration > because that enables WebRTC indeed. I built WebKit trunk with -DDEVELOPER_MODE=ON -DENABLE_EXPERIMENTAL_FEATURES=ON and then changed ephy-embed-prefs.c to force on enable-media-stream. (In reply to Philippe Normand from comment #2) > Did you enable the media-stream setting in Ephy? I'd advise not to, because > that enables only access to capture devices currently, which isn't very > useful without a working webrtc backend at runtime. So far, I've only done this locally for experimentation. Of course the goal is to do it for real. :) (In reply to Michael Catanzaro from comment #6) > (In reply to Philippe Normand from comment #2) > > Did you enable the media-stream setting in Ephy? I'd advise not to, because > > that enables only access to capture devices currently, which isn't very > > useful without a working webrtc backend at runtime. > > So far, I've only done this locally for experimentation. Of course the goal > is to do it for real. :) What do you mean with "for real"? In production releases, for users. We'd need to talk about how to get there, but I have a strawman proposal in bug #214813 that might suffice until the gstwebrtc work is ready. We got quite excited yesterday when Jan-Michael revealed he was connected to our video call using WebKitGTK MiniBrowser, and then again a bit later when I got it working in my Ephy. ;) Asides from the crashes and lack of pipewire screen sharing, it works surprisingly well. Alternatively, if you want us to wait until the gstwebrtc work is ready, we have a community of Ephy users willing to help test various video calling sites. Yesterday we tried Jitsi Meet (broken), Big Blue Button (works), and BlueJeans (we think it will work after bug #214811 and bug #214812 are fixed). TODO: test Google Meet. At least for me and exalm Jitsi Meet worked fine. (In reply to Michael Catanzaro from comment #8) > In production releases, for users. We'd need to talk about how to get there, > but I have a strawman proposal in bug #214813 that might suffice until the > gstwebrtc work is ready. We got quite excited yesterday when Jan-Michael > revealed he was connected to our video call using WebKitGTK MiniBrowser, and > then again a bit later when I got it working in my Ephy. ;) Asides from the > crashes and lack of pipewire screen sharing, it works surprisingly well. > > Alternatively, if you want us to wait until the gstwebrtc work is ready, we > have a community of Ephy users willing to help test various video calling > sites. Yesterday we tried Jitsi Meet (broken), Big Blue Button (works), and > BlueJeans (we think it will work after bug #214811 and bug #214812 are > fixed). TODO: test Google Meet. I've been thinking about maintaining a flatpak browser app including my branch actually... but as this would be yet another hobby project for me, it's not very high priority, I try to do other things during my weekends :( FTR: Google Hangouts & Meets are working fine as well. Is there something we can do in the meantime to enable it until the gst part is ready? @Philippe: I tried your current gstwebrtc-2020 branch and it works somehow. I can join my meetings but audio is delayed and during session hangup MiniBrowser freezed once. But overall this work is impressive as the cpu load is much lower at the moment (due to audio?). master branch ~ 150%, your branch ~ 55%. Keep going :) Anyway we are getting a bit off topic here. Let's continue general WebRTC discussion in bug #214813, which exists to explore whether we can expose the current libwebrtc implementation or not. Let's use this bug for the gst_buffer_map_range() crash. What is this GStreamer version anyway? Looks like the GstMemory data points to some JS code, WTF? (In reply to Philippe Normand from comment #14) > What is this GStreamer version anyway? gstreamer1-1.16.2-2.fc32 > Looks like the GstMemory data points to some JS code, WTF? Memory corruption? Maybe having https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/a91ab7908955aa57f4c9ca52765d7cbe1cf5e71f would help... It is in the 1.16 branch but not in any 1.16 release yet. Is this still an issue after patching gst-plugins-base? Problem is I don't know a way to reproduce this one. Sometimes I saw it several times in a row but other times I went half an hour or more without hitting this crash. I don't think we can be confident whether this is fixed or not until we do way more testing than I'm able to volunteer.... |