Return to JPG.....

[shropna 0]

I thing, IP CCTV will return to JPG, instead of MPEG*, H2**, etc....

Just leave that standards for cable, satellite, disc TV and teleconferencing systems.

What you thing, colleagues?

[thewireguys 3]

Why

[shropna 0]

Just one stream per source. Less processor power per camera and "decoding". Less "theoretical" latency of signal. All "clients" take from that ONE stream necessary frame rate. Off course, second stream with small image resolution can be easy made on source for "slow" transmission line. "Down-scaling" JPG resolution takes less power, than decoding of groups of pictures, so, NO dual, triple, etc. streams from video source required.

Storage capacity increases much higher and faster, than processors speed.

[thewireguys 3]

What about bandwidth? how are you going to stream 30 5MP cameras at Mjpeg? your going back into time doesn't make any sense? My cellphone has a 1G processor and has a 8 MP camera with 720P. Give me better resolution, better analytics, and better compression at the edge.

[shropna 0]

What about bandwidth? how are you going to stream 30 5MP cameras at Mjpeg? your going back into time doesn't make any sense? My cellphone has a 1G processor and has a 8 MP camera with 720P. Give me better resolution, better analytics, and better compression at the edge.

Analytic with JPG can be made not on camera more easy

About bandwidth. Like i said, just one stream O course, JPG stream with the same frame rate and image size parameters will be more higher, than group of pictures based compression, but you need more streams from that type of source, to meet "real" live viewing and recording requirements...

[rory 0]

i do love the axis mjpeg. ..

[Twilo123 0]

obviously for clarity the closer to lossless the better off you are. any compression will introduce artifacts so for that card yes JPG is better right now.

for bandwidth considerations h264 has the seat right now. unfortunately for mobile side there is limited support (you are lucky if you get baseline live streaming)

processor power has matured at this point for computers. for mobiles they will catch up faster than pc since they benefit from the mature pc market.

 

i guess my question is are containers like mpg4/h264 better than audio/video split separately like say mjpg and aac?

 

also what streaming format should we really adopt? we have options like regular http streaming, rtsp streaming, rtpoverhttp, and apple's segmenter streaming method. stream session startups and teardowns are affected, scrubbing video options, etc depending on which method we use.

 

then we have things like svc vs. avc for h264 streaming

 

then there is a question on analytics. when will a 'google' type of company really index every possible metadata for analytics. there is so much to search on this metadata from video surveillance that it could give regular internet search a run for it's money.

[shropna 0]

One interesting document:

http://www.iqeye.com/iqeye/H.264_Considerations_III.pdf

[pavel1883 0]

h 264 demanding for CPU during decoding you are right. But nowadayes SW developers already start to use GPU decoding in their survialance systems. Specially it become more popular with i3, i5 and i7 Intel Core generation 2. GPU implemented in the core already.

 

For example GeoVision GV-NVR already use this benefit. You may decode simultenuasly 32 HD video streams if use i7 2600, 8 GB RAM, Win7 64 Bit.

 

So jpeg will be in the pust) no way to returne ))

[pavel1883 0]

One interesting document:

http://www.iqeye.com/iqeye/H.264_Considerations_III.pdf

 

all new cameras from IQeye with h264. I remember the time when market start to use H264 but IQinVision company couldn't follow to the quick market demant. And starts to write so called white pappers)))) Very fan ))

 

The same situation but with megapixel technology has Bosch. They only 2 years has HD cameras))) till that time they loose projects and write white pappers how is bad to use Mp cameras in the survialence systems)

[mike_va 0]

I like the MPJEG better, mostly Axis cameras and encoders around the house. Have not played around extensively with Axis 264 settings, so don't know how good it could be. The Axis cameras are nice, in that they have adequate frame rate even with multiple streams, unlike the Panasonic 502.

 

For our home, I really don't care about the bandwidth (~16% Gigabit switch). Have an i7 running analytics and Axis ACS with 12+ cams and still at ~20-25%. ACS live view you can set up to have smaller shots so with multiple cams still works well over wireless (large split settings).

 

Especially at night mjpeg gives a better picture.

 

However I use 264 (and mpeg4) to record with sound, don't know if there is a way to do that with mjpeg.

[JoeBobKing 0]

I joined this forum if only to participate in this discussion.

Return to JPEG? **** YES!

These delta/temporal format video schemes are undermining the very core of the security world. I have been trumpeting the virtues of discreet video formats (ones that contain all needed information, like JPEG) for many years... ever since the first mpeg1 encoders arrived on security market from a major manufacturer you may well know....

 

There are many issues that the Mpeg Series bring to the table. i will make a short list of these issues

1) Can be defeated / forced to crash/ degrade significantly. Documented and publicly shown.

2) Can cause significant artifacting and image fragmentation.

3) Takes a huge CPU load to encode and even more to decode.

4) Utilizes RTSP (for the most part) to transmit the video. Most corporate backbones discourage this function wholesale

5) Has an extremely complex header architecture.

6) Has almost NO third part tools to manipulate and integrate (Live555 has a monopoly /VLC)

7) Significant latency in most implementations

was designed for teleconferencing D1 or less quality video from day 1.. This house has too many rooms added on....

9) Dropped SPS or PPS header data packets can mean no video for You. ( many camera MFGS do not periodically send down these headers.... requiring any server/client to cache and send as needed.

10) any dropped packet, such as a Iframe packet or p/B frame can trash the entire sequence until the next I frame arrives... That can be 30 seconds or more of gray screens.

11) Date time stamps are a derived function of stream start offsets.... no hh:mm:ss here!

12) We may see a wall for image sizes above 20 MP... too much to handle

13) a Snapshot is a JPEG ( usually)

14) The powers that be are already planning a replacement SOON (read the standards)

15) Don't forget you must buy licenses to engage additional streams!

 

All this distilled from years of development and extensive application-coding research. Not just reading the blogs.

 

Now on to JPEG.

 

1) Has only a few simple tags to identify all of the components.

2) Tags can be easily read.

3) Since nearly 100% HTTP/TCP, pac test are not lost. You get your images every time

4) Cant be defeated or forced to crash.

5) hundreds of tools can be used to decode/encode and utilize it.

6) Singe frames are already a JPEG.

7) JPEG is everywhere on most every device.

Comment tags, which can be multiple can contain audio, telemetry data or other info synchronized to the video itself... without touching the video fields.

9) JPEG can do most anything... so why mess with it?.... BECAUSE ITS TOO FAT.. THEY SAY...

 

 

Well it ain't....

 

Lets take a look at a system of oh... lets say 2,500 JPEG 1-2 MP cameras ( yes, they exist)

 

1) all 2500 cameras consume less than 7% f a 1GBPS network at 5 FPS x 1.3 - 2.0 MP each

2) How is this possible? SIMPLE:

3) Not all cams are on one fiber.... several hundred per fiber maybe

4) this hub/spoke design allows the gal work to be performed by the backplane of the switch... where speed is almost limitless....

5) Ip data is not all set simultaneously.... There are milliseconds when the wire is actually quiet.... This is the real world now...

 

what you get is a reliable system running on a corporate backbone eating a fraction of the 'computed' values.

 

As for disk... how much is a 2 TB disk drive lately.... Disk is almost free... building a disk system to accommodate 10TB ,100TB or even 1000TB is not a big deal. One will find that using the proper NVMS that the COST for JPEG is actually LESS than the H264 equivalent... and more so with the higher MP cameras.... Due to the following factors

 

1) The camera delivering JPEG is much less CPU powered and memory loaded; therefore it is cheaper.

2) The CPU needed to Decode/display the H264 is several times that of JPEG. One CPU can decode 200+ cameras on a single machine in JPEG mode... MAYBE 20-50 in H264 Mode...This means you trade DISKS for CPUS, MEMORY and BTU LOADING.... a losing proposition.

 

As a last note...

 

1) Disks keep getting cheaper and higher density

2) Networks of 1GBPS and 10+ GBPS are getting cheaper

 

The JPEG issue is a manufactured one... or should i say manufacturer?