EndeavourOS, H264/H265 on long run

General system Kernel, boot, graphics & hardware
1

Legal Issues

As long time users of Debian may know, there has been a long history of legal concerns when it comes to using various multimedia related software due to software patents. Because of this, various multimedia codecs could not be made available within Debian. However, Debian’s position on software patents has changed, resulting in the inclusion of these various multimedia codecs within Debian.

For information on Debian’s position with regards to software patents, see the following.

As with any topic involving legal issues, if you have any legal concerns, it is recommended you seek your own legal counsel.
– https://wiki.debian.org/MultimediaCodecs#Legal_Issues

I understand that it is a PIA when you have hardware capable of doing the hard work and then your encoding tasks takes multitude longer to encode and your youtube video are delayed for hours while the content is compressing using CPU instead of GPU.

Building mesa yourself - enabling the codecs - depending on hardware it is anything between 5-35 minutes - so to me possible absence is not an issue.

As I see it

  • and why I bring it up
  • knowing it is it’s a touchy subject
  • please forgive me
  • what is the difference
  • with respect to the legal position
  • when it comes to connecting the dots
  • the final piece in the puzzle

between

  1. Fedora
  2. openSuSE
  3. Manjaro
  4. EndeavourOS
  5. KaOS
  6. … numerous other distros

EndeavourOS is in the same position as Manjaro - as it is last link in the chain connecting the dots - the last piece in the puzzle - the turnkey solution enabling H264 and H265 hardware encoding/decoding in the mesa library.

With reference to forum topics [1] [2] and the debate on Manjaro forum on the subject of copyrighted codecs and the thin grey line between legal or infringing.

As I understand this fine line it has something to do with being the last link in the chain that enables hardware encoding/decoding for AMD GPU - thus making the last link responsible for the fees due to the copyright holders.

I also understand it has become an issue because some smart business people has made it their business to collect those tiny fees for copyright holders - and everyone holding a copyright is per defnition greedy - that is a gross statement - perhaps not - in any case.

I understand that Arch itself may have a point in their stance providing access to H264/H265 (and derivatives)

  1. it has never been a problem - why make it one
  2. Arch has never provided a turnkey solution thus providing the option in the mesa build has never been that last link in the chain.

The topic is quite hot - judging from a search - just for debian

Other than using Arch repos - what distinguishes EndeavourOS from other mainstream distributions with relation to upstream mesa - excluding H264 etal. from the compile process - that entitles EndeavourOS to include H264 etal.

2

while I find it good that Arch decided to keep H264/H265 enabled (EndeavourOS does not maintain its own repos, it simply uses Arch repos and thus does not have to decide whether to enable or disable it)

I think that H264/H265 looses its relevance already. Youtube already uses VP9/VP8 and so do many other streaming services. Personally, I don’t think that I would be hit by disabling it as everything I use does not use H264/H265 any more.

3

H264/H265 are still largely used to this day, especially in the movies industry. Many streaming services use these encodings and will most likely continue to use them for the foreseeable future.

That being said, I don’t see a real potential problem with Arch or its derivatives, if the Arch devs decide to no longer ship Mesa with the proprietary codecs enabled I bet that the very next day we will see a new AUR package recompiled with the codecs enabled, if Endeavour decides to maintain its own version of Mesa with the codecs disabled (like Manjaro is doing) we can simply install the Arch version from Arch repos. So I don’t really think it’ll be a problem for Arch and it’s derivatives (except for Manjaro since it uses its own repos).

1 Like
4

not true anymore. The biggest streaming service Youtube uses VP9/8. The biggest movie/series streaming service Netflix switched to VP9 some years ago and is in the process of going to AV1.
Twitch also went to VP9 years ago. Amazon Prime also uses VP9 since 2020.

Their reason is that VP9 and AV1 are more energy efficient and energy costs are the biggest expense in hosting such services.

5

I absolutely love VP9 / AV1 and all that new jazz.
However…Disabling it in Mesa is kinda nuts to me, although i get devs concerns.

H264/H265 are used in all blu-rays, and i’m fan of:

  1. Private property
  2. Original media (not re-encoded with quality loss)

So making it pain in the butt to use by default is…questionable solution.

1 Like
6

Thanks, I didn’t know that, I thought that both Netflix and Prime were still using H264/5 for their services, good to hear that they switched. Still tho, some old movies and TV Series from yesteryear which you might have lying around might be using these proprietary codecs. The version of Better Call Saul that I’ve been watching during the holidays for example uses H265, I also think that some old games cinematics might be using these codecs.
All in all I guess that in 2022 it’s not that important, but it’s a functionality I’d rather have than not.

7

Twitch is currently h.264 only?

1 Like
8

well, I only checked on Google:

twitch
twitch721×680 92 KB

9

Twitch uses max. 1080p and H264 (AVC) by default. But there is no 1440p and no 4K.

Screenshot_20230111_160821
Screenshot_20230111_160821575×537 48.7 KB

Every CPU runs fine with H264 decoding without hardware acceleration. Because H264 decoding effort is very low. Twitch uses live stream always 1x speed decoding only. there is no more than 1x speed decoding or no 10x speed.

10

I remember now, they talked about it, but it never materialized.