Gap in post processed recording when mic is off

General
1

Hi. Have an issue while recording videoroom and turning mic off with "request": "configure" with "streams": [{"mid": 0, "send": false}]. There is just a gap in the post processed recording when the microphone is turned off.

$ ./janus-pp-rec -d 7 -D aud.mjr aud-res2.ogg
...
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 29 bytes out of 49 (seq=390, step=1, ts=4295340735, time=7s)
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 51 bytes out of 71 (seq=391, step=1, ts=4295341695, time=7s)
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 37 bytes out of 57 (seq=392, step=1, ts=4295342655, time=7s)
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 41 bytes out of 61 (seq=393, step=1, ts=4295826975, time=17s)
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 34 bytes out of 54 (seq=394, step=1, ts=4295827935, time=17s)
[Thu Jul 20 14:24:54 2023] pos: 000000, writing 34 bytes out of 54 (seq=395, step=1, ts=4295828895, time=17s)
...

Is it a bug? Can it be fixed with some janus-pp-rec flags? Or maybe it must be separated .mjr files for every turned on mic segment in this case?

full janus-pp-rec debug log
mjr file

It can sound as not a big problem since in media players such file still plays fine with pause when the mic is turned off (not counting freezing and jumping time indicator in vlc and others). But when I mixing such files with ffmpeg and amix this gaps just dissapears and one voice segment follows another without a pause

2

That depends what you mean by “mic turned off”. MJR files are just a capture of RTP packets, so if when the mic is off the client doesn’t send any RTP packet, then janus-pp-rec may artificially inject silent packets to fill the gaps. If the RTP headers the client sends are broken, then nothing the tool can do.

3

we still have this issue. We are disabling track on sender side and rtp packets stops to flow and then reenable stream - seq of rtp packets starts from there stopped and correct timestamps in rtp headers are set. e.g.:

image
image927×203 6.07 KB

You said janus-pp-rec may generate silence?

If I mute track and rtp comfort noise packets is flowing, the resulting mjr file contains these cn frames. Is it possible to get the same result in output ogg/opus file without generation of comfort noise rtp frames?

4

Since there’s no sequence number gap, the silence in this case will be inserted by libavcodec (ffmpeg), which janus-pp-rec leverages to write to the target opus format. The timestamp is translated to a presentation time (pts) that is passed to the format, so that it’s played with the right delay (60s in this case).

5

Hi lorenzo, I’ve been researching some AV sync issues we have with recordings. Based on your reply here am I correct in assuming that if I have the situation here with sequential packet numbers but a huge gap in the time that ffmpeg will “correct” this - ie. converting the mjr file containing that audio would fill in the correct gaps?

Screenshot from 2024-08-14 13-32-38
Screenshot from 2024-08-14 13-32-381238×94 28.3 KB

EDIT: Just to clarify, the mjr for the audio was exported to the pcap which I’ve screenshotted above. When I do janus-pp-rec audio.mjr audio.opus the audio file is exactly the length of the audio input.

So for my test I used a virtual mic and streamed a ~60 second audio into it, I waited a few seconds (about 29 seconds absed on the above) then streamed the same file into it again. So the file is ~120 seconds long, the second audio plays right after the first (there should be a ~29 second gap inbetween).

6 
[    342611][ 105] seq=2987, ts=4297833855, time=59.72s pts=59.74s
[    342726][ 105] seq=2988, ts=4297834815, time=59.74s pts=59.76s
[    342841][ 120] seq=2989, ts=4297835775, time=59.76s pts=89.43s
[    342971][  27] seq=2990, ts=4297836735, time=59.78s pts=89.46s
[    343008][ 146] seq=2991, ts=4297837695, time=59.80s pts=89.49s

pos: 000000, writing 81 bytes out of 105 (seq=2987, step=1, ts=4297833855, time=59s)
pos: 000000, writing 81 bytes out of 105 (seq=2988, step=1, ts=4297834815, time=59s)
pos: 000000, writing 96 bytes out of 120 (seq=2989, step=1, ts=4297835775, time=59s)
pos: 000000, writing 3 bytes out of 27 (seq=2990, step=1, ts=4297836735, time=59s)
pos: 000000, writing 122 bytes out of 146 (seq=2991, step=1, ts=4297837695, time=59s)