Re: splitmuxsink, issues with max-size-time and exact duration
Антон Шаров
sharov_am at mail.ru
Fri Jul 21 12:18:34 UTC 2023
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 >:
>>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 >:
>>>
>>>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 >:
>>>>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
>>>>
>>>>
>>>>
>>>>--
>>>>С Уважением,
>>>>Шаров Антон
>>
>>
>>--
>>С Уважением,
>>Шаров Антон
>>
--
С Уважением,
Шаров Антон
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230721/76516770/attachment.htm>
More information about the gstreamer-devel
mailing list