[Bug 793333] matroskademux: Allow Matroska headers to be read more than once

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk
           Severity|normal                      |enhancement

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at coaxion.net

y.bandou <bandou.yacine at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bandou.yacine at gmail.com

--- Comment #1 from Alicia Boya García <aboya at igalia.com> ---
This is necessary for MSE, where a new MSE initialization segment may be
appended at any point. These MSE initialization segments consist of an
entire WebM file until the first Cluster element (not included). [1]

Note that track definitions are ignored on successive headers, they must
match, but this is not checked by matroskademux (look for
`(!demux->tracks_parsed)` in the code).

Source pads are not altered when the new headers are read.

This patch has been splitted from the original patch from eocanha in [2].

[1] https://www.w3.org/TR/mse-byte-stream-format-webm/
[2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212

--- Comment #2 from Alicia Boya García <aboya at igalia.com> ---
Created attachment 368183
  --> https://bugzilla.gnome.org/attachment.cgi?id=368183&action=edit
matroskademux: Allow Matroska headers to be read more than once

This is necessary for MSE, where a new MSE initialization segment may be
appended at any point. These MSE initialization segments consist of an
entire WebM file until the first Cluster element (not included). [1]

Note that track definitions are ignored on successive headers, they must
match, but this is not checked by matroskademux (look for
`(!demux->tracks_parsed)` in the code).

Source pads are not altered when the new headers are read.

This patch has been splitted from the original patch from eocanha in [2].

[1] https://www.w3.org/TR/mse-byte-stream-format-webm/
[2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212

--- Comment #3 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
Maybe they must match in MSE but I think it's a perfectly valid use case to
have them change during normal streaming (even if rarely supported)?

--- Comment #4 from Alicia Boya García <aboya at igalia.com> ---
Could you provide an example? qtdemux already works this way.

--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
QuickTime is a different format. All I'm saying is that we probably shouldn't
make this assumption, but check and error out if not.

--- Comment #6 from Alicia Boya García <aboya at igalia.com> ---
It may be a different format, but we're talking about the same behavior:
finding metadata again at some point in the stream. Shouldn't both be
consistent?

For instance, it would be a bit weird if in WebKit code where I need to support
both I end up having to handle stream events just for one of the formats while
it's handled by the demuxer in the other.

--- Comment #7 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
This is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=334082 or
not? Also has a patch, also mentions MSE

--- Comment #8 from Alicia Boya García <aboya at igalia.com> ---
(In reply to Sebastian Dröge (slomo) from comment #6)
> This is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=334082 or
> not? Also has a patch, also mentions MSE

Not really, because the original problem in that patch is mostly unrelated to
MSE even if the discussion turned that way. I'll post a mega-reply there
explaining it soon.

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