
H.265 Is Approved - FreeKill
http://techcrunch.com/2013/01/25/h265-is-approved/
======
jbk
> The new video format is the successor to the H.264 codec, which nearly every
> video publisher has standardized after the release of the iPad and several
> other connected devices.

No. H.264 was already used by HD-DVD, Blu-Ray, DVB (since 2004) and AVCHD.

> It seems crazy now, but once upon a time, Apple’s adoption of H.264 and
> insistence on HTML5-based video players was controversial — especially since
> most video before the iPad was encoded in VP6 to play through Adobe’s
> proprietary Flash player.

No. Most professional videos were using MPEG-2 and pirated movies were using
Mpeg-4 part 2 (DivX, Xvid).

Seriously, Apple can do great things, but this TC sensationalism is boring and
inaccurate.

Besides that, it is great to finally have H.265 ready. We'll see the fight
with VP9 and Daala very soon.

~~~
wmf
I think when TechCruch says publisher they mean Web site. If you really think
about it, the Web is the entire universe.

~~~
nolok
> If you really think about it, the Web is the entire universe

_their_ entire universe

------
ghc
H.265 sounds great...but the article doesn't mention the most important point:
Is it patent-encumbered? Last time around patents proved a major barrier to
adoption in free browsers, so why should this time be any different? A quick
wiki check seems to indicate that MPEGLA has patents on H.265, so a
GPL3-compliant decoder is probably a no-go, but we don't yet know whether
they'll take a more enlightened approach to licensing this time around so that
adoption will be cleaner than it was with H.264.

~~~
josephlord
I doubt that MPEG-LA has any patents on H.265 (they don't have any on H.264).
They offer a bulk licensing deal for many different patent owners which is
much better than licensing from each individually.

You are right that it is highly doubtful that it would be GPLv3 compatible
until the patents have expired. In practice I expect it will be included in
FFMPEG and available to open source users even if impure and unavailable to
strict Free software purists.

I'm not sure what isn't clean about the H.264 license except for
Motorola/Google's legal action that attempts to make the FRAND commitment
nearly meaningless. It would be much better for everyone else if they were
part of the MPEG-LA offer.

~~~
ksherlock
Google signed the MPEG-LA license agreement which would put Motorola's patents
into the MPEG-LA pool as well. Arguments are Monday, so one way or another, it
will be clarified sooner or later.

~~~
josephlord
Even if they lose that part they won't be signed up to H.265 licence unless
they choose to so the FRAND status matters too so can potentially charge
excessively. Also if the weak FRAND interpretations stand many other patent
holders may stay outside the collective license to get as much as they can.

------
nextparadigms
I'm confident VP9 has a much better chance of succeeding this time around.
h264 was already widely supported _before_ Apple decided to promote it against
Flash. That's not the case with h.265 right now. It will have to start from
scratch, which gives VP9 a much larger window of opportunity.

This is from November, where they posted they are about 7% behind h.265/HVEC:

[https://www.ietf.org/proceedings/85/slides/slides-85-videoco...](https://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf)

I've also seen in another document I can't find right now them saying that
work on h.265 started in 2005, while work on VP9 started in 2011...and they
are already pretty close to matching it, and they are gaining 10% on it every
quarter. If that's true it should be at least as efficient or more within a
quarter or two, than h.265.

Then it will be just a question of adoption. Software adoption should be much
easier. Many have already implemented VP8 (which is also slightly better than
h.264 at this point - [1]), and I'm sure Google will use VP9 for HD Hangouts,
and for Youtube. This time I hope they go through with their promise and make
it the default codec for Youtube, with fallback to Flash for browsers not
supporting it (only about 20% of the users are not supporting VP8 right now,
for reference [2]).

That should encourage adoption by other video sites, and also chip makers. And
that's I think the biggest hurdle - getting chip makers to support VP9. But
now with Android's popularity and virtually every chip maker supporting
Android, I think it will be much easier than it was to get support for VP8.

The nice part about VP9 is that it will also come integrated with the Opus
codec inside WebM, and that should be a big factor in the adoption of WebM,
too.

[1] [http://pacoup.com/2012/12/20/vp8-webm-
vs-h-264-mp4-december-...](http://pacoup.com/2012/12/20/vp8-webm-
vs-h-264-mp4-december-2012/)

[2] [http://downloads.webmproject.org/ngov2012/pdf/03-ngov-
vp8-up...](http://downloads.webmproject.org/ngov2012/pdf/03-ngov-
vp8-update.pdf)

~~~
doublec
Integrating Opus and/or VP9 into WebM removes one of the selling points they
used to promote the format. WebM wasn't supposed to be a generic container
format holding different codecs. It was specifically tied to Vorbis/VP8 to
ensure everyone advertising WebM support would be able to play the files.

If they decide to add these additional codecs then there will be some players
that can play some WebM files but not others. If that was the direction they
wanted to head then they could have just stuck with Matroska for the container
format.

~~~
fosap
webm is a defined subset of mkv. And it stays that way. Only a small, finite
number of codecs have to be implemented (so far vp8, vp9, vorbis, opus).

~~~
doublec
The defined subset included the particular codecs that would only be
supported. Implementers who got on the WebM train agreed to VP8 and Vorbis.
They may not be keen to do VP9 or Opus. There's no "have to be implemented"
for these two formats. This means there will be fragmentation which WebM was
supposed to avoid.

------
modeless
VP9 is also under development. VP9 decoding support was recently added to
Chromium.
[http://src.chromium.org/viewvc/chrome?view=rev&revision=...](http://src.chromium.org/viewvc/chrome?view=rev&revision=172738)
<http://en.wikipedia.org/wiki/VP9>

~~~
kristofferR
Unless VP9 decoding is implemented in hardware chips like H.264 is and H.265
is going to be, it'll likely fail.

It sucks, but I'd much rather have a "non-free" codec that plays smoothly on
all my devices than a "free" codec with lag issues on everything but my
computer.

Try playing 1080P H264 videos on your tablet/phone without using the H264
hardware decoder and you'll know what I mean.

Decoding H265 and VP9 will likely be even more resource intensive than
decoding H264 already is

And really, does the closedness of H264/H265 really matter at all for the end
users? x264 seems pretty free to me, what is the difference in reality?

~~~
modeless
Hardware support for VP8 exists, though it's not widespread as of yet. Tegra 3
has it. <http://www.nvidia.com/object/tegra-3-processor.html>

As with most software, the closedness of H.26X matters a lot more to
developers than users.

~~~
wmf
I think the last developer who cared was Firefox and even they gave up.

~~~
gillianseed
Firefox has native vp8/webm support. I know as I use it when I visit Youtube
pretty much everyday and watch webm (vp8) videos. I don't have flash
installed.

~~~
homosaur
Does YT default to this if you go there with a newer Firefox?

~~~
sp332
No, but you can opt-in at <https://youtube.com/html5>

------
ComputerGuru
I'm just waiting for DarkShikari [1] to post in this thread :)

Reading his codec-related comments on HN is always such a wonderful and
humbling learning experience. I look forward to his take on the h265 spec and
the changes (both advantages and disadvantages, as there are bound to be both)
over h264.

1: <http://news.ycombinator.com/user?id=DarkShikari>

~~~
wmf
And many of us are wondering if he's working on x265.

------
ksec
Few Points.

1\. To the Post above on VP8 better then x264. Comparing a single frame,
single video, single....? isn't very detail. VP8 has improved A LOT!. That is
true. But as far as i am concern and many other video encoder it is also true
that it hasn't match x264 yet.

2\. VP9 is great! It has matched and in many case even exceed x264 quality.
Although there would still be areas where x264 perform better simply because
it is much more mature.

3\. So given more time VP9 will very likely beat x264 quality. It is only with
10% range of HEVC / h.265 JM, under benchmarks. So it will very likely beat
that too.

4\. Do bare in mind JM is reference encoder. So it does not in anyway show the
full potential of h.265 as a codec. While VP9 is itself the standard and the
best encoder available. If you look at the difference between h.264 JM and
x264. I will argue it is very likely x265 ( If DS decide to do it ) will still
be better then VP9.

5\. Daala... as much as i love Mozilla, knowing their pace of work and Daala's
current condition, expect it to compete with h.266 or VP10.

6\. Patents are not evil. Patents Trolls are.

------
rcthompson
So how much better can video formats theoretically get? Are we anywhere near
the absolute limit of compression, or are current solutions limited by what
can be accomplished in real time on today's hardware?

~~~
lmm
We're a long, long, way from the theoretical limit - you can tell by comparing
the size of programmatically generated videos (e.g. 3D renderings, or
videogame videos) with their source material. A "perfect" video codec would
mean they were the same size, but at the moment a 256kb SNES rom and a few
hundred bytes of buttonpresses will generate you a video that's easily in the
10s of megabytes (granted video codecs aren't optimized with snes gameplay
videos as their primary target).

~~~
snowwrestler
These are two totally different things. Video codecs do not try to "discover"
the equations that created the scene. They take the recorded data of the scene
and then try to represent it "well enough" in a smaller number of bits.

By analogy: knowing the equation for conservation of momentum does not help
you find the smallest way to record the results of 1 million experimental
collisions.

~~~
lmm
>These are two totally different things. Video codecs do not try to "discover"
the equations that created the scene. They take the recorded data of the scene
and then try to represent it "well enough" in a smaller number of bits.

Think of it in information-theory terms (e.g. Kolmogorov complexity). If the
scene was created from no more than n bits of data, then it is possible to
represent it in n bits, and a "theoretically perfect" video codec would do so.

Video codecs really do try and "discover" the simplest representation of a
scene (e.g. motion vectors are exactly that), and the things they can
"understand" are getting more and more complex as video codecs advance (e.g.
film grain).

~~~
snowwrestler
Let's say you take an algorithm for generating the digits of pi, and run it on
2 computers. One you let run only a short time and it produces a string
100,000 digits long. The other you let run for a longer time and it produces a
string one million digits long.

Would you argue that these two strings should compress to the same size
because the source code that generated each of them is the same size?

edit: to clarify my question

~~~
lmm
Yes, very much so. You'll find that most compression algorithms will do this
for a string of zeroes (i.e. 100,000 zeroes will compress to approximately the
same size as 1,000,000 zeroes) or 1s, or simple repeating patterns. I don't
know whether any common compression algorithm is "smart" enough to be able to
compress the digits of pi, but a "perfect" compression algorithm certainly
would be.

------
benwerd
h.265 is exciting. It takes into account the vastly improved processing power
of today's devices to create smaller files - I'm looking forward to
integrating it with our service, which in turn will put h.265 in easy reach of
broadcasters. Really great step forward for the industry, although, of course,
I wish it was an open standard.

~~~
pkulak
1080p H.264 can just now be played back on modern processors without hardware
acceleration. I shutter to think about playing back 2160p H.265 before anyone
builds hardware support. I'm sure you don't get "twice as efficient" without
making it about twice as difficult to decode. Or maybe 4 times...

------
nextstep
So when can we expect this to be supported in VLC?

~~~
jbk
As soon as there is a GPLv2 compatible decoder available?

See <https://github.com/smarter/libav/commits/hevc>

------
Hello71
And... patents.

~~~
alexkcd
No different than h264 in that regard. I'd rather we discuss the technical
merits of this technology than have another patent debate. Not that I wouldn't
agree, just that if you want to talk patent reform, it might be better suited
to do so in a dedicated HN posting.

As far as encoding technology goes, this is pretty exciting. Looking forward
to the first wave of 4K TVs & cell phone cameras hitting the market.

(Disclaimer: I'm the cofounder of a startup specializing in high quality
cellphone videos)

~~~
jfb
High quality cellphone videos? Tell us more.

~~~
alexkcd
We remove handshake by computing optimally smooth camera paths. Some example
videos shot on a handheld iPhone using our app: <http://luma.io/v/Brl>
<http://luma.io/v/BtN> <http://luma.io/v/Brm>

More info here: <http://luma.io>

~~~
jfb
I'd love to chat with you about luma. My cofounder and I worked on something
substantially similar before YC. Ping me at the email in my profile?

~~~
alexkcd
Doesn't list your email in your profile. Ping me at alex (at) luma.io

------
Keyframe
Path us now open for 4k streaming! Well, that and we need affordable 4k
displays.

------
venomsnake
It will be interesting when the scene groups will adopt H.265 or at all. I
have always found fascinating how piracy and porn can be trendsetters in
technology standards.

~~~
seanalltogether
Scene groups are actually very conservative with codecs. They jumped onto mkv
format because they didn't have an alternative for hi def rips, but it took
them a long time to get off the avi format until enough devices supported h264
mp4 containers.

