PDA

View Full Version : Is There An I-Frame CODEC Faster/More Efficient Than MJPEG?


Schrade
29th February 2008, 00:51
Does anyone know of a codec that can do intra frame and is faster than MJPEG?

I'm just curious if there's one out there that is more efficient with compression at about the same speed or better.

foxyshadis
3rd March 2008, 23:44
Hardware MJPEG will be about the same speed as MJPEG2K, MPEG2 I-only, or DV, all much faster than any software solution. Finding HD-capable hardware might be tricky in some cases, and I assume that's why you're interested in speed.

On my quick tests, ffdshow's mpeg2 and mpeg4 are actually about 15% faster than its mjpeg and 30% faster than DV, but this is all on maximum quality and only ffdshow. Unfortunately I don't have any third-party mjpeg or mpeg2 vfw codecs installed at the moment, just the much slower mj2k.

benwaggoner
8th March 2008, 06:35
There's been interest in a Motion JPEG XR, which would certainly be more bandwidth-efficient than Motion JPEG, and certainly faster than JPEG 2000.

One thing we haven't seen a lot of is multithreaded I-frame codecs, which is a shame since it's extremely easy to alternate frames to different cores.

Dark Shikari
8th March 2008, 08:45
There's been interest in a Motion JPEG XR, which would certainly be more bandwidth-efficient than Motion JPEG, and certainly faster than JPEG 2000.

One thing we haven't seen a lot of is multithreaded I-frame codecs, which is a shame since it's extremely easy to alternate frames to different cores.x264 can do some pretty damn efficient multithreaded I-frame only encoding :p

Inventive Software
8th March 2008, 12:26
Yeah, if the search algos are switched off! :p

Dark Shikari
8th March 2008, 12:28
Yeah, if the search algos are switched off! :pThat's what --keyint 1 does :p

akupenguin
8th March 2008, 13:18
On my quick tests, ffdshow's mpeg2 and mpeg4 are actually about 15% faster than its mjpeg and 30% faster than DV
Slow DV is to be expected. DV syntactically requires true CBR, so the encoder has to try multiple quantizers to find one that's the right bit size.

Inventive Software
9th March 2008, 14:22
For shits and giggles, I thought I'd try Intra only encoding Elephants Dream (SD lossless version) with x264 and CRF18, subme 1, partitions none, me dia. The bitrate was around 4 Mbit, the file size was 318 MB, and the quality was below the 500 Kbit encode I'd done 6 months previous. The speed, mind you, was incredible! Around 30 FPS on a mobile Turion64 X2 @ 1.6 GHz. :D

If I let this at lossless, I reckon it'd wipe the floor with MSU on speed. If I cranked up the search algos, I wonder...

Inventive Software
9th March 2008, 18:22
That's what --keyint 1 does :p

I did a "lossless" encode of Elephants Dream SD (qp 0, keyint 1, subme 5, partitions all, me tesa, trellis 1, threads 3). Speed was close to real-time (a rare sight with x264 and my laptop :D), and the final file size was about 1.5 GB. Out of those options, which are actually enabled, and which are switched off during lossless encoding? Also, should I be surprised that x264 didn't output PSNR and SSIM data? If it's lossless, wouldn't SSIM be 1?

Dark Shikari
9th March 2008, 19:31
I did a "lossless" encode of Elephants Dream SD (qp 0, keyint 1, subme 5, partitions all, me tesa, trellis 1, threads 3). Speed was close to real-time (a rare sight with x264 and my laptop :D), and the final file size was about 1.5 GB. Out of those options, which are actually enabled, and which are switched off during lossless encoding? Also, should I be surprised that x264 didn't output PSNR and SSIM data? If it's lossless, wouldn't SSIM be 1?Trellis is set to 0, because trellis is an inherently lossy compression method.

TESA is dropped to ESA, because SATD is useless in lossless mode.

Partitions all and subme 5 are still useful though. Subme can be useful all the way to 7.

Note that B-frames are useless in lossless mode, but if you put them on, x264 will still use them even though they likely lower compression.

Using a few --refs and --mixed-refs might help a little bit.

CruNcher
9th March 2008, 20:18
Dark_Shikari many Professional implementation i think dropped the loosless mode and i think also it was taken out of the official specs, why was that the case do you know anything about it?

Inventive Software
9th March 2008, 20:18
I thought subme 7 would only be useful with B-frames. :confused: Will try using refs though. ;)

Dark Shikari
9th March 2008, 20:24
Dark_Shikari many Professional implementation i think dropped the loosless mode and i think also it was taken out of the official specs, why was that the case do you know anything about it?For the same reason the original lossless implementation had no pixel-based prediction whatsoever: they're idiots. They replaced it with a slightly better lossless mode, but nothing supports it.
I thought subme 7 would only be useful with B-frames. :confused: Will try using refs though. ;)Subme 7 isn't B-RDO, its inter/intra RD refinement.

Inventive Software
10th March 2008, 14:15
I did another encode from the lossless Elephants Dream SD version at qp0, only this time with 16 refs, keyint 100, subme 7, 8x8dct, partitions all. Encoding was 10 times as slow, but the resulting file was half the bitrate of one without refs and subme 5, keyint 1. Is this down to x264 this time also using P-frames too?

Dark Shikari
10th March 2008, 15:24
I did another encode from the lossless Elephants Dream SD version at qp0, only this time with 16 refs, keyint 100, subme 7, 8x8dct, partitions all. Encoding was 10 times as slow, but the resulting file was half the bitrate of one without refs and subme 5, keyint 1. Is this down to x264 this time also using P-frames too?Yes, that's the main reason. The other settings likely had nearly zero effect by comparison.

Also note that 8x8dct is disabled in lossless mode.

kolak
10th March 2008, 20:14
BlackMagic has very fast MJPEG codec, but the fastest I-frame codec is Canopus HQ (but it's not free).

Andrew