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