It is a bit annoying, but the ARM ubnt_ubvinfo runs very well on x86 using qemu-user, so I'd recommend that (instructions in the README.md).

I've been doing a fair amount of reverse engineering work on the .ubv file format, and can handle most cases - but there are still a large number of unknown fields (and in particular, multi-partition files pose some issues). I have considered adding a native parser behind an experimental flag, but due to those issues it won't provide as reliable an experience

Thanks for the info @petergeneric - I was trying to run it in docker too - so that added a couple frustrations on its own.

I have a dockerfile set up that pulls the an x86 version of ubnt_ubvinfo from archive.org. I just updated it to 3.0.0.

https://github.com/TokugawaHeavyIndustries/ubv-remux-docker

I've renamed this issue and marked it as an enhancement. I've been working on it, although it's slow work!

Does the UBV file contain any reference to detected objects (either motion or smart detections)?

Not as far as I have seen, that data is all stored in Protect's postgresql database

Thanks for creating this tool @petergeneric, and I'm sure I'm being thick here but trying to locally remux .ubv files on my ARM based Mac using the macARM64 tool it fails asking for ubnt_ubvinfo (which I have extracted from the Cloud Key), but am unsure of the "PATH" it is looking for?

Hi @PLiPhaze

While M1 Macs are supported for the tool (it's what I develop on), the native .ubv parsing logic I've been experimenting with isn't good enough yet to offer a fully-macOS option, and Ubiquiti's ubnt_ubvinfo tool (which I use to extract frame offsets from the .ubv file) only runs on Linux.

You could run a Linux VM on your Mac... for that, you'd copy the ubnt_ubvinfo tool from your Cloud Key and run it in Linux ARM on the M1... it should be very fast, even a little virtualisation overhead.

If you don't want to go the Linux route, then you can run the ubnt_ubvinfo tool on your cloudkey (N.B. it is somewhat IO intensive, and will be slow on the cloudkey's drive), and write the output to a .txt file (should be the same name as the .ubv but with a .txt extension instead). Have a look at https://github.com/petergeneric/unifi-protect-remux#run-ubvinfo-remotely-and-remux-locally - the tool should pick up this .txt and use it instead of trying to run ubnt_ubvinfo.

P.S. you're probably already aware, but you'll also need FFmpeg available. You can either install this via Homebrew, or install static binaries, e.g. from https://evermeet.cx/ffmpeg/

Dumb question - but I cannot figure out how to run ubnt_ubinfo on the udm pro - is that even an option?
The location of ubnt_ubvinfo isn't in the path defined in the prepare.sh script (on the udm pro).

@investscripts you should be able to find it with:

find / -name ubnt_ubvinfo

And then put that directory in your PATH, e.g. if find returned /path/to/ubnt_ubvinfo then you'd run:

export PATH="$PATH:/path/to"

FYI: Recent versions of Protect ship with a ubnt_ubvexport tool which can create .mp4 files from a .ubv; I've not had much success with it (especially in cases where there is some damage/corruption on the ubv or on the filesystem), but you might want to look at running that on your udm pro instead of my tool, and check if that works for you (should be in the same directory as ubnt_ubvinfo, it takes a -h or --help argument to print documentation if memory serves)

Thank you @petergeneric for the quick response! I don't know why I didn't do this before. It appears it's in a container. I think I'm good. Last question - I should be able to run ubnt_ubvinfo on the ubv files I'm interested in and it will create a txt file that remux needs... is that correct? These ubv files are pretty important (long legal story) and I want to make sure the ubnt_ubvinfo binary doesn't do anything other than produce a text file. Thanks again for all of your wonderful work!

If you're using the prepare.sh script in this repo (or running the commands within it) then yes, all that will happen is the creation of .txt files, none of my scripts/code modify the .ubv file (N.B. while I have not observed any version of the ubnt_ubvinfo tool to modify the file, I cannot guarantee that it won't since I don't have access to the Ubiquiti source code).

If they are important files I would highly recommend checksumming the .ubv files immediately on the UDM Pro, and then copying them off the Ubiquiti hardware before you run any info/remux tools. Validate the checksums after the transfer and archive them separately. Document the process you used to checksum, copy and remux and keep that safe, alongside the checksums. It's always going to be best to show the original files should there ever be any question over authenticity, and any lost .mp4 can always be re-exported from the .ubv in the future if needed, so the .ubv is the important media to archive.

Another suggestion would be to make sure you run ubnt_ubvinfo command as a user with no write access to the .ubv files, that way you can be sure that the filesystem would deny any attempt at modification -- that way you don't have to trust me or Ubiquiti.

Also, if you're able to run the demux and MP4 creation process on an x86 Linux host/VM, I highly recommend following the instructions in the README at https://github.com/petergeneric/unifi-protect-remux#dependencies-ubnt_ubvinfo-from-cloudkey on running the ARM ubnt_ubvinfo using qemu (with only a moderate slowdown). Running info, demux and ffmpeg all on a machine with much faster IO capabilities should be a lot faster, and also have less impact on any ongoing Protect recordings on the UDM Pro.

P.S. can you let me know what path you found ubnt_ubvinfo at on your UDM Pro? I will aim to put that in the list of paths to try for future users

I'm closing this issue, I never got very far with my format decoding work (was avoiding reverse engineering any of Ubiquiti's binaries) and I'm not planning to revisit it. Given that the ubnt_ubvinfo tool can be used with qemu on x86, I don't think there's much benefit to be had from format decoding (really the ideal there would be to write that with the intention of building an FFmpeg demuxer, but the FFmpeg community can be quite hostile in my experience)