• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 423 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Video capture encode delay

Holger Eberhard102906
Genius 4570 points


We use DVR RDK 03.00.00.00 / Udworks platform.

For a recording time protocol we want to save the start times of video recording.
I calculate the difference between VCODEC_BITSBUF_S.encodeTimestamp and VCODEC_BITSBUF_S.timestamp if a new I-frame arrives.
The following log shows results example.

I have 2 questions for this issue:

1.) If I calculate the delay I get results in millisecond (30...50 msec).
Are these values realistic for D1 / PAL ?

2.) Is VCODEC_BITSBUF_S.timestamp the time value if captureing is finished or started ?




 

Jun 24 12:43:28 192 user.debug: Ch 0
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44211
Jun 24 12:43:28 192 user.debug: capture_encode_delay 33
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 2
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44211
Jun 24 12:43:28 192 user.debug: capture_encode_delay 33
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 4
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44211
Jun 24 12:43:28 192 user.debug: capture_encode_delay 33
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 7
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44218
Jun 24 12:43:28 192 user.debug: capture_encode_delay 40
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 10
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44218
Jun 24 12:43:28 192 user.debug: capture_encode_delay 40
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 3
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44222
Jun 24 12:43:28 192 user.debug: capture_encode_delay 44
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 6
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44222
Jun 24 12:43:28 192 user.debug: capture_encode_delay 44
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 9
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44222
Jun 24 12:43:28 192 user.debug: capture_encode_delay 44
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 5
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44226
Jun 24 12:43:28 192 user.debug: capture_encode_delay 48
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 8
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44226
Jun 24 12:43:28 192 user.debug: capture_encode_delay 48
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 11
Jun 24 12:43:28 192 user.debug: timestamp 44178
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44226
Jun 24 12:43:28 192 user.debug: capture_encode_delay 48
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 13
Jun 24 12:43:28 192 user.debug: timestamp 44211
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44254
Jun 24 12:43:28 192 user.debug: capture_encode_delay 43
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 12
Jun 24 12:43:28 192 user.debug: timestamp 44211
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44254
Jun 24 12:43:28 192 user.debug: capture_encode_delay 43
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 15
Jun 24 12:43:28 192 user.debug: timestamp 44211
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44254
Jun 24 12:43:28 192 user.debug: capture_encode_delay 43
Jun 24 12:43:28 192 user.debug:
Jun 24 12:43:28 192 user.debug: Ch 14
Jun 24 12:43:28 192 user.debug: timestamp 44211
Jun 24 12:43:28 192 user.debug: encodeTimestamp 44258
Jun 24 12:43:28 192 user.debug: capture_encode_delay 47

  • 0
    TI__Guru 59700 points

    DVR RDK 3.0 doesn't support correct values of capture timestamp. The timestamp is just extrapolated as capture start time + capture frame count * frame duration. The frame duration is set to 40 ms for PAL and 33 ms for NTSC.

     

    DVR RDK 3.5 and above supports accurate timestamp-ing by the capture driver indicating the exact instant frame was captured.

     

    The encode timestamp is logged after encoding is complete and will vary depending on the number of channels encoded and the HDVICP load. The numbers you have shared are reasonable but if you require accurate timestamp values you should migrate to DVR RDK 4.0 .

  • 0 in reply to Badri Narayanan
    Genius 4570 points

    Thanks for Your answer,

    For the next steps in our application software I will use timestamp handling

    of version 03.00.00.00.

    But I think upgrade to higher version is unavoidable and we will go to version 3.5.

    Is DVR RDK 4.0 available already ?

  • 0 in reply to Holger Eberhard102906
    TI__Guru 59700 points

    Yes DVR RDK 4.0 release is available