KMS Recorder corrupted MP4 video due to new CAPS

[Carlos]

Hello all,

Docker KMS 6.16.0

Background: We've previously had issues with MP4 container since it doesn't accept changes of resolution. We've tried WEBM and MKV, but there's transcoding and the quality is very low, so we've discarded at the moment (I still have to open an issue for that). So we're "controlling" Chrome to avoid resolution scalation, which was causing our previous issue.

The issue: So now we're recording at all moments at the same resolution, but randomly in some devices (specially with Chrome HW acceleration enabled) and continuously in others we get a MP4 recorded with all audio but only few milliseconds of video.

Attached KMS logs.

Found out from logs: What I see is that everything is correct until the Recorder starts to source to qtmux. Then after a moment, the Recorder, without any CAPS query from WebrtcEndPoint, process a new CAPS event for video pad (with identical previous CAPS) to qtmux. It looks like it's the Recorder itself, nothing else requested that new CAPS event. qtmux refuses to accept the new CAPS (which, again, are the same) and stops recording video on the file.

HELP: Any idea where this can come from or how to find it out? I'm very confused about why that new CAPS event is happening. And also confused about why qtmux doesn't just drop it.

Thanks.

[Carlos]

Hi,

Is there anyway to tell WebRTCEndpoing or RecorderEndpoint to reject any CAPs negotiation event coming from upstream at any time?

Thanks.

Regards,

[Carlos]

I forgot about this issue. Just linking it here for the sake of completeness: https://github.com/Kurento/bugtracker/issues/535

We solved it firstly doing a replaceTrack just when starting to receive video in KMS (not sure why the trick worked...). Then we eventually moved to WEBM as recording container and all problems got fixed. We also mangled SDP to force each browser to use the specific codec to avoid transcoding in KMS.

[Neil Young]

I suppose you never got an answer to this, right? Fighting the same. WEBM is OK, but in case of H.264 input it will show up quality loss due to transcoding.

[Neil Young]

I found that with GStreamer 1.20 the qtmux (which is the underlaying responsible plugin for the break) is now able to re-negotiate the resolution change with upstream. So the recording doesn't break anymore. But - the content of the recording is complete garbage after the first resolution change. I suspect it is because qtmux is NOT sending an updated PPS/SPS set, but just the IDR. This is not sufficient for the decoder, so that there is just garbage on the screen while playing back such a recorded file.

That simply means, that even with KMS 7.0 this problem will not be solved. :(

The only thing what worked is this: WebRtcEndpoint -> RtpEndpoint -> FFMPEG -> RTSP Server. Behind the RTSP server the resolution change is properly communicated, so that clients will get a perfect H.264 recording.

But since nobody cares, this problem will survive.