Canopus HQ Codec

John Jay · February 26th, 2005, 09:35 AM

After visiting the Canopus HDV Education site I have a better understanding of how the codec works.

The issues I was experiencing above arise because once the HQ Codec has determined the complexity of the scene, it will NOT allocate any more bits to the encode regardless of the higher file size setting, so for my test above 80 mbps is all the scene needed and it refused to allocate more.

To confirm this I added a shed load of grain to the clip and recompressed it with
Q = 4, Size = 100%

Sure enough the HQ Codec obliged by returning a compressed data rate of a whopping 340mbps

In conclusion the file size parameter is not a demand but a limiter parameter.

I am far happier now and my strategy will be to encode
Q = 4, Size = 60%,

(NB this is 10% better than superfine and I am calling it Atomic)

safe in the knowledge that low complexity scenes will never be this high because of the HQ internal quality algorithm.

David Newman · February 26th, 2005, 12:17 PM

This reflects the nature of a constant quality codec. Same design philosophy went in CFHD, although I've never seen bit-rates that high, probably due to base transform efficiency. I would still like to try it out myself. Anyone at Canopus willing to send an evalualion verison of the software?

Randy Donato · February 26th, 2005, 10:34 PM

"although I've never seen bit-rates that high, probably due to base transform efficiency" Why does that surprise you David? The goal of the codec is different than yours. It was designed first and foremost to do full frame full resolution out to monitor so it makes a super DV with 4-6x the bitrate encoding.....Your codec is a wavelet that is partially decoded at least using accelerated preview. It is indeed a very efficient way to go and you can argue the pictures values are all there at lower resolution till the cows come in...I know they are with HQ. To quote a friend of yours and mine( I will try and get him to intro us at NAB) in a debate over the same subject we have discussed here and elsewhere
"Canopus' HQ codec IS beautiful stuff. I think to a point the hangup on codecs is splitting hairs. " He is a great supporter of your codec and I think he is right....so lets not split hairs.

Graham Hickling · February 26th, 2005, 11:22 PM

Hmmm...interesting discussion. For me, output quality on playback is usually going to be a secondary consideration to the codec being as transparent as possible through several generations.

David, I'll look forward to your planned comparison, sometime.

Randy Donato · February 27th, 2005, 08:37 AM

"the codec being as transparent as possible through several generations."
Don't get me wrong that is very important and Hq is bettter than most if not all DCT based codecs. What you look for in a high quality DCT is how the filtering takes care of high contrast lines within about about 30 degress of horizontal or vertical....they tend to show aliasing(stair stepping) with lesser DCT based codecs. The bitrate is also important to whether this appears as a problem or not and as David admits Canopus uses "Constant Quality" aka variable bitrate structure just like Cineform. Hq does a great job. Mosquito noise around titles in low resolution DCT based codecs is also inherent in the compression scheme depending on the specified data size...again handled differently by different DCT codecs and not nearly a real problem (visually detectable) in high resolution with a decent data size.

February 26th, 2005, 09:35 AM	#16
John Jay Major Player Join Date: Sep 2002 Location: US & THEM Posts: 827	Final Update After visiting the Canopus HDV Education site I have a better understanding of how the codec works. The issues I was experiencing above arise because once the HQ Codec has determined the complexity of the scene, it will NOT allocate any more bits to the encode regardless of the higher file size setting, so for my test above 80 mbps is all the scene needed and it refused to allocate more. To confirm this I added a shed load of grain to the clip and recompressed it with Q = 4, Size = 100% Sure enough the HQ Codec obliged by returning a compressed data rate of a whopping 340mbps In conclusion the file size parameter is not a demand but a limiter parameter. I am far happier now and my strategy will be to encode Q = 4, Size = 60%, (NB this is 10% better than superfine and I am calling it Atomic) safe in the knowledge that low complexity scenes will never be this high because of the HQ internal quality algorithm. __________________ John Jay Beware *PLUGGER-BYTES*

February 26th, 2005, 12:17 PM	#17
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	This reflects the nature of a constant quality codec. Same design philosophy went in CFHD, although I've never seen bit-rates that high, probably due to base transform efficiency. I would still like to try it out myself. Anyone at Canopus willing to send an evalualion verison of the software? __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

February 26th, 2005, 10:34 PM	#18
Randy Donato Regular Crew Join Date: Feb 2005 Location: Houston, Texas Posts: 138	"although I've never seen bit-rates that high, probably due to base transform efficiency" Why does that surprise you David? The goal of the codec is different than yours. It was designed first and foremost to do full frame full resolution out to monitor so it makes a super DV with 4-6x the bitrate encoding.....Your codec is a wavelet that is partially decoded at least using accelerated preview. It is indeed a very efficient way to go and you can argue the pictures values are all there at lower resolution till the cows come in...I know they are with HQ. To quote a friend of yours and mine( I will try and get him to intro us at NAB) in a debate over the same subject we have discussed here and elsewhere "Canopus' HQ codec IS beautiful stuff. I think to a point the hangup on codecs is splitting hairs. " He is a great supporter of your codec and I think he is right....so lets not split hairs.

February 26th, 2005, 11:22 PM	#19
Graham Hickling Trustee Join Date: May 2004 Location: Knoxville, Tennessee Posts: 1,669	Hmmm...interesting discussion. For me, output quality on playback is usually going to be a secondary consideration to the codec being as transparent as possible through several generations. David, I'll look forward to your planned comparison, sometime.

February 27th, 2005, 08:37 AM	#20
Randy Donato Regular Crew Join Date: Feb 2005 Location: Houston, Texas Posts: 138	"the codec being as transparent as possible through several generations." Don't get me wrong that is very important and Hq is bettter than most if not all DCT based codecs. What you look for in a high quality DCT is how the filtering takes care of high contrast lines within about about 30 degress of horizontal or vertical....they tend to show aliasing(stair stepping) with lesser DCT based codecs. The bitrate is also important to whether this appears as a problem or not and as David admits Canopus uses "Constant Quality" aka variable bitrate structure just like Cineform. Hq does a great job. Mosquito noise around titles in low resolution DCT based codecs is also inherent in the compression scheme depending on the specified data size...again handled differently by different DCT codecs and not nearly a real problem (visually detectable) in high resolution with a decent data size.