Duration of recordings is not consistent

[j1elo]

Prerequisites

These are MANDATORY, otherwise the issue will be automatically closed.

• I agree to fill this issue template.
• I have read the Troubleshooting Guide and Support Instructions.

Issue description

Original report & technical details:
recording duration not consistent
https://groups.google.com/g/kurento/c/yVMyJNUP1JU/m/Bou842wsDQAJ

Kurento 6.15.0 fixed an issue that affected how RecorderEndpoint generates files from incomplete RTP streams: Fixed Recorder synchronization on streaming gaps.

The issue here was that incoming RTP streams (from WebRTC, RTSP, or RTP) can suffer from packet loss when the network is congested. The NACK mechanisms in WebRTC try to help with this, by asking for packet retransmissions, but at the end of the day some RTP packets are definitely lost and not recoverable.

This, when stored into a local file, would yield a recording which contained "gaps" within the media streams. And these gaps were able to cause synchronization issues, depending on the player used. The player included in Chrome is most sensible to these gaps, and they would make the audio and video in the file to go out of sync.

However other players such as FFplay (which uses FFmpeg) were fine and able to dynamically adapt the playback rate and/or "fill in the blanks" to provide a smooth playback.

After the fix, Kurento adjusts the timestamps of all buffers, so that gaps are taken into account and removed from the resulting file. This produces recordings that are perfectly playable directly in Chrome, but on the other hand, the total duration of these files has been reduced by an amount equal to the cumulative time of the gaps.

This poses a problem for users who expect to do individual recordings of each participant, with the intention of playing them back all at the same time. With the previous recording method, these would all have the same length and would somewhat keep a reasonable synchronization between them; with the new method, each file has a different duration, so it is not possible to play them back together and obtain a coherent conversation.

Also, the issue with gaps was not a problem for those users who would anyway perform a post-processing step with FFmpeg or similar tools, in order to convert formats. This kind of post-processing would naturally remove all gaps that might exist within the file.

Due to this, we're going to add a user-settable configuration option that allows choosing between gap-less recording, or ignoring gaps. This way users can choose their own compromise.

Context

An example can make it much clear:

Assume a stream that plays for 5 seconds, then there is a 5 seconds gap (in practice, it is more common to have lots of very small, milliseconds gaps), then recovers again for 5 seconds. In total, the resulting video should take 15 seconds. Also, for simplicity, assume a 1 frame per second stream. As it was until Kurento 6.15, the RecorderEndpoint would store each frame with its timestamp as follows:

    frame 1  - 00:01
    frame 2  - 00:02
    frame 3  - 00:03
    frame 4  - 00:04
    frame 5  - 00:05
    frame 11 - 00:11
    frame 12 - 00:12
    frame 13 - 00:13
    frame 14 - 00:14
    frame 15 - 00:15

Technically, this was a bug in the RecorderEndpoint, because local files should never contain gaps, and this could be perfectly considered an invalid file that should not be playable.

The changes introduced in Kurento 6.15 would store the file as follows:

  frame 1  - 00:01
  frame 2  - 00:02
  frame 3  - 00:03
  frame 4  - 00:04
  frame 5  - 00:05
  frame 11 - 00:06
  frame 12 - 00:07
  frame 13 - 00:08
  frame 14 - 00:09
  frame 15 - 00:10

Thus providing a correct file without gaps, but reducing its length to 10 seconds instead of 15.

About Kurento Media Server

• Kurento version: 6.15.0

[github-actions]

Hello @j1elo! 👋 we're sorry you found a bug... so first of all, thank you very much for reporting it.

To know about progress, check in Triage. All issues are considered Backlog Candidates until work priorities align and the issue is selected for development. It will then become part of our official Backlog.

[j1elo]

Fixed by Kurento/kms-elements#31