The credit goes all to Joao here. He’s the one doing magic on the video backend
I hope your tests go well! Let us know about anything.
We still have some improvements to be done on the video backend, regarding stuttering and resource leaking, but we think we are close to solve most of it. Cockpit video pipeline is getting closer to what we expect for the stable release.
@rafael.lehmkuhl I have completed a test today with our 4k camera, resulting in a 12gb 1hr 40min *.webm file and associated *.ass file.
There was about 10 seconds delay from ending recording to the file being available for download (no issue there). But the resulting file is still only viewable in both VLC and WMP as realtime playback only. It is not possible to jump to any point in the playback or scrub through it, it just reverts to the last viewed time. Tested on a couple of windows machines - this one RTX4090 GPU, AMD Ryzen 7 3800X 8-Core CPU 3.89 GHz, 64gb RAM and all data on PCIe 4.0 NVMe SSDs so I don’t think there’s a performance issue.
When playing we see no overload of CPU, GPU or excess RAM utilisation. It’s like there is an indexing issue in the file or similar.
BlueOS Master - as of today and Cockpit v1.0.0-beta.12
It would be interesting to have one of these long video files to analyse, and to see what is going wrong. I don’t see any reason as to why matroska (webm/mkv) should have problems seeking on longer files.
If you’re looking for alternate players, I would suggest trying MPV and MPC-HC (on github, clsid2)
Would also be very interesting to remux the file to mp4/mov, and see if that resolves the issue. It will not re-encode, and will happen at the max speed your disk can read/write. For instance with ffmpeg: ffmpeg -i orgFile.webm -c copy outFile.mp4
@mattcmgb was actually right in his understanding that the master version of BlueOS was already including the fix. It’s also on the latest versions (1.2.0+).
I’ve tested here and was able to still reproduce the issue with latest Cockpit version. What I think can be happening now is that the fix we have on the Cockpit side (that most of the time didn’t actually fix the video) is breaking the correct duration. I will take a look at that.
I think I’ve fixed the duration/seek problem in the videos! Please take a look at v1.0.0-beta13 and let me know if it’s working for you guys. I’ve tested it with 1, 5, 30 and 60 minutes recording and all went fine.