Dynamic pipeline: record frames before mux/filesink is linked

Mon Jan 23 11:38:26 UTC 2023

Hi,

Now, that you mention it I think that appsrc/appsink is what I have seen 
people recommend other times for buffering scenarios, so I think you are 
in the right track.

And though it is more work to have 2 pipelines, it also has its 
advantages, as the decoupling will prevent errors from propagating 
between them.
And controlling the pipeline states and timing is easier when they are 
separated.

Best Regards

Marianna

On 23.01.2023 12.28, Sylvain wrote:
> 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”

-- 
Best regards / Med venlig hilsen
“Marianna Smidth Buschle”