Summary: | [GStreamer] Twitter video freezes | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
Component: | Media | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED MOVED | ||
Severity: | Normal | CC: | mcatanzaro, pnormand |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | PC | ||
OS: | Linux | ||
See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1778874 |
Description
Michael Catanzaro
2019-11-06 10:23:53 PST
Same symptom as #203465 ? Ah no, crash vs hang. nevermind Doesn't play at all here in Ephy TP 3.35.1-24-gcda92ff68..... After removing my GStreamer registry cache I can reproduce the problem... which is a bug in openh264: 0:00:00.401688992 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 2 0:00:00.418652145 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 4 0:00:01.447068389 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 8 0:00:01.498072192 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 0 0:00:03.300621381 257 0x5617bd9f58f0 WARN openh264dec :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Warning:referencing pictures lost due frame gaps exist, prev_frame_num: 14, curr_frame_num: 1 0:00:03.322809811 257 0x5617bd9f58f0 ERROR openh264dec :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Error:Ref Picture for B-Slice is lost, B-Slice decoding cannot be continued! 0:00:03.322859048 257 0x5617bd9f58f0 WARN openh264dec :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Warning:DecodeCurrentAccessUnit() failed (394291) in frame: 2 uiDId: 0 uiQId: 0 0:00:03.327560063 257 0x5617bd9f58f0 WARN openh264dec :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Warning:parse_nal(), no exist Sequence Parameter Sets ahead of sequence when try to decode NAL(type:1). 0:00:04.239162286 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 10 0:00:04.239582644 257 0x5617bda024f0 WARN tsdemux tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, stream 1 Reproducible with gst-play-1.0 <m3u8 url> This must be what we were discussing yesterday. Should it be reported upstream? The bug happens only in the flatpak runtime, as usual. I can't reproduce the bug in gst-build with the openh264 lib update to git master HEAD (987cc5f512416873aea6ef7b9acd8acea5b327b0). So either this was fixed in gst-plugins-bad git already, or in openh264. Oh, actually :) If I download the video with youtube-dl it plays fine locally, but if I play the HLS playlist, the bug happens. I'll report it. Should this be closed? Am I correct that it should be fixed in gst-plugins-bad 1.16.2? OK for me to backport https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/817.patch? (In reply to Michael Catanzaro from comment #10) > Am I correct that it should be fixed in gst-plugins-bad 1.16.2? > Yes :) > OK for me to backport > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/817. > patch? Backport where? (In reply to Michael Catanzaro from comment #9) > Should this be closed? Yes (In reply to Philippe Normand from comment #11) > Backport where? freedesktop-sdk and Fedora. Of course, a new GStreamer release is always much better.... (In reply to Philippe Normand from comment #4) > After removing my GStreamer registry cache I can reproduce the problem... > which is a bug in openh264: > > 0:00:00.401688992 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 2 > 0:00:00.418652145 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 4 > 0:00:01.447068389 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 8 > 0:00:01.498072192 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 0 > 0:00:03.300621381 257 0x5617bd9f58f0 WARN openh264dec > :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Warning:referencing > pictures lost due frame gaps exist, prev_frame_num: 14, curr_frame_num: 1 > 0:00:03.322809811 257 0x5617bd9f58f0 ERROR openh264dec > :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Error:Ref Picture for > B-Slice is lost, B-Slice decoding cannot be continued! > 0:00:03.322859048 257 0x5617bd9f58f0 WARN openh264dec > :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, > Warning:DecodeCurrentAccessUnit() failed (394291) in frame: 2 uiDId: 0 > uiQId: 0 > 0:00:03.327560063 257 0x5617bd9f58f0 WARN openh264dec > :0::<openh264dec0> [OpenH264] this = 0x0x7f8e64065440, Warning:parse_nal(), > no exist Sequence Parameter Sets ahead of sequence when try to decode > NAL(type:1). > 0:00:04.239162286 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 10 > > 0:00:04.239582644 257 0x5617bda024f0 WARN tsdemux > tsdemux.c:2402:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 0, > stream 1 > > Reproducible with gst-play-1.0 <m3u8 url> |