Correctly terminating a recording with multiple sources

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Correctly terminating a recording with multiple sources

Adam Goodwin
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!)

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Correctly terminating a recording with multiple sources

Thiago Santos
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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel