Multi-stream recording issue

djuka

Member
I have a multi-stream recording finished as *.mp4.tmp file.
The file is not playable.
The mixer did not process mixing, probably because the file was incorrect or the session was not closed.
How can I fix this file?
 

Max

Administrator
Staff member
Good day.
Unfortunately, you cannot fix this file. The file contains a recording data without header, so the header cannot be formed manually.
Seems like there was no free disk space to save mp4 file. But the latest WCS builds can control the disk space and stop recording correctly in this case. By default, there should be at least 1 Gb:
Code:
file_recorder_min_space=1g
If you recording files may be more than 1 Gb, please increase the threshold value, for example
Code:
file_recorder_min_space=10g
 

djuka

Member
Hi Max, it was not a lack of disk space. On that disk, there is 2TB of free space.
I had 20 multi-stream recordings in 2 hours; only 3 of them are not finished properly and have only *.mp4.tmp files. The other 17 finished mixing correctly.
This situation happens each day, most of the multi-stream recordings went OK, but a few of them finished as corrupted files *.mp4.tmp
 
Last edited:

Max

Administrator
Staff member
We checked the report. In the logs provided, there are no any multiple recordings, but single stream recodings only, and all of them seems to be successful. So the problem seems to be not reproduced during the last 3 hours (logs collection time by default).
In the ticket WCS-4053 scope, we plan to optimize recording flow to exclude an excessive file rewriting, and to write MP4 header on the fly. This should allow to play the file even if recording was incorrectly stopped. But this may require a time.
You can do the following for more stable server work:
1. Add more Java heap space. Now, you're using a default Java heap size 1 Gb. It may be not enough because recording data are kept in Java heap memory. We recommend to use 1/2 of server RAM, 6 Gb in your case
Code:
-Xms6g
-Xmx6g
2. Seems you are using JDK 8 and CMS garbage collector. We recommend to update JDK to 14 or 15: JDK 14, JDK 15 and enable ZGC: The Z Garbage Collector. This may reduce a garbage collection pauses in Java machine work cycle, and increase a performance.
 

djuka

Member
Hi, I did what you suggested, but the same issue happened today. Two multi-stream recordings failed and 5 went OK. I caught a report within a 3-hour frame but can not send you using the support form since it is not working.
Add: After the recommended change it works worse. Today I have more corrupted videos.
 
Last edited:

djuka

Member
Hi Max,
I want to inform you that I found the issue. The recording file was not corrupted but MultiRecorder was not finished since the session was never terminated. I used '/multipleRecorder/find_all' rest API endpoint and I found all 'broken' video files are not closed by the recorder. When I manually terminated all recorders, all files went to the mixer and finished as OK.
 

Max

Administrator
Staff member
I caught a report within a 3-hour frame but can not send you using the support form since it is not working.
We tested report sending via Report, it works now.
The recording file was not corrupted but MultiRecorder was not finished since the session was never terminated.
This is an expected behavior: multiple recorder must be started and stopped by REST API because it never knows when a stream will be added or removed from it. You should review your backend flow to stop multirecorder when room is closed.
We will still work on the ticket WCS-4053 to prevent an excessive file rewriting when recorder is stopped.
 

Max

Administrator
Staff member
Good day.
Since build 5.2.1990 it is possible to update MP4 atoms data on the fly
Code:
mp4_container_moov_first_reserve_space=true
mp4_container_write_header_on_fly=true
In this case MP4 atoms data are updating periodically according to actual recording media data. This feature allows to play the recording file even if the recording was interrupted due to some error.
 
Top