I made a better remote-live-view page [OLD]

I think that speed up/down buttons will be sufficient. "Pause" would also be nice...

"Speed Up" | "Speed Down" | "Pause" would be absolutely fantastic and of great use!
 
New update is online!

It includes clip playback controls, but they currently require you to have the "Frame Rate Boost" (MJPEG) option disabled.

v0.7.0 - 2015-05-16
+ Added simple clip playback controls. Play/Pause, Slow Down, and Speed Up.
+ Added a 15 second timeout for image loads to work around an issue where Chrome sometimes fails to notice that an image did not load after network loss.
* Fixed a bug where clicking the "Load Fresh Alerts" or "Load Fresh Clips" buttons would change your clip group selection to the currently displaying camera(s).
* Fixed a bug where if the only camera was a PTZ, it was not controllable in UI2.
 
Bravo!
attachment.php
 

Attachments

  • salute3.gif
    salute3.gif
    423 bytes · Views: 655
Ok. You definitely rule. Your recent speed up, slow down, pause controls are absolutely terrific. So I have to ask, would it be possible to add a method to control forward and reverse?

attachment.php
 

Attachments

  • praying.gif
    praying.gif
    4.8 KB · Views: 609
That's too bad. I just gave this another go, and it's really looking good. My clips are combined into 24 hours recordings. To find something that happened mid-day means I have to FF (at 128x), but I tend to overshoot it. Without a scrub bar, or the ability to rewind, I have to start completely over. Get that booger working, and I'd PAY to use it :)
 
How about "go back 10 minutes?" Smooth reverse video is not required...a "stutter back" feature would be fine, if possible.
 
How about "go back 10 minutes?" Smooth reverse video is not required...a "stutter back" feature would be fine, if possible.

Bumpin' dis tuda Beepster!
 
Yes, I can certainly do a "stutter back" button. I can even do a reverse-play button, but like I said there are complications.

The way Ken designed clip playback, the web browser doesn't know the frame rate or the duration of the recording. The browser just has to make image requests one after another, specifying the time index as the number of milliseconds from the start of the video clip.

The requests look something like this.

Code:
http://127.0.0.1/file/clips/porcha.20150519_141733.bvr?time=0
http://127.0.0.1/file/clips/porcha.20150519_141733.bvr?time=136
http://127.0.0.1/file/clips/porcha.20150519_141733.bvr?time=301
http://127.0.0.1/file/clips/porcha.20150519_141733.bvr?time=447
http://127.0.0.1/file/clips/porcha.20150519_141733.bvr?time=592

If the video is a very low frame rate, then some of the requested frames might be identical. As we all know once the clip ends it just starts again. When the time index exceeds the duration of the video clip, the clip starts over. And it will continue looping like this indefinitely.

This is why I did not implement a seek bar. I would need to know the exact length of the clip in order to know what time is represented by the different positions on the seek bar. But Blue Iris does not provide this value. You might say "well it is right there in the clip list where it says 13sec" but unfortunately that value is inaccurate for all alerts, and inaccurate for combined clips (e.g. those created from multiple alerts with the "combine or cut" option). It is only roughly accurate for clips that have not been combined.

Reversing the playback is easier. I don't need to know the length of the video. But Blue Iris won't respond properly to requests that specify a negative time value, so you would only be able to reverse after playing forward, and when the time value hit 0 again the playback would stop. To work around that I could have the video start at some crazy high time index like 100000 so that you could play a clip in reverse without playing it forward first, but it would start at a random point in the clip and that is a poor user experience.

I'm also not sure if Blue Iris does any caching to optimize clip playback, but if it does then playing a clip in reverse is sure to be counter-productive :)
 
  • Like
Reactions: Larebear and Q™
It's been quite a while since I tried your improved interface on 3.x
Just installed it on 4.0.6 and I have to say wow, really great stuff!
Not sure why I waited so long...

Thanks!
 
You know what, I'll ask Ken if he can do something to help us out here.

Thank you so much for your detailed answer and all of your effort; I believe I speak for many when I say that your work is greatly appreciated.
 
Any idea why my CPU usage readout went up after I updating files? I don't see any reason why that should occur, but I thought I would ask :)

Thanks for all the hard work. Oh, did you add the ability to fast forward clips? I didn't see anything when I brought them up (buttons or arrows et cetera) and I thought I read where you put rudimentary ability to do it via the web browser window.
 
Any idea why my CPU usage readout went up after I updating files? I don't see any reason why that should occur, but I thought I would ask :)

Thanks for all the hard work. Oh, did you add the ability to fast forward clips? I didn't see anything when I brought them up (buttons or arrows et cetera) and I thought I read where you put rudimentary ability to do it via the web browser window.

The clip controls do not show when in Live View mode, so you have to have a clip selected. My CPU fluctuates about 5% just from one reboot to the next but no dramatic CPU changes that I've seen with bp2008's excellent updated UI2 interface!

Clip controls:

attachment.php
 

Attachments

  • clipcontrols.JPG
    clipcontrols.JPG
    16.6 KB · Views: 574
I would not expect any difference in the CPU readout from updating UI2. Something else must be the cause.

The last update did include one change I forgot to note. In previous versions I animated the background color of the Go Live button so it would gradually pulse in brightness to be more noticeable. I discovered the smooth, gradual pulsing was using too much CPU to justify its existence so I changed it to a simpler, instant brightness change. But that won't affect the CPU usage of the BI server unless you are running the browser on the BI server, and it would be a decrease in CPU usage and only when playing a recording.
 
Found them, freaking awesome! I was just thinking about this yesterday how wonderful it would be to be able to forward this 46 minute clip and walla!

Thanks!

I am not sure what the CPU increase was, but it seems to have resolved itself. I jumped about 22% but it has leveled back to normal with no change; odd but it might of been something else in the background though the server only has BI, these goodies and the BI Tools running.

I finally caught the police on film, police on film; sorry a little Duran Duran slipped in there :)





And I caught an intruder!



Ah anyway, thanks for the interface and telling me where the buttons are!
 
You know what, I'll ask Ken if he can do something to help us out here.

Ken said he could accommodate by adding the necessary clip length information. If this works out, then I should soon be able to overhaul the entire clip playback experience in UI2 so that reverse playback makes more sense and a seek bar will be possible. Some of the enhancements won't work in older BI versions (like 4.0.6 or 3.66), but some will.
 
A "nice to have" feature:
In the standard BI web interface, in the clips area, if I down-arrow through the list of clips, each clip starts playing as I scroll through them.
In yours, it scrolls through, highlights, but doesn't change which clip is playing unless I click on one. I've become used to scrolling through the clips with a down-arrow when looking for something. I do like the thumbnails in your list of alerts.