Thursday, February 07, 2008

CineForm 444 always better than the HDCAM-SR?

Sony's HDCAM SR and CineForm 444 are very different compression technologies, one designed for tape-based existing deck control conform/master workflows and the other designed for online disk based workflows. Below I discuss how their core differences impact image quality, and why it is not so simple to state that one is better than the other for all image sources.

About this time last year, I blogged on a test we performed comparing CineForm's then new 444 mode to that of the respected de facto industry standard HDCAM SR; the results of that test are posted on CineForm's quality analysis page (and one of the graphs is repeated below.) While we never expected to exceed SR quality, we did select test material that would not favor SR, i.e. using very detailed source material, like full frame StEM footage (which is designed to trip up compression) plus live green-screen footage shot using a Thompson Viper. We informed Sony in advance that we were performing the test and that we were not intending to show up SR; rather we set out to prove that both SR and CineForm 444 are indistinguishable from the source, and this is still completely true. We also had the results independently verified.

Back then, it seems we had only slightly ruffled feathers at Sony, as Sony Broadcast CTO Hugo Gaggioni tried to find me at NAB 2007 to work out what we did, and if the test procedure was valid. I tried to follow up with Hugo but we never overlapped at that trade show. Sony and CineForm have long been good partners and we want to keep it that way; to demonstrate our long term relationship we even have the extremely rare bread-boarded Sony Z1 camera somewhere around the office. But in the months following NAB' 07 there was no more discussion on the test, well, until a few months ago. It seems the Sony had independently performed their own CineForm vs SR tests and drew mixed conclusions of "no significant difference between CineForm and SR 4:4:4 SQ in terms of PSNR." Sony went on to say that their 880/HQ mode is better still; in our tests we found HQ to be better than the SQ mode but of no significant difference when compared with CineForm highest quality mode.

How could Sony and CineForm do valid tests, yet get different results and both be correct in their findings? The fact is, you could almost draw these conclusions without doing the actual tests and here is why: Any very light compression (say 4:1) of DCT, Wavelet, long GOP or I-frame, will yield similar image quality; the real differences happen with much higher compression ratios. As compression ratios increase, I-Frame Wavelets (CineForm) will show their advantages over I-Frame DCT (SR, D5, DVCPRO), and as you compress more again the long GOP codecs like MPEG2 and H.264 start to shine over I-frame solutions. So in these tests we really weren't testing Wavelet vs DCT, but rather constant quality (CineForm Wavelet) vs constant bit-rate (SR). Tape systems like SR are always constant bit-rate, modulating the compression quality so the data rate matches that of the tape system.

(Click on image for clearer view)

So when you see a graph like this showing quality over time, there is a reverse graph that shows the CineForm data rate changing and SR's remaining constant. In this test, the average bit-rate of CineForm happens to be lower than SR, even though the quality is higher, so there was a real measured advantage to CineForm, yet there are tests that can show the reverse. When the image is simpler for compression, like a lot of sky or large regions with low noise or detail, the data rate in a constant quality codec like CineForm's will fall. In this latter example you may be comparing an 8:1 Wavelet to a 4:1 DCT, which would likely be in favor of the DCT. The quality on the Wavelet image has not changed, yet the quality of the constant bit-rate DCT has increased, making good use of the available bits.

A recent good example of this happened with a customer (who will remain nameless until we get an OK) that is scanning a classic 65mm color print for restoration that uses CineForm as the archive format. They independently did CineForm vs SR testing, and found in some frames SR had better PSNR numbers (than CineForm 444), and sent me the frames to investigate. The 65mm source produced really clean source for a 2K scan, and the images had shallow depth of field, so there was minimal foreground material in focus that would give the compressor a full work-out. So while SR was using all its estimated 440Mb/s, CineForm's data was running around 345Mb/s (Filmscan 2 444 keying mode.) For these frames SR yielded a PSNR of 57dB and CineForm measured 55dB--both pretty awesome by the way.

As CineForm is not limited to a tape transport mechanism, we decided to increase our quality for the Filmscan 2 mode in our next release (we have always called this mode "overkill" in house.) The sample images from our unnamed source now produce 58dB PSNR using CineForm 444 compression, averaging 390Mb/s (still under SR's bit-rate.) While Sony can leapfrog our quality for these images with their new decks that can do the 880Mb/s mode (we found it had about 3dB PSNR boost over its more common 440Mb/s mode), there are diminishing benefits for a disk-based workflow. Uncompressed DPX 1080p sequences are about 1520Mb/s, so 880Mb/s is less than 2:1, and at that rate uncompressed DPX is likely a better disk based workflow. CineForm intends to target 4:1 compression or more (usually averaging 6:1) where the visual quality is the same as uncompressed (even with extreme post manipulation) but the data rates are low enough to significantly reduce the cost of storage and the bandwidth required for capture and playback.

All of this is designed to continue to improve image quality in ways you can't even see. :)


Anonymous said...

My small test with Prospect HD in Film 2 mode (390Mb/s avg) (8bit 4:2:2) gave me 50dB PSNR, which is very good.
It wasn't professional tes- rather in house to have some idea how good is Cienform codec. In the same time Canopus HQ was about 45dB, but bitrate was 230Mb/s average, which is also very good.


David said...

Hi Andrew,

I think you made an error in your bitrate calculations, Filmscan-2 in 4:2:2 YUV will produce data half that size. I would expect around 200Mb/s maximum from YUV 4:2:2 sources.

Anonymous said...

I think it's correct. It was checked with Virtualdub. I think the bitrate was so high because of the source nature: very noisy, low light HD video.
I'll check it again.


David said...

You must have accidentally set the 4:4:4 encoding mode mode; by design the codec not going to achieve 390Mb/s in 4:2:2.

Anonymous said...


I've done another test.
This time it was stright capture using HDLink and Aja card into Cineform FilmScan 2. Avrage bitrate- 290Mb/s.
Source was quite claen 60i full HD.
FilmScan 2 mode goes above 200Mb/s very easly.
I also found a bug when using VirtualDub or other non Premiere software with Cineform. First 2 top lines (fileds) have some distortion. It's something to check.



Anonymous said...

Sorry- forgot to mention. I don't have 4:4:4 license, so I can't use this mode.


Frank Wylie said...

Someone is ARCHIVING in the Cineform codec? Not being snotty, but why? Isn't it dicey to archive in a proprietary format that is constantly evolving?

Frank Wylie said...

Sorry, forgot to add my follow up email address!

David said...


We are thought of that also. We pitched this solution at Hollywood Post Appliance last year the idea of embedding the decoder source code (ANSI-C) into archive master. People really liked this idea. So even if we change the codec in the future, the needed decoder will be present in an archive class bitstream. Plus our current decoder is compatible every HD stream we every encoded, and we plan to keep that functionality. While the archive mode it is not active yet, in the CineForm HD Export mode under Premiere Pro, you currently see a greyed out control called "Achive mode, future proofing your media." Once we have this, I feel we are more future proofed than a traditional standard, evidenced with my experience finding various implementations of MPEG, JPEG2000, that don't work on some decoders. In 50 years time, after CineForm is likely forgetten, there is a good chance many of the standards will be also, yet a bit-stream containing the decoder source will be retreivable as long as there are computers.

Although even without this archive mode, customers have many thousands of hours of CineForm HD content already in their archives. All the HD content that drives X-Box Live is archived today in CineForm, and there are many other similar archives. This is a market we are very interested in, so we intend get the archive mode completed before too long.

fred sky said...

hi david !
for some reasons i can not yet post in forums...

here is a list a questions regarding cineform and sony vegas.
perhaps you will make a FAQ with it :)

Sytem I will use (draft)
1 single Intel quad core (q6600 or q9450)
Dedicated HDDx2 for OS (RAID1)
Dedicated HDDx2 for video (RAID0)
Windows XP 32.
Sony vegas 8
Cineform NEO 4K
Blackmagic decklink pro (4:4:4)
AJA 2Ke (4:4:4)

Sources :
[SD] My source is meanly from a Sony VTR deck with Digital Betecam SD. Can I capture in SD 4:2:2 10 bits ? What is the minum CPU to do that (max quality) ? in max quality mode, what is the maxium bitrate needed ? how much RAM is needed ?
(I mean capture with preview + inverse telecine process.)
The final quality will be about the same as from the tape (archiving purpose)?

[HD] My source is meanly from a Sony HDCAM SR deck with Digital Betecam HD. Can I capture in SD 4:4:4 12 bits 1080i60/1080p60 ? What is the minum CPU to do that (max quality) ? in max quality mode, what is the maxium bitrate needed ? how much RAM is needed ?
Is it best to have a 4 cores @3Ghz or a 8 cores @2Ghz ?
(I mean capture with preview + inverse telecine process.)
The final quality will be about the same as from the tape (archiving purpose)?

Preview :
Do I have a preview during capture in realtime (with AJA and Blackmagic cards) ? this preview in on the PC monitor only ? Or can I have the preview outputted to SDI ? this preview reflect the input only, or the on-fly-compressed video ?

Timecode :
Do I get the timecode form the Deck and from SDI LTC-VITC (live sources) into the captured file ?. Is the embeded timecode available into AVI and MOV files ?
In vegas is there a way to see this embedded timecode (timecode reader) ? A way to burn it in the video ?

Closed Captions
[SD] EIA-608, closed captioning in line 21. Do the CC is embedded into the captured file ? AVI and MOV ? when I playback from the Vegas timeline, do I directly see the CC (via external decoder) ? With both AJA and blackmagic cards ?

[HD] EIA-708, closed captioning in line 9. Do the CC is embedded into the captured file ? AVI and MOV ? when I playback from the Vegas timeline, do I directly see the CC (via external decoder) ? With both AJA and blackmagic cards ?

Inverse telecine (24p film look)
My sources are mostly film telecined into digital betacam tapes NTSC. Is there a way to automatically remove the telecine process during capture ? I mean a professional film look, with no more fields, whatever the pulldown sequence of the source is (clean or broken). What happen if the source is purely video or video and telecined mixed ?
With 24p, my final footage will be much higher quality and less CPU intensive to process ?
Then can I edit this footage transparently in Vegas ? Can I mix normal video and 24p footage ?

And ultimate capture question :
Can I capture directly in Vegas with :
- close caption
- time code
- preview
- inverse telecine
- HD or SD

Or I must use cineform HDlink ?

best regards,
fred sky

David said...

Good questions, but not for here. If you can't use, use the Vegas forums on (although I prefer Other users will also help with you questions where I don't have answers.

fred sky said...

ok :)
but... some questions only about cineform :
- average and max bitrate in SD 4:2:2 ? (max quality)
- in HD 4:2:2
- in HD 4:4:4 ?

for what I understand your codec is about the same that MJPEG2000 : I-frames with wavelets compression in Variable BitRate, constant quality.
so during encoding it's very CPU intensitve (and easily mutli threaded), but for decode is much lighter ?
and so the mathematics involved in wavelet are much younger and powerful than the basic DCT of sir Fourrier ;)

Is there a way so that a MJPEG2000 hardware decoder (like a GVG video server) can decode cineform files ?

fred sky

David said...

Similarity to JPEG2000 ends with "I-frames with wavelets compression in Variable BitRate, constant quality" -- we have none of the compute load issues. We are between 5-7 times faster for encode and decode than JPEG2000. No hardware is needed.

Data rates depend on you, your quality choice and your content. Data rates in compression ratios work for all source formats. 10:1 for good quality, 7:1 for very good quality with peak data rate hitting 4:1 (rare.)

Erick said...
This comment has been removed by a blog administrator.
Tuxedo said...
This comment has been removed by a blog administrator.