Announcement

Collapse
No announcement yet.

Mesa Can Now Be Built With Select Video Codecs Disabled For Software Patent Concerns

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by billyswong View Post
    Such nightmare is no good for both the patent owners and end users. Patent fee not paid and end users avoid patented codec at the end.
    Exactly yet very little effort goes into fixing the problem correctly. Also remember particular countries different patent pools don't legally apply either. Yes again no documentation on the device on what is paid the user does not know its not paid. The reality is a correctly fixed system user could know that X is not paid and if they are using X buy X license.

    Lot of people incorrectly presume that patent pools have sane licensing designs. The reality is majority of them their licensing is mega flawed.

    One of the worst cases of mega flawed was the 3 mp3 patent pools where they were all claiming. Yes there was basically no mp3 device that was legally paid up the complete time as most just paid one patent pool or another and hoped the other 1 would not take them to court and 2 that there was something in pool they signed up for would cause a mutually assured destruction in case of legal case so cause a settlement. Yes this is a historic example of stupid but we have modern day patent pool the same that are basically playing cold war game methods to patent licensing.

    Patent licensing on products is a pure mess. There is no need for it to be this kind of mess.

    Leave a comment:


  • billyswong
    replied
    Originally posted by oiaohm View Post

    This is when you know the MPEG-LA stuff you know its a mess. Yes AMD and Intel should be paying for the H264 in the CPU chips they release directly to public. But for the GPU cards that are assembled by board partners since it has their brand on it by MPEG-LA rules AMD. Intel and Nvidia don't have to pay instead the board partners have to pay. Now it gets worse you are buying OEM system from Dell/HP since they are putting their brand on it the board partner can choose not to pay so have the OEM pay. All this choosing not to pay if someone else could is part of the MPEG-LA patent pools.

    Of course we don't have details when we by this stuff on what has been paid. This is a big legal problem. We really should get a statement when we by a phone/computer.... saying what patent pools have been paid . It really possible with H264 to have a case where everyone says we thought someone else was paying the H264 so on X hardware nobody did because there are so many different parties who could pay and its not mandatory for those to pay if they believe their supplier already paid or who they are supplying to is going to pay(yes we have the classic chicken and egg problem). Remember just like we did not get any documentation when we bought the device on what patent pools were paid the same happens when OEM and ODM buy parts This is not the only patent pool group like this. This is like the push we have with open source to get businesses to properly track their open source usage.

    Royalty free do have advantage here that you know the stuff is paid for end users. Silicon makers may be having to still pay a design patent for the silicon encoder/decoder design(yes that a per unit payment no time frames) but that is not a end user problem with Royalty free codecs.

    Yes the Royalty-based codec with the current rules they use are a pure nightmare to know if you have paid up hardware or not. Of course you can expect one day to come where the Royalty-based codec patent pools get upset they are not getting enough payments and start going after those who are not paid up.

    I remember when there was a patent requirement in the USA for items using a patent to have the patent number on them and that patent number could only be there if the patent payments was in fact paid this requirement was removed leading to today problem of not knowing what in heck is paid.
    Such nightmare is no good for both the patent owners and end users. Patent fee not paid and end users avoid patented codec at the end.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by RAMChYLD View Post
    On that note, if the hardware ASIC on the GPU is the one doing the encoding or decoding, does the patent matter? Since I assume for AMD, NVidia and Intel to put the H264 codec into the ASIC, they must've already paid to MPEG-LA?
    This is when you know the MPEG-LA stuff you know its a mess. Yes AMD and Intel should be paying for the H264 in the CPU chips they release directly to public. But for the GPU cards that are assembled by board partners since it has their brand on it by MPEG-LA rules AMD. Intel and Nvidia don't have to pay instead the board partners have to pay. Now it gets worse you are buying OEM system from Dell/HP since they are putting their brand on it the board partner can choose not to pay so have the OEM pay. All this choosing not to pay if someone else could is part of the MPEG-LA patent pools.

    Of course we don't have details when we by this stuff on what has been paid. This is a big legal problem. We really should get a statement when we by a phone/computer.... saying what patent pools have been paid . It really possible with H264 to have a case where everyone says we thought someone else was paying the H264 so on X hardware nobody did because there are so many different parties who could pay and its not mandatory for those to pay if they believe their supplier already paid or who they are supplying to is going to pay(yes we have the classic chicken and egg problem). Remember just like we did not get any documentation when we bought the device on what patent pools were paid the same happens when OEM and ODM buy parts This is not the only patent pool group like this. This is like the push we have with open source to get businesses to properly track their open source usage.

    Royalty free do have advantage here that you know the stuff is paid for end users. Silicon makers may be having to still pay a design patent for the silicon encoder/decoder design(yes that a per unit payment no time frames) but that is not a end user problem with Royalty free codecs.

    Yes the Royalty-based codec with the current rules they use are a pure nightmare to know if you have paid up hardware or not. Of course you can expect one day to come where the Royalty-based codec patent pools get upset they are not getting enough payments and start going after those who are not paid up.

    I remember when there was a patent requirement in the USA for items using a patent to have the patent number on them and that patent number could only be there if the patent payments was in fact paid this requirement was removed leading to today problem of not knowing what in heck is paid.

    Leave a comment:


  • leigh123linux
    replied
    Originally posted by STiAT View Post

    Fedora may still opt to drop them and have rpmfusion again to maintain that part if it can be split, but legally distributing them would not be an issue.
    There is little to no interest at rpmfusion to package and maintain it, also keeping the repo in sync with fedora isn't a priority for me.

    Leave a comment:


  • Quackdoc
    replied
    apologies im on mobile

    Originally posted by RAMChYLD View Post
    I wish. I don't know if Youtube, Facebook and Twitch accept AV1. I'm not even sure if my upstream aggregator (restream.io) accept AV1.
    what is there to wish? youtube does, faceboom and twitch are working on it. though thats a pretty poor basis for av1 adoption. device playback and video encode support matters far more then that.

    av1 encode is already fast enough to compare to hevc in terms of qualityreformance. is easier software decoding. all major vendors are getting decode support and rummored encode support. all major platforms have video players that can play regardless of platform status. (sorry specific samsung/LG smart TVs) av1 is already used in video conference software.

    av1 adoption needs no wishes, only time.

    And lastly, OBS certainly doesn't appear to support anything except H264- my only options on OBS are x264 (software) and VAAPI H264 (hardware accelerated). This bothers me extra because I do use VAAPI H264 GPU acceleration to stream.
    OBS already has beta support for AV1
    EDIT: quality : preformance., is there anyway to disable these blasted emoji things permanently?

    Leave a comment:


  • RAMChYLD
    replied
    Originally posted by Quackdoc View Post
    This is good, now we can propel AV1 adoption to even greater heights
    I wish. I don't know if Youtube, Facebook and Twitch accept AV1. I'm not even sure if my upstream aggregator (restream.io) accept AV1. And lastly, OBS certainly doesn't appear to support anything except H264- my only options on OBS are x264 (software) and VAAPI H264 (hardware accelerated). This bothers me extra because I do use VAAPI H264 GPU acceleration to stream.

    On that note, if the hardware ASIC on the GPU is the one doing the encoding or decoding, does the patent matter? Since I assume for AMD, NVidia and Intel to put the H264 codec into the ASIC, they must've already paid to MPEG-LA?

    Maybe AMD can be the good guy and foot the bill for all AMD GPU owners?

    As for Cisco, good guy to them (they're also ClamAV's current owner if people aren't already aware). But yeah, Cisco's codec is a software solution, thing is I'd like to use VAAPI on my GPU to encode my stream. I paid several thousand Malaysian Ringgits for my GPU, surely I've paid up to use the codec in the ASIC as part of the price?

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by carewolf View Post

    It is a precompiled version of openh264 offered by Cisco where they have already paid the license once. See https://brendaneich.com/2013/10/ciscos-h-264-good-news/
    I dunno if that would be considered a work around lol, but I guess

    Leave a comment:


  • carewolf
    replied
    Originally posted by Quackdoc View Post

    im not familiar with the work around, any enlightenment? but I am familiar with compiling mesa don't get me wrong, (testing rusticl, thank you aur). but it's not always the greatest experience on some setups for sure. (building mesa on a cellphone in a proot env is not fun lul)
    It is a precompiled version of openh264 offered by Cisco where they have already paid the license once. See https://brendaneich.com/2013/10/ciscos-h-264-good-news/

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by carewolf View Post

    Some already do, others use the cisco binary work around.
    im not familiar with the work around, any enlightenment? but I am familiar with compiling mesa don't get me wrong, (testing rusticl, thank you aur). but it's not always the greatest experience on some setups for sure. (building mesa on a cellphone in a proot env is not fun lul)

    Leave a comment:


  • carewolf
    replied
    Originally posted by Quackdoc View Post

    for some reason, I don't see distros doing this that will ending well
    Some already do, others use the cisco binary work around.

    Leave a comment:

Working...
X