Restarting splitmuxsink fails

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

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
Reply | Threaded
Open this post in threaded view
|

Re: Restarting splitmuxsink fails

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