[Bug 794199] qtdemux: Premature EOS when some files are played in push mode

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=794199

--- Comment #1 from Alicia Boya García <aboya at igalia.com> ---
(In reply to Alicia Boya García from comment #0)
> The `stream->on_keyframe` check is also interesting. I have not experimented
> with it too much, but on first glance it looks like it would avoid entering
> the `if` body on most files, which would explain why this issue has not been
> detected before. Since most GOPs are longer than 3 frames and for most files
> with basic edit lists, like the one attached, the buffer PTS match can only
> occur in the last GOP, the chances of it happening on both buffer PTS =
> segment.stop and exactly the next frame after an I-frame are quite low. (EOS
> is sent later because as a reaction of upstream sending EOS itself when
> there are no more bytes to read, not because of last frame emission*).

The check is for the first frame *outside* of the seek segment, so it makes no
difference for regular playback where stop is unbounded or bounded to the end
of the file, since there should not be any frames past that. In cases where
there are such frames, they will be pushed until the next keyframe is reached,
but the sinks can ignore those frames. Albeit in a slightly inefficient way,
this ensures that decode dependencies are fulfilled.

> * To make things worse, our WebKit MSE implementation actually relies on EOS
> not being sent on last frame emission when working on push mode. Today I've
> learned that is the case most often but not always.

This should not be a problem in most files for the reason explained above. It
could become a problem if someone made a file with an edit list or
mvhd.duration that truncated the file in the middle though, but that's a
problem unrelated to the bug currently being discussed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.