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

Armin Erkert via gstreamer-devel <[email protected]>
Newsgroups gmane.comp.video.gstreamer.devel
Message-ID <[email protected]>

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 
> <[email protected]>:
> 
> 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, Антон Шаров <[email protected] [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 
> <[email protected] [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 
> <[email protected] [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: [email protected]
Tel.:  +39 349 4385335
WWW:   www.erkert.it [4]

Links:
------
[1] 
http://mail.konmail.net//e.mail.ru/compose/?mailto=mailto%[email protected]
[2] 
http://mail.konmail.net//e.mail.ru/compose/?mailto=mailto%[email protected]
[3] 
http://e.mail.ru/compose/?mailto=mailto%3agstreamer%[email protected]
[4] http://www.erkert.it
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.