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/