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

Armin Erkert armin.erkert at rolmail.net
Fri Jul 21 12:32:28 UTC 2023 


Hi,

a compressed stream as H264 is a sequence of I-frames and B-frames. A I 
frame decribes

fully a frame, and B-frames has only information of changes to the 
previous I frame. In a stream

evry GOP-size is inserted a I frame.

Splitmuxsink can only split at a I frame, because a file needs to 
beginning with an I frame.

So,if you have a GOP-Size of 1.5 seconds (also I frames at 0 sec, 1.5 
sec, 3.0 sec, 4.5 sec ...)

and you set split max-size-time to 4 seconds, splitmux splits at the 
nearest previous I-frame,

which is at 3.0 seconds.

That's all, redcue the GOP Size in your RTP-Stream and it will work fine 
... or transcode the stream

(decoding and encoding with another gop-size)

Am 21.07.2023 14:18, schrieb Антон Шаров via gstreamer-devel:

> I just checked data more carefully, when I set 5 sec., it's actual 
> length in major cases is 3.9* seconds
> so media player shows 3 seconds. Seems strange to me that the case with 
> 4.9* seconds (which is almost
> 5 seconds as desired) is quite rate (like 5:1 ot 6:1). So I would 
> correct myself and say that it is not n-2 but
> rather n-1.
> Пятница, 21 июля 2023, 14:42 +03:00 от Krutskikh Ivan 
> <stein.hak at gmail.com>:
> 
> At first to confirm the issue try lowering the gop on your ip cam to 
> lowest possible value (fps or lower if possible) and see how that 
> effects the precision on splitmuxsink. I use splitmuxsink in production 
> and +/- 2-3 seconds does not bother me.
> 
> пт, 21 июл. 2023г. в 14:27, Антон Шаров <sharov_am at mail.ru [1]>:
> 
> Hi! Thank you for reply!
> 
> How to fix this issue? From one point of view I think it would be ok to 
> ask user for n seconds and
> set n+2 to obtain exact duration, but I think I miss somthing to deal 
> with it properly.
> 
> Пятница, 21 июля 2023, 14:05 +03:00 от Krutskikh Ivan 
> <stein.hak at gmail.com [2]>:
> 
> Hi!
> 
> I think it depends on seconds between  key (I) frames since 
> splitmuxsink begins each new file with a key frame.
> 
> пт, 21 июл. 2023г. в 13:46, Антон Шаров via gstreamer-devel 
> <gstreamer-devel at lists.freedesktop.org [3]>:
> 
> 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.
> 
> Thanks in advance.
> 
> Here some initial seesion info:
> 
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: latency = 
> 2000
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: ntp-sync 
> = false
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> rfc7273-sync = false
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> add-reference-timestamp-meta = true
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> ntp-time-source = ntp
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> drop-on-latency = false
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> max-rtcp-rtp-time-diff = 1000
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> max-ts-offset-adjustment = 0
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> buffer-mode = none
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1: timeout = 
> 5000000000
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1: caps = 
> application/x-rtp, media=(string)video, payload=(int)97, 
> clock-rate=(int)90000, encoding-name=(string)H264, 
> packetization-mode=(string)1, 
> profile-level-id=(string)4D00000000000000, 
> sprop-parameter-sets=(string)"Z00AH52oFAFum4CAgIE\=\,aO48gA\=\=", 
> a-framerate=(string)15, ssrc=(uint)3053121902
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc2: caps = 
> application/x-rtcp
> Progress: (request) SETUP stream 1
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc3: timeout = 
> 5000000000
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc3: caps = 
> application/x-rtp, media=(string)audio, payload=(int)0, 
> clock-rate=(int)8000, encoding-name=(string)PCMU, 
> encoding-params=(string)1, ssrc=(uint)2174462030
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc4: caps = 
> application/x-rtcp
> Progress: (open) Opened Stream
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager: 
> buffer-mode = none
> Progress: (request) Sending PLAY request
> Redistribute latency...
> Redistribute latency...
> Progress: (request) Sending PLAY request
> Redistribute latency...
> Redistribute latency...
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1: caps = 
> application/x-rtp, media=(string)video, payload=(int)97, 
> clock-rate=(int)90000, encoding-name=(string)H264, 
> packetization-mode=(string)1, 
> profile-level-id=(string)4D00000000000000, 
> sprop-parameter-sets=(string)"Z00AH52oFAFum4CAgIE\=\,aO48gA\=\=", 
> a-framerate=(string)15, ssrc=(uint)3053121902, 
> clock-base=(uint)2632806877, seqnum-base=(uint)14666, 
> npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1, 
> onvif-mode=(boolean)false
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc3: caps = 
> application/x-rtp, media=(string)audio, payload=(int)0, 
> clock-rate=(int)8000, encoding-name=(string)PCMU, 
> encoding-params=(string)1, ssrc=(uint)2174462030, 
> clock-base=(uint)661265319, seqnum-base=(uint)53364, 
> npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1, 
> onvif-mode=(boolean)false
> Progress: (request) Sent PLAY request
> /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1.GstPad:src: 
> caps = application/x-rtp, media=(string)video, payload=(int)97, 
> clock-rate=(int)90000, encoding-name=(string)H264, 
> packetization-mode=(string)1, 
> profile-level-id=(string)4D00000000000000, 
> sprop-parameter-sets=(string)"Z00AH52oFAFum4CAgIE\=\,aO48gA\=\=", 
> a-framerate=(string)15, ssrc=(uint)3053121902, 
> clock-base=(uint)2632806877, seqnum-base=(uint)14666, 
> npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1, 
> onvif-mode=(boolean)false
> 
> --
> С Уважением,
> Шаров Антон

--
С Уважением,
Шаров Антон

--
С Уважением,
Шаров Антон

-- 
--------------------------------
Ing. Erkert Armin
Mittelstrich 9
I-39050 Tiers (BZ)

Email: armin.erkert at rolmail.net
Tel.:  +39 349 4385335
WWW:   www.erkert.it [4]

Links:
------
[1] 
http://mail.konmail.net//e.mail.ru/compose/?mailto=mailto%3asharov_am@mail.ru
[2] 
http://mail.konmail.net//e.mail.ru/compose/?mailto=mailto%3astein.hak@gmail.com
[3] 
http://e.mail.ru/compose/?mailto=mailto%3agstreamer%2ddevel@lists.freedesktop.org
[4] http://www.erkert.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230721/e6f1a953/attachment.htm>

More information about the gstreamer-devel mailing list