Uneven recording size getting generated

[divdaisymuffin]

Hi @nnshah1
We are facing an issue where when we specify the "max-size-time" field in pipeline.json in nanoseconds, we are observing that the size of recording getting generated are not same, sometimes they are less duration and sometimes they are of high duration.

Please let us know how to get uniform size recordings.

[xwu2git]

How much variation do you see?
The recorded file has to cut off at the GOP length. This there will naturally be some variation. What is the GOP size in your incoming stream?

[nnshah1]

As @xwu2git mentioned a fixed length (in size) won't be possible without fixed gop sizes

[divdaisymuffin]

Hi @xwu2git and @nnshah1 , Thanks for sharing this information,
I am sharing our current configuration on the camera, where FPS is 20 and I-frames are going at 40, so every 2secs Iframe is going, Now what you suggest for getting the fix size?

[divdaisymuffin]

Is there is a way that via gstreamer pipeline we can fix the GOP length?
@nnshah1 @xwu2git

[divdaisymuffin]

@nnshah1 @xwu2git I have found this in gstreamer documentation, https://gstreamer.freedesktop.org/documentation/openh264/openh264enc.html?gi-language=c#openh264enc:gop-size

which stats about gop-size parameter. But how to implement it in our pipeline.json?

[nnshah1]

@divdaisymuffin Can you give more details on the goal / requirement and the variation in size you are seeing currently?

There is also a max bytes option to splitmuxsink that could be explored. But its not clear your intent - is it that all files have the same exact size or that they are bounded? And how much variation is acceptable?

[divdaisymuffin]

@nnshah1 @xwu2git Actually Our target is to get a fixed length video as a output snippet, by fix video length I mean fixed time duration, like if I set 5 mins all the snippets should be of 5 mins only, not less not more than that.

Currently we were using
splitmuxsink max-size-time=60500000000 name=\"splitmuxsink\ which means 1 mins
But that results in wide range of variation, sometimes some snippets are of 10 secs and some of them are going up-to 3 mins or further.

The thing you have mentioned about GOP so I have checked into it and found out that its fixed to 2secs or 40 frames for camera.
So, what you suggest how I can achieve this goal?

[divdaisymuffin]

@nnshah1 @xwu2git we got another issue while running pipeline on a live rtsp camera, Please look at the error below

Error on Pipeline 1: gst-stream-error-quark: Could not multiplex stream. (10): ../gst/isomp4/gstqtmux.c(4832): gst_qt_mux_add_buffer (): /GstPipeline:pipeline4/GstSplitMuxSink:splitmuxsink/GstMP4Mux:muxer:\nBuffer has no PTS."

which says specifically "buffer has no PTS", this we have faced first time only on this camera, it is running fine on another camera.

What is a alternate way to create a recording without PTS, Can we do it using gstreamer some parameter tuning?

Pipeline template we are using
"template":"rtspsrc udp-buffer-size=212992 name=source ! queue ! rtph264depay ! h264parse ! video/x-h264 ! tee name=t ! queue ! decodebin ! videoconvert name=\"videoconvert\" ! video/x-raw,format=BGRx ! queue leaky=upstream ! gvadetect ie-config=CPU_BIND_THREAD=NO model=\"{models[head_yolov4_tiny_608to416_default_anchors_mask_012_INT8][1][network]}\" model-proc=\"{models[head_yolov4_tiny_608to416_default_anchors_mask_012_INT8][1][proc]}\" name=\"detection\" threshold=0.30 ! gvametaconvert name=\"metaconvert\" ! queue ! gvapython name=\"new_wait\" module=\"custom_transforms/new_wait\" class=\"WaitTime\" ! gvametapublish name=\"destination\" ! appsink name=appsink t. ! queue ! splitmuxsink max-size-time=300000000000 name=\"splitmuxsink\""

[nnshah1]

@divdaisymuffin Can you double check the properties of the camera in terms of encoding - that it is h264, etc. - also does the pipeline work if you remove the splitmuxsink branch?

[divdaisymuffin]

@nnshah1 yes we checked camera property, it is h264 only, also confirmed by playing same rtspurl on vlc player and checked codec information, it is h264 only.
If we remove splitmuxsink recordings will not be able to create right?

[nnshah1]

@divdaisymuffin That's correct - I wanted to just confirm if the pipeline operates normally for detection and the problem is isolated to recording. That could give us an idea of what to look at.

Can you also share the make / model of the camera just in case we can find something related to that?

[divdaisymuffin]

@nnshah1 please find
NVR Details
Device Type/model : DHI-NVR4432-4ks2

Camera Details

Device Type
DH-IPC-HDW1230T1P-S4
System Version
V2.680.0000000.7.R, Build Date: 2019-09-11
WEB Version
V3.2.1.26770
ONVIF Version
18.12(V2.0.0.26587)
S/N
5M0714BPAGE38BA
Security Baseline Version
V1.4
Copyright 2019, all rights reserved.

[divdaisymuffin]

@nnshah1 Analytics is working fine, issue is with recording where in recording filename the offset value is _0 continuously. For eg. File name is 1634568904331_0.mp4
And it tries to create multiple files but all with _0.mp4

[nnshah1]

Are the timestamps in the metadata also all at 0?

Is it possible to reproduce this from a recorded file (that is record via vlc and then run through pipeline directly with a filesrc?)

[divdaisymuffin]

@nnshah1 We found issue with the camera
The RTP packets miss proper information like DTS, Please see the attached snap.

Also it seems like, the splitmuxsink is very dependent on these informations from RTP packets? Do you know any other plugin which can create recording by neglecting DTS and PTS information

[nnshah1]

one thing you could try is to add a videorate element before the splitmuxsink to add in pts - I'd still like ot understand what timestamps the metadata are reporting - as you'll want to ensure you can synchronize those. in your gvapython code - you can get access to the buffer and print the .pts and .dts yourself - you could also potentially modify it

[nnshah1]

@divdaisymuffin We're not able to easily reproduce the issue you're seeing or offer a solution. Is there a way to reproduce without access to the camera in question? Also I believe we would want to open a seperate issue for this specific case (missing PTS / DTS). Let's use this issue to focus on normalizing recording segment size.