Why is BI exporting only part of my 1 hour video?

[Sybertiger]

BI Release 5.5.7.11

Sometimes it's 20, 23, 40 or some varying amount of time even though the clips are all one hour. I've set start and end frames to the beginning-end respectively and I've tried this in both the BI GUI as well as the UI3 GUI.

 

[bp2008]

There maybe a tiny chance Blue Iris's log will have an error message. Otherwise I think you'll have to ask Blue Iris Support about this one.

 

[bp2008]

But being on 5.5.7.11, they will probably just tell you to get current and try again

 

[Flintstone61]

I wonder if its affected by the record tabs setting.
For instance I also use 1 hour breaks but i changed the default numerical value of Gigabytes to 8.
Thinking it wouldn't break early based on file size.

 

[Sybertiger]

But being on 5.5.7.11, they will probably just tell you to get current and try again

I would upgrade to the latest but I'm still sticking to the very last version that supports DeepStack since it's less work to migrate. Ergo, I'd like to stay put but wanted to save some video footage before it gets overwritten in a couple of days.

 

[bp2008]

Well if you have another computer handy, you could install Blue Iris 6 without a license and copy the bvr files over, open them with Blue Iris, and possibly get it to export the whole file properly.

I wish "bvr" was a public format understood by anything besides Blue Iris. Maybe I could get Ken to produce a spec sheet for me. With AI available it should be easy for him, and then it'd be easy for anyone else (like me) to use AI to build a standalone BVR player and/or converter. Heck with it. I'm gonna send Ken a support email asking if he'll provide that. Doesn't hurt to try.

 

[bp2008]

I wish "bvr" was a public format understood by anything besides Blue Iris. Maybe I could get Ken to produce a spec sheet for me. With AI available it should be easy for him, and then it'd be easy for anyone else (like me) to use AI to build a standalone BVR player and/or converter. Heck with it. I'm gonna send Ken a support email asking if he'll provide that. Doesn't hurt to try.

For anyone following along ... Ken delivered a BVR spec to me this afternoon, so I built a web-based player based on it. GitHub - bp2008/BVR-Player-Web: A web-based player for Blue Iris .bvr files. (none of this would have been possible on this timescale without AI !)

I would be very curious to know if it has any issues playing your bvr files, @Sybertiger. I've only tested it so far on 3 of my own BVR files which were created much more recently by BI 6. But supposedly the BVR format has been pretty stable. This player doesn't have export-to-mp4 capability yet but that should be coming soon.

 

[Sybertiger]

I'll try it out in the morning and let you know.

 

[Flintstone61]

working in Goog Chrome.

 

[Flintstone61]

trying to screen shot it

 

[Flintstone61]

You can pin it to your taskbar as an app. still tinkering....

View attachment Screen Recording 2026-08-24 230220.mp4

 

[Flintstone61]

For anyone following along ... Ken delivered a BVR spec to me this afternoon, so I built a web-based player based on it. GitHub - bp2008/BVR-Player-Web: A web-based player for Blue Iris .bvr files. (none of this would have been possible on this timescale without AI !)

I would be very curious to know if it has any issues playing your bvr files, @Sybertiger. I've only tested it so far on 3 of my own BVR files which were created much more recently by BI 6. But supposedly the BVR format has been pretty stable. This player doesn't have export-to-mp4 capability yet but that should be coming soon.

Thanks @bp2008. I can wrench on cars, screw around with home maintenance repairs, build a PC, etc etc,,,but I know literally nothing about writing code or a program. So big thanks to you sir.

 

[jaydeel]

For anyone following along ... Ken delivered a BVR spec to me this afternoon, so I built a web-based player based on it. GitHub - bp2008/BVR-Player-Web: A web-based player for Blue Iris .bvr files. (none of this would have been possible on this timescale without AI !)

I would be very curious to know if it has any issues playing your bvr files, @Sybertiger. I've only tested it so far on 3 of my own BVR files which were created much more recently by BI 6. But supposedly the BVR format has been pretty stable. This player doesn't have export-to-mp4 capability yet but that should be coming soon.

Here's a nice real-world example of the usefulness of your new BVR Player:

A couple of weeks ago I found a reproducible Blue Iris /time/ API issue while testing a GIF-creation script. I was requesting main-stream JPGs from a BVR recording via the /time/ API, but one particular request consistently returned an image that clearly looked like it originated from the substream -- the camera source timestamp font was larger, yet the returned JPG was still 1920x1080, so at the time I could only infer its source.

I sent Ken the BVR and test results. He eventually tracked the behavior to /time/ stream selection and changed BI to provide the main-stream image first whenever it was available.

Your BVR Player gave me a way to go back and independently examine the original recording.

The BVR contains a 2688x1520 main stream and 704x480 substream. I selected Main, went to the troublesome timestamp (~10:32:50), and stepped frame-by-frame through several seconds around it. The main stream was present and completely normal throughout.

I then selected Sub and stepped through the same interval. At the troublesome timestamp I found the substream frame that unmistakably matches the anomalous JPG returned by the old /time/ API -- the vehicle position, scene timing, and large overlay all match.

So the player let me establish directly from the BVR that:

1. A valid main-stream frame existed at the troublesome time.
2. A closely time-matched sub-stream frame also existed.
3. The anomalous JPG returned by /time/ was clearly derived from that sub-stream frame.

That removes any question about whether the original recording lacked main-stream video at that point. The problem really was BI selecting the wrong stream during the timeline /time/ API extraction, as Ken subsequently determined.

This is something I couldn't conclusively establish before without relying on Blue Iris itself to decode/extract the BVR. Being able to select the individual streams and frame-step through the original BVR makes your player a very useful diagnostic tool in addition to being a playback utility.

Nice work!

EDIT: Here are the frames and extracted JPG of interest:
Main 2688×1520 → Sub 704×480 → anomalous /time/ timeline-extracted 1920×1080 JPG



BTW, It's hard to see in the screenshots, but the main-stream frame screenshot is at 10:32:50.347, while the "matching" sub-stream frame screenshot is at 10:32:50.048. That's only about 299 ms apart, and visually the pickup is essentially in the corresponding position. Given the different frame rates/keyframe structure of the two streams, that's very good temporal alignment.

 

[Sybertiger]

Works fine on my V5.5.7.11 BI generated BVR files. Used Chrome browser and the complete 1 hour clipped played with audio as you would expect.

 

[jaydeel]

Here's something else interesting that the BVR Player makes very easy to see:

I opened the same one-hour BVR from my previous post and compared the three stream selections.

This camera (DW1) is configured for Continuous sub + Triggered recording, so the BVR contains continuous sub-stream video while the main-stream is recorded only during triggered events. Nothing surprising there, but seeing the streams independently makes the structure of the BVR particularly obvious.

With Sub 704x480 selected, the player spans the entire one-hour recording and reports 54,097 frames - screenshot #1 below.

With Main 2688x1520 selected, the available main-stream video ends at about 10:33:11, with only 882 frames - screenshot #2 below.

And here's another interesting detail: with Auto (main + sub) selected, the player again spans the entire hour but reports 54,099 frames -- only two more than Sub alone, rather than the sum of the main- and sub-stream frame counts - screenshot #3 below.



So Auto apparently isn't simply presenting all 54,097 substream frames plus all 882 main-stream frames as one interleaved sequence. It appears to be constructing a continuous playback timeline using the sub-stream as the baseline and substituting main-stream video where it is available. I'm curious about the extra two frames in the Auto count -- perhaps that's a consequence of how the streams are aligned or switched at boundaries.

This also adds some context to the wrong-stream /time/ API example I posted above. At the troublesome ~10:32:50 timestamp, both streams were present. So this wasn't a case where Blue Iris returned a sub-stream frame because no main-stream video existed at that point. A closely time-matched 2688x1520 main-stream frame was actually present in the BVR.

Again, none of the underlying Continuous sub + Triggered behavior is surprising, but being able to select Auto, Main, and Sub independently makes the internal structure of the recording much easier to see and understand.

 

[Flintstone61]

cool. i found that menu...didn't notice it last night.

 

[Flintstone61]

but wait theres more.

 

[bp2008]

Here's something else interesting that the BVR Player makes very easy to see:

I opened the same one-hour BVR from my previous post and compared the three stream selections.

This camera (DW1) is configured for Continuous sub + Triggered recording, so the BVR contains continuous sub-stream video while the main-stream is recorded only during triggered events. Nothing surprising there, but seeing the streams independently makes the structure of the BVR particularly obvious.

With Sub 704x480 selected, the player spans the entire one-hour recording and reports 54,097 frames - screenshot #1 below.

With Main 2688x1520 selected, the available main-stream video ends at about 10:33:11, with only 882 frames - screenshot #2 below.

And here's another interesting detail: with Auto (main + sub) selected, the player again spans the entire hour but reports 54,099 frames -- only two more than Sub alone, rather than the sum of the main- and sub-stream frame counts - screenshot #3 below.

View attachment 248121 View attachment 248122 View attachment 248124

So Auto apparently isn't simply presenting all 54,097 substream frames plus all 882 main-stream frames as one interleaved sequence. It appears to be constructing a continuous playback timeline using the sub-stream as the baseline and substituting main-stream video where it is available. I'm curious about the extra two frames in the Auto count -- perhaps that's a consequence of how the streams are aligned or switched at boundaries.

This also adds some context to the wrong-stream /time/ API example I posted above. At the troublesome ~10:32:50 timestamp, both streams were present. So this wasn't a case where Blue Iris returned a sub-stream frame because no main-stream video existed at that point. A closely time-matched 2688x1520 main-stream frame was actually present in the BVR.

Again, none of the underlying Continuous sub + Triggered behavior is surprising, but being able to select Auto, Main, and Sub independently makes the internal structure of the recording much easier to see and understand.

That is very interesting because I haven't fed in a file with those properties yet. Essentially this entire app is AI generated with me just providing the prompts and some testing. It seems like a more elegant seek bar visualization could be done which shows which sections of the clip have video from which streams, but it'd be a little weird to use and probably kind of tricky to work out the bugs.

cool. i found that menu...didn't notice it last night.

It probably wasn't there. I've updated the app several times since last night when I announced it. Digital zoom, export to MP4, snapshot downloads, and more, are things that were not present on day 1.

I have some more improvements on the way tonight, currently waiting for my Claude session usage limit to reset. It will fix some issues that were causing playback stalls, among other things. Fortunately, unlike UI3, the scope of this app is fairly small so I probably won't have a lot more to change after tonight or tomorrow and things should stabilize.

 

[jaydeel]

That is very interesting because I haven't fed in a file with those properties yet. Essentially this entire app is AI generated with me just providing the prompts and some testing. It seems like a more elegant seek bar visualization could be done which shows which sections of the clip have video from which streams, but it'd be a little weird to use and probably kind of tricky to work out the bugs.

Glad that was useful. The new BVR spec Ken posted with 6.1.0.6 actually documents this as “switching mode,” and apparently the MAINAVAILABLE flag identifies substream frames for which a corresponding mainstream frame exists (excerpt pasted below). So it seems the BVR provides quite a bit of information for that sort of visualization if you ever decide it's worth pursuing.

But I agree about keeping the scope under control.

Specification excerpt...

### 5.3 Dual-stream files

Blue Iris can record two elementary streams of the same camera into one file:

Independent dual-stream (SUBSTREAM set, MAINAVAILABLE clear on header):
Both streams are complete and independently playable. Main-stream frames have flags & STREAMFLAGS == 0; sub-stream frames have SUBSTREAM set. A player selects one stream and filters frames by (flags & STREAMFLAGS) == selected. Main and sub frames interleave in the file in recording order.

Switching mode (SUBSTREAM and MAINAVAILABLE both set on header):
Set by the recorder when the camera's record mode is one of the dual-stream "sub continuous + main when triggered" options. The sub stream is recorded continuously; the main stream is recorded only during triggered/alert periods. Sub-stream frames recorded while a main frame also exists carry MAINAVAILABLE. To play "best available quality":

• Prefer main-stream frames (STREAMFLAGS == 0) when present.
• Use sub-stream frames only where MAINAVAILABLE is not set.
• Expect resolution changes at the switch points; the first frame after a switch is always a key frame.

Each stream has its own BITMAPINFOHEADER and its own AOI rectangle.

 

[bp2008]

Glad that was useful. The new BVR spec Ken posted with 6.1.0.6 actually documents this as “switching mode,” and apparently the MAINAVAILABLE flag identifies substream frames for which a corresponding mainstream frame exists (excerpt pasted below). So it seems the BVR provides quite a bit of information for that sort of visualization if you ever decide it's worth pursuing.

But I agree about keeping the scope under control.

Specification excerpt...

### 5.3 Dual-stream files

Blue Iris can record two elementary streams of the same camera into one file:

Independent dual-stream (SUBSTREAM set, MAINAVAILABLE clear on header):
Both streams are complete and independently playable. Main-stream frames have flags & STREAMFLAGS == 0; sub-stream frames have SUBSTREAM set. A player selects one stream and filters frames by (flags & STREAMFLAGS) == selected. Main and sub frames interleave in the file in recording order.

Switching mode (SUBSTREAM and MAINAVAILABLE both set on header):
Set by the recorder when the camera's record mode is one of the dual-stream "sub continuous + main when triggered" options. The sub stream is recorded continuously; the main stream is recorded only during triggered/alert periods. Sub-stream frames recorded while a main frame also exists carry MAINAVAILABLE. To play "best available quality":

• Prefer main-stream frames (STREAMFLAGS == 0) when present.
• Use sub-stream frames only where MAINAVAILABLE is not set.
• Expect resolution changes at the switch points; the first frame after a switch is always a key frame.

Each stream has its own BITMAPINFOHEADER and its own AOI rectangle.

Last night I already I did add a simple visualization to the seek bar showing which parts of the clip have the main stream, by making the seek bar brighter in those regions. It also says which streams are there when you mouse over the seek bar.



The same update also fixed issues I identified with the stream selection mode. When "main" stream is selected, it will skip past timespans with no main stream video. And when "Auto" is selected, it will play the main stream if available, otherwise play the sub stream. I know you said that was already working but in my own tests it was not (no idea why). Anyway it works for me now as of last night's update.