AV1: A new general-purpose video codec(people.xiph.org)
people.xiph.org
AV1: A new general-purpose video codec
https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml
251 コメント
Yes, Google is developing a free AV1 HW decoder, as discussed near the end of this (interesting!) deck: https://parisvideotech.com/wp-content/uploads/2017/07/AOM-AV...
For what it's worth, Intel shipped "hybrid" implementations of HEVC and VP9 for older products where the CPU does some work but the GPU's shader cores do shader-y bits (https://www.anandtech.com/show/10610/intel-announces-7th-gen...). I don't know how far that approach gets you, especially in mobile settings where you really care about power use. But you might see that before complete hardware decoders everywhere.
A use case that might be interesting before full hardware acceleration is to provide an improved still image format. The graph in the post is a great demonstration that improving video encoding and improving image encoding are closely related these days. AV1 has backing and went through IP review that may help it avoid being mired in a patent mess like previous proposals to replace JPEG. (Apple is using .heic, based on HEVC intra coding. Android'll support .heic in the next major version, but the HEVC patent situation will likely constrain how many external tools, platforms, etc. pick it up.) There's work on defining an AVIF format (https://github.com/AOMediaCodec/av1-avif) and tech demos look great (https://people.xiph.org/~tdaede/av1stilldemo/). So, maybe fewer ugly JPEG artifacts in our future, partly thanks to that deringing filter mentioned at the end of Monty's post.
(I said more or less the stuff about stills above, with a couple more details and links, at https://news.ycombinator.com/item?id=16699000)
For what it's worth, Intel shipped "hybrid" implementations of HEVC and VP9 for older products where the CPU does some work but the GPU's shader cores do shader-y bits (https://www.anandtech.com/show/10610/intel-announces-7th-gen...). I don't know how far that approach gets you, especially in mobile settings where you really care about power use. But you might see that before complete hardware decoders everywhere.
A use case that might be interesting before full hardware acceleration is to provide an improved still image format. The graph in the post is a great demonstration that improving video encoding and improving image encoding are closely related these days. AV1 has backing and went through IP review that may help it avoid being mired in a patent mess like previous proposals to replace JPEG. (Apple is using .heic, based on HEVC intra coding. Android'll support .heic in the next major version, but the HEVC patent situation will likely constrain how many external tools, platforms, etc. pick it up.) There's work on defining an AVIF format (https://github.com/AOMediaCodec/av1-avif) and tech demos look great (https://people.xiph.org/~tdaede/av1stilldemo/). So, maybe fewer ugly JPEG artifacts in our future, partly thanks to that deringing filter mentioned at the end of Monty's post.
(I said more or less the stuff about stills above, with a couple more details and links, at https://news.ycombinator.com/item?id=16699000)
There is some interesting Q&A at the end of Pascal's talk. My schoolboy French is not fast enough to do a proper translation unfortunately. He was asked about parallel (software) decoding and I think the gist was he thought it would be a bit difficult because of the dependencies between region images.
https://parisvideotech.com/pvt-4-les-formats-et-codecs-du-fu...
https://parisvideotech.com/pvt-4-les-formats-et-codecs-du-fu...
It shouldn't surprise anyone to learn that a brand new just released video codec does not yet have hardware decode support.
Came here to comment this. Seriously, HN, relax. This is like the introductory blogpost, how is there supposed to be a meatspace hardware implementation yet?
> if a mobile device can't hardware-decode it (which saves precious power!), that's going to be a significant blocker.
A mobile device needs to be able to hardware-encode it as well - countless hours of 4k/60 video are taken on phones.
A mobile device needs to be able to hardware-encode it as well - countless hours of 4k/60 video are taken on phones.
I'm not sure that you need mobile hardware encoding to drive initial adoption. As long as streaming services and the like can start using it to save bandwidth, you have a clear win for a big segment of the market. Older codecs can serve just fine for mobile encoding until the hardware catches up. But if most existing phones can't decode it efficiently, it's going to be pretty stuck until that situation changes.
I'd argue that it's more important to get encoders working, since re-encoding lossy->lossy is always a bad idea.
There isn’t really a video hosting site that doesnt do a lossy transcode of all uploads, unless you count Dropbox.
The bitrate used to encode real-time captures is generally two or more times greater than the bitrate you want to distribute.
The bitrate used to encode real-time captures is generally two or more times greater than the bitrate you want to distribute.
Lossless 4K is 12 gigabit a second (even then there's chroma compression)
Nobody edits at that bitrate, compression is concattenated multiple times. How a codec copes with real world multi-compression is key.
Nobody edits at that bitrate, compression is concattenated multiple times. How a codec copes with real world multi-compression is key.
4K is common in TV production. In my experience lossy compression is a big no-no in TV and they do edit 4K losslessly, although in order to transfer it they generally split it as 4 times 3G links (either interleaving the pixels or generating a 2x2 mosaic). 12G links exist but 4x3G is still vastly more popular due to being backward compatible with existing equipment. Color correction, scaling, blending and compositing are all generally done with uncompressed video.
Of course once mastered the video gets heavily compressed to be sent to the consumers.
Of course once mastered the video gets heavily compressed to be sent to the consumers.
Ok I shouldn't use the word nobody, I admonished someone for using that word a few days ago, but it's very rare, especially outside high end production houses.
Even 12G sdi is compressed - we consider 4:2:2 and 10bit uncompressed, but 4:4:4 is less compressed than 4:2:2. Once you go into interlace or stupid things like 24p you're throwing away tons of data.
2022-6 seems to be the transmission method of choice so far, 2110 may well take over, but there are significant compatibility issues.
Personally I'd prefer everything originated as 4:4:4 10 bit 150fps (no drop frames), resolution I'm less concerned with.
I work in news though, broadcast quality is what we broadcast. 5mbit h264 PPP with a vbv of 200k is fine for a talking head internationally. 5 times that is plenty for an actual broadcast program with astons and stuff.
Even 12G sdi is compressed - we consider 4:2:2 and 10bit uncompressed, but 4:4:4 is less compressed than 4:2:2. Once you go into interlace or stupid things like 24p you're throwing away tons of data.
2022-6 seems to be the transmission method of choice so far, 2110 may well take over, but there are significant compatibility issues.
Personally I'd prefer everything originated as 4:4:4 10 bit 150fps (no drop frames), resolution I'm less concerned with.
I work in news though, broadcast quality is what we broadcast. 5mbit h264 PPP with a vbv of 200k is fine for a talking head internationally. 5 times that is plenty for an actual broadcast program with astons and stuff.
> Nobody edits at that bitrate
Interesting. Not even as a final rendering step after everything has been done in a compressed "preview mode"?
Interesting. Not even as a final rendering step after everything has been done in a compressed "preview mode"?
Setting aside high end production houses. Even then things aiming for TV get compressed to a mezzanine format that's heavily compressed (in comparison), then compressed again for TX
And yet, you'll be astonished to learn how many times each video is lossy-lossy re-encoded on its way from camera to end viewer.
[deleted]
Hardware acceleration for encoding is also pretty important. Entry-level game streamers need it (Twitch recently proved that this isn't a negligible market[1]). Playing back AV1 on a phone implies receiving it - which means that users need to store their videos to AV1 directly.
[1]: https://www.forbes.com/sites/insertcoin/2018/04/07/ninjas-ne...
[1]: https://www.forbes.com/sites/insertcoin/2018/04/07/ninjas-ne...
Adoption is forced by pirated stuff. If scene groups start to use it, people will want to play it. And those groups don't care if you can play whole movies on your phone. Because thats not what a phone is mainly for.
The scene cares a lot about codec support.
You can tell that they do if you read the scene standards.
They care much much more about this than most people do. Even a lot of people that work with video professionally don’t care as much about codecs and codec support as these guys do.
https://en.wikipedia.org/wiki/Standard_(warez)#Video_standar...
So no, I don’t believe that “real” scene groups would start using a new codec unless it was widely supported. The scene standards, then, would not include such codecs. Failure to follow scene standards will have your releases nuked in the scene.
As for the torrent sites, if someone puts up videos using codecs that cause the videos to stutter or plain fail to play then the torrent users will learn to associate whoever encoded those videos with videos that don’t work and they will avoid torrents with that person or group name in them.
You can tell that they do if you read the scene standards.
They care much much more about this than most people do. Even a lot of people that work with video professionally don’t care as much about codecs and codec support as these guys do.
https://en.wikipedia.org/wiki/Standard_(warez)#Video_standar...
So no, I don’t believe that “real” scene groups would start using a new codec unless it was widely supported. The scene standards, then, would not include such codecs. Failure to follow scene standards will have your releases nuked in the scene.
As for the torrent sites, if someone puts up videos using codecs that cause the videos to stutter or plain fail to play then the torrent users will learn to associate whoever encoded those videos with videos that don’t work and they will avoid torrents with that person or group name in them.
I remember when MP4 was the standard yet the scene used AVI and MKV. I get the impression that they care more about their own idiosyncratic notions of technical superiority than compatibility (hey, kinda like HN).
Note that avi, mkv and mp4 are all container formats.
avi and mkv can contain nearly any audio and video streams regardless of codec. mp4 can contain only a specific set of audio and video streams determined by a limited set of codecs.
You can trivially copy the audio and video streams directly over into an mp4 container provided that the codecs used are supported by mp4. As long as the codecs were supported also by the device you were looking to watch it on then you’d be able to watch it. So the codecs are the most important bit.
If I remember correctly, aac + h264 was commonly used for audio and video respectively, both of which are supported by mp4.
Of course it would still be an annoying extra step for someone who needed the file to be mp4, but at least being able to simply copy the streams is fast and cheap compared to streams that need to be transcoded. Transcoding could take painfully much time and could also easily further degrade the quality of the streams.
An important thing to note about mp4 is that in some configurations, metadata that is needed for playback is placed at the end of the file. This means you can’t playback this sort of file directly until you had downloaded the whole file completely. Often there would be a separate sample file that you could download to have a look at the quality anyway but still, it is one reason that you might want to go with avi or mkv instead as I don’t think those containers suffer from that problem at all. So if you download mkv and preview it early in let’s say VLC and you know from the nfo that they are using mp4-compatible codecs then you can both always have preview to ensure quality is good (or even that it is at all the movie you are looking for), and then after you’ve downloaded it you can copy the streams over in an mp4 container quickly and then consume the movie on your mp4 media device.
avi and mkv can contain nearly any audio and video streams regardless of codec. mp4 can contain only a specific set of audio and video streams determined by a limited set of codecs.
You can trivially copy the audio and video streams directly over into an mp4 container provided that the codecs used are supported by mp4. As long as the codecs were supported also by the device you were looking to watch it on then you’d be able to watch it. So the codecs are the most important bit.
If I remember correctly, aac + h264 was commonly used for audio and video respectively, both of which are supported by mp4.
Of course it would still be an annoying extra step for someone who needed the file to be mp4, but at least being able to simply copy the streams is fast and cheap compared to streams that need to be transcoded. Transcoding could take painfully much time and could also easily further degrade the quality of the streams.
An important thing to note about mp4 is that in some configurations, metadata that is needed for playback is placed at the end of the file. This means you can’t playback this sort of file directly until you had downloaded the whole file completely. Often there would be a separate sample file that you could download to have a look at the quality anyway but still, it is one reason that you might want to go with avi or mkv instead as I don’t think those containers suffer from that problem at all. So if you download mkv and preview it early in let’s say VLC and you know from the nfo that they are using mp4-compatible codecs then you can both always have preview to ensure quality is good (or even that it is at all the movie you are looking for), and then after you’ve downloaded it you can copy the streams over in an mp4 container quickly and then consume the movie on your mp4 media device.
Nitpick: AVI doesn’t support B frames without ugly hacks. This was one of the main motivations to switch to mkv.
AC3 mostly.
Yes, sorry. Fortunately ac3 is supported by mp4 as well.
not "officially". anyway mkv is by far the superior container.
AVI was used for years, way before MP4 existed, and MP4 did not offer any relevant advantages so groups kept using AVI.
MKV has builtin multiple-language-tracks, chapter and subtitle support (MP4 support is non-standard and incompatible), so if a release needed that MKV was used instead of AVI.
MKV has builtin multiple-language-tracks, chapter and subtitle support (MP4 support is non-standard and incompatible), so if a release needed that MKV was used instead of AVI.
MKV has more features than MP4.
Whenever I remux MKV->MP4, I lose chapters.
Technical superiority is more important than compatibility, especially when you have MPC-HC and VLC that are happy to play practically any format ever.
Whenever I remux MKV->MP4, I lose chapters.
Technical superiority is more important than compatibility, especially when you have MPC-HC and VLC that are happy to play practically any format ever.
MP4 also supports chapters; it's probably the muxer you're using that does not implement the feature.
But yes, MKV supports virtually any codec, so that is a big plus. It comes at the expense of support on different platforms.
But yes, MKV supports virtually any codec, so that is a big plus. It comes at the expense of support on different platforms.
Basically only pirates used MKV, yet it's now gaining wider support; the beta version of Windows supports it natively.
WebM is based on MKV, and it's been in browsers since 2010.
I've used MKV for lots of things, such as video production work, remuxing digital TV stream grabs so normal programs can play them, etc. It's the most reliable container format, from my point of view.
I've used MKV for lots of things, such as video production work, remuxing digital TV stream grabs so normal programs can play them, etc. It's the most reliable container format, from my point of view.
yes, but there are codec restrictions for audio and video.
My whole media library of ripped DVDs and Blurays (that I legally own) is in MKV format. You get video, chapter marks, multiple audio streams, and subtitles all in one file. Plus almost every modern device plays them. I love it as a container format.
My MKVs typically have H264 video + AC3/DTS audio.
My MKVs typically have H264 video + AC3/DTS audio.
That's not really true.
The data from YouTube or Netflix dwarfs what you'd get from a torrent distributor of a show or whatever.
Some pirate/niche markets may adopt a codec solely for some arbitrary reason, but those reasons (say, maximum compression, good open source tools) are normally orthogonal to what a streaming business usually needs (compression, but also hardware/software compatibility for all sorts of form factors, and commercial unencumberment).
The data from YouTube or Netflix dwarfs what you'd get from a torrent distributor of a show or whatever.
Some pirate/niche markets may adopt a codec solely for some arbitrary reason, but those reasons (say, maximum compression, good open source tools) are normally orthogonal to what a streaming business usually needs (compression, but also hardware/software compatibility for all sorts of form factors, and commercial unencumberment).
I bet you’re right. AFAIK pretty much all but the cheapest TVs sold now (or at least 4K TVs) support HEVC specifically to support builtin apps for Netflix and similar. Unfortunately YouTube uses the competing VP9, which my 2 year old Vizio 4K TV does not support, but apparently devices like the Chromecast Ultra and 4K Apple TV support it as well.
Movie and music piracy has taken a prodigal nosedive to the point that I don't think this would be true at all anyway. In addition streaming video and short form content dwarfs film and TV consumption, making high mobile efficiency paramount.
I am always blown away when reading about codecs. Video compression seems to be the perfect intersection of math, programming, and psychology.
And money. This is what happens when a lot of money is thrown at a problem.
For the record. Yes, a lot of money was spent developing this codec. However, a lot of creativity and risk-taking was involved as well.
It was far from clear 15 years ago when xiph released Theora (aka vp3, ancestor of av1) that going up against mighty MPEG, with their enormous war chest from a decade of royalties, and dozens of patents (and the money to defend them) that success in the end was even possible much less assured.
It's really a wonderful story of the triumph of open source philosophy over the IP licensing model.
It was far from clear 15 years ago when xiph released Theora (aka vp3, ancestor of av1) that going up against mighty MPEG, with their enormous war chest from a decade of royalties, and dozens of patents (and the money to defend them) that success in the end was even possible much less assured.
It's really a wonderful story of the triumph of open source philosophy over the IP licensing model.
While none of this is false, it's a bit of a misdirection to imply that the 'mighty MPEG' was a monolithic actor preventing this course of action from taking place. In fact, the individual collaborators that MPEG (or ITU) brought to the table were the same sorts of hardware companies, software companies, universities, research institutes, and media companies that are surprisingly familiar among AV1's contributors, and MPEG's licensing scheme -- the patent pool being its primary innovation -- was a way to seek mutually assured use of each other's work.
The story here isn't that the Big Evil companies behind the MPEG codecs were beaten by the Good companies behind the Alliance for Open Media -- the story is that the pool of companies is kinda-sorta the same or comparable, with plenty of them playing both sides, a fact not lost on the founder of MPEG [1][2].
[1] http://blog.chiariglione.org/2018/01/28/ [2] https://news.ycombinator.com/item?id=16261313
The story here isn't that the Big Evil companies behind the MPEG codecs were beaten by the Good companies behind the Alliance for Open Media -- the story is that the pool of companies is kinda-sorta the same or comparable, with plenty of them playing both sides, a fact not lost on the founder of MPEG [1][2].
[1] http://blog.chiariglione.org/2018/01/28/ [2] https://news.ycombinator.com/item?id=16261313
MPEG is, for purposes of this discussion, a system that member companies have learned how to game. It is so thoroughly gamed that it has become dysfunctional and an impediment to progress. The open/RF development strategy is now consistently beating it despite MPEG having a consistent royalty revenue stream and a massive patent war chest. At this point, MPEG, as a self-interested system, is only trying to slow things down and keep control.
No, it's not monolithic inside, but the worst actors have solid control and it warps the behavior of the entire organization.
We saw that coming a long, long time ago and yet barely in time.
No, it's not monolithic inside, but the worst actors have solid control and it warps the behavior of the entire organization.
We saw that coming a long, long time ago and yet barely in time.
> it's a bit of a misdirection to imply that the 'mighty MPEG' was a monolithic actor preventing this course of action from taking place. In fact, the individual collaborators
True but if we are comparing models for getting stuff invented collaboratively (open source vs. licensed IP) then this hardly misdirection. Indeed the fact that the same sort of actors found it possible/useful/necessary to go down the open route makes TD-Linux's point all the more interesting.
This is important because when policymakers talk among themselves they often just assume that IP and such are necessary for fostering innovation.
True but if we are comparing models for getting stuff invented collaboratively (open source vs. licensed IP) then this hardly misdirection. Indeed the fact that the same sort of actors found it possible/useful/necessary to go down the open route makes TD-Linux's point all the more interesting.
This is important because when policymakers talk among themselves they often just assume that IP and such are necessary for fostering innovation.
> This is important because when policymakers talk among themselves they often just assume that IP and such are necessary for fostering innovation
Would AV1 have been possible in 1993 when MPEG-1 came out? How would you have bankrolled the standard at the time?
Would AV1 have been possible in 1993 when MPEG-1 came out? How would you have bankrolled the standard at the time?
> Would AV1 have been possible in 1993 when MPEG-1 came out?
No. There weren't enough transistors in the world. I'm not being silly. Something like Av1 happens now because Moore/Dennard allow it to.
No. There weren't enough transistors in the world. I'm not being silly. Something like Av1 happens now because Moore/Dennard allow it to.
It seemed to me like they meant the question politically, not technically, as in, would AOMedia have been possible?
I think it's widely understood that the technical innovations in sixth-generation codecs like AV1 were simply not computationally feasible on circa ~1993 devices, so I highly doubt that's what was meant. Therefore I'm not sure how transistor density relates to funding models for DSP innovation.
I think it's widely understood that the technical innovations in sixth-generation codecs like AV1 were simply not computationally feasible on circa ~1993 devices, so I highly doubt that's what was meant. Therefore I'm not sure how transistor density relates to funding models for DSP innovation.
The answers aren't entirely separable. Hardware capable of any kind of video wasn't accessible to the larger community and it sure as hell wasn't affordable.
When Xiph.Org started (1994), even audio required high-end hardware. Yes, sound cards were available for PCs, but big enough hard disks were not.
When only the elites have access, the standards are made by elites.
When Xiph.Org started (1994), even audio required high-end hardware. Yes, sound cards were available for PCs, but big enough hard disks were not.
When only the elites have access, the standards are made by elites.
Getting something like AOM would have been easy back in 1993 because the costs would have been much lower. Back then complexity had to be really low, which means most of the complicated modern tools were off the table. Coming up with something equivalent to MPEG-1 would have required just a handful of engineers over maybe a year. In terms of IPR, there would also have been much less to check than today. OTOH, the minefield was moving really fast at the time, which could have added some complications. In the end, I think the main reason nobody bothered with something AOM-like is that few people realized the huge problem of patents on standards.
~1993 is around when CompuServe and Unisys began negotiating about the implications of patented LZW in GIF files, but the issue didn't become public until 1994, but the community rebounded spectacularly by developing PNG in 1995.
So perhaps the cutoff year of 1993 is right before the threat of non-pooled patents was well-publicized.
There was a lot of video codec innovation back then too, but everything aside from the MPEG or ITU-T codecs was proprietary, and everyone took out patents. To Monty's point, the sheer number of endpoints capable of consuming digital video whose consumption somehow results in income for the publishers was just not quite there, making an alternate push for deriving revenue from DSP IP than patent licensing fees much less likely.
So perhaps the cutoff year of 1993 is right before the threat of non-pooled patents was well-publicized.
There was a lot of video codec innovation back then too, but everything aside from the MPEG or ITU-T codecs was proprietary, and everyone took out patents. To Monty's point, the sheer number of endpoints capable of consuming digital video whose consumption somehow results in income for the publishers was just not quite there, making an alternate push for deriving revenue from DSP IP than patent licensing fees much less likely.
Money is necessary. IP rights are a general and flexible tool to funnel money into research.
AV1 is basically funded by Google as a quasi-charitable endeavor, as far as I can tell. Whilst there may be several apparent funders like Mozilla, they in turn trace their funding to Google.
"Research funding by Google" is never going to be a tactic that policymakers take seriously, and rightly so, even if it happens to be doing a lot of good work in this particular time period.
AV1 is basically funded by Google as a quasi-charitable endeavor, as far as I can tell. Whilst there may be several apparent funders like Mozilla, they in turn trace their funding to Google.
"Research funding by Google" is never going to be a tactic that policymakers take seriously, and rightly so, even if it happens to be doing a lot of good work in this particular time period.
>AV1 is basically funded by Google as a quasi-charitable endeavor
Nothing charitable about it. They want to make money. So do a bunch of other companies. And they've realized the way to win that game is to relinquish control over the fundamental/infrastructural pieces.
That also has some beneficial aspects beyond 'a rising tide lifts all boats', but I feel more comfortable appealing to reliable motivations. The benefits to others aren't an accident, and they're important to e.g. us at Xiph, but let's not ascribe industry interest to anything more charitable than 'enlightened self-interest'.
Nothing charitable about it. They want to make money. So do a bunch of other companies. And they've realized the way to win that game is to relinquish control over the fundamental/infrastructural pieces.
That also has some beneficial aspects beyond 'a rising tide lifts all boats', but I feel more comfortable appealing to reliable motivations. The benefits to others aren't an accident, and they're important to e.g. us at Xiph, but let's not ascribe industry interest to anything more charitable than 'enlightened self-interest'.
> It's really a wonderful story of the triumph of open source philosophy over the IP licensing model
It’s not an “open source philosophy over the IP licensing model.” It’s bankrolling a codec with content, device, and middleman revenues rather than content player revenues. The $_ dollars that Sony or Panasonic got for every DVD player through patent licensing has simply been replaced by the $_ that Google gets for every ad impression on YouTube or sale in the Google Play Store. It’s not a philosophical shift, merely a business model shift enabled by Internet video distribution.
It’s not an “open source philosophy over the IP licensing model.” It’s bankrolling a codec with content, device, and middleman revenues rather than content player revenues. The $_ dollars that Sony or Panasonic got for every DVD player through patent licensing has simply been replaced by the $_ that Google gets for every ad impression on YouTube or sale in the Google Play Store. It’s not a philosophical shift, merely a business model shift enabled by Internet video distribution.
But, there's an important distinction. In this case, Google did in fact support an open technology platform, so anyone can get their hands on it and distribute content, free of royalty and legal obligations.
They could have chosen to be much more focused on narrow self-interest, kept the technology proprietary, and played games with their competitors. I honestly believe they chose the high road because that's part of their culture.
They could have chosen to be much more focused on narrow self-interest, kept the technology proprietary, and played games with their competitors. I honestly believe they chose the high road because that's part of their culture.
You've got it backwards. AV1 is pushed by companies that profit from people who "distribute content." Apple and Google take a cut of sales on iTunes and Google Play, Google gets revenue from ads on Youtube, Netflix gets monthly fees, etc. The MPEG folks never tried to get money from people distributing content--the patents address, and the licenses are for, people who distribute encoders and decoders.
And I don’t agree with your point about the “high road.” Google releases lots of open R&D “for free” that’s bankrolled by its enormous advertising profits. I think you have to view their R&D efforts through that lens, because none of it would be possible without the monetization models enabled by the advertising business. Is Android, for example, a “high road” compared to Symbian, just because Android is free and open? Not in my view.
(Incidentally, it’s a lot like Xerox. Xerox PARC invented a ton of stuff that it didn’t patent and people freely used. But it was all bankrolled by their patents on copiers. When Xerox was forced to license those patents to Japanese companies, the money printing press disappeared and so did PARC.)
And I don’t agree with your point about the “high road.” Google releases lots of open R&D “for free” that’s bankrolled by its enormous advertising profits. I think you have to view their R&D efforts through that lens, because none of it would be possible without the monetization models enabled by the advertising business. Is Android, for example, a “high road” compared to Symbian, just because Android is free and open? Not in my view.
(Incidentally, it’s a lot like Xerox. Xerox PARC invented a ton of stuff that it didn’t patent and people freely used. But it was all bankrolled by their patents on copiers. When Xerox was forced to license those patents to Japanese companies, the money printing press disappeared and so did PARC.)
Your analysis accurate as far as it goes but you are kind of missing the point.
Granted, companies like Google and Xerox don't do things out of an altruistic desire to save the world. It's enlightened self-interest, and they do develop business models to make money.
The difference between their model and the more typical patent protection / royalty approach is that in the open case, anyone else can use the research to do whatever they want. Rather than being siloed within a single company, and protected through legal means, the research is free for anyone else to leverage. This results in best of class open solutions rising to the top, and avoids the problem of everyone reinventing the wheel in their own little wheelhouse.
I care less about how much money Google is making, & more about how much access I have to the research they are sponsoring.
Granted, companies like Google and Xerox don't do things out of an altruistic desire to save the world. It's enlightened self-interest, and they do develop business models to make money.
The difference between their model and the more typical patent protection / royalty approach is that in the open case, anyone else can use the research to do whatever they want. Rather than being siloed within a single company, and protected through legal means, the research is free for anyone else to leverage. This results in best of class open solutions rising to the top, and avoids the problem of everyone reinventing the wheel in their own little wheelhouse.
I care less about how much money Google is making, & more about how much access I have to the research they are sponsoring.
> It's really a wonderful story of the triumph of open source philosophy over the IP licensing model.
3-5 years will tell whether it's a triumph or a tragedy. It's certainly not possible to know today. Fans were quite sure Beta meant the end of VHS, but there are so many other (more important, in many cases) factors than the technology.
3-5 years will tell whether it's a triumph or a tragedy. It's certainly not possible to know today. Fans were quite sure Beta meant the end of VHS, but there are so many other (more important, in many cases) factors than the technology.
Betamax wasn't an open standard for digital formats, so that comparison is disingenuous.
The fact that AV1 is explicitly not patent-encumbered is a very important feature.
The fact that AV1 is explicitly not patent-encumbered is a very important feature.
That was a pretty nice write up about it. I don't know very much about video encoding, and usually when I've tried reading about it I very quickly am out of my depth, but this bit seemed pretty reader friendly to a not-even-close-to-an-expert like myself. How did it read for those who actually know about video encoding?
I'm no video codec expert either, but the author of this article, "Monty" Montgomery, has a real gift for technical explanation. '
Here's a video he created a few years ago, taking apart some popular misconceptions about how digital audio works: https://xiph.org/video/vid2.shtml
Here's a video he created a few years ago, taking apart some popular misconceptions about how digital audio works: https://xiph.org/video/vid2.shtml
Luc Trudeau, who wrote most of the deeper technical papers and specifications on CfL at Xiph, has a real gift too. I'm riding his technical prose in this post.
If you liked my update, you'll like his papers linked in 'Additional Resources'. They're some of the best and clearest technical documents I've ever read.
>> Monty" Montgomery, has a real gift for technical explanation.
He does. I love his posts. Some say you don't really understand something until you can explain it to someone else. By that metric he's probably in the top 5 codec folks in the world today.
He does. I love his posts. Some say you don't really understand something until you can explain it to someone else. By that metric he's probably in the top 5 codec folks in the world today.
Some take it further and go "I want to really know this newfangled X stuff, gonna teach a class on it."
What I appreciate most of all in that video is that he has carefully considered his words, not just to make a lay audience able to follow, but also so that what he says is _precisely_ correct.
I knew I recognized his name! That digital audio video (series?) was so fantastic and I loved the hardware setups that he used to make his points.
Site seems to be down. Google cache link: https://webcache.googleusercontent.com/search?q=cache:https:...
This made me realise how much I enjoyed and have missed the Daala blog updates :)
Any idea how many more articles are planned, so that can adjust my expectations a bit?
Any idea how many more articles are planned, so that can adjust my expectations a bit?
The next two will be on the Constrained Directional Enhancement Filter and the Daala Entropy Coder, which AV1 adopted as it EC system. Beyond that, there will be several more though I've not yet planned out a specific order.
Thanks, looking forward to them!
Can we somehow convince you to part-time more technical blogs and videos? Like others here said, you have a knack for writing really accessible technical articles without them feeling dumbed down.
I don't know if you're just more into doing the hands-on work of developing the codec (I can imagine that's exciting), or if it's a question of technically not being hired to do that.
In the latter case, maybe "The People" could vote with their wallet to convince the higher-ups otherwise?
Like, Ubuntu lets us decide what we want them to spend our donations on. If we had that with xiph.org and it had a section that said "more technical blogs!", or maybe even something like patreon a set-up where you can pledge to automated repeat donations for each blog entries, wouldn't be surprised if there were enough nerds willing to send donations specifically to justify to the managers that you may spend more time on outreach.
Can we somehow convince you to part-time more technical blogs and videos? Like others here said, you have a knack for writing really accessible technical articles without them feeling dumbed down.
I don't know if you're just more into doing the hands-on work of developing the codec (I can imagine that's exciting), or if it's a question of technically not being hired to do that.
In the latter case, maybe "The People" could vote with their wallet to convince the higher-ups otherwise?
Like, Ubuntu lets us decide what we want them to spend our donations on. If we had that with xiph.org and it had a section that said "more technical blogs!", or maybe even something like patreon a set-up where you can pledge to automated repeat donations for each blog entries, wouldn't be surprised if there were enough nerds willing to send donations specifically to justify to the managers that you may spend more time on outreach.
What does this mean for hardware accellerated decoding?
Intel implemented VP9/h265 decoding in its processors just recently.
Intel implemented VP9/h265 decoding in its processors just recently.
Considering Intel, AMD, ARM, Nvidia, Apple, and other hardware companies are all members of the Alliance for Open Media - which is the consortium behind AV1 - I'd expect that work to support it in hardware is already well underway.
https://aomedia.org
https://aomedia.org
Ah...
So we have to buy new processors.
So we have to buy new processors.
Well, if you want hardware-accelerated decoding, you need new hardware. That seems reasonable?
Software encoder/decoder implementations will also be a thing in the interim, until the hardware is ready.
Software encoder/decoder implementations will also be a thing in the interim, until the hardware is ready.
Are there no common computations among compression algorithms?
It doesn't really matter even if there are, in the case of hardware implementations -- because hardware decoders/encoders are typically fixed-function hardware blocks with fixed functionality. They are not designed for flexibility or reuse between formats. They are designed for exactly 1 function and nothing else.
Even if AV1 and VP9 share structurally similar components, no VP9 decoder is going to work out of the box. It may mean that people who produce AV1-capable encoding/decoding hardware have a better starting point, though (provided they had VP9 hardware, beforehand)
Even if AV1 and VP9 share structurally similar components, no VP9 decoder is going to work out of the box. It may mean that people who produce AV1-capable encoding/decoding hardware have a better starting point, though (provided they had VP9 hardware, beforehand)
Right but I guess I’m asking if they COULD be or if you’d need like a FPGA for that.
AFAIK a lot of "hardware" codecs are DSPs with some extra instructions that are good for video (like sum of absolute differences). In theory maybe they could support new algorithms with a firmware update. In reality, such firmware may simply not be developed or the DSP may not be fast enough to run a new codec.
Most DSPs I've worked with have an assortment of really specific extra instructions added for the particular application. I suspect these DSPs are similar - adding a new codec probably means adding a few more instructions, or even the odd hardware block dangling off the side.
Do you think the Mill family of processors could find a niche here? (if it ever sees the light of day, and I hope so because the technical videos are super-interesting (and educational))
[0] https://millcomputing.com/
[0] https://millcomputing.com/
People suggesting Mill as the solution to every problem without giving any reasons certainly doesn't give a good impression.
The Mill has been described as having more in common with a DSP than with a regular CPU. Apologies, I thought that was common knowledge.
There are. That's the reason we got instruction set extensions like simd.
If you don't want your macbook to burn a hole in your lap, potentially. I'm sure most recent processors will be able to do playback, just not optimized, and at high cpu load.
I wonder if AV1 could work with an OpenCL decoder since it does block prediction. Would almost certainly need too much per-frame sychronization to work though...
No different than HEVC or anything else. My CPUs are a few generations behind (i7-4790K and i5-4690K) and they can't hardware decode/encode HEVC.
Yet if you bought a Nvidia 960 about 1.5 years ago when I did (because it supported HEVC, and I upgraded my 10 year old plasma to a 4k TV), it can do it for you. My HTPC can happily play back high bitrate 4k HEVC content without as much as breaking into a sweat.
Sadly Netflix doesn't see it that way and demands that I update my perfectly functional i7-2500 system to a newer one to play back their 4k content.
(Sorry, slightly OT rant).
Sadly Netflix doesn't see it that way and demands that I update my perfectly functional i7-2500 system to a newer one to play back their 4k content.
(Sorry, slightly OT rant).
Unlikely, I would imagine that the vast majority of intrinsics used for VP9 decoding can be used for AV1 decoding as well.
FPGAs can't come soon enough.
The power of FPGA's is their flexibility, not their pure performance.
Dedicated, fixed silicon will outperform FPGA's in performance and energy use practically every time.
For rare/uncommon use cases, having an FPGA you can adapt to your algorithm is fantastic, but for a use case as common and day-to-day as decoding video, a dedicated chip is far more ideal.
Dedicated, fixed silicon will outperform FPGA's in performance and energy use practically every time.
For rare/uncommon use cases, having an FPGA you can adapt to your algorithm is fantastic, but for a use case as common and day-to-day as decoding video, a dedicated chip is far more ideal.
[deleted]
FPGAs will never be able to compete on size, cost, or performance/watt compared to optimized dedicated silicon. You're not going to find an FPGA capable of being programmed to encode video on a mobile device.
Aside: I did laugh the other day when I saw a video of the Amiga Vampire FPGA enabling an A600 to decode and play MP3 files.
http://www.apollo-accelerators.com
http://www.apollo-accelerators.com
On the performance/watt scale they sit between dedicated silicon and general cpus, right? If so, they could be useful as a stop-gap to keep older devices relevant longer as new standards are released that didn't make it into the silicon yet.
in theory yes, but in practicality, there are two points that make it probably impractical.
First, the reprogrammability of FPGAs means lots of unused gates and less density, or wasted space. with flash technology nowadays, it doesn't waste as much power, but the footprint is just so large it's not worth it.
Second, a lot of the things that make custom silicon fast can be found in GPUs, such as ALU, MAC, FFT, FIR, SIMD and other DSP slices. Sure, there is a whole additional layer of optimization that can be done with custom silicon, but the computational powerhouses already exist. It's mostly (not all) a matter of reprogramming the memory movements from block to block, delegating certain operations to the CPU and general optimization. Most new codec algorithms can probably done pretty well with GPUs on phones these days.
And unfortunately, cell phone companies aren't interested in keeping older HW relevant :( Other industries might, though. My friend said lots of military radar projects he worked on used FPGAs.
First, the reprogrammability of FPGAs means lots of unused gates and less density, or wasted space. with flash technology nowadays, it doesn't waste as much power, but the footprint is just so large it's not worth it.
Second, a lot of the things that make custom silicon fast can be found in GPUs, such as ALU, MAC, FFT, FIR, SIMD and other DSP slices. Sure, there is a whole additional layer of optimization that can be done with custom silicon, but the computational powerhouses already exist. It's mostly (not all) a matter of reprogramming the memory movements from block to block, delegating certain operations to the CPU and general optimization. Most new codec algorithms can probably done pretty well with GPUs on phones these days.
And unfortunately, cell phone companies aren't interested in keeping older HW relevant :( Other industries might, though. My friend said lots of military radar projects he worked on used FPGAs.
Same as when every new format comes out -- give a few years for the hardware folks to iterate on the hardware.
Upon purchasing On2, It was Google's intention to release a new codec every 18-24 months or so. That would mean hardware would never catch up. However, Google didn't keep that pace. VP8 came out in 2010 and VP9 was 2013. AV1 was just released now. I would estimate that high end hardware launching in 2020 will have hardware decoding support for AV1. If AV2 doesn't launch until at least 2022, we'll have 2 good years :).
Can't wait to have my laptop dropping frames while running at 90°
To what extent are the set of intrinsics used for VP9/h265 decoding unreusable for AV1 decoding? My guess is that there is large amount of reusable intrinsics.
Intrinsics aren't used. The decoding is generally done by a fixed function hardware block.
Intrinsics must be used, how else is the hardware invoked?
Video decoders live somewhere in the general vicinity of the GPU and aren't invoked through CPU instructions. AFAIK.
This thread is about Intel processors, not GPUs
The VP9/H.265 support in Intel chips is on the GPU side.
Thanks for the correction. I think my core point still holds without the intrinsics but I was mistaken on that point.
https://en.wikipedia.org/wiki/Nvidia_PureVideo
>PureVideo occupies a considerable amount of a GPU's die area
>PureVideo occupies a considerable amount of a GPU's die area
How much more effective is this than HEVC/x265 (especially at 4K HDR) resolutions?
Bitmovin's comparison: https://bitmovin.com/av1-multi-codec-dash-dataset/
MSU's comparison: http://www.streamingmedia.com/Articles/News/Online-Video-New...
x265 complained about the recent MSU test: http://www.x265.org/x265-incorrectly-represented-msus-2017-c...
But equally x265 likes to refer to MSU comparisons when the results make x265 look good: http://www.x265.org/
An x265 post referencing another paper which says HEVC outperforms AV1. The post insinuates AV1 might not be royalty-free. Reads like an attempt to spread fear, uncertainty, and doubt: http://www.x265.org/excited-av1-closing-doors/
MSU's comparison: http://www.streamingmedia.com/Articles/News/Online-Video-New...
x265 complained about the recent MSU test: http://www.x265.org/x265-incorrectly-represented-msus-2017-c...
But equally x265 likes to refer to MSU comparisons when the results make x265 look good: http://www.x265.org/
An x265 post referencing another paper which says HEVC outperforms AV1. The post insinuates AV1 might not be royalty-free. Reads like an attempt to spread fear, uncertainty, and doubt: http://www.x265.org/excited-av1-closing-doors/
MSU actually in the meantime updated their description. According to them they used a more recent version – see the Facebook comment thread below the streamingmedia.com link you shared.
But indeed it's a little bit ironic for someone advocating for HEVC to be concerned about patent royalties and licensing.
But indeed it's a little bit ironic for someone advocating for HEVC to be concerned about patent royalties and licensing.
Thanks for the heads up. I didn't see those Facebook comments because Firefox's tracking protection blocked it (which in general is what I want). The x265 team really should add an update to their blog post to explain that MSU corrected the version number error.
Instead of 7th version older, their one was 6th?
x264 or x265 was basically never tuned for PSNR or SSIM what ever metrics. Basically the 30-40% AV1 claimed to be better in those value. And in that case, the x265 developer isn't wrong, it is very much the picture, not the values that matters.
VMAF should hopefully bring much more useful numbers. But we will have to see and put some time in since it is very new.
x264 or x265 was basically never tuned for PSNR or SSIM what ever metrics. Basically the 30-40% AV1 claimed to be better in those value. And in that case, the x265 developer isn't wrong, it is very much the picture, not the values that matters.
VMAF should hopefully bring much more useful numbers. But we will have to see and put some time in since it is very new.
30% smaller than h26_4_ is an often heard statement. If you know how much more efficient h265 is in comparison with h264 you can do the math :)
At transloadit we’ve been testing the reference implementation but to encode a video it’s about 20x slower than h264 still :) there will be many improvements to speed up but it’s expected to remain a lot slower (up to 4x as slow) or so I’ve read.
At transloadit we’ve been testing the reference implementation but to encode a video it’s about 20x slower than h264 still :) there will be many improvements to speed up but it’s expected to remain a lot slower (up to 4x as slow) or so I’ve read.
h26_4_? What do the underscores mean (excuse my ignorance).
Probably meant to emphasize the 4 instead of h265 (since the parent they responded to mentioned h265 not h264) but used markdown instead of HN formatting so instead of 4 got _4_.
Taking part in the campaign to make Hacker News recognise underscores as the way to do italics. That's what you would do on a typewriter to indicate to the typesetter that something should be set in italics.
Just emphasizing the 4.
In markdown that would put the 4 in italics, where it's not supposed it still works as emphasis, but can be a bit confusing.
In markdown that would put the 4 in italics, where it's not supposed it still works as emphasis, but can be a bit confusing.
Pseudo-formatting for emphasis. If the page was markdown it would be bold/italicized.
It's not more effective technically, or perhaps only slightly in some metrics. In some ways it's much worse, like encoding speed.
People like it because it has better licensing.
People like it because it has better licensing.
Current reference implementation's encoding speed is much worse.
That is definitely going to change when real optimized encoders are written, especially since all the major CPU/GPU manufacturers are part of the Alliance for Open Media.
That is definitely going to change when real optimized encoders are written, especially since all the major CPU/GPU manufacturers are part of the Alliance for Open Media.
AV1 is a poor name for a video codec because it is too easy to visually confuse with AVI.
I know how you feel. But they didn't like my suggestion of "Deep Space VP9".
what about .. av2
it's "windows 8 to windows 10" problem again.
so we'll just use nullsoft solution. Introducing av5
Mozilla says not to worry, since each version number won't be around for more than a few weeks anyway.
You could argue not only is it an ergonomic/usability mess but also a security risk, because if future flaws are found in an AVI container code path, it could be used to trick users into executing the video that they normally wouldn’t play. I know that’s a stretch, but there’s just no reason to even have the any of these issues.
That said, I hate to criticize them too much for this detail, in fact, congratulations are in order. It’s been a great engineering effort so far, and hopefully this will continue with the reference implementation evolving into some highly optimized players and encoders.
Aside from the engineering accomplishment you can imagine that it took quite a bit of business effort and coordination to get all these players together and on the same page.
I’d make a bet whoever first proposed the extension name has never been involved with user experience design. But again it’s relative. An excellent chef made a great meal, if just the garnish on top is not perfect it’s not a lot to complain about.
That said, I hate to criticize them too much for this detail, in fact, congratulations are in order. It’s been a great engineering effort so far, and hopefully this will continue with the reference implementation evolving into some highly optimized players and encoders.
Aside from the engineering accomplishment you can imagine that it took quite a bit of business effort and coordination to get all these players together and on the same page.
I’d make a bet whoever first proposed the extension name has never been involved with user experience design. But again it’s relative. An excellent chef made a great meal, if just the garnish on top is not perfect it’s not a lot to complain about.
Hopefully, it doesn't ever become the file extension. Current containers for AV1 include Matroska (.mkv), WebM (.webm), ISO base media file format (.3gpp), and WebRTC.
While technically file extensions so far reflected the container used, rather than codec, I think it should be the other way around.
I see “regular users” making decisions based on container file formats all the time, as to whether the file will be playable on their favorite device: DVD player, smartphone, portable music player etc.
It’s not very reliable, or accurate, but if you see an .mkv that’s usually h.264 or hevc, .webm is vp8/vp9 and .avi will play on your DVD.
There’s really no technical reason why file extensions should reflect the container format.
If I rename “BunnyVideo.mkv” to “BunnyVideo.av1” VLC will still play it just fine. But now I can tell at first glance that it will not play on my legacy Smart TV or last year netbook with no hardware decoding.
Whether that AV1 video is actually in a MKV or WebM container doesn’t really matter at all to your average user. It only matters if it will play.
Maybe it would be even better to just have .av1.mkv instead, but double file extensions don’t work on Windows and people think it’s a trick to get you to run malware.
I see “regular users” making decisions based on container file formats all the time, as to whether the file will be playable on their favorite device: DVD player, smartphone, portable music player etc.
It’s not very reliable, or accurate, but if you see an .mkv that’s usually h.264 or hevc, .webm is vp8/vp9 and .avi will play on your DVD.
There’s really no technical reason why file extensions should reflect the container format.
If I rename “BunnyVideo.mkv” to “BunnyVideo.av1” VLC will still play it just fine. But now I can tell at first glance that it will not play on my legacy Smart TV or last year netbook with no hardware decoding.
Whether that AV1 video is actually in a MKV or WebM container doesn’t really matter at all to your average user. It only matters if it will play.
Maybe it would be even better to just have .av1.mkv instead, but double file extensions don’t work on Windows and people think it’s a trick to get you to run malware.
It's actually not a good idea to name the files after the codec, and there's good (technical) reasons for that.
A container contains more than just a single video stream.
They can also contain audio streams and subtitles, with multiple of each, of different types.
What are you going to call a file containing an AV1 video stream, an MPEG2 video stream, a 2-channel MP3 audio stream, a 5.1-channel AC3 audio stream, SubRip (.srt) subtitles for one language, and VobSub (.sub+.idx) for another language?
The above also means that just knowing the video codec is not enough to know whether your device can play it, since your proposition will be missing e.g. audio codec(s).
Trying to play a file with e.g. FLAC audio on a device that does not support it? Worst case it doesn't work at all, best case you get video but no audio.
All that is before you get to the actual video codec, which also complicates matters: For example, H.264 has profiles and levels, and not all devices/decoders support all profiles and levels. This means you also need to know the profile+level of the file, and the maximum supported by the device to tell whether it can play the file.
A container contains more than just a single video stream.
They can also contain audio streams and subtitles, with multiple of each, of different types.
What are you going to call a file containing an AV1 video stream, an MPEG2 video stream, a 2-channel MP3 audio stream, a 5.1-channel AC3 audio stream, SubRip (.srt) subtitles for one language, and VobSub (.sub+.idx) for another language?
The above also means that just knowing the video codec is not enough to know whether your device can play it, since your proposition will be missing e.g. audio codec(s).
Trying to play a file with e.g. FLAC audio on a device that does not support it? Worst case it doesn't work at all, best case you get video but no audio.
All that is before you get to the actual video codec, which also complicates matters: For example, H.264 has profiles and levels, and not all devices/decoders support all profiles and levels. This means you also need to know the profile+level of the file, and the maximum supported by the device to tell whether it can play the file.
The question is whether “.av1” conveys more useful information to the end user than “.mkv”
Of course you can make an “.h264” with opus audio but in reality no one does that. And anyway even if that wasn’t the case, once you decide to use that extension you agree to not do that.
Audio is also both easier to play on anything with software encoding and easy to reencode if needed.
Perfect is the enemy of the good.
What useful information does the “.mkv” or “.webm” extension offer exactly? It’s “correct,” but also completely useless. The only signal it provides is accidental and unreliable. Might as well use “.video” and “.audio”.
Of course you can make an “.h264” with opus audio but in reality no one does that. And anyway even if that wasn’t the case, once you decide to use that extension you agree to not do that.
Audio is also both easier to play on anything with software encoding and easy to reencode if needed.
Perfect is the enemy of the good.
What useful information does the “.mkv” or “.webm” extension offer exactly? It’s “correct,” but also completely useless. The only signal it provides is accidental and unreliable. Might as well use “.video” and “.audio”.
> Of course you can make an “.h264” with opus audio but in reality no one does that.
People definitely do that. And even if they didn't, significantly more people create h264+flac releases, and flac is also supported by much fewer devices than e.g. AC3.
E.g. .mkv does convey useful information. A player needs to support the container format as well, not just the codecs for the streams it contains. Different containers also support different features (not all containers are equal), and there are tools that only work for some containers.
The signal provided is only accidental and unreliable as a proxy for audio or video codec, not in general.
.webm is also a bit of a bad example here, since it's just a subset of matroska (mkv), but more importantly it initially only supported a single video codec and a single audio codec (VP8 & Vorbis). Of course, that has changed since, with the addition of support for VP9, AV1, and Opus.
People definitely do that. And even if they didn't, significantly more people create h264+flac releases, and flac is also supported by much fewer devices than e.g. AC3.
E.g. .mkv does convey useful information. A player needs to support the container format as well, not just the codecs for the streams it contains. Different containers also support different features (not all containers are equal), and there are tools that only work for some containers.
The signal provided is only accidental and unreliable as a proxy for audio or video codec, not in general.
.webm is also a bit of a bad example here, since it's just a subset of matroska (mkv), but more importantly it initially only supported a single video codec and a single audio codec (VP8 & Vorbis). Of course, that has changed since, with the addition of support for VP9, AV1, and Opus.
Is it really not a good idea per se, or simply that it would need to be more prescriptive?
For example a new extension could mandate minimum support for codecs or features. Like wp explains, matroska file extensions are .MKV for video (with subtitles and audio), .MK3D for stereoscopic video, .MKA for audio-only files, and .MKS for subtitles. I’m not aware of any reason an extension couldn’t represent minimum package requirements, like audio/video/at least av1 codec, etc, that would work for most cases, while potentially still retaining extensibility where practical.
For example a new extension could mandate minimum support for codecs or features. Like wp explains, matroska file extensions are .MKV for video (with subtitles and audio), .MK3D for stereoscopic video, .MKA for audio-only files, and .MKS for subtitles. I’m not aware of any reason an extension couldn’t represent minimum package requirements, like audio/video/at least av1 codec, etc, that would work for most cases, while potentially still retaining extensibility where practical.
But then you're not really naming it after the codec.
Instead you create a standard that mandates container X, support for video codecs Y[, ...], and support for audio codecs Z[, ...]. Then you can document a player/device as supporting that standard and also name video files after it.
Instead you create a standard that mandates container X, support for video codecs Y[, ...], and support for audio codecs Z[, ...]. Then you can document a player/device as supporting that standard and also name video files after it.
Thank you, that’s correct. I was questioning an argument you made in a way that was not technically analogous.
The gist of the comment should have referred only to what I brought up, which as you point out is a minimum simple standard for packaging and contents as it could relate to a file extension.
The gist of the comment should have referred only to what I brought up, which as you point out is a minimum simple standard for packaging and contents as it could relate to a file extension.
I agree that there needs to be a better proxy for understanding this for average users. It certainly is odd to have the container format as the primary bit of information we convey, but it reflects the information gap between users and developers. I believe the reasoning is that the codec should ideally be invisible and irrelevant information to the average user.
How is a user to know he might need to install a special codec to play a video? This is why OS and hardware support across many devices is essential to the success of new formats. This is why the Alliance for Open Media ensures AV1 succeeds across the spectrum of devices available.
How is a user to know he might need to install a special codec to play a video? This is why OS and hardware support across many devices is essential to the success of new formats. This is why the Alliance for Open Media ensures AV1 succeeds across the spectrum of devices available.
> I believe the reasoning is that the codec should ideally be invisible and irrelevant information to the average user.
I don’t think anyone decided to do it like that. It’s just been the way it always was.
Anyway, early on container formats were actually correlated with the codec, or at least the multimedia stack you needed.
Let’s remember the early file extensions:
.avi .rmbv .wmv .mov .flv
Everyone knew what they needed to install to play one of these files. It’s only later, starting with .mkv really, that container formats stopped having anything to do with codecs.
Even so, .mkv used to for a long time just mean h.264 to most users. If you had a device that could play mkvs it could play h.264 as well.
The confusion started full on with HEVC. To many users mkvs suddenly just stopped being playable.
I don’t see any reason to continue this trend. AV1 should just use “.av1”. Any device/program that can play av1 can also handle mkv/webm. And no one will be confused.
I don’t think anyone decided to do it like that. It’s just been the way it always was.
Anyway, early on container formats were actually correlated with the codec, or at least the multimedia stack you needed.
Let’s remember the early file extensions:
.avi .rmbv .wmv .mov .flv
Everyone knew what they needed to install to play one of these files. It’s only later, starting with .mkv really, that container formats stopped having anything to do with codecs.
Even so, .mkv used to for a long time just mean h.264 to most users. If you had a device that could play mkvs it could play h.264 as well.
The confusion started full on with HEVC. To many users mkvs suddenly just stopped being playable.
I don’t see any reason to continue this trend. AV1 should just use “.av1”. Any device/program that can play av1 can also handle mkv/webm. And no one will be confused.
Your reasoning and conclusion are exactly correct.
The only reason for this “I agree” comment is to underscore one last time there is absolutely no reason it has to specifically be .av1, and in fact several reasons it should be something else.
Whoever is involved please just walk right into the execs office and make the case to bring it up at the next meeting, it’s not too late.
The only reason for this “I agree” comment is to underscore one last time there is absolutely no reason it has to specifically be .av1, and in fact several reasons it should be something else.
Whoever is involved please just walk right into the execs office and make the case to bring it up at the next meeting, it’s not too late.
[deleted]
You’re right that would be worse, but even if it never happens we’ve all seen how people can be lulled into clicking/trusting seemingly prominent domain names that don’t really exist. More sort of confusion trickery than tech trickery.
It's a video codec, the average user will never give a shit or even realize they are using it. C is a stupid name for a programming language. No one cares.
Not just visually. For a long time, googling for "AV1" would produce mostly results about AVI.
At first I thought this was a late April Fool's prank. The next headline might be a new FOSS font called C0mic S4ns.
No need for that now that we have Comic Sans Neue: http://www.comicneue.com/ (FOSS-licensed)
Now the FOSS people have something to laugh at too!
At least it's not a container - you won't have *.av1 filenames.
I very frequently deal with .h264 files, containing just a raw h264 bitstream. Granted, that's more of a special case, because I deal with video encoding and decoding a lot through work.
That's a very important distinction.
I immediately thought this was like, a joke article RE: AVI format.
..So there you have it from an "unbiased^, first impression" -standpoint.
^ Unbiased in terms of any exposure / prior knowledge of this project.
..So there you have it from an "unbiased^, first impression" -standpoint.
^ Unbiased in terms of any exposure / prior knowledge of this project.
All the more reason for AV2 to be created more quickly (like when those "lapping approach and frequency-domain techniques" mentioned in the article reach technical maturity)
The first is a video codec, the second a container format. You won't see the raw .av1 much.
Finally, a codec name stupider than "DivX ;-)".
Fun fact - "DivX ;-)" was a cracked version of the Microsoft MPEG4 decoder which was originally restricted to only play in ASF containers and has nothing to do with DivX the company which came later.
For more history on this, see https://en.wikipedia.org/wiki/DivX#History
For more history on this, see https://en.wikipedia.org/wiki/DivX#History
Are you confusing the DivX codec with the DIVX DVD format? I don't know how accurate to it is to say that the cracked MPEG4 decoder had nothing to do with DivX the company. Gej (https://en.wikipedia.org/wiki/J%C3%A9r%C3%B4me_Rota) was the guy that created the DivX ;) crack, and definitely worked at DivX, Inc. from the very beginning.
Source: worked at DivX
Source: worked at DivX
I can't agree with you enough. I am astonished this didn't occur to anyone at Xiph.
Everyone here is asking about hardware encoding/decoding, which is obviously important.
My question is, at what level do these encoders work at? Are they basically specialized SIMD instructions, or are they fully featured chips that take raw data as input and produce byte streams in the format of the protocol? Or somewhere in between?
My question is, at what level do these encoders work at? Are they basically specialized SIMD instructions, or are they fully featured chips that take raw data as input and produce byte streams in the format of the protocol? Or somewhere in between?
Typically it's a dedicated hardware block on the die of a larger chip, like AMD's UVD [1] and VCE [2] inside their GPU/APUs, or Nvidia's PureVideo [3] and NVENC [4]. Sometimes the line is even blurrier, like the Broadcom SOC in the Raspberry Pi, where various more general-purpose processors can work together to decode [5].
Then you have APIs that try to disassemble all the typical stages of video codec processing that applications can call and GPU drivers can implement, which serve as a bridge between hardware-assisted decode and application code. These are APIs like DXVA or one of the several in use with Linux [6].
[1] https://en.wikipedia.org/wiki/Unified_Video_Decoder [2] https://en.wikipedia.org/wiki/Video_Coding_Engine [3] https://en.wikipedia.org/wiki/Nvidia_PureVideo [4] https://en.wikipedia.org/wiki/Nvidia_NVENC [5] https://github.com/hermanhermitage/videocoreiv [6] https://wiki.archlinux.org/index.php/Hardware_video_accelera...
Then you have APIs that try to disassemble all the typical stages of video codec processing that applications can call and GPU drivers can implement, which serve as a bridge between hardware-assisted decode and application code. These are APIs like DXVA or one of the several in use with Linux [6].
[1] https://en.wikipedia.org/wiki/Unified_Video_Decoder [2] https://en.wikipedia.org/wiki/Video_Coding_Engine [3] https://en.wikipedia.org/wiki/Nvidia_PureVideo [4] https://en.wikipedia.org/wiki/Nvidia_NVENC [5] https://github.com/hermanhermitage/videocoreiv [6] https://wiki.archlinux.org/index.php/Hardware_video_accelera...
In between, but more like the latter conceptually. It’ll be a collection of bulk data processing blocks that are glued together by software. Generally, you want to implement the large bulk operations in HW, with SW handling all the option parsing and control logic.
And this opens up the question of how easy it is to re-target exiting hardware to new techniques.
For example, if I understand the Chroma-from-Luma prediction; then the maths involved is just 2-d linear regression (once for U vs. L once for V vs L.). That's a pretty generic task. Even when with the domain-specialisation that it is done over pixels in an encoding block, we are still talking about concepts common to all codecs.
So maybe there existing acceleration hardware can already do it. But even if it can, the require primitive needs to be exposed to software if new protocols are to benefit from it. So my question (and maybe Boxxed's too) is whether the hardware interface is low-level enough for such adaptability.
For example, if I understand the Chroma-from-Luma prediction; then the maths involved is just 2-d linear regression (once for U vs. L once for V vs L.). That's a pretty generic task. Even when with the domain-specialisation that it is done over pixels in an encoding block, we are still talking about concepts common to all codecs.
So maybe there existing acceleration hardware can already do it. But even if it can, the require primitive needs to be exposed to software if new protocols are to benefit from it. So my question (and maybe Boxxed's too) is whether the hardware interface is low-level enough for such adaptability.
> AV1 leapfrogs the performance of VP9 and HEVC
Does anyone have any evidence of this claim?
Does anyone have any evidence of this claim?
For decoders. Encoder now is very very slow.
I believe that in that context "performance" refers to encoding efficiency (aka compression factor), not the encoding or decoding speed.
So not a good format for live streaming then?
Bitmovin produced an AV1 live stream a year ago using 200 cores: https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...
And six months ago they had improved on that to do live streaming with 32 cores: https://bitmovin.com/constantly-evolving-video-landscape-dis...
Twitch wants to use AV1 for live streaming. Here's a talk on the "switching frame" feature of AV1 for use in live streaming: https://www.youtube.com/watch?v=o5sJX6VA34o
And six months ago they had improved on that to do live streaming with 32 cores: https://bitmovin.com/constantly-evolving-video-landscape-dis...
Twitch wants to use AV1 for live streaming. Here's a talk on the "switching frame" feature of AV1 for use in live streaming: https://www.youtube.com/watch?v=o5sJX6VA34o
The project is still underway, but I think decoding is more important than encoding, especially with live streams. Given a Twitch stream, for example, the encoding is only done by one peer while the decoding is done by thousands or (as of recent) millions.
Counter-argument: encoding is the bottleneck in live-streaming
But you only have to encode once, or once per client type as opposed to per-client. And the more efficient decoding is, the wider the range of potential clients and/or the better the quality for a given amount of bandwidth.
> But you only have to encode once
In real-time. If the encoder is too slow for that it is the bottle-neck.
In real-time. If the encoder is too slow for that it is the bottle-neck.
[deleted]
I was thinking of the case where the encoding is being done by a centralized 'broadcaster', as opposed to individual users streaming from their own machines; for the latter case I agree with you.
Ah ok! I'm a bit sceptical of how well that would work in practice, though:
1. the uploader would have to quickly send data to the server, which requires fast encoding in a different format (so lower-quality than AV1, and introducing artefacts from a different lossy encoding)
2. this low quality then gets recompressed with a different codec with different artefacts, and possibly worse compression due to the artefacts introduced by the first codec
When uploading to video sites that are not live, the idea is usually to use as high-quality an input as possible first, in which case this won't be much of a problem.
But I might be mistaken on how bad this affects live-streaming! Perhaps the first codec throws out information in a way that smooths out the video, which then makes re-encoding with AV1 faster and have better compression with minimal extra loss of details.
1. the uploader would have to quickly send data to the server, which requires fast encoding in a different format (so lower-quality than AV1, and introducing artefacts from a different lossy encoding)
2. this low quality then gets recompressed with a different codec with different artefacts, and possibly worse compression due to the artefacts introduced by the first codec
When uploading to video sites that are not live, the idea is usually to use as high-quality an input as possible first, in which case this won't be much of a problem.
But I might be mistaken on how bad this affects live-streaming! Perhaps the first codec throws out information in a way that smooths out the video, which then makes re-encoding with AV1 faster and have better compression with minimal extra loss of details.
Live-streaming is typically a type of broadcast. Some latency (a few or even tens of seconds) is typically OK.
True, how about caling it "soft real-time"? It can't stutter too often, and can't be too resource intensive as that would take them away from whatever task is being live-streamed (games, live-drawing in photoshop with heavy filters, etc), and there is an upper limit of acceptable latency.
Depends on how parallelizable the encoding algorithm is.
With a live stream, it's generally not parallelizable at all. You won't have future frames to work with unless you add a huge delay in the stream, which generally doesn't mesh well with doing something live.
5 minute delays are common on twitch, especially to circumvent stream snipers. Totally live video is a liability actually and I would guess most live broadcasts have a delay.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.
I am not going to say it never happens but purposely induced delays are very rare. You have to remember that Twitch is a community and the people watching communicate with the streamer through chat. Getting a response to something you say in chat 5 minutes later is not a workable solution.
Now, this works fine for large broadcasts where there is no two way communication between a streamer and their followers or in some type of competitive situations, but that is not the norm.
Now, this works fine for large broadcasts where there is no two way communication between a streamer and their followers or in some type of competitive situations, but that is not the norm.
All the streamers I watch respond to chat in digest form after finishing a game
Twitch is just one example, and I'd assume most live video viewed would benefit from a lower delay. That goes for everything from security cameras to sports to video chat. I'd bet that for the vast majority of live video a lower delay would not be a "liability", but rather a plus.
Iter-frame parallelizability is made possible (at least in the context of h264) by using slices. It comes with a minor penalty in the resulting data compression ratio.
Please do elaborate.
It can take an enormous amount of compute power to encode 4k video at 1:1 speed with these more complex codecs. Multiply for multiple bitrates and resolutions. If you can't encode at 1:1, you add significant delays to 'live' streaming, thus making it not 'live'.
Case in point, a 40 second 1080p clip would take over 8 hours to encode on an i7-4800 - that's less than 2 frames per minute. You need a lot of horsepower to cut that down to 40s / 60 FPS.
[1] https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...
Case in point, a 40 second 1080p clip would take over 8 hours to encode on an i7-4800 - that's less than 2 frames per minute. You need a lot of horsepower to cut that down to 40s / 60 FPS.
[1] https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...
Like the other comment said: the point is live streaming, so the encoding has to be done in real-time. Being the slower of the two steps (assuming comparable hardware between sender and recipient), it becomes the performance bottleneck when measured as frames per second.
When measured in, say, total sum of all CPU cycles and hence total energy spent, then yes: the decoder is the bigger deal. So your argument holds for non-live videos.
When measured in, say, total sum of all CPU cycles and hence total energy spent, then yes: the decoder is the bigger deal. So your argument holds for non-live videos.
Efficient encoding is very important for WebRTC and video communication in general. And AV1 is proposed for it. So hopefully some major improvements are planned.
Bitmovin and Mozilla recently also did a Webinar about AV1: https://bitmovin.com/an-introduction-to-av1/
>The Twitch test set is entirely live-streamed video game content, and we see solid gains here as well.
From the article, near the end.
From the article, near the end.
For now
Does anyone know when h264 goes patent-free? It’s truly ubiquitous, and it first came out in around 2003. It’ll be very exciting when it becomes totally libre.
That is actually a good question. Mp3 is now patents free as well.
And both standards are “good enough” for most use cases and are supported by an overwhelming majority of hardware devices. Once h264 goes off patent, the interest in more advanced formats will dwindle.
It will be good enough, for things like Gif replacement. For Video though I think we still have long way to go.
Or once all the AVC patents expire, what additional tools, like new encoding and tools from Open Sources like Daala we could add to, to form a new baseline codec for the web, that is truly Patents free.
The current AV1 is only royalty free.
When will all AAC patents expire? It is over 20 years since AAC introduction.
The current AV1 is only royalty free.
When will all AAC patents expire? It is over 20 years since AAC introduction.
Probably 2020 or later.
Hopefully it will go the way copyrights are going and never be patent-free... /s
Is Daala development abandoned now?
They said a while ago they will be using Daala as a developmental testbed.
Yes. We still have internal investment is many pieces of Daala that didn't get adopted in AV1. I don't know the liklihood that Daala will rise again as a standalone codec project... possible, wouldn't bet on it.
That's a pity, it was very promising, but if I remember correctly it hit some major blockers that weren't solved yet?
See also my previous statement on the subject: https://news.ycombinator.com/item?id=14599601
Additional background testing and perspective can be found in the following sponsored industry article - note BitMovin and Harmonic are both discussing this at the ongoing NAB conference in Las Vegas - http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti...
[deleted]
Where's the demo? It's not unreasonable to expect to see an actual video if the article is about a next generation video.
This has been available for a while: https://demo.bitmovin.com/public/firefox/av1/
(although might not be up to spec which was published only recently: https://aomedia.org/the-alliance-for-open-media-kickstarts-v... )
(although might not be up to spec which was published only recently: https://aomedia.org/the-alliance-for-open-media-kickstarts-v... )
How would we play it? The only decoders that exist are experiments or tests, and they are not currently optimised enough for mainstream use.
You can simply reencode the result of a low bitrate test using high bitrate H.264. It would take more bandwidth of course but the visual result would be more or less the same.
Also a webassembly decoder could probably do short clips.
No one has yet written a good performant decoder for native, let alone Wasm.
I don't dispute that it is theoretically possible - of course it is, people are making this codec for actual use, and I'm looking forward to it - just that it doesn't seem doable right now.
I don't dispute that it is theoretically possible - of course it is, people are making this codec for actual use, and I'm looking forward to it - just that it doesn't seem doable right now.
Congratulations Chris!
Are you hiring?
Mandatory xkcd comic strip ;-) https://xkcd.com/927/
> The AV1 format is and will always be royalty-free
Not sure how they can make this statement.
VP8 was patent encumbered all over the place and eventually required licensing from MPEG-LA. Surely AV1 would be infringing on at least some of HEVC's expansive patent pool. Unless of course Google is willing to indemnify user's against patent infringement lawsuit. Which would be really big news.
Not sure how they can make this statement.
VP8 was patent encumbered all over the place and eventually required licensing from MPEG-LA. Surely AV1 would be infringing on at least some of HEVC's expansive patent pool. Unless of course Google is willing to indemnify user's against patent infringement lawsuit. Which would be really big news.
Apparently Google does IP diligence for AV1 to navigate around patents.
Matt Frost of Google is quoted as saying:
"Obviously, if we have an open source codec, we need to take very strong steps, and be very diligent in making sure that we are in fact producing something that's royalty free. So we have an extensive IP diligence process which involves diligence on both the contributor level – so when Google proposes a tool, we are doing our in-house IP diligence, using our in-house patent assets and outside advisors – that is then forwarded to the group, and is then again reviewed by an outside counsel that is engaged by the alliance. So that's a step that actually slows down innovation, but is obviously necessary to produce something that is open source and royalty free."
The original source is a video, but this quote transcript is on Wikipedia: https://en.wikipedia.org/wiki/AV1#cite_note-frost-sme2017-16
Matt Frost of Google is quoted as saying:
"Obviously, if we have an open source codec, we need to take very strong steps, and be very diligent in making sure that we are in fact producing something that's royalty free. So we have an extensive IP diligence process which involves diligence on both the contributor level – so when Google proposes a tool, we are doing our in-house IP diligence, using our in-house patent assets and outside advisors – that is then forwarded to the group, and is then again reviewed by an outside counsel that is engaged by the alliance. So that's a step that actually slows down innovation, but is obviously necessary to produce something that is open source and royalty free."
The original source is a video, but this quote transcript is on Wikipedia: https://en.wikipedia.org/wiki/AV1#cite_note-frost-sme2017-16
How did we end up at this point? It's like a self-enforced ceiling on evolution of technology. The tar pit gets more tarry every year.
Fortunately patents are fairly short-lived (at least compared to copyright). A lot of the worst software patents were granted in the '90s and early 2000s and are reaching their 20-year expiration date.
20 years is still an eternity for tech that improves every day.
Have a look at recent patents for Facebook. http://stks.freshpatents.com/Facebook-Inc-nm1.php
A patent for 'user status update suggestions' for example. Yuck.
A patent for 'user status update suggestions' for example. Yuck.
Does this actually help that much, though? I imagine many of the important patentable improvements end up being obsolete by the time the patents expire.
The MPEG-2 patents are all expired, and it's still widely used (all terrestrial and most cable TV). It higher bitrates MPEG-2 is still very reasonable.
Sure, but I expect that's more because no one wants to tell everyone their TVs that they were forced to buy in the mid-2000s are obsolete and they must buy a new MPEG-4 (or whatever) capable TV in order to keep watching broadcast television. (Of course, cable networks can do whatever they want; they can just build new decoder boxes if it's worth the expense to them).
Terrestrial broadcast standards have to move slowly. Internet-based streaming and storage can move much faster, and it's supremely beneficial to be able to do so. MPEG-2's now-expired patent portfolio isn't too useful for that, and hasn't been for quite a while now.
Terrestrial broadcast standards have to move slowly. Internet-based streaming and storage can move much faster, and it's supremely beneficial to be able to do so. MPEG-2's now-expired patent portfolio isn't too useful for that, and hasn't been for quite a while now.
The "evolution of technology" requires dollars. Gobs of them. R&D thus must have a monetization model. The monetization model used by AV1 didn't exist until relatively recently, but MPEG's patent-based monetization model worked just fine for two decades before that.
For decades, companies like Sony, Sharp, NTT, etc., bankrolled that R&D by licensing patents to the technology, and selling devices incorporating the technology.
Today, the Internet enables new monetization models. Companies like Apple and Google can directly monetize video content through iTunes and Google Play (or indirectly through Youtube). They can use that to bankroll their investment in new video codecs.
For decades, companies like Sony, Sharp, NTT, etc., bankrolled that R&D by licensing patents to the technology, and selling devices incorporating the technology.
Today, the Internet enables new monetization models. Companies like Apple and Google can directly monetize video content through iTunes and Google Play (or indirectly through Youtube). They can use that to bankroll their investment in new video codecs.
> VP8 was patent encumbered all over the place
Was it? Can you name a single patent? MPEG-LA never did.
https://arstechnica.com/information-technology/2013/03/googl...
Was it? Can you name a single patent? MPEG-LA never did.
https://arstechnica.com/information-technology/2013/03/googl...
> MPEG-LA never did
The never do. It's like the mob: "pay us or you'll be in trouble". You can either pay the MPEGLA (and by the way, you will never know who inside the MPEGLA decided to sue you), or face consequences (and discover which patents are supposedly infringed)
The never do. It's like the mob: "pay us or you'll be in trouble". You can either pay the MPEGLA (and by the way, you will never know who inside the MPEGLA decided to sue you), or face consequences (and discover which patents are supposedly infringed)
Why should Google indemnify users when MPEG-LA isn't willing to do so for their licensees? (see the mess that HEVC is in now, or even good old MP3 with Sisvel)
> Surely AV1 would be infringing on at least some of HEVC's expansive patent pool
Yes, it probably would, but if these patents are owned by members of AOM it is not an issue
Yes, it probably would, but if these patents are owned by members of AOM it is not an issue
When did VP8 require licensing?
From wikipedia:
AOMedia Video 1 (AV1), is an open, royalty-free video coding format designed for video transmissions over the Internet. It is being developed by the Alliance for Open Media (AOMedia), a consortium of firms from the semiconductor industry, video on demand providers, and web browser developers, founded in 2015.
https://en.wikipedia.org/wiki/AV1
AOMedia Video 1 (AV1), is an open, royalty-free video coding format designed for video transmissions over the Internet. It is being developed by the Alliance for Open Media (AOMedia), a consortium of firms from the semiconductor industry, video on demand providers, and web browser developers, founded in 2015.
https://en.wikipedia.org/wiki/AV1
Guessing (maybe generously?) at OP's meaning, claims were made in the past about VP8 being royalty free etc, and that turned out to be wrong. It's not clear how much we can trust them this time around.
http://www.streamingmedia.com/Articles/News/-76781.aspx
http://carlodaffara.conecta.it/an-analysis-of-webm-and-its-p...
http://www.fosspatents.com/2013/03/patent-clouds-remain-over...
http://www.fosspatents.com/2013/03/next-patent-infringement-...
http://www.streamingmedia.com/Articles/News/-76781.aspx
http://carlodaffara.conecta.it/an-analysis-of-webm-and-its-p...
http://www.fosspatents.com/2013/03/patent-clouds-remain-over...
http://www.fosspatents.com/2013/03/next-patent-infringement-...
There is nothing in there that asserts your claim about VP8 being encumbered by royalties/patents.
All of those are quite old sources, and patent claims were refuted. Is there anything newer?
https://www.zdnet.com/article/google-and-mpeg-la-settle-long...
So far as I can see, that's the final state. Google ended up having to get a license from the MPEG-LA VP8 patent pool.
So far as I can see, that's the final state. Google ended up having to get a license from the MPEG-LA VP8 patent pool.
from your link:
> Google's Serge Lachapelle notes that today's agreement is "not an acknowledgment" that VP8 infringes on any of the patents claimed by MPEG LA
https://www.ietf.org/mail-archive/web/rtcweb/current/msg0663...
> Google's Serge Lachapelle notes that today's agreement is "not an acknowledgment" that VP8 infringes on any of the patents claimed by MPEG LA
https://www.ietf.org/mail-archive/web/rtcweb/current/msg0663...
Bad for Google, but it's not a proof that they require a license. The court didn't rule on it, so it just shows that they didn't want to fight the troll further.
You know I just watched an old (and much degraded) VHS of a TV broadcast of the 80s superman. I missed zero HD 4K whatever.
Something about the medium and the message here.
Something about the medium and the message here.
I could survive just fine without glasses. That doesn't make it noble to do so.
Well I recently watched an old laserdisc rip of star wars and I found it so terrible that I stopped watching. To each his own, but I for one welcome high quality codecs.
I know Google provided a free hardware decode block for VP8, and I assume also for VP9 (since there appears to have been some, though not universal, hardware acceleration for that according the the Wikipedia article). I'm hoping they'll soon (or already) have the same for VP1.
I see Apple, Nvidia, Intel, Allegro, AMD, and a bunch of other silicon vendors are also members of the Alliance for Open Media, so I expect to see hardware acceleration within the next 2-3 years. I'll be impressed if it's earlier.
Edit: maybe hardware acceleration earlier. If the standard was released recently with the collaboration of the silicon industry, it's likely the current in-design/early-production silicon already has an implementation of the important parts of the codec, so we can expect consumer products with at least partial acceleration within 6 months.