Page 2 of 3
Re: Upgrading Montage Review page
Posted: Tue Jul 02, 2024 1:32 pm
by IgorA100
iconnor wrote: ↑Tue Jul 02, 2024 1:12 pm
We can add support for passing frame time instead of frame #.
Great!
Will you do it?
Will this time format be supported?
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 12:53 pm
by IgorA100
At the time of forming the grid on the page in the mode of viewing camera recordings, I display images instead of a black square for each monitor.
Code: Select all
$Event = new ZM\Event($options['lastEvent']['Id']);
if (file_exists($Event->Path().'/alarm.jpg')) {
$fid = 'alarm';
} else if (file_exists($Event->Path().'/objdetect.jpg')) {
$fid = 'objdetect';
} else if (file_exists($Event->Path().'/snapshot.jpg')) {
$fid = 'snapshot';
} else { //Event file verification required! It may not exist due to a failure. But you need to display something!
$fid = 1;
}
The size of the resulting images is 300-500kb; when displaying 30 cameras, this is 12Mb, which slows down the browser.
How can I get smaller images? Doing compression in PHP is probably not the best option.
It should be taken into account that there is a “Layout” setting where you can select both “1 Wide” and “6 Wide”. For "1 Wide" the image must be larger than for "6 Wide".
There is also a “Custom layout”, where the image from one camera will be 1800px wide, and from the other 300px.
I don’t yet know what to do in this situation.
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 1:04 pm
by iconnor
You can ask for a scaled version. If you want to save bandwidth, then someone has to generate a scaled image. The php view=image code will write the scaled image to the events folder, so if asked again it will already exist.
Always ask for the minimum quality you need and then have the browser scale it in css.
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 1:30 pm
by IgorA100
iconnor wrote: ↑Wed Jul 03, 2024 1:04 pm
The php view=image code will write the scaled image to the events folder
This code works:
Code: Select all
?view=image&eid=464908&fid=alarm&width=300
Great.
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 1:57 pm
by IgorA100
I think that when switching between "Layouts" you should not resize static images. At least for now.
Images with a width of 300px (obtained with "6 Wide") of course does not look very nice when switching to "2 or 1 Wide" with a FHD monitor resolution, but this is just a picture for a general understanding
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 5:33 pm
by IgorA100
I plan to place control buttons such as "Stop", "Pause", "Play", "Rewind", "Fast Forward". I think there will be no difficulties in processing the actions of these buttons.
The "Step Back" and "Step Forward" buttons will most likely not be active, because... It will not be possible to move frame by frame due to the fact that all events may have different FPS. You can probably try moving through time in steps of, say, 10ms.
And I still don’t know what will happen in terms of load on the server and browser when using “Rewind”, “Fast Forward”. It seems to me that the disk subsystem cannot cope with such a load.
When playing, I use mode=jpeg, I don’t know how to use mode=mpeg yet.
Isaac, what do you think about this?
Re: Upgrading Montage Review page
Posted: Wed Jul 03, 2024 9:31 pm
by iconnor
mode=mpeg does not work. It is old, from the mpg1 days. Would require flash player to play it...
We need something new, to pass h264 frames, but that may be too much for the client as well.
Re: Upgrading Montage Review page
Posted: Fri Jul 05, 2024 8:48 pm
by IgorA100
iconnor wrote: ↑Tue Jul 02, 2024 1:12 pm
We can add support for passing frame time instead of frame #.
Isaac, Haven't you done this yet?
Re: Upgrading Montage Review page
Posted: Sun Jul 07, 2024 1:55 pm
by iconnor
No.
Looks like there is already a time= parameter. Seems to take a unix timestamp.
Re: Upgrading Montage Review page
Posted: Mon Jul 08, 2024 2:05 pm
by IgorA100
iconnor wrote: ↑Sun Jul 07, 2024 1:55 pm
a time= parameter. Seems to take a unix timestamp.
For some reason this doesn't work for me.
I decided to use "command: CMD_SEEK, offset:XX"
This seems to work fine and I think it's better than changing the SRC.
I'm right?
Re: Upgrading Montage Review page
Posted: Mon Jul 08, 2024 2:27 pm
by iconnor
Yes definitely that is the way to go.
The src is only good for initial stream startup.
Re: Upgrading Montage Review page
Posted: Mon Jul 08, 2024 5:29 pm
by IgorA100
Is CMD_MAXFPS not supported when playing events?
Re: Upgrading Montage Review page
Posted: Mon Jul 08, 2024 6:23 pm
by IgorA100
iconnor wrote: ↑Sun Jul 07, 2024 1:55 pm
a time= parameter. Seems to take a unix timestamp.
Because "time= parameter" doesn't work for me
My SRC line where "time" doesn't work:
Code: Select all
mode=jpeg&scale=21&rate=100&maxfps=1&replay=none&connkey=441617&source=event&event=477618&rand=1720462871&auth=55b76267172f9931638faadcdbe67427&time=1720420649
, then I'm forced to use CMD_SEEK. In this case, if I run CMD_SEEK immediately after replacing the URL, then nothing happens. If I run CMD_SEEK with a delay of 1.5 seconds, then everything works. But launching with such a delay is terrible.
What should I do ?
ADDED: This long delay before executing CMD_SEEK is required if the Frame URL that is currently being played changes. This is probably due to the frame stopping and starting again.
Perhaps a better solution would be to support CMD_MAXFPS and CMD_SCALE when playing events.
ADDED2: CMD_SCALE turns out to work when playing events! This is already great!
ADDED3: I spent a long time figuring out why CMD_MAXFPS does not work. It seems like it should work, but it doesn’t want to. This makes me very sad.
Re: Upgrading Montage Review page
Posted: Tue Jul 09, 2024 11:08 am
by IgorA100
I'm working in JS with a sparse array of events, where I use the Event ID as the key.
I wondered if this is correct... It's convenient, but can the number of events exceed 4,294,967,294? If yes, then you will have to not use Event ID as a key.
My calculation:
500 cameras with 8,000 events per day (all day for 10 seconds) = 4,000,000 per day * 365 days = 1,460,000,000 per year
those. about 3 years.
Perhaps I should stop using Event ID as an array key???
ADDED: I decided to remake the array and not use Event ID as the array key . It will be more reliable this way.
Re: Upgrading Montage Review page
Posted: Tue Jul 09, 2024 3:35 pm
by iconnor
You might exceed that integer. Originally Event ID was 32bit. I had to increase it to 64bit because I hit the limit at a client's.
I think using a sparse array indexed by EventId is the right way to go (makes you are using object though, as arrays aren't actually sparse).
I think it is unlikely that a system would keep all those events.
A lot of systems these days want to use UUIDs. So maybe just treat the EventId as a string and not an integer.