Feature Request: adding pixel_dif in the mjpeg stream

Description

OK I have another angle on this. Not wanting to break the mjpeg stream protocol how about adding the following

Add yet another motion config option for example UseFirstPixelAsCarrier = yes

Instead (after the frame compression) of this (top left) corner of the image actually representing a pixel it represents state information from the motion server such as pix_dif (maybe as a percentile there is enough space in one pixel to cram a lot of info ).

Teletext reborn

-- RobertH - 21 May 2005

Follow up

You forget that the mjpeg stream is a stream of jpegs. There is no such thing as an upper left pixel. There is an upper left square which will be quite visible. And the important most important problem - limit the bandwidth is not addressed since the filtering happens in the client.

I cannot support this idea.

-- KennethLavrsen - 21 May 2005

Comments

Sorry, I forgot to add why..... Its one thing to be able to have a stream of images. I will bet that 98% of the time they are arbitrary and probably quite useless (useless in the sense of too much worthless information... Tree blowiing in the wind etc.....). What we need is a way to know (filter) in the mjpeg stream that something is different and the motion server is sensing it. Otherwise what’s the point of all the motion detection algorithms and the mjpeg streaming if all what you know is after the fact? Sure its possible to simply set the web_cam motion only parameter and be done, however I am thinking in terms of a piece of software being able to react and inform the user of conditons while the user sill knows that events are occuring. A good example of this is the squelch on mobile phones. In short moments of silence you find yourself asking if the other party is still there !!

And lets be honest. Other than processing overhead which should be minimal who would ever notice the top left pixel doing wierd things and care.......

-- RobertH - 21 May 2005

---

ok

-- RobertH - 21 May 2005

---