splitmuxsink, issues with max-size-time and exact duration

Tim-Philipp Müller t.i.m at zen.co.uk
Fri Jul 21 13:46:44 UTC 2023


Hi
 
> I found very strange issue with splitmuxsink and it’s  max-size-time
> property, namely
> given n sec. for desired duration, it’s actual duration would be n-2
> sec.  Initially I’ve discovered this
> issue while testing hand-coded pipeline, but then desided to
> reproduce the issue with gst-launch
> and observed the very same behaviour. Given 
> gst-launch-1.0 -e -v rtspsrc buffer-mode=0 add-reference-timestamp-
> meta=true
>  location=rtsp://user:pass@ip_addr/onvif/media?profile=Profile1 !
> rtph264depay ! h264parse ! splitmuxsink
> location="d:\\video_files\\video_%02d.mp4" max-size-time=10000000000
> (note, max-size-time=10000000000 is 10 sec in nanoseconds)
> the actual duration of files will be 8 sec.
> Same for 7→ 5, 5→ 3, and so on. So, it seems to be the pattern — set
> for n secodns, receive for n-2 seconds.
> Is it ok or maybe I miss something? I don’t think that it depends on
> rtps source.

I think it's somewhat expected that the file will be shorter than the
target duration - because the GOP size will be a few seconds and likely
won't be an exact multiple of the target-duration.

I believe splitmuxsink will send a force-key-unit request upstream for
the target time, but that only works if there's an encoder upstream (it
might get passed on to the rtsp camera, but may or may not be handled
or handled too late).

It's curious that it's always 2 seconds less than the target time
though, that should vary as you change the target duration and the GOP
size stays the same (assuming it's constant).

It would be good to know what GStreamer version you're using here.
There have been a few splitmuxsink fixes in that area over time.

Also, if you don't think it depends on the camera, you could capture an
input stream with

 rtspsrc ! application/x-rtp,media=video ! gdppay ! filesink
location=rtp_h264.gdp

and then it's possible to replay that and feed it to splitmuxsink to
see what's going on.

Cheers
 Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230721/310bd70c/attachment.htm>


More information about the gstreamer-devel mailing list