h.266 H.266 Video Codec promises 50% size reduction over the current H.265

[Kisai]

On 7/7/2020 at 6:00 AM, BuckGup said:

Really? H.264 creates banding, blocky shadows, and distortion if the bitrate is too low for me but H.265 has none of that at the same bitrate. It's one of the reasons vimeo looks so much better than Youtube

 

Anime and Western cartoons have to add noise to their productions so that the output doesn't have banding in them. Exports from Toonboom, and other animation tools that produce too-clean of linework all have to do this otherwise that nice gradient ends up looking terrible. There's also the stair-stepping of smooth linework that also happens and it's pretty sad.

 

Yes, they have to intentionally make it less-compressible to make the compressor not make it look awful. h265 is no better in this respect, but h265 has variable block sizes that 264 doesn't have, so the problem can be mitigated somewhat better.

[LAwLz]

21 hours ago, Kisai said:

And had you actually read the post you'd see I was talking about the encoder and decoder, which guess what:

 

- No AMD chips support VP9 in hardware, AMD removed VP9 support.

- No Apple chips support VP9 in hardware

- No Intel chips before Kaby Lake (that is skylake and prior) in hardware

- No nVidia chips at all, desktop, laptop or SoC support VP9 in hardware. Nvidia doesn't even list VP9 as an encoder. In more than one place.

- Android flagships  like the Samsung Galaxy didn't support until the S8, which is guess what only 3 years old

 

There is a fixed function IP core out there at https://www.webmproject.org/hardware/vp9/bige/ and most vendors don't even use it, and it is only good to 4Kp30.

Nobody cares about implementing the VP9 encoding in hardware because:

1) It results in significantly worse quality than software encoders.

2) 99% of all video computing people do is decoding, not encoding.

 

If you're not wrong then you're being incredibly misleading by saying "it's not implemented anywhere" when the function that is responsible for like 99% of peoples' use-cases (decoding) is implemented everywhere since 2015, but the remaining 1% of usage (encoding) is lacking. Do you not understand that you are being extremely misleading? I am questioning why you are being so misleading. If it's deliberate or not.

 

 

You need to stop saying stuff like "it doesn't support VP9 in hardware" when you are only referring to encoding, because they do support it for decoding, which is what really matters.

 

 

 

21 hours ago, Kisai said:

You must be too young to have used flash, because it had the distinction of only being a software player, and highly single-threaded. It can't spit and chew bubblegum. Adobe even says as much https://help.adobe.com/en_US/as3/dev/WSe9ecd9e6b89aefd2-68d5ef8f12cc8511f6c-7fff.html

Nope, not too young to have used flash. Maybe you're just referencing outdated info? It wouldn't be the first time.

https://en.wikipedia.org/wiki/Flash_Video

Quote

• Hardware Accelerated Video : Flash Player supports hardware accelerated video playback since version 10.2, for H.264, F4V, and FLV video formats. Such video is displayed above all Flash content, and takes advantage of video codec chipsets installed on the user's device. Developers must specifically use the "StageVideo" technology within Flash Player in order for hardware decoding to be enabled. Flash Player internally uses technologies such as DirectX Video Acceleration and OpenGL to do so.

 

Hardware accelerated video decoding was introduced in Flash 10.2, which was released in 2011. The things you are saying haven't been true for over 9 years.

 

 

 

21 hours ago, Kisai said:

There's a good dozen exceptions to where it will not use hardware acceleration and pretty much all of them apply to the web browser, specifically acceleration is only available in full screen mode. And you know what usually happened full screen? the video would be cut into bands where the top and bottom would be out of sync. Don't be fooled, the hardware acceleration that flash did, wasn't meaningful and hit all the bugs in browsers in 2013 just as much as it does today. 

Where did you get the idea that it only works in full-screen mode from? You keep saying stuff like this with 0 evidence, then I have to try and find evidence for you only to find out that it seems like you're wrong. It's really annoying and a colossal waste of time.

Oh wait, maybe you did realize that you were completely wrong about Flash not supporting hardware acceleration (even though you in the paragraph before this said that it didn't support it at all) so now you're trying to post bullshit arguments that can neither be proven or disproved like "oh it was buggy". I never noticed it was buggy, and I used it a lot. Maybe that problem was only on your computer?

 

 

21 hours ago, Kisai said:

Apple did not allow flash on the iPhone because flash burned CPU cycles to do the exact rubbish I explained above. A fixed h264 decode on the cpu is more battery efficient than allowing flash to burn your battery life on the millions of website that have flash ads on it.

https://www.theguardian.com/technology/blog/2010/apr/29/steve-jobs-flash-ipad-letter-dead#:~:text=Steve%20Jobs%20has%20defended%20Apple's,battery%20life%20and%20user%20experience.

Now you're throwing around made up terms again. What do you mean by "fixed h264 decode on the cpu"? What does the "fixed" in that sentence refer to exactly?

And now you have changed your argument. You said Apple sloped Flash because of a lack of hardware accelerated video decoding. Now you're saying they didn't include support for it because they didn't want a bunch of flash ads being shown on websites. That argument I have no problem with. It's your previous argument (that you are now arguing against) that it was because of video decoding Apple didn't want Flash on iOS that I had a problem with.

 

 

 

 

21 hours ago, Kisai said:

Also consider that Adobe didn't even have hardware acceleration on OSX at the time of the iPhone's release. Hence my comment about "cutting their own throat" , here's adobe, claiming they have a huge install base, but mostly what their flash product gets used for is trash and a software video player in 2009. We've only been installing flash because of sites like Youtube, at the time, needed it, and it was also used for flash games and as an audio player on sites for largely the same reason it's used as a video player. The web browser did not support h264, mp3, aac, or anything other than raw wave files. It also continues to be an issue. https://caniuse.com/#feat=aac

Yes, and? Completely irrelevant to our conversation. It feels like you are trying to pad your posts with irrelevant facts like "browsers doesn't support AAC" to make your previous arguments feel more validated, even though it has nothing to do with our current conversation.

And the reason why browsers lack AAC support is because it's a patented and proprietary format which, like I said before, most browser vendors don't want to implement. Same reason they were against H.264. Proprietary standards which require licensing do not belong as web standards. The web should be open for everyone, not closed and owned by some patent holders.

 

 

 

21 hours ago, Kisai said:

No, I'm 100% right here, and you're just restating exactly what I said. Go look at websites other than wikipedia. Here the Kodi project has a nice list of Android hardware : https://kodi.wiki/view/Android_hardware , the vast majority of Android hardware does not support H265 or VP9 in hardware. Note that the Tegra actually does everything in software but VP9/h265. Yet these are playback lists, not encoder lists, as Kodi devices are not used for transcoding anything.

1) You're not arguing the origional point anymore. You said that Android did not have hardware accelerated video decoding until Android 6.0. This is complete and utter bullshit.

Here is our conversation, citation for citation, just so that people can see how you flip flop between arguments as soon as you get proven wrong.

 

Here you say Android did not have hardware-supported video playback until Android 6.0:

On 7/7/2020 at 5:23 AM, Kisai said:

So Apple has had support for hardware-supported video playback since it's inception, where as android, has not, and stubbornly refuses to (and didn't exist until Android 6.0 despite underlying hardware having support for it since 3.0) Android still does not support h.265 or VP9 as encoders.

 

My response to that was:

On 7/7/2020 at 8:50 PM, LAwLz said:

This is wrong. Android has supported hardware accelerated decoding of video codecs, including H.264, for far longer than Android 6.0.

Hardware support for it existed long before Android 3.0 was released as well. I have genuinely no idea where you have gotten any of these ideas from.

 

Want proof?

Quote

• Google's Android platform for mobile devices natively supports H.264 (based on PacketVideo's OpenCORE).^[14] On the T-Mobile G1, a Qualcomm MSM7200 CPU provides hardware decoding.^[15]

Do you honestly believe that Android devices could not play H.264 using hardare decoding until Android 6.0 which was in 2015?

Hardware accelerated decoding of H.264 worked flawlessly on my Galaxy S2 from 2011 for crying out loud. It honestly bothers me so much that you're so wrong and just make a ton of stuff up. If it wasn't for my Galaxy S2 being broken I would boot it up and record myself doing hardware accelerated decoding just to shut you up.

 

 

Also, that article on the Kodi wiki is very outdated. Seriously, didn't the fact that it only goes up to the Snapdragon 820 tic you off to the fact that it is outdated? That article just confirms what I said earlier. Basically anything released after 2015 has support for HEVC. Why does it seem like most Android hardware doesn't support HEVC on that list? Because most chips on that list are from before 2015, and they have also bundled up a lot of chips. So for example the 808, 810 and 820 all support HEVC, but they have been bundled together as one line.

By the way, wanna know when the 820, which happens to be the latest Snapdragon on that list was released? 2016. So nothing later than 2016 is on that Kodi list. Wanna know when support for HEVC started turning up in Android hardware? 2015. Of course it will look like barely any Android hardware supports HEVC when you're using a list from 2016 and support started being added in 2015.

[Bombastinator]

I’m often annoyed by the phrase “if you had read the post you would have...”. How could they possibly reply the way they had if they hadn’t read the post?  A pointless insult.

[LAwLz]

21 hours ago, Kisai said:

HTML5 includied a video tag in the draft specifications but it was written with the idea that any video codec or container could be used. I don't know why you are nitpicking this. W3C was not wrong in trying. https://caniuse.com/#search=h264

Kind of irrelevant to our discussion but I'll respond anyway.

The reason why a video format agnostic tag is a bad idea, is because it can create a compatibility nightmare. Website developers need to stick to a handful of formats that they can be sure the browsers support. Make it format agnostic and it would be the wild west and sites would be displayed differently in different browsers. Browser developers like Mozilla, Apple, Microsoft and Google wanted one standard codec to implement, that site developers could stick to. That's why there was a war between VP8 and H.264.

 

Here is the section on Wikipedia that I strongly recommend you read before you reply to this conversation again:

Quote

The HTML5 specification does not specify which video and audio formats browsers should support. User agents are free to support any video formats they feel are appropriate, but content authors cannot assume that any video will be accessible by all complying user agents, since user agents have no minimal set of video and audio formats to support.

The HTML5 Working Group considered it desirable to specify at least one video format which all user agents (browsers) should support. The ideal format in this regard would:

• Have good compression, good image quality, and low decode processor use.
• Be royalty-free.
• In addition to software decoders, a hardware video decoder should exist for the format, as many embedded processors do not have the performance to decode video.

Initially, Ogg Theora was the recommended standard video format in HTML5, because it was not affected by any known patents. But on 10 December 2007, the HTML5 specification was updated,^[7] replacing the reference to concrete formats:

User agents should support Theora video and Vorbis audio, as well as the Ogg container format.

with a placeholder:^[8]

It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available.^[9]

The result was a polarisation of HTML5 video between industry-standard, ISO-defined but patent-encumbered formats, and open formats.

 

Seems like I was mistaken when I said it was the W3C that wanted to decide on a standard format. It was the HTML5 working group that wanted to specify a standard format. Sorry for that, but my point still stands.

 

 

That Wikipedia article is actually very good because it goes over exactly what I talked about before. Apple pushed for a non-free format (H.264) and other browser makers like Mozilla, Opera and Google did not like that (because proprietary formats do not belong as web standards), so Google bought, open sourced and made VP8 royalty free.

 

 

 

21 hours ago, Kisai said:

That is because Firefox and Google "my-way-or-the-highway"'d so all references to codecs and containers were stripped from it. No point in establishing a standard that nobody will adhere to. That's the same reason why Apple follows html5, and chrome does not. Stock web server configurations support none of this, and even to this very day there is no support for any video format that works on everything. That is entirely the fault of google. They tried to remove support for h264 in 2011 https://www.wired.com/2011/01/google-dropping-h-264-codec-from-chrome-browser/

Yes, and I am very glad that Mozilla and Google refused to implement H.264 back when it was non-free (money wise). Neither I nor those companies wanted to live in a world where you needed to pay to use web standards. Like I said, the idea of paying to pay Apple to watch Youtube video with Mozilla's browser is fucked up. I honestly don't understand how you can support that world.

You're also wrong in saying that Apple follows HTML5 but Chrome doesn't. Both follow HTML5 to varying degrees. It's ridiculous of you to say that Apple follows it when they don't support for example Theora and also say Chrome doesn't follow HTML5 standards because it doesn't support H.264. Both of them can be seen as HTML5 standards.

Once again you're telling half truths and trying to mislead and decisive people. I would appreciate it if you would stop doing this. It's a massive waste of my time to have to correct and elaborate on everything you say so that people aren't mislead.

 

 

 

21 hours ago, Kisai said:

Microsoft turned around and released plugins for h264 in Chrome and Firefox https://www.zdnet.com/article/microsoft-adds-h-264-support-to-google-chrome/

Yes, and? Microsoft wanted H.264 to be the web standard as well, because they didn't care about a free and open Internet (this was the Balmer era where they hated free and open source technologies).

 

 

21 hours ago, Kisai said:

But here's really how things went down:

https://webrtchacks.com/ietf-finally-made-decision-mandatory-implement-mti-video-codec-webrtc/

 

You're once again trying to mislead people, or you just don't understand the full story. That chart was made AFTER Cisco open sourced and took on the licensing burden of their H.264 implementation. That's the only reason why H.264 got so many green faces. If it weren't for that, Mozilla for example would certainly have been a red face. Just like I said in my post. Hell, it might not even have been possible for Firefox to use H.264 if it weren't for Cisco. As Mozilla themselves have said:

Quote

Many streaming videos rely on the H.264 codec in order to work. Because of licensing restrictions, H.264 is not available for open source software like Firefox. Instead, Firefox uses its open source alternative, OpenH264, to support video calls.

 

 

 

21 hours ago, Kisai said:

And note that nothing I said was false.

A ton of things you have said have been false or at the very least half truths.

 

 

21 hours ago, Kisai said:

Pretty much nothing at the time supported VP8 that wasn't a Google product, Everything else supported h264, some in software, some in hardware.

That's true, but when deciding on a format standard you need to think a bit further into the future than "what do we have today". H.264 would have been a horrible choice for the standard codec because of licensing issues. It wasn't for technical merits that some groups were vocally against it. It was more of a philosophical and licensing argument. Making a web standard rely on a proprietary format would go against everything that makes the web so great. That it's free and open for everyone. You can't just decide the faith of an Internet standard based on "well we have this bad solution today and I don't want to wait a few years for something better to become usable".

Do you think it's a coincidence that all open source browser developers were against H.264 and all closed source browser developers were for it?

 

 

22 hours ago, Kisai said:

Note that the Cisco license is only for a software codec. So h264 support that is present, right now, is for supporting webRTC. Not HTML5. It just so happens that browsers are a popular way to "jump" into video conferencing, as we can see today with Zoom, Microsoft Teams, Slack, Discord, Microsoft Skype, Cisco WebEx. So relying on the browser vendors here was suicide, again. If Cisco didn't decide to take on the liability for any potential claims on h264, it would be stuck selling video conferencing hardware that only works with other Cisco hardware, and that's simply not how Enterprises do things. You can dial into a Webex call without video, you can participate with video using a web browser on any device that has hardware encode and decode h264 (though not all of them https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/discuss-webrtc/ZLrq1BGQN7E/TuGtuXT3DQAJ ), or a decent enough cpu to support it in software.

Are you referring to encoding as "codec" again? It is really annoying when you do that. Can you please start saying encoder and decoder when talking about either one of those specifically?

Anyway, I don't really disagree with anything you said here, but I am not sure why you're bringing it up either since I haven't really said anything to the contrary.

 

 

22 hours ago, Kisai said:

So what do you think is going to happen with h265 and h266? It's use case a 4K-8K video codec differs very much from it's use case as a Video conferencing product. What I expect is a repeat of what already went down with h264. Some big hardware vendor wants to sell their hardware products but they need the webRTC support in order to get all the edge cases (such as staff working from home, or on a remote work site over a low-bandwidth satellite link) and I just sincerely doubt we're ever going to get any more unified codec support in the browser. Google has the monopoly power to dictate what happens in software, but is just does not have any leverage over the SoC vendors that build Android devices, and since Samsung is the only one who builds their own SoC's, that's the only Android vendor who can. And even Samsung is not putting Android in their SmartTV devices.

I think H265 and H266 will fail and AV1 will take over. I don't think it will be a repeat of H.264 because all major companies in the industry are fed up with the shitty licensing situation and have told the MPEG-LA to go fuck themselves.

The fact that you don't think we will have hardware support shows how out little you know about the subject. AV1 has pretty much all major hardware players on-board, and the entire thing is spearheaded by Google.

[Kisai]

2 hours ago, LAwLz said:

 

A ton of things you have said have been false or at the very least half truths.

Nope, the things you've said have been antagonistic and nitpicky and added nothing to the conversation just to stroke your own ego, and then you lied about things just to make yourself look "right-er".  Stop doing that.

 

Quote

 

That's true, but when deciding on a format standard you need to think a bit further into the future than "what do we have today". H.264 would have been a horrible choice for the standard codec because of licensing issues. It wasn't for technical merits that some groups were vocally against it. It was more of a philosophical and licensing argument. Making a web standard rely on a proprietary format would go against everything that makes the web so great. That it's free and open for everyone. You can't just decide the faith of an Internet standard based on "well we have this bad solution today and I don't want to wait a few years for something better to become usable".

We could have had a standard back in 2011 when hardware was still incapable of playing and encoding h264 content in realtime, and thus many other sites could have competed with Youtube. But instead every site was forced to keep using Adobe flash, and Adobe withdrew developing Flash for mobile devices. So "web apps" were constrained to exactly what HTML5 supported, which was only complete on the iPhone, not Android devices, which were still trying to use the flash plugin.

 

This squabble pretty much ensured that the iPhone cemented it's place as the #1 smartphone for several years, because the performance and battery life all pre-Android 6.0 devices had no hardware support for encoding and decoding h264 in hardware. 

 

Quote

Do you think it's a coincidence that all open source browser developers were against H.264 and all closed source browser developers were for it?

No, that's not a coincidence at all, they had no means to pay for it (Firefox), or refused to because they were providing a free product (Google). Apple and Microsoft already charge you money, and they can roll that licencing cost into their own products. It's not even a big deal to Apple, and Microsoft made you buy mpeg codec licences because they were originally pushing their own codec which is a BD standard.

 

When you don't support standards, you get left behind. I'm of the opinion this was just another cutting off the nose to spite the face brought to you by the same people who act like Stallman GPL fools. If those people had their way, every time, software would still look like it did in 2002.

 

Quote

 

Are you referring to encoding as "codec" again? It is really annoying when you do that. Can you please start saying encoder and decoder when talking about either one of those specifically?

Here's you being antagonistic for no reason again.

 

Quote

 

I think H265 and H266 will fail and AV1 will take over. I don't think it will be a repeat of H.264 because all major companies in the industry are fed up with the shitty licensing situation and have told the MPEG-LA to go fuck themselves.

 

You do realize that h265 is the one that exists in hardware right now. Not AV1 right? All UHD Blueray equipment is paying for that licence. Mobile devices and GPU's support hardware decoding, but largely do not support full hardware encoding. What we're going to see is the patents on H264 start to drop off rapidly in about 3 years and it will no longer be a concern, but you can't just wait out the patents for 20 years when people throw away their computers after 7 years and mobile devices after 3 years. That war has already been won, and it's the disgusting greed shown by the licencing groups that is what is ultimately going to keep h264 around until ...

At least 2030

https://www.mpegla.com/wp-content/uploads/avc-att1.pdf

 

If there was ever a reason for patent reform, the "submarine" patents should not be granted on a standard after a standard is published.

 

Quote

The fact that you don't think we will have hardware support shows how out little you know about the subject. AV1 has pretty much all major hardware players on-board, and the entire thing is spearheaded by Google.

Again with your arrogance. There are no hardware encoders or decoders for AV1 that are in computer or mobile phone products. The decoders "in hardware" are entirely in "TV box" ip cores announced last year. You know, for products announced this year, not actually available. People who actually keep their fingers on the pulse of this topic know there are no hardware AV1 products yet otherwise there would be studio cameras with it already. The first products will be 8K TV's and that will be of no help to the installed base of 4K and HD TV's.

 

Just because a company says they back a certain codec, does not make them obligated to prefer it over another. If nVidia and AMD decided to not support h.266, that doesn't mean they're going to suddenly develop fixed function encoders for AV1 instead. No it just means that until there is some demand for it, they won't bother with the extra cost of licencing the patents.

 

nVidia has made no announcements about AV1 support, whatsoever.

No VP9 encoder either.

 

Look at this slide from AMD:

 

Which if you look at what it's actually doing it's actually an OpenCL software support, not a fixed function encoder at all. The Fixed function encoder for h265 is only in the Vega chips, and the VP9 decoder is only on the Raven/Navi VCN chips. No encoder.

 

So that's the problem we are going to keep seeing. New codecs come out, and they end up in products that the patent holders could trade horses with to lower their licence cost. Meanwhile, it does not end up in the vast majority of consumer products because it's too expensive or too much of a landmine (which includes VP9 and AV1, not just h265 and h266.)

 

https://sisvel.com/licensing-programs/audio-and-video-coding-decoding/video-coding-platform/patents

 

So please stop pretending like Google is a saint here. It isn't. It's just bumbling along like it has before in this space, and losing, hoping that a miracle like Cisco's h264 happens again.

 

[The1Dickens]

Just want to point out that implementing it may not be as big of a hurdle this time around, because:

Quote

To reduce the risk of the problems seen when licensing HEVC implementations, for VVC a new group called the Media Coding Industry Forum (MC-IF) was founded.

 

As for who all is in that group, well you can see the members HERE. And it's possible the list will grow. I think I read somewhere that Google and AMD will be in this group, too, though they are not currently on that page.

[leadeater]

6 hours ago, Kisai said:

You do realize that h265 is the one that exists in hardware right now. Not AV1 right? All UHD Blueray equipment is paying for that licence. Mobile devices and GPU's support hardware decoding, but largely do not support full hardware encoding.

 

6 hours ago, Kisai said:

There are no hardware encoders or decoders for AV1 that are in computer or mobile phone products. The decoders "in hardware" are entirely in "TV box" ip cores announced last year. You know, for products announced this year, not actually available. People who actually keep their fingers on the pulse of this topic know there are no hardware AV1 products yet otherwise there would be studio cameras with it already.

 

 

As for the encoding part that for most people doesn't really matter, if you are watching YouTube or Netflix you will only be decoding and in terms of web standards decoding is also the only thing that matters, nobody is encoding using a webbrowser.

 

So as nice as hardware encoding could be for any codec for the most part the professional and online services industry want/prefer software encoding due to the greater flexibility in controlling the process. Hardware end user encoding is mostly important in video and audio communication type scenarios.

[Loote]

Overall comparing VP9 with h265 and on that basis proclaiming 266 will be better than av1 is a mistake, h265 was ready over a year before VP9 and VP9 is basically a Google only thing, in which it succeeded, but wasn't really pushed into other spheres. AV1 on the other hand has widespread industry backing and is already showing up in some places, whereas h266 is just beginning to get mentioned.

 

Looking at members of both groups I wouldn't be surprised if AV1 became the streaming/web codec, sometimes getting into cameras, whereas h266 would be the default for cameras, perhaps h266 would be less demanding for real time compression whereas AV1 would look better in very low bitrates. I'd also expect the Hollywood to follow the bigger lobbyist.

[LAwLz]

2 hours ago, leadeater said:

 

 

 

As for the encoding part that for most people doesn't really matter, if you are watching YouTube or Netflix you will only be decoding and in terms of web standards decoding is also the only thing that matters, nobody is encoding using a webbrowser.

 

So as nice as hardware encoding could be for any codec for the most part the professional and online services industry want/prefer software encoding due to the greater flexibility in controlling the process. Hardware end user encoding is mostly important in video and audio communication type scenarios.

There is also the Mediatek Dimensity 1000 which supports decoding of AV1 in fixed function hardware. It has started showing up in a few phones that's on the market already. 

[Kisai]

8 hours ago, leadeater said:

 

 

 

As for the encoding part that for most people doesn't really matter, if you are watching YouTube or Netflix you will only be decoding and in terms of web standards decoding is also the only thing that matters, nobody is encoding using a webbrowser.

 

So as nice as hardware encoding could be for any codec for the most part the professional and online services industry want/prefer software encoding due to the greater flexibility in controlling the process. Hardware end user encoding is mostly important in video and audio communication type scenarios.

Hopefully you've been paying attention to the last 7 months of work-from-home shift and see that the lack of hardware encoders and it's connection to bandwidth costs is a big thing. It would be nice if bandwidth caps/throttles weren't a thing, but they are. You can't ask people with the sub $1000 computer/phone hardware and the minimum of internet connections to just not participate while their friends with the more expensive equipment and unthrottled/unlimited data caps can participate as much as they want. Likewise businesses don't want to pay through the nose for bandwidth to have meetings with their customers and clients either.

 

But let's not get too far ahead here. The entire discourse around h264 and how it eventually wound up in browsers is due to Cisco seeing a business case it benefited from, by having WebEx available in the browser. Now everyone with a similar product is now eating Cisco's lunch on.

 

https://techcommunity.microsoft.com/t5/microsoft-teams-blog/what-s-new-in-microsoft-teams-june-2020/ba-p/1489142

See that Zoom feature with the large video participation? That's coming to Teams next month, and that screenshot is from Teams.

 

This is why I said I don't see the same thing happening with h265, or h266. Cisco may be an, or even the industry leader here, but it's not stupid. Businesses are not going to rip out there meet-me rooms just to save money when those rooms already cost them a significant amount of money and yet the actual hardware it runs on is exactly the same hardware you would find in a highend blueray player that just happens to have multiple camera/hdmi outputs.

 

AV1 and VP9 have their own patent minefields. VP9 largely was passed over for WebRTC because of the loophole provided by Cisco. That didn't give everyone using h264 a licence to use h264, only those using Cisco's implementation. You can't put that implementation in a hardware ASIC. That also didn't give site operators (such as youtube or netflix) a license either.

 

It's far too early to see what adopts AV1, and the patent minefield may again prevent it from ending up in anything but Google products for end-users. The fact that everyone seems to be reading from the same Wikipedia article here also tells me everyone commenting on it, have no specialized knowledge on this topic either. So let's cite some sources:

 

Cisco intends to use AV1, skip h265

https://blogs.cisco.com/collaboration/cisco-leap-frogs-h-264-video-collaboration-with-real-time-av1-codec

 

Quote

Running an encoder at these kinds of speeds inevitably results in some loss in performance. Real-time encoding is a matter of trade-offs: compression power relative to complexity, at realistic levels of CPU usage and speed. So another question is whether Cisco AV1 produces significant compression gains when going so fast.

 

Again, the answer is Yes. In our demo, we not only managed to encode live 720p30 camera video at half the bandwidth of H.264, but we also encoded high frame rate share at 1080p30 using around 2/3 of the bitrate of H.264 encoding 720p30, all encoded on a commodity laptop.

 

Microsoft's free AV1 codec:

https://www.microsoft.com/en-us/p/av1-video-extension/9mvzqvxjbq9v

 

Members of the AOM:

Webkit (Apple)'s support for WebRTC HEVC :

https://webkit.org/blog/10264/release-notes-for-safari-technology-preview-104/

 

 

 

Android's lack of support for WebRTC due to missing hardware support:

https://webrtcbydralex.com/index.php/2020/04/28/how-to-enable-hevc-h265-and-av1-in-webrtc-in-your-browser/

Quote

Most of the people in the WebRTC ecosystem know that today H264 in WebRTC is only supported in Android on a limited number of devices that have Hardware Acceleration. One of the reason is that shipping it with a software implementation would make the browser vendors liable. Windows Firefox users have been prompted to download the openH264 dll the first time they used that codec. That iss because for Firefox not to be liable, they both:

• cannot compile the codec implementation (which Cisco does for everyone with openH264),
• but also cannot ship it. The end user needs to install it itself. Since legally the only binding action on a web page is a click in a prompt, here you go.

Same page about h265 in hardware for webrtc:

Quote

Why adding H265 in webrtc? The question is more, why not? The code was already made available by INTEL. Apple already had H265 hardware acceleration. It does not reduce the capacity for those who can’t support it, but it allows peers with the capacity to have an improved experience. It’s only a win. It was was helping internally bringing the two groups together and leveraging a common asset. In practice, it took less than 2 days for one very jet-lagged Apple engineer and the main coder behind the implementation at INTEL to get the code into libwebrtc-in-webkit and to have a working version. It was not a big effort.

 

WebRTC: 

https://www.w3.org/TR/webrtc/ (Note that it's candidate recommendation, which means it's not finished.)

Quote

Sources that also encode (typically hardware encoders) might be unable to produce the negotiated codec; similarly, software sources might not implement the codec that was negotiated for an encoding source.

There is no mention of h264, mpeg, avc, av1, etc in it.

 

https://www.w3.org/TR/webrtc-svc/

Quote

The term Single Real-time Transport Protocol (RTP) stream Single Transport (SRST), defined in [RFC7656] Section 3.7, refers to SVC implementations that transmit all layers within a single transport, using a single RTP stream and synchronization source (SSRC). The term Multiple RTP stream Single Transport (MRST), also defined in [RFC7656] Section 3.7, refers to implementations that transmit all layers within a single transport, using multiple RTP streams with a distinct SSRC for each layer. This specification only supports SRST transport, not MRST. Codecs with RTP payload specifications supporting SRST transport include VP8 [RFC7741], VP9 [VP9-PAYLOAD], AV1 [AV1-RTP] and H.264/SVC [RFC6190].

 

IETF wants h264 in 2014:

https://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-04.html

Quote

This document proposes that, and motivates why, H.264 should be a Mandatory To Implement video codec for WebRTC.

 

So as of right now, there actually is not a defined requirement for what codec's to support for webRTC, we've only got to where we have because of Cisco, and Firefox.

 

https://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox (2014)

Quote

The Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C) have been working jointly to standardize on the right video codec for WebRTC. Cisco and many others have been strong proponents of the H.264 industry standard codec. In support of this, almost a year ago Cisco announced that we would be open sourcing our H.264 codec and providing the source code, as well as a binary module that can be downloaded for free from the Internet. Perhaps most importantly, we announced that we would not pass on our MPEG-LA licensing costs for this binary module, making it effectively free for applications to download the module and communicate with the millions of other H.264 devices. At that time, Mozilla announced its plans to add H.264 support to Firefox using OpenH264.

 

So if AV1 is an intended alternative to H.266, the patent licencing groups better come up with a better plan than "repeat the mistakes of h265"

 

[LAwLz]

16 hours ago, Kisai said:

We could have had a standard back in 2011 when hardware was still incapable of playing and encoding h264 content in realtime, and thus many other sites could have competed with Youtube. But instead every site was forced to keep using Adobe flash, and Adobe withdrew developing Flash for mobile devices. So "web apps" were constrained to exactly what HTML5 supported, which was only complete on the iPhone, not Android devices, which were still trying to use the flash plugin.

Again, no idea where you are antagonizing and blaming Google for all of this.

The HTML5 standard (written by a person at Google) suggested Theora as the default format but for some reason did not companies like Apple and Microsoft want that. They wanted closed source and proprietary solutions instead. So why are you constantly saying it is Google's fault when it was one open and free standard and a closed and proprietary one, and two camps? Why are you saying the companies who wanted a free and open Internet are to blame and not the companies who wanted an Internet where you would need a license (not a coincidence that the license comes from the companies who wanted the closed standard to win)?

You are giving Apple a free pass to go "no it's our proprietary way or nobody gets to play!" but when Googles goes "no, it's the free and open way or nobody gets to play!" you blame them for holding back progress.

 

Also, I don't get why you keep bringing up flash because neither the iOS Youtube app nor the Android Youtube app used Flash for video playback. Websites were free to write their own app and use whichever format they wanted for video playback. They weren't limited to Flash or H.264 if they didn't want to. Flash was pretty much irrelevant on Android even in the early days. Nobody I know used the browser to visit Youtube and then used Flash to play video on their Android phone, because it was slower and a far worse experience than just using the Youtube app. Flash was only useful for a handful of websites that didn't have an app, like Newgrounds.

 

 

 

16 hours ago, Kisai said:

This squabble pretty much ensured that the iPhone cemented it's place as the #1 smartphone for several years, because the performance and battery life all pre-Android 6.0 devices had no hardware support for encoding and decoding h264 in hardware. 

You keep saying that they had no hardware support until Android 6.0 but you have so far not backed this up with anything. By the way, you are extremely, horribly wrong when you say that Android did not have hardware accelerated encoding or decoding of H.264 until Android 6.0 (2015). I am honestly flabbergasted that you even think this is correct because it is so ridiculous. By the way, I have already provided you with a link that stats that you are wrong but it seems like you will just ignore that.

 

 

 

16 hours ago, Kisai said:

When you don't support standards, you get left behind. I'm of the opinion this was just another cutting off the nose to spite the face brought to you by the same people who act like Stallman GPL fools. If those people had their way, every time, software would still look like it did in 2002.

And now you're showing your true colors. Seems like you just hate free and open standards and want things closed source and proprietary.

 

 

 

16 hours ago, Kisai said:

You do realize that h265 is the one that exists in hardware right now. Not AV1 right?

You have already been proven wrong on this point. Also, AV1 is not going to compete with H.265. It will compete with H.266.

Guess which format has support in hardware on the market right now and guess which one doesn't?

 

 

 

16 hours ago, Kisai said:

There are no hardware encoders or decoders for AV1 that are in computer or mobile phone products. The decoders "in hardware" are entirely in "TV box" ip cores announced last year. You know, for products announced this year, not actually available. People who actually keep their fingers on the pulse of this topic know there are no hardware AV1 products yet otherwise there would be studio cameras with it already. The first products will be 8K TV's and that will be of no help to the installed base of 4K and HD TV's.

This is wrong. There are phones on the market right now with AV1 decoding support in hardware.

Also, not sure what you mean by "studio cameras" but I would like to inform you that professional grade cameras generally do not record to a format like HEVC. So I am not sure why you are bringing up studio equipment as if they are relevant to this conversation.

 

 

 

16 hours ago, Kisai said:

Just because a company says they back a certain codec, does not make them obligated to prefer it over another. If nVidia and AMD decided to not support h.266, that doesn't mean they're going to suddenly develop fixed function encoders for AV1 instead. No it just means that until there is some demand for it, they won't bother with the extra cost of licencing the patents.

 

nVidia has made no announcements about AV1 support, whatsoever.

<image>

No VP9 encoder either.

 

Look at this slide from AMD:

<image>

 

Which if you look at what it's actually doing it's actually an OpenCL software support, not a fixed function encoder at all. The Fixed function encoder for h265 is only in the Vega chips, and the VP9 decoder is only on the Raven/Navi VCN chips. No encoder.

You believe whatever you want. AMD and Nvidia would have to be idiots to not support hardware accelerated AV1 decoding. We will see fixed function hardware for it, mark my words.

I don't get why you are so obsessed with encoders. It's almost the only thing you talk about, yet barely anyone cares about fixed function encoding.

Like I said before, and like @leadeater said, what really matters is decoding, not encoding. My big problem with your posts in this thread is that you have been constantly saying "there is no hardware support for the codec" when what you mean is "there is no hardware support for encoding".

Why do you even care so much about hardware accelerated encoding, to the point where it seems to be the only thing that matters to you? Like I said earlier, 99% of all video processing being done on consumer devices is decoding. Encoding is quite frankly irrelevant. It would be a nice bonus for things like video conferencing, but for those tasks the quality is generally so low that you can do encoding in software without any problems.

Did you know that Google Duo uses AV1 already, and it does it in software on phones without any problems?

 

Video conferencing streams are very low bandwidth and low quality streams. So while it would be nice to have hardware accelerated encoding, it's pretty irrelevant. I think it's best if you stop putting so much emphasis and importance on it. Focus on decoding instead, which is what will actually benefit people.

 

 

 

16 hours ago, Kisai said:

So that's the problem we are going to keep seeing. New codecs come out, and they end up in products that the patent holders could trade horses with to lower their licence cost. Meanwhile, it does not end up in the vast majority of consumer products because it's too expensive or too much of a landmine (which includes VP9 and AV1, not just h265 and h266.)

AV1 will not have any licensing costs or issues. If someone tries to enforce licensing on AV1 they will have to go through Google, Microsoft, Apple, Adobe, Netflix, Amazon, Nvidia, AMD, Intel, and a bunch of other companies lawyers. It just won't happen.

And yes I know that Sisvel is trying to claim they own patents that are AV1 is infringing on. Sisvel is just a patent troll and it won't lead anywhere. If you don't belive Sisvel is a patent troll then just look at this 13 year old article about them called "who is going to stop Europe's patent troll".

 

 

 

16 hours ago, Kisai said:

So please stop pretending like Google is a saint here. It isn't. It's just bumbling along like it has before in this space, and losing, hoping that a miracle like Cisco's h264 happens again.

1) Google is the saint. They literally bought an entire company and gave away their stuff for free just so that we can keep enjoying an open and free Internet.

2) They are not losing. Do you seriously think that AOMedia is losing? They aren't, and the entire thing is spearheaded by Google. AV1 is basically VP10, and it will be the next big standard. Mark my words.

3) No miracle will happen with HEVC. It's a failure and it's dead, and it's probably bringing the entire MPEG with it to its grave (thank God). They even removed the payment cap for HEVC so that Cisco would not be able to do what they did with H.264. Here is an article from Leonardo Chiariglione (co-founder of MPEG) titled "A future without MPEG" about the entire situation. Well worth a read.

[LAwLz]

1 hour ago, Kisai said:

AV1 and VP9 have their own patent minefields. VP9 largely was passed over for WebRTC because of the loophole provided by Cisco. That didn't give everyone using h264 a licence to use h264, only those using Cisco's implementation. You can't put that implementation in a hardware ASIC. That also didn't give site operators (such as youtube or netflix) a license either.

This is wrong. OpenH264 (Cisco's H.264 implementation) is free to use for anyone, including site operators.

The reason why it isn't used is because OpenH264 is rather limited (only free if you use the exact binary Cisco releases, only supports the baseline H.264 profile, might be OS support limitations, etc) and there are better tools available, and for companies like Youtube, paying a license fee isn't a big deal since they only need a license for themselves. The licensing problem of H.264, HEVC and the like is when you ship millions of programs or hardware devices which needs support for it, because you need one or multiple licenses for each device.

[spartaman64]

6 minutes ago, LAwLz said:

And now you're showing your true colors. Seems like you just hate free and open standards and want things closed source and proprietary.

maybe this is jensen huang's secret account

[Kisai]

2 minutes ago, LAwLz said:

Again, no idea where you are antagonizing and blaming Google for all of this.

Because they're the ones who keep pushing for non-standards in the browser, and everyone else pays for it with higher energy costs, low battery life, and poor support on other devices that would otherwise not go obsolete in just 2 years.

 

2 minutes ago, LAwLz said:

The HTML5 standard (written by a person at Google) suggested Theora as the default format but for some reason did not companies like Apple and Microsoft want that. They wanted closed source and proprietary solutions instead.

 

No they wanted to use what they already paid for and not get caught in lawsuits for using propietary codecs that may infringe on patents.

 

In case you're completely ignorant on the entire thing:

https://www.osnews.com/story/23058/theora-more-of-a-patent-threat-than-h264-wait-what/ (2010)

Quote

MPEG-LA’S PATENTS

 

The second group of patents Gruber claims Theora might be infringing upon are those that reside within the MPEG-LA’s patent pool. Theora supporters have long claimed this is not the case (Theora is patent-free, they say), but Gruber points to an interview with MPEG-LA’s CEO, Larry Horn, who claims otherwise.

 

“No one in the market should be under the misimpression that other codecs such as Theora are patent-free,” Horn claims, “Virtually all codecs are based on patented technology, and many of the essential patents may be the same as those that are essential to AVC/H.264. Therefore, users should be aware that a license and payment of applicable royalties is likely required to use these technologies developed by others, too.”

 

When asked to clarify that statement, Horn said that the MPEG-LA believes that some of its patent holders own patents used in Theora. He also added that the MPEG-LA might consider offering a license to Theora users to negate these worries. And thus our true colours reveal.

 

Take that as "We will sue you if you do"

 

2 minutes ago, LAwLz said:

 

 

So why are you constantly saying it is Google's fault when it was one open and free standard and a closed and proprietary one, and two camps? Why are you saying the companies who wanted a free and open Internet are to blame and not the companies who wanted an Internet where you would need a license (not a coincidence that the license comes from the companies who wanted the closed standard to win)?

Are you really subscribing to the "information wants to be free" group of fools. Their goals might be honorable, but their means are not. Their means are basically "everything should be free, no matter how much investment, research or consumables are required to produce it." This is why Microsoft was always so antagonistic with Linux and Apple antagonistic with GPL software. These are not "free" licences, they are designed to rob you of your investments, especially the GPLv3. And as time has proven, companies are just as willing to avoid GPL software as they are willing to avoid paying for patents or being sued for submarine patents.

 

Unless you want to perpetually be locked into 20-year old hardware, patents apply to pretty much everything. So Go ahead, go back to watching mpeg-2 videos and mp3 audio, at 4x the bandwidth where we are at now on your Pentium III or AMD Athlon. Software patents suck, but we would also not see any incentive to standardize on anything when companies will just undermine each other to be the one to dictate the standard everyone uses.

 

2 minutes ago, LAwLz said:

You are giving Apple a free pass to go "no it's our proprietary way or nobody gets to play!" but when Googles goes "no, it's the free and open way or nobody gets to play!" you blame them for holding back progress.

Hell no, but Apple adheres to the standards they say they do, Google does not. Third parties using Google Chromium or Google Android are under no obligation to support anything that google doesn't make free to them. Free software can not include things that have pay-per-use/pay-per-seat licencing, so if there is an axe held over VP9 from MPEG-LA, no vendor is going to implement it.

 

2 minutes ago, LAwLz said:

Also, I don't get why you keep bringing up flash because neither the iOS Youtube app nor the Android Youtube app used Flash for video playback. Websites were free to write their own app and use whichever format they wanted for video playback. They weren't limited to Flash or H.264 if they didn't want to. Flash was pretty much irrelevant on Android even in the early days. Nobody I know used the browser to visit Youtube and then used Flash to play video on their Android phone, because it was slower and a far worse experience than just using the Youtube app. Flash was only useful for a handful of websites that didn't have an app, like Newgrounds.

 

Because Flash as of Flash 10 was used entirely for pushing h264 video by Adobe who made a big stink about having their player installed on 75% of devices, h264 is what Youtube was pushing to flash player, and hence Android devices were incapable of playing video in the flash player. You forget, the early "smartphone" app era, everyone and their dog wanted to "app" their website, and since the webview can't run flash, Apple managed to do what everyone else wanted to do. Kill Flash.

 

Of course web designers were pissed at having to throw away all their flash content, music players, video players and such. Japanese amateur animation and western amateur animators all use flash, and were now forced to export their content into much larger video files and no place to host them (until newgrounds decided to solve that themselves.) Youtube versions of flash animations lack any of the menus, subtitles, interactivity that the flash versions have, and there is no way to play that content on mobile devices, at all. 

 

Android phones didn't have hardware playback and couldn't play back video in software either. Apple does not let you include GPL software on it's device, so no software video players built on FFMPEG are supported.

 

https://forum.videolan.org/viewtopic.php?f=36&t=153215&p=502833#p503040

Quote

Starting on iOS 9, VLC uses the hardware decoder included in modern iOS devices (so 64bit only) for H264 and if available H265. The same applies to mp3 and AAC audio decoding. According to Western legislation (US-American, EU), you may not be charged for the same patents twice and since the user already paid for the hardware decoders when purchasing the iOS device, there is no legal way for clients app using it to be required to pay a second time.

 

[Kisai]

27 minutes ago, LAwLz said:

This is wrong. OpenH264 (Cisco's H.264 implementation) is free to use for anyone, including site operators.

The reason why it isn't used is because OpenH264 is rather limited (only free if you use the exact binary Cisco releases, only supports the baseline H.264 profile, might be OS support limitations, etc) and there are better tools available, and for companies like Youtube, paying a license fee isn't a big deal since they only need a license for themselves. The licensing problem of H.264, HEVC and the like is when you ship millions of programs or hardware devices which needs support for it, because you need one or multiple licenses for each device.

I linked you directly to Cisco's own information, and quoted the relevant part and you're still pulling this "no u" nonsense.

 

Read: https://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox

Quote

The Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C) have been working jointly to standardize on the right video codec for WebRTC. Cisco and many others have been strong proponents of the H.264 industry standard codec. In support of this, almost a year ago Cisco announced that we would be open sourcing our H.264 codec and providing the source code, as well as a binary module that can be downloaded for free from the Internet. Perhaps most importantly, we announced that we would not pass on our MPEG-LA licensing costs for this binary module, making it effectively free for applications to download the module and communicate with the millions of other H.264 devices. At that time, Mozilla announced its plans to add H.264 support to Firefox using OpenH264.

 

[Bombastinator]

I think there sis good and bad things about open and closed source.  Nothing is free of all detriment or without gain.  One could be clearly better but pretending it is perfect and without flaw is pointless.

[LAwLz]

On 7/9/2020 at 7:43 PM, Kisai said:

Because they're the ones who keep pushing for non-standards in the browser, and everyone else pays for it with higher energy costs, low battery life, and poor support on other devices that would otherwise not go obsolete in just 2 years.

This is wrong. The entire argument over video formats for the web was "what should be the standard". A standard had not been decided yet. I don't understand why you think H.264 was a standard and Theora or VP8 wasn't. H.264 was just as much of a web standard as any other format. That's what the entire debate was about, which format should become the standard.

 

You keep saying that H.264 was the standard when it wasn't. It was not a HTML5 standard. It was not a W3C standard. It was not a standard for WebRTC.

 

 

On 7/9/2020 at 7:43 PM, Kisai said:

No they wanted to use what they already paid for and not get caught in lawsuits for using propietary codecs that may infringe on patents.

 

In case you're completely ignorant on the entire thing:

https://www.osnews.com/story/23058/theora-more-of-a-patent-threat-than-h264-wait-what/ (2010)

Quote

MPEG-LA’S PATENTS

 

The second group of patents Gruber claims Theora might be infringing upon are those that reside within the MPEG-LA’s patent pool. Theora supporters have long claimed this is not the case (Theora is patent-free, they say), but Gruber points to an interview with MPEG-LA’s CEO, Larry Horn, who claims otherwise.

 

“No one in the market should be under the misimpression that other codecs such as Theora are patent-free,” Horn claims, “Virtually all codecs are based on patented technology, and many of the essential patents may be the same as those that are essential to AVC/H.264. Therefore, users should be aware that a license and payment of applicable royalties is likely required to use these technologies developed by others, too.”

 

When asked to clarify that statement, Horn said that the MPEG-LA believes that some of its patent holders own patents used in Theora. He also added that the MPEG-LA might consider offering a license to Theora users to negate these worries. And thus our true colours reveal.

 

Take that as "We will sue you if you do"

I am not ignorant about that. I am not ignorant about the threats against VP8 either.

 

Gee, what a surprise that the people behind the paid format threatens that if people use the competing format they would sue them.

To me that just goes to show what a bunch of scumbags the MPEG-LA are. All they seem to do is threaten anyone who looks at other options until they hand over a bunch of cash and goes with H.264. I don't even think anyone has ever been sued successfully for using Theora, or VP8 for that matter. It's just empty threats, but sadly they seem to have worked (kind of, Theora is still around today).

 

But even if Theora was not ideal, they could have picked some other format.

 

 

 

On 7/9/2020 at 7:43 PM, Kisai said:

Are you really subscribing to the "information wants to be free" group of fools. Their goals might be honorable, but their means are not. Their means are basically "everything should be free, no matter how much investment, research or consumables are required to produce it." This is why Microsoft was always so antagonistic with Linux and Apple antagonistic with GPL software. These are not "free" licences, they are designed to rob you of your investments, especially the GPLv3. And as time has proven, companies are just as willing to avoid GPL software as they are willing to avoid paying for patents or being sued for submarine patents.

 

Unless you want to perpetually be locked into 20-year old hardware, patents apply to pretty much everything. So Go ahead, go back to watching mpeg-2 videos and mp3 audio, at 4x the bandwidth where we are at now on your Pentium III or AMD Athlon. Software patents suck, but we would also not see any incentive to standardize on anything when companies will just undermine each other to be the one to dictate the standard everyone uses.

These two entire paragraphs are wrong and you will have a hard time justifying your stance now that both Apple and Microsoft have sided with the free and open formats.

Also, you are once again showing your true colors. You just hate anything that is free and/or open source and want proprietary stuff. You can not ignore AOMedia no matter how much you want them to disappear.

 

 

 

On 7/9/2020 at 7:43 PM, Kisai said:

Hell no, but Apple adheres to the standards they say they do, Google does not. Third parties using Google Chromium or Google Android are under no obligation to support anything that google doesn't make free to them. Free software can not include things that have pay-per-use/pay-per-seat licencing, so if there is an axe held over VP9 from MPEG-LA, no vendor is going to implement it.

Again, H.264 was not a standard. Please stop saying it was. It wasn't. The entire debate was about which format would be a standard.

It doesn't matter that you repeat it over and over, it doesn't make it any more true. H.264 was not a standard. In fact, Theora was more of a standard than H.264 was because Theora was in the beginning the official fallback format according to the HTML5 specification.

 

 

On 7/9/2020 at 7:43 PM, Kisai said:

Because Flash as of Flash 10 was used entirely for pushing h264 video by Adobe who made a big stink about having their player installed on 75% of devices, h264 is what Youtube was pushing to flash player, and hence Android devices were incapable of playing video in the flash player. You forget, the early "smartphone" app era, everyone and their dog wanted to "app" their website, and since the webview can't run flash, Apple managed to do what everyone else wanted to do. Kill Flash.

I don't understand what you are saying here. I can't even keep track of how many incorrect things are in your posts anymore.

1) Android devices had native support for H.264, without having to rely on Flash Player.

2) Video served from Youtube to Android devices was primarly done through the Youtube app, which did not use webview. It was its own client for Youtube, not just a a browser.

3) What is even your argument? Youtube on Android had nothing to do with Flash. Flash was in no way shape or form involved with 99% of Youtube playback on Android, even in the beginning.

 

 

 

 

On 7/9/2020 at 7:43 PM, Kisai said:

Android phones didn't have hardware playback and couldn't play back video in software either. Apple does not let you include GPL software on it's device, so no software video players built on FFMPEG are supported.

[Citation Needed]

I have provided you with evidence that this is completely and utterly wrong but you just keep repeating it. Show me proof that Android did not support hardware accelerated H.264 playback until Android 6.0. This is a complete lie from you that you are either telling for for malicious purposes or from ignorance. My guess is a bit of both.

For those reading this thread and are wonder, Android have had support for hardware accelerated video playback since the beginning.

Want more evidence than what I have already provided? Here you said Android did not get this until Android 6.0. That was released in late 2015.

  

On 7/7/2020 at 5:23 AM, Kisai said:

So Apple has had support for hardware-supported video playback since it's inception, where as android, has not, and stubbornly refuses to (and didn't exist until Android 6.0 despite underlying hardware having support for it since 3.0) Android still does not support h.265 or VP9 as encoders.

• Here is a thread from Kodi from 2013 where it says Android can do video decoding in hardware.
• Here is a thread from a developer in 2014 where he mentions improvements to hardware decoding Google made in Android 4.1. Please note that just because Google made improvements to it in 4.1 does not mean it didn't exist until 4.1 (because it did).
• Here is documentation from NXP about hardware accelerating video in Android. The documentation is from 2012. Please note that if you download the presentation it does specifically say hardware decoding of H.264 is supported. So was encoding, even in 2012.
• Here is the source code for Android back in 2012 for MediaCodec.java, which is the library used to access hardware based encoding or decoding engines. If you don't believe me, here is a backup of the Android developer site hosted on MIT. As you might see, it says "added in API level 16" in the right corner. Wanna know what API level 16 means? It means Android 4.1 Jelly Bean.

I could go further back but it's easier to find references to hardware decoding in 4.1 because I know the MediaCodec library was used for it. I don't know what the older APIs were but I can look it up if you want. Or just pick up an old Android phone, download MX Player (maybe an old version) and play a video. It will show you if it does it in hardware or software.

[LAwLz]

On 7/9/2020 at 7:46 PM, Kisai said:

I linked you directly to Cisco's own information, and quoted the relevant part and you're still pulling this "no u" nonsense.

 

Read: https://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox

I think the problem here is that you do not understand what "binary module" means. It means pre-compiled program. Nothing more and nothing less.

 

I'll explain what the part you quoted means. This is essentially what Cisco are saying:

Quote

If you download and compile our program for yourself, our license will not cover you. However, if you download the program we have compiled for you (binary module) then you are free to use it however you want and our license will cover your usage. You can use our binary file for your own program (like Firefox) or your website (a website like Youtube).

 

That is why it is separately downloaded in Firefox. Because Mozilla are not allowed to include the source code in their own project. They have to (for licensing reasons) download the complete encoder from Cisco, not the source code.

 

 

I am not sure why you think you would need a special license for running a website. The license is for being allowed to use an encoder, regardless of the purpose.

In terms of licensing, Cisco are basically manufacturing and selling a bunch of H.264 encoders and giving them away for free. Those encoders then end up in a wide variety of projects and Cisco are the ones paying for the licenses (since they are the ones who "manufactured" the encoder).

The licensing issues that Cisco warns about is if you pick "Cisco's manufactured encoder" apart, and then using other parts builds a replica, because if you do that then technically Cisco aren't the "manufacturer" anymore and their license doesn't cover you.

[LAwLz]

On 7/9/2020 at 8:04 PM, Bombastinator said:

I think there sis good and bad things about open and closed source.  Nothing is free of all detriment or without gain.  One could be clearly better but pretending it is perfect and without flaw is pointless.

Not sure if this post was aimed at me or not but I'll respond as if it was.

I am not saying that AV1 is perfect and flawless, but the closed source competitor (HEVC, and from what it seems VVC) were so bad that Apple, Microsoft, Google, Nvidia, AMD, Intel, Facebook, Amazon, Netflix and many more all went "okay, let's work together to fix this". That should tell you not only how horrible HEVC was, but also the massive backing the open source alternative now has.

You would have to be a fool to doubt that AV1 will be big.

 

 

So right now, on one side we have a format that pretty much everyone in the industry loathes and would rather not touch. On the other side we have a format that (almost) all major players in the business have worked together to develop, committed their patents to and have pledged to drive adoption of.

[Bombastinator]

2 minutes ago, LAwLz said:

Not sure if this post was aimed at me or not but I'll respond as if it was.

I am not saying that AV1 is perfect and flawless, but the closed source competitor (HEVC, and from what it seems VVC) were so bad that Apple, Microsoft, Google, Nvidia, AMD, Intel, Facebook, Amazon, Netflix and many more all went "okay, let's work together to fix this". That should tell you not only how horrible HEVC was, but also the massive backing the open source alternative now has.

You would have to be a fool to doubt that AV1 will be big.

 

 

So right now, on one side we have a format that pretty much everyone in the industry loathes and would rather not touch. On the other side we have a format that (almost) all major players in the business have worked together to develop, committed their patents to and have pledged to drive adoption of.

It wasn’t really pointed at anyone.  Just the open source/closed source debate.  Closed source has problems and open source has problems.  With closed source it’s the nature of closed source, and with open source it’s the nature of open source.   One allows not enough people and the other allows absolutely everyone.  This he can thing seems like it’s sort of both which might explain why it is well liked.

[Kisai]

44 minutes ago, Bombastinator said:

It wasn’t really pointed at anyone.  Just the open source/closed source debate.  Closed source has problems and open source has problems.  With closed source it’s the nature of closed source, and with open source it’s the nature of open source.   One allows not enough people and the other allows absolutely everyone.  This he can thing seems like it’s sort of both which might explain why it is well liked.

 

The problem with this entire open/closed community-developed vs commercially developed codec is that companies hate losing money and they want the horse they backed to be the winner.

 

This is where capitalism tends to waste a lot of human capital. You don't need to 30 different options when the difference between all of them is who makes money from it. Let things be competitive entirely on "which is technically superior, least expensive to implement" and most privately backed options end up not being the least expensive to implement.

 

What we have with GPLv3 is an actual clause to steal patents.

Quote

12 Liberty or Death for the Program.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute the Program, or other covered work, so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute it at all. For example, if a patent license would not permit royalty-free redistribution by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution.

It is not the purpose of this section to induce you to infringe any patents or other exclusive rights or to contest their legal validity. The sole purpose of this section is to protect the integrity of the free software distribution system.

 

So FFMPEG is GPL 2 "or later", which applies. Nearly every "free implementation" of a codec is part of FFMPEG. Including that of Google Chrome. So that means the implementation of h264, h265, vp8, vp9, av1, etc is subject to this license

 

https://chromium.googlesource.com/chromium/third_party/ffmpeg/

 

And FFMPEG can be built without the "non-free" parts, but you have to build it yourself, and you're not permitted to incorporate it into your program, it can only be Dynamically linked to otherwise it still violates the GPL. Just building it without the non-free parts makes it easier to distribute without liability.

 

Google uses FFMPEG in it's transcoding on youtube. We all know this because it leaves it's fingerprints all over it. Youtube doesn't want to pay MPEG-LA pennies every time someone watches a video subject to the MPEG-LA licence, so that's why they try to force you to watch videos in VP9/AV1 and hide the option to watch it in h264. You can of course upload h265 videos to youtube and it will transcode it into AV1, VP9 and h264, but you can't play the h265 video itself. Most of the time, the video you watch is being transcoded on the fly, because if you upload any video that uses LongGOP (eg the key frames are far apart) it will be unable to seek the video. I know this from experience because videos I uploaded years ago were uploaded with minutes between keyframes because they were uploaded in a lossless format with the assumption that youtube was transcoding the video once, not on the-fly. This was done on purpose, but it also makes the videos impossible to seek, and they used to work at the time they were uploaded.

 

So the situation is that if you want to develop a "free" implementation of h.264, h.265, and so forth, you have to develop it in a way that fulfills the licence obligations of MPEG-LA, and for h264, that means you can only use Cisco's BINARY, which means Cisco has to produce binaries for every platform, operating system and tool that wishes to use it. They can withdraw this at ANY time. Even though they made the code open source, nobody is allowed to compile it but Cisco to meet the obligation of the licence.

 

This is a thing that happens, quite a bit, with dancing around the GPL, if your project gets hijacked by GPL trolls, then you will never be able to sell it ever again. The GPL licence is only useful for protecting tools and software packages that are used to build things. The BSD/MIT licence is better for pretty much everything that has to be embedded in other software/hardware, because that pushes the licence compliance to the one who compiled it, without promising to sue the user of the software for any reason other than stripping the copyright from it.

 

https://github.com/cisco/openh264/blob/master/LICENSE

 

Copyright (c) 2013, Cisco Systems
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this
  list of conditions and the following disclaimer in the documentation and/or
  other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

That is a BSD 2-clause licence.

 

Note how it makes no mention of MPEG-LA licencing.

 

[Bombastinator]

6 minutes ago, Kisai said:

 

The problem with this entire open/closed community-developed vs commercially developed codec is that companies hate losing money and they want the horse they backed to be the winner.

 

This is where capitalism tends to waste a lot of human capital. You don't need to 30 different options when the difference between all of them is who makes money from it. Let things be competitive entirely on "which is technically superior, least expensive to implement" and most privately backed options end up not being the least expensive to implement.

 

What we have with GPLv3 is an actual clause to steal patents.

 

So FFMPEG is GPL 2 "or later", which applies. Nearly every "free implementation" of a codec is part of FFMPEG. Including that of Google Chrome. So that means the implementation of h264, h265, vp8, vp9, av1, etc is subject to this license

 

https://chromium.googlesource.com/chromium/third_party/ffmpeg/

 

And FFMPEG can be built without the "non-free" parts, but you have to build it yourself, and you're not permitted to incorporate it into your program, it can only be Dynamically linked to otherwise it still violates the GPL. Just building it without the non-free parts makes it easier to distribute without liability.

 

Google uses FFMPEG in it's transcoding on youtube. We all know this because it leaves it's fingerprints all over it. Youtube doesn't want to pay MPEG-LA pennies every time someone watches a video subject to the MPEG-LA licence, so that's why they try to force you to watch videos in VP9/AV1 and hide the option to watch it in h264. You can of course upload h265 videos to youtube and it will transcode it into AV1, VP9 and h264, but you can't play the h265 video itself. Most of the time, the video you watch is being transcoded on the fly, because if you upload any video that uses LongGOP (eg the key frames are far apart) it will be unable to seek the video. I know this from experience because videos I uploaded years ago were uploaded with minutes between keyframes because they were uploaded in a lossless format with the assumption that youtube was transcoding the video once, not on the-fly. This was done on purpose, but it also makes the videos impossible to seek, and they used to work at the time they were uploaded.

 

So the situation is that if you want to develop a "free" implementation of h.264, h.265, and so forth, you have to develop it in a way that fulfills the licence obligations of MPEG-LA, and for h264, that means you can only use Cisco's BINARY, which means Cisco has to produce binaries for every platform, operating system and tool that wishes to use it. They can withdraw this at ANY time. Even though they made the code open source, nobody is allowed to compile it but Cisco to meet the obligation of the licence.

 

This is a thing that happens, quite a bit, with dancing around the GPL, if your project gets hijacked by GPL trolls, then you will never be able to sell it ever again. The GPL licence is only useful for protecting tools and software packages that are used to build things. The BSD/MIT licence is better for pretty much everything that has to be embedded in other software/hardware, because that pushes the licence compliance to the one who compiled it, without promising to sue the user of the software for any reason other than stripping the copyright from it.

 

https://github.com/cisco/openh264/blob/master/LICENSE

 

Copyright (c) 2013, Cisco Systems
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this
  list of conditions and the following disclaimer in the documentation and/or
  other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

That is a BSD 2-clause licence.

 

Note how it makes no mention of MPEG-LA licencing.

 

All I got out of that was “it’s complicated”

[Kisai]

28 minutes ago, Bombastinator said:

All I got out of that was “it’s complicated”

Let's go for a silly analogy.

 

Team A, is baking cookies

Team B, is baking brownies

Team C, is baking cookies with brownie stuffing

 

Now on the surface, Team C is producing the better product, because it incorporates the features of Team A and Team B. Thus if no patents were involved, Team C would ultimately win.

 

But now let's say Team A has patents on "cookie" and Team B has patents on "Brownie"

Team C can't sell their product at all because it would stomp on the patents that Team A and Team B hold. This basically the situation with AV1.

 

Now Team A and Team B decide to form a pact where they will not sue each other, but will sue anyone who makes cookies or brownies. So this prevents any other teams from making any of Team A B or even C's products.

 

So in order to solve this, Team C has to get both Team A and Team B to promise to not sue them. So in order to do that Team C's cookies with brownie stuffing must cost more than Team A and Team B's combined, even if the materials costs are equal. 

 

Now the situation with h264, is that Team A basically said that it won't sue anyone, and nobody can be sued since it paid the maximum amount to everyone who has a claim on the cookie recipe. So everyone come use Team A's cookies for cheap, since Team B's is more expensive, and Team C's impossible to use without being sued into oblivion.

 

So where we are in the "present" time is that Team A is contributing to Team C's efforts, but Team B is not onboard.

 

This analogy ignores every aspect about patents except the lawsuit bait. So don't even start.

[LAwLz]

On 7/11/2020 at 1:01 AM, Kisai said:

Team C can't sell their product at all because it would stomp on the patents that Team A and Team B hold. This basically the situation with AV1.

No, that's not the situation AV1 is in because AV1 does lot infringe on any patents. Sisvel, a known patent troll, claims that they have patents that AV1 infringes on but has so far not provided any evidence, just empty threats. 

 

Lawyers from Microsoft, Mozilla, Google and many others have all looked over AV1 to ensure that it is written in such a way that it does not infringe on other patents. 

It's very important to remember that AV1 is basically backed up by the legal teams of all major companies in the industry. There is a lot of FUD trying to be spread by opponents because they want AV1 to fail and proprietary codecs to be the default (since that makes them money) but don't let that scare you. 

 

 

The companies behind proprietary formats have time and time again tried the same techniques.

Theora starts becoming a real threat to their marker share? Threaten people who use it into paying us money instead! 

VP8 starts becoming a real threat to their marker share? Threaten people who use it into paying us money instead! 

VP9 starts becoming a real threat to their marker share? Threaten people who use it into paying us money instead! 

The difference this time is that AV1 is not just some random competitor developed by one or maybe two companies. It's the entire industry doing S revolt against MPEG. Even the co-founder of MPEG says that it might be time for MPEG to disappear and AOMedia with AV1 has filled the role of future MPEG formats already. I linked to his blog about it earlier. 

Edited July 12, 2020 by colonel_mortis
Remove an unnecessary and off topic comment

[Kisai]

1 hour ago, LAwLz said:

No, that's not the situation AV1 is in because AV1 does lot infringe on any patents. Sisvel, a known patent troll, claims that they have patents that AV1 infringes on but has so far not provided any evidence, just empty threats. 

 

 

Doesn't matter. If someone says "we will sue you" there's nobody out there going "yep, do it asshole so we can own you"

 

Mitsubishi already bought into their licence pool, so if anything, they added legitimacy to their claim.

https://rethinkresearch.biz/articles/aomedia-will-relent-to-fair-av1-patent-licensing-program/

Quote

Sisvel expects as many as 2,000 patents submitted for license relating to AV1 and a further 1,000 for VP9.

 

Sisvel CEO Mattia Fogliacco is confident that AOMedia members will relent. “When AOMedia looks at the list of the members we represent, they will realize that the reality is quite a bit different compared to what they imagine it to be. They will realize that the pricing is fair and that we did a thorough job of internal screening with accredited third parties and by our own technical domain experts in establishing a technical foothold for the patents,” he said.

 

Of all 14 current members, Faultline most recently spoke with InterDigital a few weeks back. We noted how at MWC 2019, InterDigital exuded an aura of being unfazed by uptake of AV1. A year later and with the likes of Netflix adopting AV1, we were unsurprised to hear that InterDigital’s stance has hardly changed. “MPEG is not going anywhere anytime soon,” stressed CTO Henry Tirri.

 

Meanwhile, when the AV1 patent pool was formed last year, AOMedia criticized it for “endorsing an environment of high patent royalty requirements and licensing uncertainty” that “would limit the potential of free and open online video technology.”

 

http://www.digitaltvnews.net/?p=34317

Quote

LUXEMBOURG — Sisvel International S.A. announced today nine new members to its Video Coding Licensing Platform, bringing the total number of technology companies participating to 14.

The platform, which launched in March 2019, includes two, separately offered licensing programs for patents relevant to the VP9 and AV1 video coding formats.

New member companies span industries including telecommunications, audio and video, R&D institutes and more:

• Dolby
• Electronics and Telecommunications Research Institute (ETRI)
• Ericsson
• GE
• InterDigital
• IP Bridge
• NTT Docomo
• SK Telecom
• Xylene*

“Today’s announcement marks a tremendous moment for patent pools, patent owners and implementers,” said Mattia Fogliacco, CEO of Sisvel. “Throughout its history, Sisvel has consistently promoted sensible patent pools and IP policies that are fair to implementers and innovators alike, and we are proud to offer a new suite of technology in a transparent, consolidated platform for companies looking to license and implement VP9 and AV1 technology.”

 

Companies participating in these pools have played pivotal roles in defining video coding technologies. Existing members of these Sisvel licensing programs include:

• JVCKENWOOD
• NTT
• Orange
• Philips
• Toshiba Business Expert Corporation

...

*Xylene is Mitsubishi

So far that basically covers mostly the who's who of home theater equipment and major telcos in Korea and Japan. 

 

You can pretend all you want that patents don't exist. You're still wrong.