Make dynamic recordings start at time zero

gotsring gotsring at live.com
Thu Aug 20 04:47:42 UTC 2020


I have a pipeline as follows:

souphttpsrc is-live=true location="http://192.168.8.162/mjpeg" ! queue !
jpegdec ! stamper ! videorate ! video/x-raw, framerate=20/1 ! tee name=t
    t. ! queue ! autovideosink
    t. ! queue ! appsink
    t. ! queue ! openh264enc ! h264parse ! splitmuxsink muxer=matroskamux
location=recording_%02d.mkv

The "stamper" element is actually a pad probe that sets the PTS of incoming
buffers to 'now' so that videorate correctly drops/duplicates buffers to get
a smooth 20 FPS, essentially doing the following:
    buffer->pts = gst_clock_get_time(pipeline_clock);


I dynamically add/remove the recording branch as needed which works in the
sense it produces a playable file. However, when playing the video with VLC,
the video start time is nonzero. 
For example, if I start the pipeline (without the recording branch), wait 2
minutes, then add the recording branch, the resulting video will have a
start time of 2 minutes and run until record duration + 2 minutes. 

Is there a way to zero this starting time without pausing/stopping the rest
of the pipeline? Would it be easier to do if after the fact? Since it's all
stored in a file, it'd be fine if I could zero the start time after
recording has finished. 

I tried a method similar to stamper that tries offsetting the buffer PTS by
saving the pipeline clock when the recording. (Pseudo-code below, I think
the math is slightly different, but I don't have the code in front of me.)

    // In start recording call
    record_start_time = gst_clock_get_time(pipeline_clock);

    // For each buffer coming into the recording branch (buffer pad probe)
    buffer->pts = gst_clock_get_time(pipeline_clock) - record_start_time;


This mostly works, except sometimes something goes wrong (though there are
no console messages). For example, a file from a 2-hour recording will show
a duration of 30 seconds and a start time of 57 hours. I create the elements
for the recording on demand, so I doubt it has something to do with a
difference in element creation time and when it's actually being used to
save to file.


In case it helps, here's my process for adding the recording branch:
 - Create a bin to hold all recording elements
 - Create the recording elements and add it to the bin
 - Set properties and link elements within the bin
 - Create a ghost-pad for the sink to connect to the tee.
 - Add the bin to the pipeline
 - Link the sink ghost pad to a tee request pad
 - sync_state_with_parent on the bin
 - Allow it to record



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/


More information about the gstreamer-devel mailing list