I'm just picking up news on the new Canon format, H.265 HEVC which will be included with the new XF705 camcorder.

Could this codec be added to other Canon Cameras through a firmware update? Just wondering as it would make recoding 4k on my C300mk2 a whole lot easier.

No it can’t, encoding is done with an encoder chip, not via software.

Could this codec be added to other Canon Cameras through a firmware update? Just wondering as it would make recoding 4k on my C300mk2 a whole lot easier.
Why do you think it would make things easier.

H.265 is harder to decode and while the compression is more sophisticated than H.264 this would only become significant for lower, destination quality, bitrates.

The higher the bitrate the less compression 'finesse' becomes a factor.

Why do you think it would make things easier.

Because 4K on the C300 Mark II is 400Mbps.

Because 4K on the C300 Mark II is 400Mbps.
I know you will disagree on this but with such a high bitrate the compression finesse of H.265 is of very little significance.

Thank's all for that feedback.

Yes, the 400Mbps rate was the reason for hoping for a more economical and efficient 4k codec for the C300mk2.

I know you will disagree on this but with such a high bitrate the compression finesse of H.265 is of very little significance.

Yes, because it’s wrong. 10-bit 4:2:2 H.265 on the XF-705 is 160Mbps. 160Mbps is less than 400Mbps.

"More efficient" often means "Throwing away more information."

Gradient issues with "blocky" gradients is MUCH WORSE with HEVC, to the point where I truly believe it should not be used in acquisition unless it has a specific profile made for it. Remember, HEVC only just drafted a "High Throughput" profile, and no hardware encoder ASICs support that yet. It's still just "Main 10." Current encoding profiles are for DISTRIBUTION, not ACQUISITION.

There's a reason Sony waited until the AVC spec had super high levels to release XAVC.

To equate the situation, to use Canon HEVC now is like using the Sanyo Xacti's H264 compression while broadcast acquisition was still 50mbps MPEG2.

There's a reason why the bitrate should be high for acquisition. Event video means you should have a dedicated person swapping cards and a LOT of storage.

Compression algorithm technology is not static, they have improved and got better over time. Not all compression methods are equal to each other.

I for one do welcome wider usage of more advanced compression tech in cameras.

"More efficient" often means "Throwing away more information."

No, it does not often mean that. "More efficient" means better algorithms (read: more CPU intensive) based on prediction, look-aheads, and how to best deal with information that doesn't read visually to the viewer in order to achieve the best result at the lowest size.

Gradient issues with "blocky" gradients is MUCH WORSE with HEVC

That is simply not true.

To equate the situation, To use Canon HEVC now is like using the Sanyo Xacti's H264 compression while broadcast acquisition was still 50mbps MPEG2.

You are equating a professional camcorder from Canon with a low-end consumer point-and-shoot from a company not known for its cameras in a professional field.

Compression algorithm technology is not static, they have improved and got better over time. Not all compression methods are equal to each other.

It changes what parts of the image get less information.

In HEVC, this means low motion often doesn't even get a full set of GOP temporal frames, as it's cheating with temporal information by sometimes not doing full GOP frames if the color in motion is too similar between shades. This is extremely common in highly compressed HEVC.

With the move to H264 and HEVC, subtle gradations between stuff like a gradient of the sky become blocky the lower the bitrate. Because they limited the highest level possible for Main 10 and can only go to a certain "very specific" bitrate, You will notice these "banding" artifacts on a clear blue sky a LOT more than H264 if the bitrate isn't high enough.

In HEVC, this means low motion often doesn't even get a full set of GOP temporal frames, as it's cheating with temporal information by sometimes not doing full GOP frames if the color in motion is too similar between shades. This is extremely common in highly compressed HEVC.

"Highly compressed" being the keyword. Highly compressed anything will throw away information, that's why you give enough bitrate for HEVC to not have to do that. The difference between 10Mbps HEVC and 160Mbps HEVC.

With the move to H264 and HEVC, subtle gradations between stuff like a gradient of the sky become blocky the lower the bitrate.

Both H.264 and HEVC exhibit the same behavior with lower bitrates.

You will notice these "banding" artifacts on a clear blue sky a LOT more than H264 if the bitrate isn't high enough.

You will not notice banding artifacts more in HEVC vs H.264 at similar bitrates.

Thank's all for that feedback.

Yes, the 400Mbps rate was the reason for hoping for a more economical and efficient 4k codec for the C300mk2.

410 Mbps is high data rate? Try shooting Cinema RAW Light with the C200. 1Gbps seems high, when we switch back to the C300 MKII, 410Mbps seems almost quaint, we end up good recording times with our 256GB CFast cards on the C300 MKII in comparison. All relative I guess but even the 1Gbps is manageable if not a little ungainly in post and data workflow.

I'm still waiting for a encoding ASIC that supports High Throughput HEVC before taking it seriously. That's likely 2 IBCs away, likely something like XEVC from Sony.

I'm sorry, 160Mbps if it's "Main 10" profile isn't enough.

I'm sorry, 160Mbps if it's "Main 10" profile isn't enough.

It's not "Main 10" because it's 10-bit 4:2:2 HEVC, so it's, at a minimum "Main 4:2:2 10" which isn't the same as standard "Main 10". Again, this seems to be conflating consumer side HEVC solutions with professional ones. The two aren't the same, and the codec in the XF705 will be very strong, I guarantee it.

It's still Main profile, not High Throughput.

High Throughput is designed for acquisition and mastering, with intra only modes and much lower compression ratios, due to the ridiculously high maximum bitrate allowed, Think of it as the new MPEG-4 SSP (HDCAM SR) for 4K and 8K and beyond.

There is going to be a "HDV" "subjective quality" uproar again with the introduction of HEVC recording in the professional realm.

But I guess it all doesn't matter if it's convenient.

There is going to be a "HDV" "subjective quality" uproar again with the introduction of HEVC recording in the professional realm. But I guess it all doesn't matter if it's convenient.

It won't be just "convenient". It will not be the "HDV" "subjective quality" uproar again at all. Not even close.

I'd be curious to see what your HEVC-based project is where you had quality problems. I did a project back in February which was primarily HEVC from Filmic Pro and a GoPro Hero 6 (a promo that included rainforest hiking and rafting). I have zero of the issues you have brought up, and that's from consumer camera sources.

Well if you must know, my gauge of HEVC compression is from end delivery, and then translating that to how it might complicate things for acquisition.

You have no experience with HEVC as an acquisition codec?

I could have been watching Demo videos from consumer Demo TV sets with HEVC encoded content from LEGAL SOURCES at a Best Buy.

And just cause I don't produce that content now, doesn't invalidate all the points about how gradients are quantisized. Yet you go on the attack with wild assumptions of inexperience just cause you can.

Quit it.

I could have been watching Demo videos from consumer Demo TV sets with HEVC encoded content from LEGAL SOURCES at a Best Buy.

Because then you'd be talking about UHD Blu-ray discs, and that content absolutely does not suffer from any of what you've been complaining about.

And just cause I don't produce that content now, doesn't invalidate all the damn points about how gradients are quantisized.

You don't get that information from watching UHD Blu-ray demo displays at Best Buy. You get that from working with FFMPEG and x265 encoded Blu-ray rips.

Again, stupid projections and anti-FFmpeg bias with ProRes and their stupid implementation of ProRes. You decided to count FFmpeg as unprofessional and x265 as only used by pirates.

I was not watching the UHD Blu-rays. The demos were legally installed INTO THE TVs with pre-licensed content.

I was not watching the UHD Blu-rays. The demos were legally installed INTO THE TVs with pre-licensed content.

Then you were watching H.264 encodes, not HEVC, thus you cannot tell the difference between the two and would fail a blind test.

Overall, the HEVC-based codec in the Canon XF705 will be perfectly fine to capture what the sensor is delivering. No one should be concerned, except for the obvious performance hit on older machines.

How can you actually prove that without asking the manufacturer directly? It could be a mezzanine format you export to the manufacturer is H.264 then they recompress it to fit on the flash memory inside the TVs in HEVC.

How can you actually prove that without asking the manufacturer directly?

If you don't know, then why are you automatically assuming it's HEVC? How did they display 4K before HEVC was viable? With H.264. Why would a TV manufacturer re-encode all their demo videos into HEVC? They wouldn't. So again, it's probably H.264 and you're just making an assumption? And then want to post here about how terrible of a codec it is? All compressed codecs are terrible at low bitrates. You might as well complain about ProResHQ in an Alexa or a Red Weapon not being a good choice because ProRes Proxy is ugly.

HEVC is a great new codec, and it's implementation in the XF705 is very interesting. I'd like to see Canon do that for the C300 Mark III in some respects, though the XF-AVC codec performs quite well on my current editing system. That would be my only concern about it.

Why? Space efficiency. The TVs only have a certain amount of flash memory for the Smart functions for it's operating system, and the demo videos.

You're speaking for yourself when you don't know a thing about FFmpeg and how widespread use it is for ACTUAL BROADCAST STUFF like converting stuff to DNxHD. Resolve uses FFmpeg on Windows.

Is Resolve suddenly invalid for using FFmpeg? For ProRes, yes. (DEFINITELY YES on Windows) For everything else, no.

Why? Space efficiency. The TVs only have a certain amount of flash memory for the Smart functions for it's operating system, and the demo videos.

Which was still enough for the original 4K displays when they were all H.264 from years ago when they first launched.

IN THE PAST.

Manufacturers have to take note of device resources and find better ways to allocate it.

This has dragged on for way too long. I'm done with this.