Issue with video recording duration in DSL's Record Tap and Record Sink.

[rafico]

Hello,
I'm working on recording videos using the 'smart_record_tap_start_session_on_user_demand.py' example from the DeepStream SDK. I've encountered an issue where the recording consistently stops after exactly 30 seconds, regardless of the settings I use.
I've attempted to modify the 'start-time' and 'duration' arguments passed to the 'dsl_tap_record_session_start' function, but these changes do not affect the recording duration. The behavior remains unchanged.
Given this consistent 30-second limit despite parameter adjustments, I suspect there might be a bug in the 'dsl_tap_record_session_start' function or in its interaction with other components.
Could you please investigate this issue or provide guidance on how to correctly set the recording duration?
Thank you for your assistance.
Best regards,

Rafi

[rjhowell44]

@rafico what version of DeepStream are you using? And what version of DSL are you on?

There was a DeepStream issue with smart record duration that was fixed in DS 6.2 see #937. Are you perhaps using an older version of DS?

[rafico]

Hi,
I'm using DS version 7 and DSL v0.30.a.alpha.

[rjhowell44]

@rafico what size are you setting the cache with dsl_tap_record_cache_size_set?

The default cache size is #define DSL_DEFAULT_VIDEO_RECORD_CACHE_IN_SEC 30

Make sure that this is set to greater than START_TIME + DURATION

[rafico]

Hi,
I set the cache to 300 seconds (5 minuts) with dsl_tap_record_cache_size_set.

I used the following sequence of commands:

// returns the default 30 seconds
retval, cache_size = dsl_tap_record_cache_size_get('my-record-tap')
// return 0 - success
retval = dsl_tap_record_cache_size_set('my-record-tap', 300)
// returns 300 seconds - just to verify the cache was changed
retval, cache_size = dsl_tap_record_cache_size_get('my-record-tap')

The recording still stops after 30 seconds.

[rjhowell44]

@rafico ok, thanks for the info... I'll see if I can reproduce this today

[rjhowell44]

@rafico I'm able to reproduce this. It's either a change in DS behavior, or a misunderstanding on my part? Either way, it's any easy issue to fix

Using the debugger...

If we look at the structure used to create the smart recording context -- at the time the Pipeline is linked and set to a state of playing -- there is a field that defines the defaultDuration for all recordings that is set to 30s

Even though the cache size is set to 400s and a value of 300s is used for the duration...

It appears the the defaultDuration is acting as a maximim-duration

The workaround is to set the default-duration in DslApi.h to something large enough for your use case. Search for.

#define DSL_DEFAULT_VIDEO_RECORD_DURATION_IN_SEC                    30

I need to think about how best to handle this in DSL. I will probable set the value to something large, and then add services to allow the client to update it. The fact that default == max will need to be covered in the docs.

[rafico82]

Hi,
The workaround was successful. Thank you!

I have an additional question regarding multi-camera recording: Is it possible to synchronize recordings from multiple cameras using the RTSP protocol? Specifically, I'm interested in methods to ensure time-aligned capture across all cameras.

[rjhowell44]

See dsl_pipeline_streammux_sync_inputs_enabled_set, but keep in mind that this is synchronization by the Streammuxer. The example above uses the Recording-Tap component which taps into the Source pre decoder which is upstream of the streammuxer. If synchronization is important, you may want look at using a demuxer with multiple Recording Sinks... downstream of the streammuxer.