Could not find codec parameters for stream 0 (Video: h264, none): unspecified size about unifi-protect-remux HOT 5 CLOSED

Thanks for the logs - it looks a lot like that .ubv had a very short (or corrupt) partition, and that's caused issues. I'm assuming nothing weird has happened with these files (i.e. the footage hasn't been deleted from the Protect UI).

Try just extracting the h264 and aac streams (by adding the -mp4=false argument) and then remuxing them separately... this should only impact the occasional .ubv file where there was some network/camera issue. It could be that one partition is just bad, and the remux tool is failing on that, and not proceeding any further.

If you're not familiar with FFmpeg commandlines, the following is what you need (assuming you want just video... audio is a little more challenging to get perfectly lined up (here's the link to what the code does for video+audio, it's necessary to work out the time difference between when the audio and the video tracks start), although if you're happy with an approximate line-up it's easy)

ffmpeg -i some-video.h264 -c copy -r 30 -loglevel warning -y output.mp4

If doing it this way doesn't work, then either the .ubv is corrupt, or there's something else odd going on.

In recent versions of Protect, Ubiquiti have started shipping their own UBV to MP4 converter (although I've not had luck with using it on weird/partially corrupt files). On my system, that's found (and used) with:

/usr/share/unifi-protect/app/node_modules/.bin/ubnt_ubvexport -s your-file.ubv -d my_output_prefix

If you get an error saying that ubnt_ubvexport doesn't exist, try running find / -type f -name ubnt_ubvexport (which may take a long time, since it scans through the whole drive) and using the path it outputs instead of the path I have above.

from unifi-protect-remux.

Closing this issue, but if the above fixes/workarounds don't work feel free to reopen

from unifi-protect-remux.

Hello and thx for your quick reply !
I definitely agree with you that this is more a ffmpeg related issue so I will investigate on that part (I tried already to change the analyzeduration & probesize with no luck - with the trace loglevel, quite a nightmare - but I'm gonna investigate further.

indeed the file was not 'corrupted' (afaik) but I have plenty of ubv file with that kind of behaviour, and what bothers me is that the process (remux) stopped with an exit code as soon as ffmpeg exits with such errors. So i used remux individually on all my files to prevent the whole list of 800 files to stop abruptly (find command with -exec features), but still I think I miss something:

when mp4=false (thanks for the tip), remux is able to extract my 35 partitions (70 files with audio) but when mp4=true it failed on the 2nd one then stops. Is there an option i can use to process all partitions even if some of them are corrupted (or 'not manageable') or cannot be merge to a mp4 container ? I mean, in my case: ffmpeg returns an error and leaves an mp4 files with 0B, but remux could keep the .h264 & aac files on disk, remove the corrupted mp4 file (or leave it - I'm fine with it) and process the next partition. is that feasable ?

regarding my problem with the 2 files .h264 & .aac I was able to mux them in a mkv container. Hence the audio is quite desynch but frankly for a 20 seconds footage I'm more than happy with it). So my last question for you is: do you think mkvmerge (mastroska container) could do the ffmpeg stuff or are you using ffmpeg library functions other than 'repacking' ?

regarding the ubv_export, ouch, does this means the end of remux ??
i tested it and I have to say, it works pretty well... (including for the file mentionned in this thread...)

from unifi-protect-remux.

I've not used mkvmerge but based on the name you could certainly use it instead of ffmpeg here - I'm just using ffmpeg to do basic mux from the extracted track bitstreams (and I prefer MP4 for broader compatibility)

Having the tool skip partitions in the event of errors (and leaving the bitstreams behind for manual recovery) shouldn't be an issue, I will look into adding that.

I'm pretty sure most uses of remux can now be replaced with ubnt_ubvexport - which I'm quite happy with, my worry with developing this tool has always been not knowing if/when Ubiquiti will make a backwards-incompatible change to the .ubv format, and now that there's an officially provided (if not supported) tool, that worry largely becomes a non-issue. It seems to run reasonably quickly with qemu, too, for folks wanting to remux their .ubv files on x86 linux machines. When I get some time, I've been meaning to run some more experiments with ubnt_ubvexport and if positive add a recommendation to the README.md file for this project pointing people at it instead.

from unifi-protect-remux.

I understand your point re the mp4 container rather than mkv (the flexibility offered by Matroska is no need here, most CVR systems offers only a video stream and occasionally a mono audio stream).

I think your remux is still a better take, at least for the timecode recognition (ubvexport just add a _xx suffix to the original file, which is fine for most users, as TC are encrusted to the video stream -this is my case-). For archiving this is better to be able to guess the TC from a filename than from a videostream.

Maybe the last trick would be to use ubvexport and post-treat the filename with your knowledge of the UBV container, or - even better IMO - contact Ubiquiti and give them your point of view (given the time you spent for the community, and knowing the mindset of Ubiquiti, they would propably listen and enrich their export feature.

(and ultimately I don't think Ubiquiti will keep this UBV container much time, this is really a non sense)

I'm not a developper (I rather do python/perl or common shell scripting) but i have almost 6 months of video from Protect running on a CloudKeyGen2+, and if you want me to test anything of course I'll do it. I use the CloudKeyGen directly and i setup a debian 12 through a VM for the occasion, so feel free to ask !

again thanks for what you did, you saved me extra hours this month and the community should be very thankfull to people like you !
Thomas

from unifi-protect-remux.