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.
Awesome! Thanks @rafael.lehmkuhl . We’ll give it a go.
Hi @mattcmgb : Let me know how your tests go.
We’ve been testing this unit: 3X 4K Ultra HD Macro Imaging Microscope Zoom Camera | Viewsheen
Looks good on paper, but benchmarked against a GoPro Hero 11/12, it’s been a bit disappointing…
@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
Hi @mattcmgb -
The expected fix is not yet released - as @rafael.lehmkuhl mentions it should arrive soon (here) with BlueOS 1.2 beta 9. Thanks!
@tony-white Apologies, I read it as it being already merged into Master, which I upgraded to prior to the test. Will retry on beta 9 when released.
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
Hey everyone!
@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.
@rafael.lehmkuhl thanks for confirming, I can confirm that the issue remains. Happy to perform further tests if you it.
Cheers
Matt
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.
@rafael.lehmkuhl excellent, I should have time tomorrow to run a test with our 4k. Great job 
Nice! I’m looking forward to seeing the results!
hi guys, i’ve had an error processing video, (actually the .ass file which we use for altitude, video ok) and followed the steps here and see both in the Indexedb - what next? save them?
Hey @chubbybutton, are you using the browser version or the standalone one?
Passing here to give an update about the current state of video recording with Cockpit.
Today we recommend you to do two things:
I personally prefer to have both recordings going on, as the vehicle one can save you in cases where you lose connection to the vehicle or have a degraded connection, while the topside one save you in case you lose your vehicle.
browser version, in chrome.
But i had to restart the topside computer this morning and when i look in the IndexedDB now the files are no longer there. We are hoping the .ass information will be in the .BIN or .TLOG file. Though in binary?
Were you using the browser in Incognito Mode?
But yes, the same data that we use to generate the .ass file is in the .tlog files.
good morning @rafael.lehmkuhl
No, not using Incognito Mode.
In regard to the .tlog files, are they more complete (i.e. more information/data) than what ends up visible in the .ass/subtitle files?
And can i “generate” a .tlog (or .BIN) file at will? (i.e. end of day?) they seem to become available sporadically…?
To clarify, the different types of logs are generated by different parts of the software and hardware stack, and contain different (somewhat overlapping) information as a result.
Cockpit’s video recording subtitle overlays (.ass files) can include fields from specific MAVLink messages, as well as some other information that the application has access to (like its memory usage, and some information about BlueOS). One is generated for each video recording, with the fields the user has configured via the settings.
Telemetry logs (.tlog files), recorded by a MAVLink router or control station software, contain a history of all MAVLink messages in a given session (where the session start and endpoints are determined by the router - often just when it’s on, although sometimes there are log rotations if the current file gets too big, and some software only record them while the vehicle is armed). The rate of information in that
DataFlash logs (.bin files) are high frequency and resolution internal logs generated by the autopilot, and stored on the flight controller board’s storage (although in the case of a Navigator that storage is readily accessible within BlueOS). Their contents and recording periods can be controlled by the relevant autopilot parameters.