Correctly terminating a recording with multiple sources

[Adam Goodwin]

Thanks for the info guys, in particular the mkvalidator tool.

Thiago, as to your first question, yes; when I play the files with my
playback GStreamer application they perform much better. With my playback
application the video streams might still skip around a bit, or one of them
might get stuck on a frame, but they do always play through whereas with
VLC they might not even play more than a frame.

I ran mkvalidator on a several of my output MKV files, and I only ever got
these warnings/errors (with varying timestamps etc):

ERR200: Missing element 'Targets' in Tag at 47758217
WRN0C2: The timecode of the Cluster at 6177 is not incrementing (may be
intentional)
WRN311: The Cues entry for timecode 438 ms is listed after entry 559 ms
WRN0B8: Track #3 is defined but has no frame
ERR0B1: SimpleBlock at 2889352 track #2 is not a keyframe

Some more info:

ERR200 seems to occur once for every file.
WRN0C2 only shows up for a few files a couple of times.
WRN311 is the same as above, it shows up in some files a few times.
WRN0B8 only happens if I don't add any subtitles to the subtitle track, so
that's to be expected.
ERR0B1 seems to correlate most with how poorly my MKV file displays in VLC.
For example, in a 17 second file (which VLC only manages the first second
or so of) this error comes up 35 times. It definitely seems that this is
the biggest issue. Files that play fairly well with VLC don't have many of
these errors, but they still do have a few.

I'm not sure where to go from here, but at least now I know what the
problems with the files are - so thanks a bunch for that. I'll have to try
to figure out if it's something I'm doing which is causing these problems.

Thanks again




On Thu, Sep 12, 2013 at 12:38 AM, Thiago Sousa Santos <
thiago.sousa.santos at collabora.com> wrote:

> On Qua, 2013-09-11 at 18:55 +1200, Adam Goodwin wrote:
> > Hi again,
> >
> >
> > For my C application, which records multiple camera streams to file
> > (and kind of records subtitles), I've had plenty of issues with my MKV
> > files being played in unexpected ways by VLC. But if my pipeline only
> > ever records one stream to the MKV file, it seems to be perfect every
> > time. If there is more than one stream going into the matroskamux
> > (irrespective of it being a video or subtitle stream) this is when I
> > start getting problems with VLC; such as the progress through the
> > video not being correctly displayed.
> >
> >
> > I've now realised that I never made sure I was terminating the
> > recording properly. I don't think this is the one single cause of all
> > my application's problems, but I do remember that a guaranteed way to
> > get a broken MKV file is to not end the stream correctly.
> >
> >
> > Currently my application terminates upon user request. This is done
> > through standard input. When the command is entered by the user, my IO
> > callback recognises it and generates an EOS event as follows:
> >
> > gst_element_send_event(pipeline, gst_event_new_eos());
> >
> >
> > Then, as per most of the examples in the manual, I watch the GStreamer
> > bus for a message of type GST_MESSAGE_EOS. When this message is seen,
> > I immediately call g_main_loop_quit(loop) and the pipeline is set to
> > GST_STATE_NULL before being deleted.
> >
> >
> > I don't know how exactly the sending of the EOS event works, but I
> > understand that the EOS *message* doesn't appear until all sinks in
> > the pipeline have received and handled the EOS event.
> >
> >
> > Out of curiosity I have tried sending an EOS event to every source
> > element, instead of just sending one to the pipeline as a whole, but
> > this has made no difference. I have verified though that if I miss a
> > source element out, then the EOS bus message doesn't arrive and the
> > application doesn't shut down.
> >
> > So from this I am led to believe that the matroskamux doesn't emit the
> > EOS event from its source pad unless it has received one from all of
> > its sink pads. This would indicate to me that I am doing things
> > correctly, and that the MKV file should be getting terminated
> > correctly by the muxer, but it certainly doesn't work out that way.
> >
> >
> > Long story short, is my current approach correct? And if not, what is
> > the correct way to shut down my pipeline? (Thanks for reading all of
> > this!)
>
> It should be the correct approach, yes. Have you checked if the
> resulting file could be played with gstreamer itself?
>
> gst-launch-1.0 playbin uri=file:///path/to/file
>
> Or maybe inspecting the file with some mkv parsing tool:
> http://www.matroska.org/downloads/mkvalidator.html
> http://www.bunkus.org/videotools/mkvtoolnix/
>
> It could also be a bug in VLC itself.
>
> --
> Thiago
>
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130912/24796566/attachment-0001.html>