"Encountered track number other than 7 or 1000"...

[JohnnyPrimus]

After encountering this remuxing one of a few .ubvs I have from 2022, hit an "Encountered track number other than 7 or 1000: 1003".

Hadn't planned on creating a bug but the comment in some relevant code says it would be worthwhile to know when this error is encountered.... if there's any additional info you're interested in that I can provide happy to do so. Certainly not blocking or anything, and only hit it one time, so please also don't hold this bug open just for this if you don't want to :).

[petergeneric]

Thanks, good to know about this - are you able to provide some detail about what device this comes from? Trying to figure out what this track might actually contain

[JohnnyPrimus]

ubvinfo_dump.txt

Here's the ubvinfo dump w/ human readable clocks....it definitely seems to be video. I only included keyframes so the file wouldn't be gigantic.

Couple interesting things I noticed was that the 1003 'chunks' appear within video partition mixed with 1000. They seem to have pretty steady sizes too....if I had to guess, it may be that this is indicating a resolution change? Maybe 1003 is e.g 720i, and 1000 is whatever the native is supposed to be? I will try to find out what cam this came from but I'd be willing to bet it's wifi, because in 2022 I had almost exclusively wifi cams on the NVR as I'd just started building out the cam network in late 2022. At the time I saw frequent 'resolution lowered' notices in Protect when reviewing videos.

One other thing - might be coincidence, but I found this file which includes refrences to TID 0x03EB...aka 1003...as part of the ATSC 3.0 broadcasting spec. Maybe ubiquiti is adhering to part or all of that spec or something? It does show 0x03EB as 720i stream in that file. Of course this could also be a total red herring and mean something completely different.

[petergeneric]

That's very comprehensive, thank you! It does make sense for it to be low-res video data from the packet dump you've supplied, since the normal video track appears to stop for a while (which could coincide with the camera having wifi issues, backed up further by the packet drop errors in the log around that time).

If you're interested, you could custom-compile a version of the d900315677aca252f8db2e61db69603d31245999 rev that swaps the values of the constants "TrackVideo" and "TrackUnknown" in ubvinfo.go. That should let you extract track 1003 (assuming it's h.264) from the .ubv, it'd be interesting to see mediainfo/ffprobe output on that file.

(As you'll see from the revision referenced, I've added logic to recognise Track 1003 and ignore packets from it rather than bailing with an error, but if this is a low-res fallback track it might be useful to add the ability to extract it)

[JohnnyPrimus]

Switched branch to d900315, then swapped TrackVideo and TrackUnknown values as suggested and built, but started hitting nilrefs. It looks like the video track is hardcoded outside of ubvinfo (ex: first nilref is line 75 of remux.go). Have to switch gears for a bit but will see if I can get through the rest and get some output files that contain the 1003 video data

[JohnnyPrimus]

just ot update, plumbed the video id through and got a build working to dump a flie with 1003 track id. long and short of it is: ffprobe shows it being HEVC. i also verified ubv this was from a G3 instant connected wirelessly.

(the ffprobe output on top is 1003, and the bottom is 7)

id read that there are some containers/media files where HEVC and h264 frames may both be present (IIRC iphones or ipads were mentioned specifically).... so as a next step i was going to try two things:

1) make a change to let it go ahead and dump files where both 7 and 1003 tid video frames are found and see what happens; and

2) since the ubv ive been testing on is a timelapse, but I have many thousands of ubvs from a couple nvrs, coming from 5 or 6 different types of cameras...i thought it would be useful to hack up something to look through all of them to see if there's anything other than 1003 and 7

does that seem reasonable?

[petergeneric]

If you're wanting to continue to investigate further then go for it... although I did just spot in your screenshot that these are _2_timelapse.ubv files, which I don't really intend to support (however I don't object to getting them working). Interesting that it's HEVC and that HEVC works (report in #43 suggested that extracting HEVC did not work - although that makes me wonder if the problem there was a different track number)

I've made some modifications to allow selection of the video track from the commandline (-video-track arg, currently defaults to 7) in the latest rev, 1251bcb0a155ff5b0ae0bee1b56340c3953fef00. Hopefully this will make it easier for you to work with. This should also correct all instances of the track numbers being hard-coded, but I wasn't able to use your ubvinfo output to test this (could you re-upload it just supplying the -P -f arguments to ubvinfo? This will allow me to include it in my local suite of test parses).