Dynamic pipeline: record frames before mux/filesink is linked

Sylvain sylgar at gmail.com
Mon Jan 23 11:28:52 UTC 2023


Hi, thanks for having taken the time to dive into this « issue ».

I think I realized the recording queue (any queue actually) does not queue any buffer on the sink side while it’s not linked on the src side, so it does not behave as a ring buffer until I dynamically link a mp4mux -> filesink pair to its src pad, contrary to what I was expecting. Indeed there are some « buffer discarded: reason not-linked » debug messages which make me think so.

So, unless somebody has a better idea, I will resort to link an appsink to the recording queue, and develop my own ring buffer logic inside the appsink, and whenever I need to record I will create a secondary (unrelated) pipeline with appsrc -> mp4mux -> filesink, feeding the ring buffer to the appsrc.

Some fun ahead!


> Le 23 janv. 2023 à 12:18, Marianna Smidth Buschle <msb at qtec.com> a écrit :
> 
> Hi
> You can try installing a buffer probe on the queue and checking the levels to figure out what is going on.
> And listening to the overrun signal.
> You might also try taking a look at the `min-threshold-` properties.
> Best regards
> 
> Marianna
> On 22.01.2023 13.00, gstreamer-devel-request at lists.freedesktop.org wrote:
>> Send gstreamer-devel mailing list submissions to
>> gstreamer-devel at lists.freedesktop.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> or, via email, send a message with subject or body 'help' to
>> gstreamer-devel-request at lists.freedesktop.org
>> 
>> You can reach the person managing the list at
>> gstreamer-devel-owner at lists.freedesktop.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of gstreamer-devel digest..."
>> 
>> 
>> Today's Topics:
>> 
>> 1. Dynamic pipeline: record frames before mux/filesink is linked
>> (Sylvain Garrigues)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Sat, 21 Jan 2023 19:16:16 +0100
>> From: Sylvain Garrigues <sylgar at gmail.com>
>> To: gstreamer-devel at lists.freedesktop.org
>> Subject: Dynamic pipeline: record frames before mux/filesink is linked
>> 
>> Message-ID: <3196DBB7-8007-4825-BD43-AA70AF1213FD at gmail.com>
>> Content-Type: text/plain; charset=utf-8
>> 
>> Hello,
>> 
>> I?m trying to setup a pipeline which can record parts of the currently displayed stream on demand (I have a ctrl-c handler installed which start/stop the recording), INCLUDING 5 seconds before the signal is emitted. It works perfectly except the recording doesn?t start 5 seconds before the signal but 2/3 seconds after.
>> 
>> I have this pipeline:
>> filesrc location="longvideo.mp4" -> qtdemux -> tee -> queue -> h264parse -> ? -> autovideosink
>> On the other branch of the tee i.e. the recording one I have: tee -> queue (named queue_recording)
>> 
>> I have set the recording queue to act like a 10 seconds ring buffer:
>> queue_recording.set_property_from_str("max-size-time", "10000000000");
>> queue_recording.set_property_from_str("max-size-buffers", "0");
>> queue_recording.set_property_from_str("max-size-bytes", "0");
>> queue_recording.set_property_from_str("leaky", "2");
>> 
>> (This is Rust code).
>> 
>> I have the pipeline playing and start watching the video.
>> 
>> When I hit ctrl-C and my program detects it, it add matroskamux -> filesink location="record.mkv" to the pipeline and link the video_0 sink pad of the matroskamux to queue_recording which was already there.
>> 
>> Since I hit ctrl-c more than 10 seconds after the video is playing, I expected the resulting record.mpv to display frames from 10 seconds before the crtl-c signal since the queue_recording has stored those frame on the sink side and there was no consumer on the src side before the matrosmamux was linked.
>> 
>> 
>> Can anybody explain me why I don?t get what I expect (the recording starting 10 seconds before the signal), and how you would solve my problem? 
>> 
>> 
>> I already manage, when hitting ctrl-c another time to stop the recording, to block the src_1 pad of the tee win a probe and send an EOS to the queue and unlink it, and when the pipeline bus gets the eos message from filesink (via message forward), I can remove the queue / matroskamux / filesink pair - just waiting for another signal to start another recording. I can share the source code if needed. 
>> 
>> Best
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> 
>> 
>> ------------------------------
>> 
>> End of gstreamer-devel Digest, Vol 144, Issue 28
>> ************************************************
>> 
> -- 
> Best regards / Med venlig hilsen
> “Marianna Smidth Buschle”



More information about the gstreamer-devel mailing list