Bug 309824 – [GStreamer][MSE] Some Youtube videos don't play

• Component: New Bugs
• Status: RESOLVED FIXED

[Przemyslaw Gorszkowski]

On https://www.igalia.com/industry/digital-tv there is a "featured media" : video "Signal in the streams" does not start at all. I attached gst logs and dots file.

[Przemyslaw Gorszkowski]

Created attachment 478653 [details]
GST logs

[Przemyslaw Gorszkowski]

Created attachment 478654 [details]
dots

[Fujii Hironori]

This is reproducible on YouTube.
https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K

[Philippe Normand]

Well at least it works in 2.51.93. The bug seems to happen in main only, maybe I can bisect this actually.

[Philippe Normand]

(In reply to Fujii Hironori from comment #3)
> This is reproducible on YouTube.
> https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K

But only that one?

https://www.youtube.com/watch?v=dQw4w9WgXcQ plays fine in main :(

[Philippe Normand]

https://www.youtube.com/watch?v=yLdeJMA9TgU : NOK
https://www.youtube.com/watch?v=ZEFNrZ4L15I : OK

[Philippe Normand]

I have dumped the audio and video MSE inputs to disk, the video is correctly demuxed, but the audio/webm isn't. So this might be a bug in matroskademux.

[Philippe Normand]

(In reply to Philippe Normand from comment #7)
> I have dumped the audio and video MSE inputs to disk, the video is correctly
> demuxed, but the audio/webm isn't. So this might be a bug in matroskademux.

That's for https://www.youtube.com/watch?v=yLdeJMA9TgU

But on https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K the input is OK...

[Philippe Normand]

For https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K I think the issue is related with the video content being encoded in h.264 with B-frames, the SourceBuffer ends-up removing most parsed samples and that triggers a re-enqueue, leading to the same removal, and so on...

[Philippe Normand]

I experimented a bit with h264timestamper which makes DTS values monotonically increasing and then reorder samples by PTS before passing them to the SourceBuffer... which that I could hear the first second of audio but video quickly stopped because the decoder detected non-monotonic DTS (due to reordering of samples on PTS)...

I think this should be somehow handled in the SourceBufferPrivate, there's supposedly code there to handle B-frames already, but it doesn't seem to work for us...

[Philippe Normand]

Created attachment 478728 [details]
log

[Vivienne Watermeier]

PR: https://github.com/WebKit/WebKit/pull/62362

The issue was that this video uses b-frames, and is encoded at only 6 FPS. Since we don't support MP4 edit lists yet, b-frames can cause an initial gap in PTS, and with such a low framerate, that gap exceeds the current 100ms threshold we have set as workaround for fixing these gaps. The workaround here is just to increase that threshold, but this comes with the risk to cause regressions elsewhere, since all of this is just a hack until we have edit list support.

[EWS]

Committed 312603@main (a3dfc3da7f4d): <https://commits.webkit.org/312603@main>

Reviewed commits have been landed. Closing PR #62362 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/176250205>

[EWS]

Committed 305877.480@webkitglib/2.52 (8da736e1c95b): <https://commits.webkit.org/305877.480@webkitglib/2.52>

Reviewed commits have been landed. Closing PR #64298 and removing active labels.