Restarting splitmuxsink fails

[jakehedlund]

Hi all,

I am attempting to add RTSP streaming and recording into my C# application
using GStreamer/GstSharp on Windows. So far everything is working fine: I
have created the pipeline with a tee splitting the stream for the display
sink and filesink. I can start and stop the preview at will (on button
presses), along with stopping/restarting the file recording. The basic
pipeline I'm using is as follows (but implemented in C#):

gst-launch-1.0.exe -e rtspsrc location=rtsp://192.168.3.250:554/cam0_0
latency=0 drop-on-latency=true ! rtph264depay ! video/x-h264 ! queue !
avdec_h264 max-threads=4 ! videoconvert ! textoverlay text="Testing 123" !
tee name=t ! queue ! autovideosink t. ! queue ! x264enc sliced-threads=true
tune=4 speed-preset=1 bitrate=8192 ! mp4mux ! filesink
location="C:\\gstreamer\\recording\\record_test.mp4"

The problem comes when I replace the mp4mux and filesink with splitmuxsink
(splitmuxsink location="C:\\gstreamer\\recording\\record_test%02d.mp4"
max-size-time=10000000000 max-size-bytes=10000000). The first time starting
the recording it works as expected, and saves multiple files as it should.
However, if I stop recording (send EOS to mux, set splitmuxsink state to
Null, remove from pipeline), then restart recording later, the preview
window freezes and/or the splitmuxsink does not record files properly. As
described above, doing the same operations using the filesink element works
fine; my goal is to split the recording into manageable chunks automatically
(I'm wondering if I should just be doing this "manually" from the
application level instead of trying to get this to work).

So what is the proper way to restart recordings using splitmuxsink? I've
tried searching but haven't found anything especially helpful...

Some more detail:
* I put the recording branch (queue ! x264enc sliced-threads=true tune=4
speed-preset=1 bitrate=8192 ! splitmuxsink) into its own bin to make
adding/removing easier to start/stop recording.
* I am adding a tee branch then blocking the pad with a padprobe as
described here:
https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html 
* When I remove the recording bin, I send an EOS, then unlink, then set the
record bin state to Null, then remove it from the main pipeline (is this
correct?).
* To start/restart the recording, I add a padprobe, then in the callback
re-add the record bin (same object as the one removed earlier - maybe this
is wrong and should be recreated from scratch?)
* I can post code, but it's rather long and messy. Let me know if anyone is
interested.

Thanks for any insight,
Jake



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jakehedlund]

jakehedlund wrote

> ...
>
> The problem comes when I replace the mp4mux and filesink with splitmuxsink
> (splitmuxsink location="C:\\gstreamer\\recording\\record_test%02d.mp4"
> max-size-time=10000000000 max-size-bytes=10000000). The first time
> starting
> the recording it works as expected, and saves multiple files as it should.
> However, if I stop recording (send EOS to mux, set splitmuxsink state to
> Null, remove from pipeline), then restart recording later, the preview
> window freezes and/or the splitmuxsink does not record files properly.
>
> ...
>
> * When I remove the recording bin, I send an EOS, then unlink, then set
> the
> record bin state to Null, then remove it from the main pipeline (is this
> correct?).
> * To start/restart the recording, I add a padprobe, then in the callback
> re-add the record bin (same object as the one removed earlier - maybe this
> is wrong and should be recreated from scratch?)

For the record, I was able to solve this issue by recreating the
splitmuxsink at the start of every recording session (inside the idle probe
callback which does the tee branch request and linking to the Recording
Bin).

I solved the other issue of corrupted/incomplete/unplayable recordings by
waiting for the EOS signal to be emitted from my Recording Bin. This was
tricky to figure out due to lack of documentation regarding listening to Bin
and sink EOS messages in C#. For anyone interested, it requires acting on
Element messages sent in the pipeline (MessageType.Element enum).

(Inside HandleMessage(object o, MessageArgs args) event handler)


Thanks for reading,
Jake



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[getashok]

Hello Jake,

Thank you for this post as I took lot of your recommendation for my work. I
am using Python.

I am currently working on using splitmuxsink to read a camera and split the
videos into 2 mins chunks based on a start and stop signal from application.

It does it perfectly and I followed your advice of build pipeline -> build
splitmuxsink-> set location/format location for customized file names ->add
sink -> play when start begins. When stops -> unlinking the splitmuxsink ->
removing it from pipeline -> set state Null. Basically reestablishing
splitmuxsink everytime, I begin recording based on the start signal from
application. While it writes the file, the files that were stopped midway
(stopped before 2 mins max time) are not playable. I am using H264 encoding.

I tried sending the EOS on the pipeline and also the element to catch it but
the message never gets send and the call back message function never gets
called.

Are there any other things I am missing?

Thanks again!



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Grant Burkhart]

The only way that I have been able to close the final file before going to
NULL state is to set a custom filesink.  Then I put an event probe of the
pad of the filesink and inject an EOS to the video pad of the splitmuxsink.
I wait until the EOS is received by the event probe before changing the
state.  

One of the big problems with restarting the splitmux sink is that it resets
the fragment id to zero, which could mean klobbering files that are already
there.    I modified splitmuxsink so that it takes as an argument the
initial fragment id, and I keep track of the fragment id using the signals
it emits.  

One reason why you have to delete and recreate splitmux sink is that it
doesn't reset all of the different times that are kept in the splitmuxsink
structure and the context.  I have tried resetting those times when the
splitmux sink goes to NULL, but I haven't yet made it work smoothly.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel