<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>Hi</div><div> </div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I found very strange issue with splitmuxsink and it’s max-size-time property, namely</div><div>given n sec. for desired duration, it’s actual duration would be n-2 sec. Initially I’ve discovered this</div><div>issue while testing hand-coded pipeline, but then desided to reproduce the issue with gst-launch</div><div>and observed the very same behaviour. Given </div><div>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</div><div>(note, max-size-time=10000000000 is 10 sec in nanoseconds)</div><div>the actual duration of files will be 8 sec.</div><div>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.</div><div>Is it ok or maybe I miss something? I don’t think that it depends on rtps source.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Also, if you don't think it depends on the camera, you could capture an input stream with</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>rtspsrc ! application/x-rtp,media=video ! gdppay ! filesink location=rtp_h264.gdp</div><div><br></div><div>and then it's possible to replay that and feed it to splitmuxsink to see what's going on.</div><div><br></div><div>Cheers</div><div> Tim</div><div><span style="font-size: 14.666667px;"><br></span></div><div><span></span></div></body></html>