Trouble getting fully valid files with matroskamux

Pedro Côrte-Real pedro at pedrocr.net
Tue Dec 31 10:46:59 PST 2013


On Tue, Dec 31, 2013 at 5:51 PM, Todd Agulnick <todd at agulnick.com> wrote:
> I'm going to go out on a limb and suggest that you're now seeing with
> matroskamux the same problem that I was experiencing with mp4mux. We both
> need to send an EOS through the muxer to get it to "finalize" the file,
> which I gather means tacking on the metadata required for the file to be
> correct.

Discussing this with Tim on IRC you're exactly right. I haven't
implemented it yet but what I will do is:

On the probe callback:
- Inject EOS on the mux
- Keep the pad blocked (return OK)

On the bus callback
- Catch the EOS and ignore it
- Destroy the old mux and filesink
- Create a new mux and filesink
- Add the probe callback to the queue again
- Remove the old probe callback from the queue thus unblocking it and
letting the pipeline flow again

These two last steps are needed for lack of a
"gst_pad_probe_unblock()". slomo and wtay seemed to be discussing on
IRC that it could be a good addition.

> I'm not using matroska myself, but I seem to remember seeing that for
> matroskamux you can set "streaming=true" to avoid the need to finalize the
> file. But I'm sure there's some downside to doing that (increased file
> size?), otherwise what would be the point of "streaming=false"?

streaming=true does indeed work better for that case but I'd like to
have files that can be played individually properly.

Pedro


More information about the gstreamer-devel mailing list