The VideoLAN Forums

Hi everyone,
I'm using VLC to record IP camera streams (from a barn owl nest).
VLC is started from a C# program I wrote, recording a rtsp stream into a file. VLC is stopped and restarted every 30 minutes, creating files of about 1.4 GB.
This worked fine for years, until middle March, where suddenly a few files contained only about 14 MB. They cannot be opened by any video application.
Surprisingly, in 12 hours of recording, between 3 and 12 files are corrupt, out of 24 (per night).
I have tried the last 3 release of VLC, to no avail. So I suspect some dirty Windows10 upgrade to be the cause of all this.

The command line:
VLC -vvv rtsp://admin:password@192.168.1.111 --sout=#transcode{acodec=mpga,ab=64,scodec=none,deinterlace}:std{select=audio,access=file,mux=mp4,dst=F:\\Video\\Chouettes\\2021\\DynamicFileNameHere.mp4}"

A corrupt file:
http://www.beecomputing.com/download/sr ... -21-30.mp4

Any idea ?
Thanks for any help.

Using "mux=ts" seems to help a lot. The new command line:
...--sout=#transcode{{vcode=h264,vb=800,scale=1,acodec=mpga,ab=128,channels=2,samplerate=44100}}:std{{access=file,mux=ts,dst=...

As usual when reading rtsp stream with VLC: trial and error is the way to go. It may work...no one knows, just try and try again until it works...

There are other reports about issues with muxing to MP4 for months:
https://forum.videolan.org/viewtopic.ph ... 89#p508489

Try with a nightly build:
https://nightlies.videolan.org

Thanks for your suggestions, but there is no solution in any of the mentioned threads.
The nightly build installer (msi - 64 bit) just stopped working in the middle of the install process.

So I tried to uninstall the last Windows update from March, and after one night recording, 4 files are corrupt out of 20 for the first camera, and none is corrupt for the second camera.
So this is much better than before, where about 50 % of the files were corrupt on both camera, but this is still unreliable.
I'll continue searching for a better solution.

New test with the latest Windows update and the last VLC nightly build (2021-04-23) : 2 files corrupt out of 40. Not yet perfect...

Files are NOT corrupt. They just did not receive synchronized video data before starting to mux.
It all depends on frame rate, GOP and decoding start point, so it's not surprising with streams with contant audio and heavily variable frame rate.

See sout-mux-caching option

Thanks for the suggestion. I have added the caching size to the command line, which looks like: (in C#)
string arg = $"-vvv rtsp://{login}:{password}@{ip} --sout=#transcode{{vcode=h264,vb=800,scale=1,acodec=mpga,ab=128,channels=2,samplerate=44100,mux-caching=5000}}:std{{select=audio,access=file,mux=mp4,dst={dest}\\srce_" + DateString(m_LastResetTime) + ".mp4}";
Let's see tomorrow how it works.
Note that the two unreadable files from last night are as big as the other files. I haven't yet analyzed why they are unreadable.

One day later, and using "mux-caching=5000", 4 files are unreadable.
A checkup with ffmpeg gives the following error:
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000124a70e6640] moov atom not found
F:\Video\Crécerelles\srce_2021-04-26-20-30.mp4: Invalid data found when processing input

The file is here (484 MB): www.beecomputing.com/download/srce_2021-04-26-20-30.mp4
The VLC (last nightly build) log is here: www.beecomputing.com/download/VLC%20error.log

Any idea why ?

Now you know how "perfect" the mp4 container is. If something goes wrong and you get the truncated file, you cannot play it. Even avi is better in this. Ts muxer should work, but you have already tried it. Then try mkv. I do not know, whether it is possible to fix such broken mp4.

Any idea why ?

The file did not end properly, so the header is missing. Out of memory ? Forced termination ?

You can try mux=mp4frag instead of mux=mp4

Thanks a lot for your help. You are certainly right : there is a forced termination after 30 minutes, but simulating a click down event on the pause button first, then a one second delay before stopping and restarting VLC.
I have tried ts, but opening such big video file with Avidemux takes ages, and I have to quickly scan so many of them every morning that this is not an option. I haven't tried yet mkv.
New race started, until tomorrow morning...

This is it : increasing the delay between the mouse down event on the Pause button and the shut down of VLC has fixed the problem.
Thanks to all of you for your help.
By the way, using mux=mp4frag lead to black images.

I do not know, whether it is possible to fix such broken mp4.

There is a way of fixing such broken/incomplete mp4 file according to a good file of the same format: https://stackoverflow.com/questions/355 ... video-file
It is not possible to check/play partially downloaded/incomplete mp4 files (during downloading/encoding), because they are mostly not "fart started" yet. mp4