Bug 203907 – [GStreamer] Twitter video freezes

• Status: RESOLVED
• Resolution: MOVED
• Component: Media

[Michael Catanzaro]

View the following video in Tech Preview (currently with WebKitGTK 2.26.1) with the OpenH264 extension installed to allow MP4 video playback:

https://twitter.com/alex_v_morrison/status/1185638510314885121

The video freezes after 4s. It shouldn't freeze.

[Philippe Normand]

Same symptom as #203465 ?

[Philippe Normand]

Ah no, crash vs hang. nevermind

[Philippe Normand]

Doesn't play at all here in Ephy TP 3.35.1-24-gcda92ff68.....

[Philippe Normand]

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>

[Michael Catanzaro]

This must be what we were discussing yesterday. Should it be reported upstream?

[Philippe Normand]

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.

[Philippe Normand]

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.

[Philippe Normand]

https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1119

[Michael Catanzaro]

Should this be closed?

[Michael Catanzaro]

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?

[Philippe Normand]

(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

[Michael Catanzaro]

(In reply to Philippe Normand from comment #11)
> Backport where?

freedesktop-sdk and Fedora. Of course, a new GStreamer release is always much better....

[Michael Catanzaro]

(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>