Choppy vs Smooth Video -- bvr vs MP4

[beepsilver]

Do you mean you changed the protocol? This is how mine are setup:
View attachment 9212

Yes, the protocol--sorry for the confusion. Mine were set to TCP as well--changing to HTTP enabled smooth live viewing from within the camera settings via Firefox.

 

[Rockford622]

No problem. I'll give it a try.

Did this fix your choppiness in your .bvr files as well?

 

[beepsilver]

No problem. I'll give it a try.

Did this fix your choppiness in your .bvr files as well?

No, the .bvr files still play as before--this adjustment simply allows better video fluency in the live view within the Hikvision interface. Additionally, today's BI update also did not fix the choppy .bvr issue, but I'm almost certain the fix for this entails a larger effort on Ken's part--but I don't doubt it's forthcoming.

 

[bp2008]

Yes, the protocol--sorry for the confusion. Mine were set to TCP as well--changing to HTTP enabled smooth live viewing from within the camera settings via Firefox.

That is odd. The HTTP protocol is just a layer on top of the TCP protocol. HTTP is not designed to add error correction, and should be not one bit more reliable. It sounds like Hikvision's "TCP" video transport mode is bugged while their "HTTP" mode is not.

 

[bp2008]

Ok, my expert opinion on this is that Blue Iris BVR playback attempts to decode each frame "just in time" and it apparently takes longer than the 1/30 of a second to decode those very large key frames ...

ACTUALLY, that's Ken's opinion and here's what he's looking at doing to mitigate: I will have to see about making this double-buffered/threaded ...

I also mentioned to him that live preview is also affected. Bottom-line, Ken is aware and he'll likely have something for us soon.

Reading this thread, I was beginning to theorize that may be what was going on. With Blue Iris being a one-man job, it is only natural for such shortcuts to be taken. I think frame timing is one of the trickiest parts of video streaming. It is actually a large part of the reason why modern cameras have such a noticeable video delay (latency) -- typically 1 to 3 seconds or so, whereas older MJPEG cameras had much less delay. The old MJPEG streaming model cared nothing for timing each frame perfectly, and simply pumped frames of roughly equal size and complexity down the pipe as fast as possible. If a modern camera was to try the same with H264, the video delay would be much reduced and efficiency would be the same, but the video would be jittery, a lot worse than it is for .bvr playback now. And so we have buffers which delay the video. Fortunately for local playback, you can get away with those buffers being really short, practically unnoticeable even, adding only a tiny fraction of a second of delay to initial video loading and seeking.

 

[beepsilver]

That is odd. The HTTP protocol is just a layer on top of the TCP protocol. HTTP is not designed to add error correction, and should be not one bit more reliable. It sounds like Hikvision's "TCP" video transport mode is bugged while their "HTTP" mode is not.

A buggy TCP video transport mode could very well be the case--I'm sure I don't have the technical wherewithal to say definitively. I'm just happy to see smooth video while live viewing in the Firefox/Hikvision interface.
And while I have no technical expertise on the intricacies of the inner workings of these cameras, I DO appreciate your (and others) efforts to spend time to clearly elaborate your expertise to so many many of us end users.

 

[beepsilver]

Reading this thread, I was beginning to theorize that may be what was going on. With Blue Iris being a one-man job, it is only natural for such shortcuts to be taken. I think frame timing is one of the trickiest parts of video streaming. It is actually a large part of the reason why modern cameras have such a noticeable video delay (latency) -- typically 1 to 3 seconds or so, whereas older MJPEG cameras had much less delay. The old MJPEG streaming model cared nothing for timing each frame perfectly, and simply pumped frames of roughly equal size and complexity down the pipe as fast as possible. If a modern camera was to try the same with H264, the video delay would be much reduced and efficiency would be the same, but the video would be jittery, a lot worse than it is for .bvr playback now. And so we have buffers which delay the video. Fortunately for local playback, you can get away with those buffers being really short, practically unnoticeable even, adding only a tiny fraction of a second of delay to initial video loading and seeking.

Thanks for this--very informative! At least we have the ability to reencode the .bvr video which removes the jitters completely.