News for hackers. Stuff that matters.

A comment on Introducing the ‘mozjpeg’ Project.

Re:Introducing the ‘mozjpeg’ Project by pavlov on Wednesday March 05, 2014 @02:30PM (#7349202)
Bravo. I love JPEG. Amazing that it's been 23 years since its release and it remains as useful as ever.

I remember what it was like to watch a 320*200 JPEG image slowly build up on a 386SX PC with a VGA card. Today, a HD frame compressed with JPEG can be decoded in milliseconds. This highlights the secret to JPEG's success: it was designed with enough foresight and a sufficiently well-bounded scope that it keeps hitting a sweet spot between computing power and bandwidth.

Did you know that most browsers support JPEG video streaming using a plain old <img> tag? It works also on iOS and Android, but not IE unfortunately.

It's triggered by the "multipart/x-mixed-replace" content type header [0]. The HTTP server leaves the connection open after sending the first image, and then simply writes new images as they come in like it were a multipart file download. A compliant browser will update the image element's contents in place.

[0] http://en.wikipedia.org/wiki/MIME#Mixed-Replace

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by dmm on Wednesday March 05, 2014 @02:36PM (#7349266)
Unfortunately chrome recently removed support for "multipart/x-mixed-replace". It's too bad too. It was a simple way to implement a webcam.

https://code.google.com/p/chromium/issues/detail?id=249132 http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-an...

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by fzzzy on Wednesday March 05, 2014 @02:47PM (#7349351)
According to those links, they still support it for images, but removed support for other types of resources.

It's too bad IE never supported multipart/x-mixed-replace or we might have seen more live updating websites earlier. Now that we have WebSockets and well understood long polling approaches it doesn't matter any more, since x-mixed-replace would keep the download spinner spinning forever and the newer approaches don't have that problem.

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by kybernetikos on Wednesday March 05, 2014 @02:51PM (#7349382)
I used multipart replace in firefox for streaming data for years with no download spinner. I couldn't use it in chrome because chrome always seemed to have some weird bug where 'frames' (of data in my case) were delayed.

I was disappointed when they were unceremoniously ripped out, but yes, websockets are better.

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by fzzzy on Wednesday March 05, 2014 @03:15PM (#7349547)
Ok, I believe you, it's been over 10 years since I tried it :-) Maybe I was thinking of the forever iframe, where a regular application/javascript document had content added to it incrementally over time.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by IgorPartola on Thursday March 06, 2014 @01:54AM (#7352299)
It is actually pretty bizarre. If you point Chrome at a .jpeg that does multipart/replace it will stall, giving you roughly 0.2 fps. Point it at a. .html that contains an <img> tag and it works fine. Found this out while hacking on Hawkeye: https://igorpartola.com/projects/hawkeye/
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by dmm on Wednesday March 05, 2014 @02:57PM (#7349430)
Thanks. I misunderstood that post.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by makomk on Thursday March 06, 2014 @05:34AM (#7352944)
Apparently breaking the web interface for older versions of CUPS in the process.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by jeena on Wednesday March 05, 2014 @03:34PM (#7349683)
It is interesting that you take up JPEG video streaming with the <img> tag in the context of a mozilla project. It works great in Chrome and Safari but in Firefox mjpeg streams only show the first frame. Here is the bug for it https://bugzilla.mozilla.org/show_bug.cgi?id=479015 which is unconfirmed since 2009, so clearly there is nobody over there who cares about this functionality.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by donatj on Wednesday March 05, 2014 @04:31PM (#7350088)
I play with motion jpeg a lot actually and I've never had an issue with Firefox.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by Yaa101 on Wednesday March 05, 2014 @05:18PM (#7350345)
The part that is amazing is called fast Fourier transform (http://en.wikipedia.org/wiki/Fast_Fourier_transform), it enabled the way we do stills, audio and video nowadays.

But there is more: (https://www.google.nl/search?q=fast+fourier+transform+use+ca...)

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by tripzilch on Thursday March 06, 2014 @08:27AM (#7353480)
Except that JPEG uses the Discrete Cosine Transform on 8x8 blocks of pixels, which, afaik doesn't make use of the FFT.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by nitrogen on Thursday March 06, 2014 @12:30PM (#7355156)
The DCT is analogous to the FFT.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by donatj on Wednesday March 05, 2014 @04:28PM (#7350074)
I wrote a little toy in PHP to play with motion jpeg actually - here: https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by userbinator on Wednesday March 05, 2014 @07:24PM (#7350981)
I used a picture viewer named LXPIC in DOS on a 486 to look at JPEGs - and it was incredibly fast and small. Apparently it works even on the original IBM PC with an 8088, but I've never tried that.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by Eleutheria on Wednesday March 05, 2014 @05:58PM (#7350586)
Somebody please post a link to a multipart IMG, I want to see what you guys are talking about.

It must be cool for sure.

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by christoph on Wednesday March 05, 2014 @08:16PM (#7351199)
http://141.89.114.58/cgi-bin/video320x240.mjpg?dummy=garb

Nothing in Chrome, but an animated (slowly) image in Firefox

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by zobzu on Wednesday March 05, 2014 @11:47PM (#7351953)
not worse than gif tho :p
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by _alastair on Wednesday March 05, 2014 @11:12PM (#7351818)
But each frame is a separate JPEG, right? So I'm guessing the compression here is less than fantastic.
[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by e12e on Thursday March 06, 2014 @01:03AM (#7352166)
It's different from something like mjpeg. More like the jpeg2000 format used by digital (4k) cinema[1].

For web cams, where you might not want true "live" video but prefer higher resolution still frames, it sounds like a reasonable choice.

[1] https://en.wikipedia.org/wiki/Digital_Cinema_Package

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by pavlov on Thursday March 06, 2014 @07:24AM (#7353236)
There's no fundamental difference between MJPEG and streaming a sequence of independent JPEG files over HTTP.

The MJPEG format doesn't really exist anymore: it was designed in the '90s to account for interlaced video content, but that's a rare breed nowadays. For progressive video, Photo-JPEG is equivalent.

Many popular intraframe video codecs are basically the JPEG algorithm with some modifications for specific pixel formats and some custom metadata. These include Apple ProRes, Avid DNxHD and the stalwart DV format (as in MiniDV tapes).

[ Parent | on HN ]
Re:Introducing the ‘mozjpeg’ Project by e12e on Thursday March 06, 2014 @03:18PM (#7356305)
My bad, I thought mjpeg was a keyframe based format.
[ Parent | on HN ]