Bug 203907 - [GStreamer] Twitter video freezes
Summary: [GStreamer] Twitter video freezes
Status: RESOLVED MOVED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-06 10:23 PST by Michael Catanzaro
Modified: 2019-12-02 09:29 PST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2019-11-06 10:23:53 PST 
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.
Comment 1 Philippe Normand 2019-11-07 07:02:51 PST 
Same symptom as #203465 ?
Comment 2 Philippe Normand 2019-11-07 07:23:37 PST 
Ah no, crash vs hang. nevermind
Comment 3 Philippe Normand 2019-11-07 07:35:02 PST 
Doesn't play at all here in Ephy TP 3.35.1-24-gcda92ff68.....
Comment 4 Philippe Normand 2019-11-07 07:39:19 PST 
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>
Comment 5 Michael Catanzaro 2019-11-14 12:47:47 PST 
This must be what we were discussing yesterday. Should it be reported upstream?
Comment 6 Philippe Normand 2019-11-15 02:25:09 PST 
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.
Comment 7 Philippe Normand 2019-11-15 02:28:35 PST 
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.
Comment 9 Michael Catanzaro 2019-12-02 06:02:50 PST 
Should this be closed?
Comment 10 Michael Catanzaro 2019-12-02 06:10:59 PST 
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?
Comment 11 Philippe Normand 2019-12-02 06:20:24 PST 
(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
Comment 12 Michael Catanzaro 2019-12-02 09:10:34 PST 
(In reply to Philippe Normand from comment #11)
> Backport where?

freedesktop-sdk and Fedora. Of course, a new GStreamer release is always much better....
Comment 13 Michael Catanzaro 2019-12-02 09:29:18 PST Comment hidden (spam)