Storage in MxPEG

[kingofkya]

Subsequent frames are not complete JPEG frames. These so-called MxPEG frames are JPEG-like frames consisting of the tiles (read: MCUs) that have changed, compared to the preceding frame.

Just a though but wouldn't this seem a better alternative than still jpegs

MxPEG reasons why it may help ZM:

Good:

the code is BSD licensed

it reduces storage space

less bandwidth to client

adds a contagion so audio could bee added easyer

would add more suport to Mobtix cameras

Lots of Documentation

Bad

activeX in browser

would need a FF plugin written

not (yet) a standard format

useless on a ptz thats moving because the whole image changes.


My idea is to have zm convert jpeg/mpeg to MxPEG from cam stream for storage then later convert MxPEG for client to view events at least until some one can make a plug-in or Java based viewer for FF


http://developer.mobotix.com/mobotix_sd ... s/how.html

http://developer.mobotix.com/mobotix_sd ... ml#cpp_lib
[/b]

[mitch]

Hi King, i am not sure if you saw my other posts but ive actually made several about MxPEG.

Search my history for my mobotix and such posts but in short:
MxPEG is sadly only decoder open source not encoder. I would LOVE if it was 100% open and would be working to make MxPEG an option for how ZM could record and stream frames.

Its a fantastic format it saves bandwidth and disk space, reduces processing overhead, and all with virtually no quality loss or additional intensive processing.

Sadly Mobotix is a business as such while they were nice enough to open up their decoder format their encoder is still a bit unwraps. As it really is one of the many features that makes them great I down they will be releasing it any time soon.

There may be enough between the decoder and the API specified to engineer an Encoder, it would be quite hard (atleast from what i read).


On the other side I have made posts about using MxPEG for an input format to ZM, and am working on a native integration of it into ZM as an input format.


As for your bads:
Instead of using activeX writing a java client would not be overly complex for browsers.
It doesn't help on PTZ cameras thats for sure, but most people using ZM aren't using it with constantly panning cameras as it also inhibits many of ZM's other features.

Also another good that wasn't mentioned:
MxPEG is very easy to convert to MJPEG, meaning even if events were stored in MxPEG they could be very easily streamed out in MJPEG to clients as desired.


As for Mobotix camera support as I mentioned previously they do currently work 100% with MxPEG in ZM but do require the intermediate decoding daemon (see my other posts) I will hopefully have a native solution soon.

[kingofkya]

yeah I saw you posts thats what gave me the idea I did not notice that the encoder was not there that sucks oh well.

maybe we need ZMxPEG (yeah that probable more work than anyone wants to do)

EDIT: I emailed them to see if they have plans to releases the encoder i do not relly expect them to but its worth a shot.