Comments

PeterDuke wrote on 8/17/2012, 1:58 AM
My first reaction was more complex algorithm, more powerful computer needed to edit it. Just when we were starting to edit H.264 without needing to transcode to Cineform or whatever, along comes H.265.

I started reading the comments to see if there was any info on this, since there was none in the article, but they went on and on arguing about frame rate! Eventually sanity prevailed and the thread got to my concern.
ushere wrote on 8/17/2012, 3:20 AM
but peter, how are they going to continue selling us more powerful computers WITHOUT having the codecs that stress them ;-)

frankly my dear, i don't give a d***

i'm suffering inertia - can't be bothered upgrading since i realise as soon as i do, bang, they'll be another round of codec / processor hype that'll tire me out even more.

the simple truth is hdv does it for me and my clients, especially when the end result is probably going to be watched on youtube or similar, or even worse, a mobile phone......
musicvid10 wrote on 8/17/2012, 3:33 AM
Looks disturbingly like the hype that surrounded VP8 -- and it's now barely ready for prime time.

Whether this latest compression scheme is 50%, or even 25% more efficient, will be found out after it is released, not before.

And Leslie's point about editability is well taken; little thought went into h264 other than as a format for hardware acquisition and delivery.
Arthur.S wrote on 8/17/2012, 3:45 AM
Well, you can't stop progress, but I'm with Ush here. Only one in about 10 clients show any interest in HD, so staying with my HDV cameras makes solid financial sense. Easy editing is a boon too. A BD made using HDV is a big jump in quality from DVD. I upscaled some HDV to match full HD footage shot by someone else a while back - you needed a real good eye to tell the difference.
riredale wrote on 8/17/2012, 12:13 PM
HDV here, too. What I shoot goes to DVD anyway, and I am used to the "self-archiving" feature of HDV source tape, though within a year or two flash memory will get down to the cost per GB of tape.

I've always been intrigued by the concept of data compression, and in fact was an early player in the HDTV wars of the late 1980's with a compression mechanism of our own (we and the other first-round contenders lost to MPEG2 a few years later).

I was impressed that years later H264 could gain ~50% over MPEG2, and now it is claimed that H265 beats that by another 50%. As Spock would say, fascinating.
musicvid10 wrote on 8/17/2012, 4:33 PM
I find x264 is at a par with MPEG-2 at 25%-30% less compression with motion video source, and is worse than MPEG-2 at 50% . I think the proponents of the new format picked up on the same hype, and that many will be disappointed when they discover its not true, or render at half the bitrate and insist it is just as good. JMO.
farss wrote on 8/17/2012, 5:54 PM
"I think the proponents of the new format picked up on the same hype, and that many will be disappointed when they discover its not true, or render at half the bitrate and insist it is just as good."

They are talking about transmission / distribution not acquisition though.
One thing I've noticed is footage recorded using H.264 and then encoded using mpeg-2 can really suffer. The technical reasons why that happens are fairly obvious and yet we let ourselves get sucked into AVCHD for acquisition.

Some of the comments on the page Ushere originally linked to are interesting. It seems the MPEG evaluated H.264 using encoders running at hours per frame! That kind of gells with my understanding of this technology, you expend a lot of horsepower encoding it once for distribution / transmission then "smart" boxes handle delivery at different bandwidths / frame sizes without actually re-encoding it.

Bob.
paul_w wrote on 8/17/2012, 6:21 PM
It does appear to be a new compression algorithm rather than a smart multi stream selection (like that used in Windows Media for example). Where pre encoded multi streams are selected for best rendering at the receiving end and selected based on available bandwidth / frame rate and frame size. Going for the 'best fit' stream for best experience in the client player, usually going for a audio first - video second preference. But this seems to be more about mathematics and compressing more raw data into the existing packet size. HiDef into the exiting bandwidth? 2 pints of water into a 1 pint glass?... better compression.

Paul.