[Bug 334082] matroskademux: support for multi-segment Matroska files

[GStreamer (GNOME Bugzilla)]

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

Enrique Ocaña González <eocanha at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eocanha at igalia.com

--- Comment #14 from Enrique Ocaña González <eocanha at igalia.com> ---
Created attachment 362212
  --> https://bugzilla.gnome.org/attachment.cgi?id=362212&action=edit
Alternative version of the patch. Honors the DISCONT flag to produce the right
GstSegments.

I found the issue described on this bug last week while analyzing why YouTube
2018[1] test "20. VideoBufferSize" failed for us in WebKitGTK+.

What the test does in our case is to append (to process) the same 1MB video
file[2] one time after another. It expects to get [0, 1] PTSs each time and
uses SourceBuffer.offset to convert that into [0, 1][1, 2][2, 3][etc.]

That file starts with a GST_EBML_ID_HEADER which is expected in the
GST_MATROSKA_READ_STATE_START stage but can't be parsed while in
GST_MATROSKA_READ_STATE_DATA. In fact, the demuxer never goes out of that DATA
state.

The solution I finally got during the GStreamer Hackfest was very similar to
Yacine's. I just found this bug later when Yacine told me about it the days
after, during the Gstreamer Conference. X-D

One additional issue I found was that, even if we "convince" matroskademux to
expect GST_EBML_ID_HEADER in the DATA state so it goes on and outputs the
buffers, the demuxer will also generate GstSegments starting from the last
output PTS. This means that the newly generated buffers (starting from 0 in my
test case) will be out of the GstSegment and thus will be ignored by the
decoder and/or the sink.

I asked Sebastian about that issue and how similar it is to the TFDT issue in
qtdemux[3]. He suggested to modify our app (WebKit) to set the DISCONT flag on
the appended buffers and to honor that flag in matroska demux and reset the
segment position. This basically works for me with my specific test case.

I acknowledge that my test case has some particularities that somehow makes it
special and not generalizable:

- The number of streams and its caps remains constant (as it's the same data).
According to the pipeline dumps, matroskademux doesn't seem to create extra
pads and just reuses the existing ones.
- All the chunks start from 0. I don't know what would happen if the data in a
new append wanted to generate eg: [5, 6] instead of always [0, 1]. I guess I'll
find out when I focus on the next tests.

Another thing that I don't understand completely is why my patch works (for me)
even though what I do to prepare the transition to
GST_MATROSKA_READ_STATE_SEGMENT is simpler than what Yacine does.


[1]
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html
[2]
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/media/vp9-video-1mb.webm
[3] https://bugzilla.gnome.org/show_bug.cgi?id=754230

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