I hope the future is bright with AV1. But even scene groups heavily release in 265 instead of AV1. Hardware support is going to get better over the years and hopefully everyone will just use AV1 and leave this license BS behind.
> But even scene groups heavily release in 265 instead of AV1.
I believe this is because scene groups don't really care about patent licensing, and there's around 5-6 years of computers with hardware H.265 decoding and no hardware AV1 decoding. I think we'll see AV1 and successors take over in 5-10 years when it's safer to assume users will have AV1 decoding.
I bought an Intel Arc A580 and then later B580 which also has an AV1 hardware encoder, and I have to say that it's really pleasant, good enough for real time streaming, video recording even at lower bitrates (e.g. 1080p30 at ~10 Mbps is okay) and ends up saving a lot of space when compared to both H264 and H265, which previously wasn't viable because the CPU based encoder is painfully slow.
I saved a few hundred GB of space by re-encoding all of my local videos in AV1, I'm guessing it might be have been one of the better cases because most of the videos were anime instead of more detailed video like regular movies, but it worked out nicely for me! Plus, the software support is also quite good: OBS and Handbrake had no issues, neither does VLC seem to have any.
All of that makes me wish it'd become more widespread in the next decade or so, everywhere from YouTube and Twitch to even our phone cameras.
FWIW Most Streaming TV Services like Zattoo do 1080p50 using H264 using that Bitrate and while not perfect it's fine - using AV1 one could probably go way below that.
1080p30 at ~10 Mbps isn't a low bitrate unless you are aiming for something very specific. Not to mention there is H.265 hardware encoder inside Intel Arc, although I have no idea about their quality. Nvidia seems to do a much better job in this area.
My guess is you were using the reference AOM encoder. This is actually a real branding problem! It was never designed for encoding speed, and it shows.
SVT-AV1 is the production encoder you should be using. It's high quality and fast in software, and should really always be the default.
For now most of the focus has been on the slow encodes, but in theory it can match h264 for speed and quality on encoding. In practice I've seen it get very close already.
Of h.264, h.265, vp8, vp9, and av1, h.264 is the only codec with consistent support across all of chat/messaging clients, browsers, smart TVs/phones, tablets, and streaming devices. The population of active, supported devices and software is much larger and much older than people realize. As such, it remains the only viable video codec if you don't want to be forced to provide multiple encodings.
Isn't it already patent free in Europe? You can't patent algorithms in Europe. For example MP3 was royalty free in Europe because there was no patent on it.
Too often the organisation behind projects is in the US, so is restricted to only what is legal in the US.
I suspect that’s the case here. IIRC, the Freedesktop servers are hosted in the US, so are also affected by what’s legal there too.
And in this case, they were shipping a userspace for their sandboxes, which is a dependency for many others. If it contains code that cannot be distributed in the US, then anyone in the US will have to pick an alternative.
It is possible to do something like webrtc without using one of h264 or h265 and have it work on all browser versions ?
Normally, apple quicktime containers with h264 payloads are playable everywhere. If you drop h264 or h265 there is no such play anywhere container available anymore right ?
VP8 should be required by the base WebRTC spec, but some devices only have hardware acceleration for H.264 so you should test the actual performance before changing codecs. Also consider using VP9 / AV1 if you know all the devices in a call support it and are fast enough to encode/decode it.
> Which codecs can be within those tracks is not mandated by the WebRTC specification. However, RFC 7742 specifies that all WebRTC-compatible browsers must support VP8 and H.264's Constrained Baseline profile for video, and RFC 7874 specifies that browsers must support at least the Opus codec as well as G.711's PCMA and PCMU formats.
Correct. The most supported container and codec families are those coming out of the MPEG - .mp3, .m4a, .mp4, H.264, H.265 etc. - because they are the products of a giant standards effort. A lot of modern TVs and set-top boxes will accept content in e.g. the Matroska container, and VP/AV video content, but unfortunately support still isn't at the level of the MPEGs.
The binary would be downloaded on the end user’s machine, inside a sandbox and then the “recipe” would be executed to create a working extension. This avoids various “redistribution” restrictions entirely since we aren’t shipping the binary itself.
That makes me wonder, why not just download the source code and compile it. You're definitely not distributing any binaries that way.
As I understand it, Cisco licenses the relevant patents and sublicenses them gratis to every user who uses Cisco’s binaries obtained from Cisco directly and not redistributed (thus also the difficulties in the article with working with Cisco’s unmaintained web server). The sublicense doesn’t apply to binaries built independently from source. I suppose this was imposed by the patent holders.
Can that library be rebuilt in a reproducible manner? If so, what's the difference between the library hosted by Cisco and a locally built one that is identical bit-for-bit? Is there any mechanism to ensure that the library was genuinely downloaded from Cisco rather than procured through alternative channels? If the Cisco server is turned off tomorrow, how can one tell if a copy of the library wasn't downloaded from the Cisco server while it was available?
I'm most likely missing a lot of crucial context, but it appears to me that this peculiar licensing scheme was a compromise made between lawyers that makes little practical sense on a technical level. That, or I'm far too chaotic for such nonsense.
Readit News
I believe this is because scene groups don't really care about patent licensing, and there's around 5-6 years of computers with hardware H.265 decoding and no hardware AV1 decoding. I think we'll see AV1 and successors take over in 5-10 years when it's safer to assume users will have AV1 decoding.
I bought an Intel Arc A580 and then later B580 which also has an AV1 hardware encoder, and I have to say that it's really pleasant, good enough for real time streaming, video recording even at lower bitrates (e.g. 1080p30 at ~10 Mbps is okay) and ends up saving a lot of space when compared to both H264 and H265, which previously wasn't viable because the CPU based encoder is painfully slow.
I saved a few hundred GB of space by re-encoding all of my local videos in AV1, I'm guessing it might be have been one of the better cases because most of the videos were anime instead of more detailed video like regular movies, but it worked out nicely for me! Plus, the software support is also quite good: OBS and Handbrake had no issues, neither does VLC seem to have any.
All of that makes me wish it'd become more widespread in the next decade or so, everywhere from YouTube and Twitch to even our phone cameras.
FWIW Most Streaming TV Services like Zattoo do 1080p50 using H264 using that Bitrate and while not perfect it's fine - using AV1 one could probably go way below that.
SVT-AV1 is the production encoder you should be using. It's high quality and fast in software, and should really always be the default.
I suspect that’s the case here. IIRC, the Freedesktop servers are hosted in the US, so are also affected by what’s legal there too.
And in this case, they were shipping a userspace for their sandboxes, which is a dependency for many others. If it contains code that cannot be distributed in the US, then anyone in the US will have to pick an alternative.
Think they just moved to Hetzner.
Formerly MP3 (expired 2017), MPEG-H Audio, xHE-AAC, EVS, LC3/LC3plus, Symphoria, Sonamic and upHear
Normally, apple quicktime containers with h264 payloads are playable everywhere. If you drop h264 or h265 there is no such play anywhere container available anymore right ?
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Fo...
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Fo...
That makes me wonder, why not just download the source code and compile it. You're definitely not distributing any binaries that way.
I'm most likely missing a lot of crucial context, but it appears to me that this peculiar licensing scheme was a compromise made between lawyers that makes little practical sense on a technical level. That, or I'm far too chaotic for such nonsense.
Why hasn’t canonical been sued by MPEG-LA et.al? Are they no redistributing compiled FFMPEG for commercial purpose?