Moving BIv6 to new Win 11 PC

[Dewcal]

I am wondering if someone could point me to a current method of transferring my BIv6 installation to a new Windows 11 PC. I assume that I can just copy the various saved recordings to a similar directory strucre on the new PC.. I would prefer not to have to set all my cameras again - hopefully there is a way of bringing the settings over.

I also assume I need to download the same version of BIv6 as I am currently using, install same and sign in with my licence before copying everything (hoepfully) over.

Thanks for any help.

 

[Techie007L]

@Dewcal Sure:

1. On the old PC, open Blue Iris -> Settings.
2. Click [Deactivate] to free your license (make sure you have your original license key handy first as you'll need it on the new PC).
3. Click [Export settings] and save the .reg file to a flash drive.
4. If your Blue Iris support period is current, just download the latest version from their website and install it on the new PC. If not, copy the Blue Iris installer you last downloaded (hopefully still saved in your Downloads folder), and C:\ProgramData\Blue Iris\temp\update.exe to a flash drive, plug it into to the new PC, install with the installer you copied, and then update via the updater you copied. Note that ProgramData is normally a hidden folder. If you can't see it, type C:\ProgramData into File Explorer's address bar and press [Enter] to open it.
5. Open Blue Iris on the new PC, activate it using your license key, and open Settings.
6. Click [Import settings] to transfer over all your cameras/storage settings from the file you saved on the flash drive (important to do this before bringing your clips over, or it will automatically delete everything over a week old).
7. Close Blue Iris on both PCs and make sure it is stopped (new PC should be fine as it wouldn't be installed as a service yet; old PC you'll probably need to manually stop the Blue Iris service after closing).
8. Copy/move the contents of your old C:\BlueIris folder to your new PC. If you've used alternate paths, you'll need to copy the desired .bvr files from them as well. You can physically connect the old drive to the new PC, or (with a little difficulty) use Windows File Sharing to copy the files from one PC to the other over your local network (you'll want both PCs connected via gigabit Ethernet as it'll take forever on WiFi).
9. Once the transfer is finished, you can start Blue Iris again on the new PC and install it as a service.
10. If it was a 1:1 copy (same folders, same drive letters) all your old clips should be there and accessible. But if clips are missing/broken, you can right-click any clip in the Clips pane -> Database -> Delete & Regenerate and it'll regenerate its database to reflect the .bvr files it has found on the PC.

 

[Dewcal]

Techie007L - Many thanks for making it sound so simple and straight forward! I will try it in the next couple of days. Your help is appreciated.

 

[Dewcal]

One further query if I may? Before I move BI v6.x to the new PC, I am wondering if there is a current "idiots guide" as to how set the cameras up? I can see one from a couple of years ago which suggests only using H264 but am wondering if that is still current advice with v6 apparently having better support for H265.

Many thanks.

 

[Bruce_H]

The built in help file is good, and from what I have read on this and other forums H264 is still preferred. Is there some reason you feel that H265 would be better?

 

[Dewcal]

Thanks for suggestion - no reason other than a "newer" format / ability and wondering if there was any advantage in using it.

 

[Techie007L]

@Dewcal In my experience, you usually get slightly better video quality and recording time (using direct-to-disk) if you set the cameras to encode in H.265 (note that this can vary based on camera model). H.265 camera decoding has been supported in Blue Iris 5 for a long time. However, I would not set Blue Iris to output H.265 (the newly added feature) unless you have a slow connection and a powerful processor—while it will give you same quality with a lower bitrate (which can help on a slow connection), it is significantly more complex to encode (higher CPU usage). Also, Blue Iris 6 calculates quality incorrectly, so switching it to output H.265 automatically results in a quality reduction unless you manually bump the quality setting up (basically have to match QP to maintain the same quality; this relationship is documented in UI3 -> Help -> Video Encoder Quality and H.264 / H.265 QP Relationships; if you were using a quality of 50% for H.264, you'll need to bump it up to 60% for H.265 to maintain the same quality). The output encoding settings I'm referring to can be found in Blue Iris -> Settings -> Webserver -> Advanced -> Configure.

 

[wittaj]

Thanks for suggestion - no reason other than a "newer" format / ability and wondering if there was any advantage in using it.

The TL : DR version is H265 is not a consistent codec standard and every manufacturer does it different, which can be problematic with some VMS systems. H264 tends to be the consistent codec. Plus H265 uses more camera processor resources, which can then be problematic with other options on the camera.

Now for the long version:

SmartCodec (+ variants) can create lots of problems with playback / search - many have seen it jumps and skips over time, plus it is proprietary to the manufacturer and can be problematic with other VMS systems.

Most of us have found H265 in these cameras suck.

H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.

However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.

The cheaper the camera, the more it will struggle with the processing requirements of H265.

Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.

The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.

In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is essentially zero.

In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.

H265 is one of those theory things that sounds good, but reality use is much different.

Some people have a field of view or goals that allow H265 to be sufficient for their needs.

Third party VMS systems do better with H264. That is the tried and true standard. H264H is ok as well.

As always, YMMV.

 

[Dewcal]

@Techie007L - Thanks for this. I have never (knowingly) changed the BI output settings! Will read up more of the help files....

 

[Dewcal]

The TL : DR version is H265 is not a consistent codec standard and every manufacturer does it different, which can be problematic with some VMS systems. H264 tends to be the consistent codec. Plus H265 uses more camera processor resources, which can then be problematic with other options on the camera.

Now for the long version:

SmartCodec (+ variants) can create lots of problems with playback / search - many have seen it jumps and skips over time, plus it is proprietary to the manufacturer and can be problematic with other VMS systems.

Most of us have found H265 in these cameras suck.

H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.

However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.

The cheaper the camera, the more it will struggle with the processing requirements of H265.

Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.

The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.

In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is essentially zero.

In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.

H265 is one of those theory things that sounds good, but reality use is much different.

Some people have a field of view or goals that allow H265 to be sufficient for their needs.

Third party VMS systems do better with H264. That is the tried and true standard. H264H is ok as well.

As always, YMMV.

@wittaj Many thanks for your reply and the information therein - will stick with H264.

 

[Techie007L]

The TL : DR version is H265 is not a consistent codec standard and every manufacturer does it different, which can be problematic with some VMS systems. H264 tends to be the consistent codec. Plus H265 uses more camera processor resources, which can then be problematic with other options on the camera.

Now for the long version:

SmartCodec (+ variants) can create lots of problems with playback / search - many have seen it jumps and skips over time, plus it is proprietary to the manufacturer and can be problematic with other VMS systems.

Most of us have found H265 in these cameras suck.

H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.

However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.

The cheaper the camera, the more it will struggle with the processing requirements of H265.

Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.

The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.

In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is essentially zero.

In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.

H265 is one of those theory things that sounds good, but reality use is much different.

Some people have a field of view or goals that allow H265 to be sufficient for their needs.

Third party VMS systems do better with H264. That is the tried and true standard. H264H is ok as well.

As always, YMMV.

@wittaj Much of what you said is BS. Learn how video encoding actually works so you can apply appropriate settings, and most of the problems you described above will go away. ALL of the cameras I manage are running H.265, and it's been a long time since I've managed a camera where the H.265 encoder did a worse job than the H.264 encoder (yes, some of the first cameras to support H.265 had issues like you mention, but that was over 10 years ago). And no, this is not because I "have a field of view or goals that allow H.265 to be sufficient for my needs"—I am looking for the clearest picture with the lowest disk usage, pixel peeping—frequently pushing cameras to the edge of their DORI limits where pixel detail matters (like reading license plates), and I universally get the best results using H.265 encoding. Furthermore, video encoding on these cameras is done by an SoC with hardware acceleration, not "by the CPU", so there's not a CPU usage issue at stake here that would cause the camera to "stutter" when encoding H.265 (and I run all my cameras at 30fps no problems). Additionally, most of the savings with H.265 are seen in static areas/scenes; so if you're using CBR instead of VBR encoding, you are negating most of the benefits of using H.265, hence you seeing no real gains (this goes back to "learn how video encoding actually works" so you can apply appropriate settings). The gains are significant if you break out of the old paradigm of settings that aren't optimal with the newer technologies. Sad thing is most cameras will let you use terrible settings, which you are obviously doing. If you wanted to present a valid argument against H.265, perhaps one would be that the cameras use slightly more power in H.265 mode and this adds a couple $ to your electric bill each month because you have so many cameras. Or that the CPU in your older Blue Iris PC can't keep up with decoding the H.265 streams but is just enough when decoding H.264 (decoding H.265 uses more CPU too, but not as much of a difference as encoding it).

 

[wittaj]

@wittaj Much of what you said is BS. Learn how video encoding actually works so you can apply appropriate settings, and most of the problems you described above will go away. ALL of the cameras I manage are running H.265, and it's been a long time since I've managed a camera where the H.265 encoder did a worse job than the H.264 encoder (yes, some of the first cameras to support H.265 had issues like you mention, but that was over 10 years ago). And no, this is not because I "have a field of view or goals that allow H.265 to be sufficient for my needs"—I am looking for the clearest picture with the lowest disk usage, pixel peeping—frequently pushing cameras to the edge of their DORI limits where pixel detail matters (like reading license plates), and I universally get the best results using H.265 encoding. Furthermore, video encoding on these cameras is done by an SoC with hardware acceleration, not "by the CPU", so there's not a CPU usage issue at stake here that would cause the camera to "stutter" when encoding H.265 (and I run all my cameras at 30fps no problems). Additionally, most of the savings with H.265 are seen in static areas/scenes; so if you're using CBR instead of VBR encoding, you are negating most of the benefits of using H.265, hence you seeing no real gains (this goes back to "learn how video encoding actually works" so you can apply appropriate settings). The gains are significant if you break out of the old paradigm of settings that aren't optimal with the newer technologies. Sad thing is most cameras will let you use terrible settings, which you are obviously doing. If you wanted to present a valid argument against H.265, perhaps one would be that the cameras use slightly more power in H.265 mode and this adds a couple $ to your electric bill each month because you have so many cameras. Or that the CPU in your older Blue Iris PC can't keep up with decoding the H.265 streams but is just enough when decoding H.264 (decoding H.265 uses more CPU too, but not as much of a difference as encoding it).

As other things you have posted, we have to agree to disagree.

So I guess most here do not know how to set up a camera. Most here agree on the H264 versus H265. We have seen it with our own eyes and performance.

Many here compliment me on my samples of low light images that have put people in jail, and I have helped countless improve the performance of their cameras both publicly in the forum and by DM.

I will take any of my still pic examples in low light up against any of yours.

Please show us an example where you pushed a camera to the edge of the DORI limits and can read plates at night of a moving vehicle. Or even ID a person at the DORI limits in low light conditions.

Oh wait, you refuse to post any examples proving your points...

 

[bigredfish]

Regardless of the theoretical benefits of h.265, the reality is that there is little or no benefit in our application.

IMHO in my experience H.265 as implemented by Dahua is inferior in image quality to h.264.h CBR and produces a blocky pixelated mess at low and medium bitrates, and is particularly bad with VBR.

It saves a little bit of HD space but not enough to make it worthwhile.

I have previously and am glad to point to the examples showing the above.

Once again Unless you have examples to compare, and are willing to show side by side results in video, it’s just a waste of time.