VP9 Vs H264 Vs H265: - Next-gen Codecs Provide 50% Bitrate ...

Trang chủ » H264 Vs H 265 Vs Vp9 » VP9 Vs H264 Vs H265: - Next-gen Codecs Provide 50% Bitrate ...

Có thể bạn quan tâm

Hacker News new | past | comments | ask | show | jobs | submit login
ju-st on Jan 12, 2016 | parent | context | favorite | on: H.265/HEVC vs. H.264/AVC: 50% bit rate savings ver... VP9 vs H264 vs H265:

- Next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow at the top settings required to accomplish such results.

- Normalized for CPU usage, libvpx already has some selling points when compared to x264; x265 is still too slow to be useful in most practical scenarios except in very high-end scenarios.

- ffvp9 is an incredibly awesome decoder that outperforms all other decoders.

https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecod...

keithwinstein on Jan 12, 2016 | next [–] One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a software VP9 decoder are either Google employees (libvpx) or ex-Google-employees who worked on VP9 when they were there (rbultje, who wrote ffvp9 with Clément Bœsch).

DannyBee on Jan 12, 2016 | parent | next [–] Which "spec" are you referring to?

The bitstream spec is definitely public.

Ace17 on Jan 13, 2016 | root | parent | next [–] There's a public RFC, but it's by no means usable as a bitstream spec. There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA. We use it at work, and getting an updated version is far more trouble than downloading a file on a public server. The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.

mrb on Jan 13, 2016 | root | parent | prev | next [–] I could only find an "overview", not a full spec: https://tools.ietf.org/html/draft-grange-vp9-bitstream-00

TD-Linux on Jan 12, 2016 | root | parent | prev | next [–] I have never seen a spec, do you have a link?

nickodell on Jan 13, 2016 | root | parent | next [–] This, perhaps? https://tools.ietf.org/html/draft-grange-vp9-bitstream-00

It's only a draft, and two years out of date, but it is public.

TD-Linux on Jan 13, 2016 | root | parent | next [–] It's a good overview of VP9, but it's certainly not enough to implement a decoder, or call it a "spec".

jimbankoski on Jan 12, 2016 | parent | prev | next [–] Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm.

Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.

Ace17 on Jan 13, 2016 | root | parent | next [–] Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy. Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does".

We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.

tagrun on Jan 13, 2016 | parent | prev | next [–] http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP...

acdha on Jan 12, 2016 | prev | next [–] > ffvp9 is an incredibly awesome decoder that outperforms all other decoders.

Not to take away from the hard work which has gone into ffvp9 but that should be “all other open-source decoders” without benchmarks comparing it against the proprietary implementations which most people actually use. ffvp9 be great but still the wrong choice if someone has a hardware/GPU-accelerated H.265 codec in their OS and would prefer longer battery life to use of free software.

microcolonel on Jan 12, 2016 | parent | next [–] Intel platform seems to have a VP9 decoder built in. Not sure about others.

cpeterso on Jan 12, 2016 | root | parent | next [–] Firefox added support for Intel's VP9 hardware decoder, but had to disable it because of Intel bugs and hardware performance was often worse the available software decoders!

https://bugzil.la/1225019

cpeterso on Jan 12, 2016 | prev | next [–] Mozilla plans to ship ffvp9 in Firefox 46 (now in Nightly channel):

https://bugzil.la/ffvp9

cat-dev-null on Jan 12, 2016 | prev | next [–] This seems like an opportunity for hardware acceleration (CPU/GPU instructions / x265 accelerator) to reduce the power consumption on video playback for the majority of devices. Perhaps it's cheaper and simpler to make a co(+)dec chip that can encode too.

dogma1138 on Jan 13, 2016 | parent | next [–] NVIDIA currently supports HEVC decoding on it's GTX 900 (and 750ti/se as they are also Maxwell) GPU's. iPhone 6s has h265 decoding also (works with Plex without transcoding flawlessly). Qalcomm has support for HEVC through all of it's latest generations 200 (2xx, 4xx, 6xx all) through 800 (808 onward) series of SOC's.

I have not had issues playing 1080 x265 content videos on any of my mobile devices past 18 months or so since they've started releasing them. There's just something to be said about 200-300MB per 1080p episode and about 700MB per movie. Can cram an entire library to most of my current mobile devices for a flight/long commute without having to worry about SD cards/USB OTG.

threeseed on Jan 12, 2016 | prev | next [–] Am I missing something or is that article's conclusions pretty disingenuous. Then again the author did work for Google on VP9 so am not totally surprised.

Yes H.265 encoding speed is 10-20x slower (at the highest quality setting) but the decoding speed was only 20% slower than H.264. And it is still quite faster than 60fps below which almost all movie content exists.

If all that mattered in a codec was encoding speed VP9 would be dominant. But it isn't. It's largely irrelevant compared to decoding speed (majority of codec users) and device support. The latter which H.265 is in an unassailable position.

spb on Jan 12, 2016 | parent | next [–] Encoding speed is very relevant for real-time feeds like WebRTC and Twitch.

HappyTypist on Jan 12, 2016 | root | parent | next [–] Good point, actually. VP9 appears to be superior for consumer real time feeds (ie not 1 million streamers backed by datacenters)

_sqkn on Jan 12, 2016 | prev | next [–] ffvp9 is indeed awesome. There was a talk at VideoLan Dev Days about the development. They outperform the reference decoder and optimized basically everything they could touch.

dogma1138 on Jan 13, 2016 | prev [–] For decoding CPU usage comparison is pretty pointless since every relevant device will have hardware decoding.

And encoding speed really only matters as far as real time services go like streaming services.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact Search:

Từ khóa » H264 Vs H 265 Vs Vp9