Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
I'd like to ask: - Can somebody elaborate on reasons to change something that was working in Fedora for some time already? - Is there any short/mid/long term plan to improve the situation? - Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
Thanks!
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. Dave.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
The last might be possible, but I'm not sure how to go about it.
Another consideration would be to somehow gate at least the h264 bits on having openh264 installed, since then in theory a system consuming h264 formats would be covered.
Dave.
Once upon a time, David Airlie airlied@redhat.com said:
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
But isn't this just providing for hardware decoding, where (presumably) the hardware vendor arranged for whatever needed licenses?
On Tue, Sep 27, 2022 at 8:11 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, David Airlie airlied@redhat.com said:
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
But isn't this just providing for hardware decoding, where (presumably) the hardware vendor arranged for whatever needed licenses?
It's really not that simple, IANAL but AFAICT the licensing costs comes down to who provides a complete solution, the HW doesn't provide that so they may not be required to arrange the licenses.
P
On Wed, Sep 28, 2022 at 5:11 AM Chris Adams linux@cmadams.net wrote:
Once upon a time, David Airlie airlied@redhat.com said:
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
But isn't this just providing for hardware decoding, where (presumably) the hardware vendor arranged for whatever needed licenses?
The presumably is wrong. hw vendors do not cover the license costs for the patents.
Dave.
On 9/27/22 1:56 PM, David Airlie wrote:
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented functionality.
If simply handling the bitstream is a violation like you say then glibc/kernel could be patent infringing with an open() call. Let's not get that silly.
On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth mike@cchtml.com wrote:
On 9/27/22 1:56 PM, David Airlie wrote:
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented functionality.
If simply handling the bitstream is a violation like you say then glibc/kernel could be patent infringing with an open() call. Let's not get that silly.
The implicit IANAL is very clear here.
Dave.
On Wed, 28 Sep 2022 05:36:01 +1000 David Airlie airlied@redhat.com wrote:
On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth mike@cchtml.com wrote:
On 9/27/22 1:56 PM, David Airlie wrote:
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems.
How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented functionality.
If simply handling the bitstream is a violation like you say then glibc/kernel could be patent infringing with an open() call. Let's not get that silly.
The implicit IANAL is very clear here.
the topic has already been opened on the legal list in https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
Dan
On 9/27/22 2:36 PM, David Airlie wrote:
The implicit IANAL is very clear here.
I wish you had started the discussion the legal list yourself prior to the git commit.
A certain website that monitors this mailing list is probably already preparing to post how Fedora 37 is no longer going to work with popular video codecs. Once that post is made the Internet will take that story and bend it a few ways to make us look bad.
On Tue, Sep 27, 2022 at 9:53 PM Michael Cronenworth mike@cchtml.com wrote:
On 9/27/22 2:36 PM, David Airlie wrote:
The implicit IANAL is very clear here.
I wish you had started the discussion the legal list yourself prior to the git commit.
A certain website that monitors this mailing list is probably already preparing to post how Fedora 37 is no longer going to work with popular video codecs. Once that post is made the Internet will take that story and bend it a few ways to make us look bad.
Phoronix already covered it being deactivated in Mesa upstream by default: https://www.phoronix.com/news/Mesa-Optional-Video-Codecs
Unfortunately, we have to be very careful to not provide a complete codepath to these codecs to avoid legal risks.
(Of course IANAL)
-- 真実はいつも一つ!/ Always, there's only one truth!
Neal Gompa wrote:
Unfortunately, we have to be very careful to not provide a complete codepath to these codecs to avoid legal risks.
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
Kevin Kofler
On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Neal Gompa wrote:
Unfortunately, we have to be very careful to not provide a complete codepath to these codecs to avoid legal risks.
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Lack of legal action is not evidence of no further legal action. There are multiple possible explanations:
- they see no point because going after distros would waste time and money and bring bad PR - going after Redhat who would assume liability is a different story as they’re a Fortune 500 company - they or some other company (through merger or acquisition) may suddenly decide to patent troll
That and the Streisand effect makes this accident more public which draws attention and scrutiny.
Lack of legal action is not evidence of no further legal action. There are multiple possible explanations:
- they see no point because going after distros would waste time and money and bring bad
PR
- going after Redhat who would assume liability is a different story as they’re a Fortune
500 company
- they or some other company (through merger or acquisition) may suddenly decide to patent
troll
That and the Streisand effect makes this accident more public which draws attention and scrutiny.
I think the hardware vendors shipping fedora should be concerned about the patents.
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Provision_for_cos...
On 29 Sep 2022, at 12:52, Tommy Nguyen remyabel@gmail.com wrote:
On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Neal Gompa wrote:
Unfortunately, we have to be very careful to not provide a complete codepath to these codecs to avoid legal risks.
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Lack of legal action is not evidence of no further legal action. There are multiple possible explanations:
- they see no point because going after distros would waste time and money and bring bad PR
- going after Redhat who would assume liability is a different story as they’re a Fortune 500 company
- they or some other company (through merger or acquisition) may suddenly decide to patent troll
For a really nasty explanation:
- Red Hat would fight back, so they’re only going after downstream distributors who won’t fight back, and as part of settling, you sign an NDA so that upstream Fedora (us!) never finds out that downstream distributors are being shaken down for money.
This would imply that there’s been lots of legal trouble, we’ve just never heard of it. — Simon Farnsworth
Neal Gompa wrote:
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
Kevin Kofler
Just because it hasn't happened yet doesn't mean it can't. I found this link very informative on the subject.
https://streaming4thepoor.live/as-a-small-business-must-i-pay-royalties-for-...
The unlikely happens all the time, I still can't believe the result in the Johnson & Johnson 'Talc' case.
Kevin Kofler via devel wrote:
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
The entire codec patent business is absolutely ridiculous. Such is the reality we must live in.
Björn Persson
On Fri, 30 Sep 2022 22:19:44 +0200 Björn Persson Bjorn@xn--rombobjrn-67a.se wrote:
Kevin Kofler via devel wrote:
Considering that we have been shipping these hardware codec interfaces for years without any legal trouble, I find this absolutely ridiculous.
The entire codec patent business is absolutely ridiculous. Such is the reality we must live in.
Given the speed which digital development moves, those patents, if they exist at all, should be no more than 5 years. As it is, rather than speed up the rate of innovation, the whole justification for patents, they are slowing and restricting the rate of innovation in this area.
In the digital space, the cost of development is low, so that the innovation that those patents are issued for would be discovered in the course of general research without the patent holder. There are often conflicts of who has first discovered some innovation, resolved by first to file, showing the lack of need for patents at all.
On Wed, Sep 28, 2022 at 5:53 AM Michael Cronenworth mike@cchtml.com wrote:
On 9/27/22 2:36 PM, David Airlie wrote:
The implicit IANAL is very clear here.
I wish you had started the discussion the legal list yourself prior to the git commit.
A certain website that monitors this mailing list is probably already preparing to post how Fedora 37 is no longer going to work with popular video codecs. Once that post is made the Internet will take that story and bend it a few ways to make us look bad.
The thing is we've had this ruling in place forever, a lot of people misunderstood it, I only recently educated myself on the topic.
HW vendors do not pay for patents. The legal list posting above is a perfect example of why technical people should not play at being lawyers.
Think of it like a jigsaw puzzle, where the person who places the last piece in the puzzle pays the license. But then stop thinking of it like that and just assume it's a lot vaguer and way more legally involved than that.
Dave.
On Tue, Sep 27, 2022 at 8:06 PM David Airlie airlied@redhat.com wrote:
Think of it like a jigsaw puzzle, where the person who places the last piece in the puzzle pays the license. But then stop thinking of it like that and just assume it's a lot vaguer and way more legally involved than that.
So, for CPU's with iGPUs sold retail to people like me, does Intel (and now including AMD) include the IP license? If not, how can I get one from Intel (who sold me a CPU/iGPU that states it can decode the codecs in question)?
On Thu, Sep 29, 2022 at 4:43 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Tue, Sep 27, 2022 at 8:06 PM David Airlie airlied@redhat.com wrote:
Think of it like a jigsaw puzzle, where the person who places the last piece in the puzzle pays the license. But then stop thinking of it like that and just assume it's a lot vaguer and way more legally involved than that.
So, for CPU's with iGPUs sold retail to people like me, does Intel (and now including AMD) include the IP license? If not, how can I get one from Intel (who sold me a CPU/iGPU that states it can decode the codecs in question)?
You will have to read the legal documentation for yours, but I'll say my i7-6700 didn't provide a statement of patent license that I could find.
-- 真実はいつも一つ!/ Always, there's only one truth!
On 9/28/22 22:42, Gary Buhrmaster wrote:
So, for CPU's with iGPUs sold retail to people like me, does Intel (and now including AMD) include the IP license? If not, how can I get one from Intel (who sold me a CPU/iGPU that states it can decode the codecs in question)?
To be pedantic... the CPU manufacturer claims that the GPU/iGPU provides *acceleration* for decoding of content that has been encoded with the codecs in question. The distinction is important, because the GPU/iGPU cannot do the job on its own, software is required to set it up, feed the data in the right format, and other things, and as has been noted in this thread earlier it's the final combination that appears to trigger patent infringement.
A patent lawyer could probably make the case that if the functionality in the GPU/iGPU has no other useful purpose *except* for decoding this type of content, then the hardware alone is infringing, but that's a totally different discussion. Since Intel and AMD employ large numbers of highly-trained patent lawyers, presumably they've decided that they do not need to address this concern.
On Thu, Sep 29, 2022 at 12:56 PM Kevin P. Fleming kpfleming@redhat.com wrote:
On 9/28/22 22:42, Gary Buhrmaster wrote:
So, for CPU's with iGPUs sold retail to people like me, does Intel (and now including AMD) include the IP license? If not, how can I get one from Intel (who sold me a CPU/iGPU that states it can decode the codecs in question)?
To be pedantic...
Fair enough (pedantic is fine), but my original question was more how can I obtain such a license.
It's very disappointing that Fedora will now be permanently crippled for a huge amount of video content. If Red Hat is largely alone in believing that this a credible legal risk, then ultimately this change will reflect poorly on the distribution regardless of any articles written.
I hope this topic does get more publicity as the change was made without broad communication and it will negatively impact many Fedora users.
Le mar. 27 sept. 2022 à 20:57, David Airlie airlied@redhat.com a écrit :
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. Dave.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
The last might be possible, but I'm not sure how to go about it.
At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
That the fedora mesa package completely drops the vaapi backend, so a complementary package can just drop the missing files instead of rebuilding a whole mesa package. It would assume the fedora mesa package to have everything needed in order to cope with vaapi backend enabled in the core libraries and that the vaapi backend only provide the implementation.
On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet kwizart@gmail.com wrote:
Le mar. 27 sept. 2022 à 20:57, David Airlie airlied@redhat.com a écrit :
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. Dave.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
The last might be possible, but I'm not sure how to go about it.
At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
That the fedora mesa package completely drops the vaapi backend, so a complementary package can just drop the missing files instead of rebuilding a whole mesa package. It would assume the fedora mesa package to have everything needed in order to cope with vaapi backend enabled in the core libraries and that the vaapi backend only provide the implementation.
Please take a look at the rawhide changes I just pushed. This should split things out sufficiently.
Dave.
On Thu, Sep 29, 2022 at 1:46 AM David Airlie airlied@redhat.com wrote:
On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet kwizart@gmail.com wrote:
Le mar. 27 sept. 2022 à 20:57, David Airlie airlied@redhat.com a écrit :
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. Dave.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
The last might be possible, but I'm not sure how to go about it.
At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
That the fedora mesa package completely drops the vaapi backend, so a complementary package can just drop the missing files instead of rebuilding a whole mesa package. It would assume the fedora mesa package to have everything needed in order to cope with vaapi backend enabled in the core libraries and that the vaapi backend only provide the implementation.
Please take a look at the rawhide changes I just pushed. This should split things out sufficiently.
But wait, aren't these the DRI drivers[1]?
[1]: https://src.fedoraproject.org/rpms/mesa/c/07e1e0b1628d9c55d3858c4655409768c5...
Nope the _video.so files are the vaapi ones.
Replacing that package with rpmfusion built should work fine.
On Thu, Sep 29, 2022 at 10:26 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Sep 29, 2022 at 1:46 AM David Airlie airlied@redhat.com wrote:
On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet kwizart@gmail.com wrote:
Le mar. 27 sept. 2022 à 20:57, David Airlie airlied@redhat.com a écrit :
On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
This was an oversight being enabled prior to this, and I think we have to remove it from older Fedora as well. Fedora cannot ship anything that causes the OS to provide an API which exposes patent algorithms.
The patent licensing around H264/H265 is such that providing this could leave Red Hat and other Fedora distributors exposed to legal problems. Dave.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion addon to alleviate the fallout in the short term?
The last might be possible, but I'm not sure how to go about it.
At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
That the fedora mesa package completely drops the vaapi backend, so a complementary package can just drop the missing files instead of rebuilding a whole mesa package. It would assume the fedora mesa package to have everything needed in order to cope with vaapi backend enabled in the core libraries and that the vaapi backend only provide the implementation.
Please take a look at the rawhide changes I just pushed. This should split things out sufficiently.
But wait, aren't these the DRI drivers[1]?
-- 真実はいつも一つ!/ Always, there's only one truth!
Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working
in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion
addon to alleviate the fallout in the short term?
Thanks!
While I can relate to the rationale to some extent, the amount of breakage caused by patents is slowly pushing me towards considering moving to a new distro. I am probably not the only one. This could be the proverbial straw breaking the camel's back. Recently, I experienced that the German AusweisApp, which already required entering the ID card PIN on the phone [1], has stopped working altogether [2]. This is due to hobbled openssl Fedora ships. There is no openssl-freeworld in RPM Fusion, probably because it would need to be rebuilt entirely. For mesa, there is apparently also little interest in maintaining a mesa-freeworld package [3]. The discontent with ffmpeg moving to fedora a while ago also seems to have been primarily caused by the monolithic nature of ffmpeg. On the other hand, gstreamer plugins seem not to be a major problem. It thus appears that, in order to keep Fedora appealing for users in jurisdictions not affected by patents, effort should be made to modularize the affected bits so that these can be shipped by RPM Fusion (or equivalent) without too much hassle.
Best regards, Julian
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2000306 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2105754 [3] https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...
On Wed, Sep 28, 2022 at 8:12 AM Julian Sikorski belegdol@gmail.com wrote:
Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49... https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working
in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion
addon to alleviate the fallout in the short term?
Thanks!
While I can relate to the rationale to some extent, the amount of breakage caused by patents is slowly pushing me towards considering moving to a new distro. I am probably not the only one. This could be the proverbial straw breaking the camel's back. Recently, I experienced that the German AusweisApp, which already required entering the ID card PIN on the phone [1], has stopped working altogether [2]. This is due to hobbled openssl Fedora ships. There is no openssl-freeworld in RPM Fusion, probably because it would need to be rebuilt entirely.
I think we need to have the crypto function hobbling stuff re-evaluated entirely, it *might* no longer be needed (IANAL). Please raise it on the legal@ list.
For mesa, there is apparently also little interest in maintaining a mesa-freeworld package [3]. The discontent with ffmpeg moving to fedora a while ago also seems to have been primarily caused by the monolithic nature of ffmpeg. On the other hand, gstreamer plugins seem not to be a major problem.
As one of the ffmpeg maintainers, I'm actively working on workarounds for the problem. And I've talked to my counterparts in RPM Fusion about the issue as well. We're all trying to figure this out.
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
As one of the ffmpeg maintainers, I'm actively working on workarounds for the problem. And I've talked to my counterparts in RPM Fusion about the issue as well. We're all trying to figure this out.
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...:
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.
On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen remyabel@gmail.com wrote:
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
As one of the ffmpeg maintainers, I'm actively working on workarounds for the problem. And I've talked to my counterparts in RPM Fusion about the issue as well. We're all trying to figure this out.
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...:
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.
I am not talking about Mesa, but ffmpeg instead.
Insofar as the Mesa situation, the comment *right below* that one explains the situation quite well: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...
On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen remyabel@gmail.com wrote:
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
As one of the ffmpeg maintainers, I'm actively working on workarounds for the problem. And I've talked to my counterparts in RPM Fusion about the issue as well. We're all trying to figure this out.
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu... :
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.
I am not talking about Mesa, but ffmpeg instead.
Insofar as the Mesa situation, the comment *right below* that one explains the situation quite well: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Does this imply that this section[1] is no longer accurate?
With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduced an un-backed (by most RPM Fusion packager involved) package with uncertain features enabled, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process.
Having non-competing packages in fedora+rpmfusion repositories is not a side thing, this is the reason why the RPM Fusion projects was created in the first place. Because of that we cannot afford support for ffmpeg-free at all and will recommend to migrate to our fully featured version.
Fedora Workaround:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
On Wed, Sep 28, 2022 at 8:50 AM Tommy Nguyen remyabel@gmail.com wrote:
On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen remyabel@gmail.com wrote:
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
As one of the ffmpeg maintainers, I'm actively working on workarounds for the problem. And I've talked to my counterparts in RPM Fusion about the issue as well. We're all trying to figure this out.
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu... :
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.
I am not talking about Mesa, but ffmpeg instead.
Insofar as the Mesa situation, the comment *right below* that one explains the situation quite well: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vu...
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Does this imply that this section[1] is no longer accurate?
With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduced an un-backed (by most RPM Fusion packager involved) package with uncertain features enabled, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process.
Having non-competing packages in fedora+rpmfusion repositories is not a side thing, this is the reason why the RPM Fusion projects was created in the first place. Because of that we cannot afford support for ffmpeg-free at all and will recommend to migrate to our fully featured version.
Fedora Workaround:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
It's being worked on, but hopefully in F38+ (and maybe in F37), it will no longer be true.
On Wed, Sep 28 2022 at 06:49:42 AM +0000, Tommy Nguyen remyabel@gmail.com wrote:
With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduced an un-backed (by most RPM Fusion packager involved) package with uncertain features enabled, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process.
Just for avoidance of doubt, getting ffmpeg into Fedora was a priority for the Workstation Working Group, and Neal was working in coordination with us on that. We want to provide as much multimedia in Fedora as we legally can without requiring that users resort to third-party repositories.
Michael
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl...:
it, also keeping the repo in sync with fedora isn't a priority for me.
Someone with the hardware and packaging knowledge will need to submit a review request at rpmfusion. I had my fill with ATI/AMD when I was packaging FGLRX and wont go there again ever!
On 2022-09-29 01:33, Leigh Scott wrote:
On Wed, 2022-09-28 at 08:24 +0200, Neal Gompa wrote:
That seems to contradict this quote from https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl...:
it, also keeping the repo in sync with fedora isn't a priority for me.
Someone with the hardware and packaging knowledge will need to submit a review request at rpmfusion. I had my fill with ATI/AMD when I was packaging FGLRX and wont go there again ever! _______________________________________________
Filed on https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426 . Hopefully it is okay to post the review request for RPM Fusion here.
On Wed, 2022-09-28 at 08:11 +0200, Julian Sikorski wrote:
Recently, I experienced that the German AusweisApp, which already required entering the ID card PIN on the phone [1], has stopped working altogether [2]. This is due to hobbled openssl Fedora ships. There is no openssl-freeworld in RPM Fusion, probably because it would need to be rebuilt entirely.
On this topic, have our legal advisors re-evaluated the ECC patent situation lately? The last patent listed in https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl supposedly expired in 2020, yet we're still doing a lot of patching of ECC stuff in the spec. Are there other patents not listed there which we're still worried about?
On Tue, 2022-09-27 at 23:39 -0700, Adam Williamson wrote:
On Wed, 2022-09-28 at 08:11 +0200, Julian Sikorski wrote:
Recently, I experienced that the German AusweisApp, which already required entering the ID card PIN on the phone [1], has stopped working altogether [2]. This is due to hobbled openssl Fedora ships. There is no openssl-freeworld in RPM Fusion, probably because it would need to be rebuilt entirely.
On this topic, have our legal advisors re-evaluated the ECC patent situation lately? The last patent listed in https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl supposedly expired in 2020, yet we're still doing a lot of patching of ECC stuff in the spec. Are there other patents not listed there which we're still worried about?
Looks like there's a related, very slow-moving discussion on legal@:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
As Fedora users and contributors, we profit a lot from everything that RedHat provides to the Fedora project, be it infra, people-power or "leverage" (talking to vendors etc.). In turn, RedHat can expect a certain amount of understanding from "us" for their business interests, which include legal liabilities, of course.
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order". This non-transparency is orthogonal to our first F and hurts all efforts to increase the number of contributors.
Now, I don't expect the communication issue to be resolved any time soon. Therefore it's important to work on the other major friction point: How difficult do we make it for users/contributors to get the missing bits that they need or can (because they are no distributors, in a different jurisdiction etc.)?
rpmfusion/gstreamer is a prime example of how things can work flawlessly, and takes into account all interests.
ffmpeg is a prime example of "in your face", of course, and I'm happy to read that it may get resolved.
The other big issue are our hobbled sources: We cannot store some original sources in the look-aside cache, obviously. But packages such as openssl do not even specify a hash nor an url for the un-hobbled sources. This makes it unncessarily difficult to verify that our openssl package has indeed been built against against the hobbled version of the original sources - for a package like openssl this really is a trust issue (and might even violate our packaging guidelines, but I'm not a lawyer...).
As a side effect, it makes it unnecesarily difficult to rebuild the package locally (though it does not effectively inhibit it either, of course; it is not an "effective measure" for that cause). I do understand that providing a functional link can be construed to be "redistribution", but in the context of a spec file, a comment really is a reference to the "source of the source", without which we cannot even claim to distribute the hobbled version legally (and without which we have no trust chain).
Note that depending on the legal outcome mesa might have to go the hobbled route, too: simply disabling the codecs in %build does not change anything about redistributing the source.
Note that depending on the legal outcome mesa might have to go the hobbled route, too: simply disabling the codecs in %build does not change anything about redistributing the source.
... or may not, if it's only about the hardware implementation, in which case I would suggest merely commenting out the switches in spec (or bcond'ing) them.
Hi,
Michael J Gruber mjg@fedoraproject.org wrote:
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions can be used against you in court. Presumably, this also applies here.
The other big issue are our hobbled sources: We cannot store some original sources in the look-aside cache, obviously. But packages such as openssl do not even specify a hash nor an url for the un-hobbled sources. This makes it unncessarily difficult to verify that our openssl package has indeed been built against against the hobbled version of the original sources - for a package like openssl this really is a trust issue (and might even violate our packaging guidelines, but I'm not a lawyer…).
As one of the people that has previously generated one of the hobbled tarballs you consider a potential trust issue: The hobbled tarball is the upstream tarball for the particular release we ship after we extract it, run ./hobble-openssl (which you’ll find in the package) and repack it.
Feel free to replicate this process and compare the output to check that we haven’t smuggled anything else into it.
Note that we’re discussing moving openssl to a src-git approach, so it should eventually become much easier to see the relation between upstream code and our downstream copy.
As a side effect, it makes it unnecesarily difficult to rebuild the package locally (though it does not effectively inhibit it either, of course; it is not an "effective measure" for that cause). I do understand that providing a functional link can be construed to be “redistribution”, but in the context of a spec file, a comment really is a reference to the "source of the source", without which we cannot even claim to distribute the hobbled version legally (and without which we have no trust chain).
Are you suggesting we add a comment that contains the URL to the upstream tarball? I don’t think we’d have a problem with that. However, we probably wouldn’t want to update it for every rebase, and a comment with a %{version} macro might not be very helpful either.
I also don’t agree that not including the URL to the upstream tarball makes a local rebuild unnecessarily difficult. If you replace the Source in the specfile with the upstream tarball URL and remove ec_curve.c and octets.c, the package should build just fine. How would you prefer we simplified this?
As one of the people that has previously generated one of the hobbled tarballs you consider a potential trust issue: The hobbled tarball is the upstream tarball for the particular release we ship after we extract it, run ./hobble-openssl (which you’ll find in the package) and repack it.
Feel free to replicate this process and compare the output to check that we haven’t smuggled anything else into it.
This is not about personal trust - personally, I don't have any problems trusting our packagers.
It is about the reproducible chain that we usually have: you can `spectool -gf` the original sources and compare checksums etc.
Note that we’re discussing moving openssl to a src-git approach, so it should eventually become much easier to see the relation between upstream code and our downstream copy.
I'm curious t see what happens when we have src-git on Fedora infrastructure, which we should have. Will our src-git carry ("distribute") unhobbled sources?
Are you suggesting we add a comment that contains the URL to the upstream tarball? I don’t think we’d have a problem with that. However, we probably
Yes, for example.
wouldn’t want to update it for every rebase, and a comment with a %{version} macro might not be very helpful either.
"%%" so that rpmlint does not complain. Yes, why not? I'm not suggesting something that could be construed as "distributing via link"; otherwise defining an %origsource and bconding build switches/hobble-related patches would be perfect, but maybe too close to "encouraging".
I also don’t agree that not including the URL to the upstream tarball makes a local rebuild unnecessarily difficult. If you replace the Source in the specfile with the upstream tarball URL and remove ec_curve.c and octets.c, the package should build just fine. How would you prefer we simplified this?
I know how to find the URL etc. (and so far don't know, but may have to in the future). I just think we can make it easier and more transparent (see above), and besides the technical aspect this also communicates "we hear you and do what we can" much better.
Clemens Lang wrote:
Note that we’re discussing moving openssl to a src-git approach, so it should eventually become much easier to see the relation between upstream code and our downstream copy.
At that point, you have the patent-encumbered files in your (src-)git history. I do not think the src-git approach is legally possible at all for these packages, at least not based on upstream git. (You could of course make your own git history with just code drops of the hobbled tarballs' contents, but that makes the use of git much less useful.)
Kevin Kofler
Hi,
Kevin Kofler wrote:
Clemens Lang wrote:
Note that we’re discussing moving openssl to a src-git approach, so it should eventually become much easier to see the relation between upstream code and our downstream copy.
At that point, you have the patent-encumbered files in your (src-)git history. I do not think the src-git approach is legally possible at all for these packages, at least not based on upstream git.
See Simo’s mail:
we are working towards removing hobbling and replacing with compilation switches that clearly and permanently disable questionable material in the binaries.
HTH, Clemens
On Wednesday, September 28, 2022, Clemens Lang cllang@redhat.com wrote:
Hi,
Michael J Gruber mjg@fedoraproject.org wrote:
Understanding is helped greatly by communication, though. Legal answers
such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions can be used against you in court. Presumably, this also applies here.
That's sounds overlay paranoid. How can an explanation on why you are *not* doing something be used against you in court? I can get why "we don't think that patent XYZ applies so this is fine to ship" is problematic, but the other way around just doesn't make sense.
On Thu, Sep 29, 2022 at 10:37 PM drago01 drago01@gmail.com wrote:
On Wednesday, September 28, 2022, Clemens Lang cllang@redhat.com wrote:
Hi,
Michael J Gruber mjg@fedoraproject.org wrote:
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions can be used against you in court. Presumably, this also applies here.
That's sounds overlay paranoid. How can an explanation on why you are *not* doing something be used against you in court? I can get why "we don't think that patent XYZ applies so this is fine to ship" is problematic, but the other way around just doesn't make sense.
Because if it is discovered you did it anyway, it can be classed as "willful" infringement, which means you can be penalized for it even more (damages can be tripled).
Now, in some cases, the reason is super-public anyway. Anything involving the MPEG-LA typically counts as such. But HEVC has multiple patent pools, MPEG-LA is just one of them. VVC is in the same boat. In screwy situations like that, you just don't even bother. Stay away from it all.
-- 真実はいつも一つ!/ Always, there's only one truth!
On 29 Sep 2022, at 21:37, drago01 drago01@gmail.com wrote:
On Wednesday, September 28, 2022, Clemens Lang <cllang@redhat.com mailto:cllang@redhat.com> wrote: Hi,
Michael J Gruber <mjg@fedoraproject.org mailto:mjg@fedoraproject.org> wrote:
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions can be used against you in court. Presumably, this also applies here.
That's sounds overlay paranoid. How can an explanation on why you are *not* doing something be used against you in court? I can get why "we don't think that patent XYZ applies so this is fine to ship" is problematic, but the other way around just doesn't make sense.
It’s related to additional damages for wilful infringement; if I say “I will not ship foo because I cannot get a suitable licence for patent US abc123455”, and the owner of that patent then claims I infringe because I ship bar, which they claim infringes patent US abc123455, they can also claim that my infringement of patent US abc123455 by shipping bar was wilful, because I clearly knew of the patent, I had analysed it to determine what it might apply to, and I’d decided to ship *bar* anyway, even though I knew or should reasonably have known (based on my analysis of why I couldn’t ship foo) that bar would put me into infringement.
Unfortunately, this is the flip side of well-meant legislation around wilful infringement - it’s simplest for a big US entity like Red Hat to simply say “no, and we’re not telling you why” to packages, because then there’s nothing to build a claim of wilful infringement around. — Simon Farnsworth
On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber mjg@fedoraproject.org wrote:
As Fedora users and contributors, we profit a lot from everything that RedHat provides to the Fedora project, be it infra, people-power or "leverage" (talking to vendors etc.). In turn, RedHat can expect a certain amount of understanding from "us" for their business interests, which include legal liabilities, of course.
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order". This non-transparency is orthogonal to our first F and hurts all efforts to increase the number of contributors.
Now, I don't expect the communication issue to be resolved any time soon. Therefore it's important to work on the other major friction point: How difficult do we make it for users/contributors to get the missing bits that they need or can (because they are no distributors, in a different jurisdiction etc.)?
rpmfusion/gstreamer is a prime example of how things can work flawlessly, and takes into account all interests.
ffmpeg is a prime example of "in your face", of course, and I'm happy to read that it may get resolved.
Let's talk for a moment here about this. I'm going to give you some "inside baseball" (or at least as much as I can). I can tell you up front that ffmpeg in Fedora is *entirely* my fault.
I spent many years tirelessly trying to come up with a solution to bring FFmpeg into Fedora. It started from the moment we got approval to introduce MPEG1 and MPEG2 codecs into Fedora. I cannot overstate how much back-and-forth with Red Hat Legal it took to figure it out. Over the last few years, more and more codecs got gradually approved, until we got to a point that enough codecs were approved that it made sense to finally produce a package to introduce. I had been trying to come up with a stripped FFmpeg source tree to deliver and was not succeeding until Andreas Scheider came up with the scripts to do it properly. That breakthrough allowed us to bring FFmpeg into Fedora as ffmpeg-free.
It was my choice to be quiet about its introduction, because I was being verbally and emotionally abused by other community members over it and I didn't want to invite more by making a big announcement like we did for mp3. At one point, I got so stressed over it that I became physically ill for weeks.
Do I regret this work? No. I still firmly believe this is going to improve the usefulness of baseline Fedora and expand the pressure to improve and prioritize Free Software in the Linux space. Do I want to do something like this again? I don't know. It really sucked and in the end all I got was hate for it. I want to make Fedora the best Linux distribution out there, but I also don't want to create a situation where all Fedora users and contributors are in legal jeopardy.
The other big issue are our hobbled sources: We cannot store some original sources in the look-aside cache, obviously. But packages such as openssl do not even specify a hash nor an url for the un-hobbled sources. This makes it unncessarily difficult to verify that our openssl package has indeed been built against against the hobbled version of the original sources - for a package like openssl this really is a trust issue (and might even violate our packaging guidelines, but I'm not a lawyer...).
I'm (personally, though IANAL) of the opinion that the hobbling of crypto libraries is probably no longer necessary and can be retired entirely. The method of producing the stripped sources is reproducible, so from our guidelines perspective, it's fine. But I do think it's probably obsolete, and I hope Red Hat Legal concurs.
As a side effect, it makes it unnecesarily difficult to rebuild the package locally (though it does not effectively inhibit it either, of course; it is not an "effective measure" for that cause). I do understand that providing a functional link can be construed to be "redistribution", but in the context of a spec file, a comment really is a reference to the "source of the source", without which we cannot even claim to distribute the hobbled version legally (and without which we have no trust chain).
Note that depending on the legal outcome mesa might have to go the hobbled route, too: simply disabling the codecs in %build does not change anything about redistributing the source.
That will depend on how much codec detail exists in the Mesa codebase. I would guess not enough to matter, but IANAL.
Here's something of a drop-kick for you though: those hardware-accelerated codecs that Dave Airlie disabled from Mesa weren't being used by *anything* in Fedora anyway. Not GStreamer, not FFmpeg, not Chromium, etc. We've been extremely careful to ensure we don't provide a "completed puzzle" as it were for those codecs. In practice, you are getting *nothing* from those codecs anyway. Fedora has only provided working hardware acceleration for unencumbered codecs. That list is expanding all the time, but for now this means you're basically only going to see MPEG1, MPEG2, VP8, VP9, and AV1 acceleration. Everything else is currently off the table.
On Wed, 2022-09-28 at 14:21 +0200, Neal Gompa wrote:
I'm (personally, though IANAL) of the opinion that the hobbling of crypto libraries is probably no longer necessary and can be retired entirely. The method of producing the stripped sources is reproducible, so from our guidelines perspective, it's fine. But I do think it's probably obsolete, and I hope Red Hat Legal concurs.
Just FYI, we are working towards removing hobbling and replacing with compilation switches that clearly and permanently disable questionable material in the binaries.
It is just not a very high priority item because the hobbling works fine but we will get there, and hopefully we'll get to a point where we do not need to disable as much stuff either.
But no promises right now, resources are what they are and we are not aware of actual issues caused by hobbling.
Simo.
On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber <mjg(a)fedoraproject.org> wrote:
Let's talk for a moment here about this. I'm going to give you some "inside baseball" (or at least as much as I can). I can tell you up front that ffmpeg in Fedora is *entirely* my fault.
Thanks for the inside view. Please note that my post was not about "fault/blame" but rather about furthering understanding by communication. While I may have failed doing so, you succeeded, thanks ;)
On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber mjg@fedoraproject.org wrote:
On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber <mjg(a)fedoraproject.org> wrote:
Let's talk for a moment here about this. I'm going to give you some "inside baseball" (or at least as much as I can). I can tell you up front that ffmpeg in Fedora is *entirely* my fault.
Thanks for the inside view. Please note that my post was not about "fault/blame" but rather about furthering understanding by communication. While I may have failed doing so, you succeeded, thanks ;)
The nature of these issues means we cannot publicly discuss most of the details. On some level, you're just going to have to trust Matthew Miller on what he says on behalf of Red Hat. Red Hat lawyers aren't going to step into this thread or any other thread about this stuff and say anything meaningful. While we would like the information, it's legal suicide to give up that information, so they won't.
It sucks, but it is what it is.
Hey, on a related note... I'm applying for a position as a Open source license compliance analyst (amazing!) and I would be eager to learn more about how we do things in Fedora. If I get the gig, I will even be able to contribute some time to the effort.
-Blaise
On Wed, Sep 28, 2022 at 8:49 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber mjg@fedoraproject.org wrote:
On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber <mjg(a)
fedoraproject.org> wrote:
Let's talk for a moment here about this. I'm going to give you some "inside baseball" (or at least as much as I can). I can tell you up front that ffmpeg in Fedora is *entirely* my fault.
Thanks for the inside view. Please note that my post was not about
"fault/blame" but rather about furthering understanding by communication. While I may have failed doing so, you succeeded, thanks ;)
The nature of these issues means we cannot publicly discuss most of the details. On some level, you're just going to have to trust Matthew Miller on what he says on behalf of Red Hat. Red Hat lawyers aren't going to step into this thread or any other thread about this stuff and say anything meaningful. While we would like the information, it's legal suicide to give up that information, so they won't.
It sucks, but it is what it is.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 9/28/22 08:21, Neal Gompa wrote:
On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber mjg@fedoraproject.org wrote:
As Fedora users and contributors, we profit a lot from everything that RedHat provides to the Fedora project, be it infra, people-power or "leverage" (talking to vendors etc.). In turn, RedHat can expect a certain amount of understanding from "us" for their business interests, which include legal liabilities, of course.
Understanding is helped greatly by communication, though. Legal answers such as "We can not" do not further this understanding, and "We can not and we can not tell you why" is not much better, but these are the typical answer we get, not even with a "sorry, but we can't". Obviously, these legal questions are difficult to explain, but it can't be true that each such case is under a "gag order". This non-transparency is orthogonal to our first F and hurts all efforts to increase the number of contributors.
Now, I don't expect the communication issue to be resolved any time soon. Therefore it's important to work on the other major friction point: How difficult do we make it for users/contributors to get the missing bits that they need or can (because they are no distributors, in a different jurisdiction etc.)?
rpmfusion/gstreamer is a prime example of how things can work flawlessly, and takes into account all interests.
ffmpeg is a prime example of "in your face", of course, and I'm happy to read that it may get resolved.
Let's talk for a moment here about this. I'm going to give you some "inside baseball" (or at least as much as I can). I can tell you up front that ffmpeg in Fedora is *entirely* my fault.
I spent many years tirelessly trying to come up with a solution to bring FFmpeg into Fedora. It started from the moment we got approval to introduce MPEG1 and MPEG2 codecs into Fedora. I cannot overstate how much back-and-forth with Red Hat Legal it took to figure it out. Over the last few years, more and more codecs got gradually approved, until we got to a point that enough codecs were approved that it made sense to finally produce a package to introduce. I had been trying to come up with a stripped FFmpeg source tree to deliver and was not succeeding until Andreas Scheider came up with the scripts to do it properly. That breakthrough allowed us to bring FFmpeg into Fedora as ffmpeg-free.
It was my choice to be quiet about its introduction, because I was being verbally and emotionally abused by other community members over it and I didn't want to invite more by making a big announcement like we did for mp3. At one point, I got so stressed over it that I became physically ill for weeks.
Do I regret this work? No. I still firmly believe this is going to improve the usefulness of baseline Fedora and expand the pressure to improve and prioritize Free Software in the Linux space. Do I want to do something like this again? I don't know. It really sucked and in the end all I got was hate for it. I want to make Fedora the best Linux distribution out there, but I also don't want to create a situation where all Fedora users and contributors are in legal jeopardy.
The other big issue are our hobbled sources: We cannot store some original sources in the look-aside cache, obviously. But packages such as openssl do not even specify a hash nor an url for the un-hobbled sources. This makes it unncessarily difficult to verify that our openssl package has indeed been built against against the hobbled version of the original sources - for a package like openssl this really is a trust issue (and might even violate our packaging guidelines, but I'm not a lawyer...).
I'm (personally, though IANAL) of the opinion that the hobbling of crypto libraries is probably no longer necessary and can be retired entirely. The method of producing the stripped sources is reproducible, so from our guidelines perspective, it's fine. But I do think it's probably obsolete, and I hope Red Hat Legal concurs.
As a side effect, it makes it unnecesarily difficult to rebuild the package locally (though it does not effectively inhibit it either, of course; it is not an "effective measure" for that cause). I do understand that providing a functional link can be construed to be "redistribution", but in the context of a spec file, a comment really is a reference to the "source of the source", without which we cannot even claim to distribute the hobbled version legally (and without which we have no trust chain).
Note that depending on the legal outcome mesa might have to go the hobbled route, too: simply disabling the codecs in %build does not change anything about redistributing the source.
That will depend on how much codec detail exists in the Mesa codebase. I would guess not enough to matter, but IANAL.
Here's something of a drop-kick for you though: those hardware-accelerated codecs that Dave Airlie disabled from Mesa weren't being used by *anything* in Fedora anyway. Not GStreamer, not FFmpeg, not Chromium, etc. We've been extremely careful to ensure we don't provide a "completed puzzle" as it were for those codecs. In practice, you are getting *nothing* from those codecs anyway. Fedora has only provided working hardware acceleration for unencumbered codecs. That list is expanding all the time, but for now this means you're basically only going to see MPEG1, MPEG2, VP8, VP9, and AV1 acceleration. Everything else is currently off the table.
Could Cisco somehow be convinced to provide hardware acceleration as part of OpenH264?
I would be very SAD if this change lands on my computer. While instead of arguing with some legal puzzles, I think those parts can be provided by seperate package (and maybe packaged in rpmfusion?) like intel- media-driver.
Is there any build-to-build ABI match requirement between the VAAPI implementation and mesa itself?
在 2022-09-27星期二的 20:01 +0200,Frantisek Zatloukal写道:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6 ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was
working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an
rpmfusion addon to alleviate the fallout in the short term?
Thanks!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 2022-09-28 at 15:11 +0800, yanqiyu01@gmail.com wrote:
I would be very SAD if this change lands on my computer. While instead of arguing with some legal puzzles, I think those parts can be provided by seperate package (and maybe packaged in rpmfusion?) like intel- media-driver.
Is there any build-to-build ABI match requirement between the VAAPI implementation and mesa itself?
在 2022-09-27星期二的 20:01 +0200,Frantisek Zatloukal写道:
Hi,
since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6 ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2123998%C2%A0).
It seems like a big regression from F36 for users with GPUs with open source drivers (mainly AMD, maybe nVidia/other non x86...), that affects common use-cases of Fedora Workstation, like watching videos, in-house game streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was
working in Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an
rpmfusion addon to alleviate the fallout in the short term?
Thanks!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher arequipeno@gmail.com wrote:
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
Well, we don't ship any userspace software that provides the necessary support code to use those codecs anyway.
Am 28.09.22 um 15:27 schrieb Neal Gompa:
On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher arequipeno@gmail.com wrote:
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
Well, we don't ship any userspace software that provides the necessary support code to use those codecs anyway.
Wasn't this being used by firefox? https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
Best regards, Julian
On Wed, 28 Sep 2022 19:24:34 +0200 Julian Sikorski belegdol@gmail.com wrote:
Wasn't this being used by firefox? https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
I don't know if it is used, but I received messages from firefox nightly that VA-API support was missing when I ran it in the terminal with the latest mesa for f37 installed.
On 28 Sep 2022, at 14:27, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher arequipeno@gmail.com wrote:
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
Well, we don't ship any userspace software that provides the necessary support code to use those codecs anyway.
Firefox was able to use VA-API on Intel (at least - I don’t have Radeon hardware to hand) to accelerate H.264 decode.
And we ship gstreamer1-vaapi which lets any GStreamer using application (Totem, for example) use hardware acceleration.
— Simon Farnsworth
On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel devel@lists.fedoraproject.org wrote:
On 28 Sep 2022, at 14:27, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher arequipeno@gmail.com wrote:
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
Well, we don't ship any userspace software that provides the necessary support code to use those codecs anyway.
Firefox was able to use VA-API on Intel (at least - I don’t have Radeon hardware to hand) to accelerate H.264 decode.
Intel doesn't use Gallium (Mesa) for VA-API. You need a separate driver package for it, which we currently don't ship and the version being reviewed will not have these codecs enabled.
And we ship gstreamer1-vaapi which lets any GStreamer using application (Totem, for example) use hardware acceleration.
Hmm, I forgot about that. FFmpeg doesn't have it because ffmpeg does stupid things when the codec is available but doesn't work. GStreamer is probably more intelligent about failing over.
On 28 Sep 2022, at 19:40, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel <devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org> wrote:
On 28 Sep 2022, at 14:27, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher arequipeno@gmail.com wrote:
On 9/28/22 03:50, Tommy Nguyen wrote:
This change will only affect AMD, as the intel non-free drivers do not depend on the changes. It is also unclear how this would affect nvidia. There is barely any hardware video acceleration support for nouveau anyway, for which you would install the proprietary driver. Further, as NVIDIA does not expose a vaapi interface, you need to install third party packages to get it to work with Firefox. So AFAICT this will primarily (if not only) affect AMD users.
So only everybody who specifically purchased a discrete GPU that works "out of the box" with Fedora?
Well, we don't ship any userspace software that provides the necessary support code to use those codecs anyway.
Firefox was able to use VA-API on Intel (at least - I don’t have Radeon hardware to hand) to accelerate H.264 decode.
Intel doesn't use Gallium (Mesa) for VA-API. You need a separate driver package for it, which we currently don't ship and the version being reviewed will not have these codecs enabled.
To be clear - I wasn’t saying that Intel used Mesa for VA-API; I was saying that with Mesa drivers and Radeon hardware, I would expect Firefox’s VA-API support to work as well as it does for Intel, but I have not been able to test this.
And we ship gstreamer1-vaapi which lets any GStreamer using application (Totem, for example) use hardware acceleration.
Hmm, I forgot about that. FFmpeg doesn't have it because ffmpeg does stupid things when the codec is available but doesn't work. GStreamer is probably more intelligent about failing over.
GStreamer elements run code to determine what codecs are supported - the VA-API elements use this to avoid claiming to support a codec unless it will work.
I’m not familiar with the current state of FFmpeg - in the dim and distant past, it relied on data tables to determine what codecs a given plugin supported, rather than running code (hence the VA-API plugins can’t claim no codec support when VA-API is unavailable).
— Simon Farnsworth
(This is a sad noob user rant, please bear me. And sorry in advance for 'whataboutism'.)
IANAL but this is a horrible idea.
It's like parents turning off the internet entirely WiFi because the kid can't be able to watch 'bad' videos. Technically, it solves parents' problems but hampers the kid's study in many ways. Are we going over the board by touching all the way to down to Mesa?
I mean, what's next? - Remove all torrent software, because it can be used to download... Juridiction=IANAL, Possibility - Use LibreKernel because... Juridiction = IANAL, Possibility - ...
This is like triggering the shotgun into your own house. What happens? Users/member of the house shift/leaves the house. I started with F34 and had to already go to heck to achieve a proper video acceleration. And now I hear about this. Truly disappointing and saddening. Reminds me of a possible youtube comment:
Redhat: How hard do you want to make your users suffer? Fedora: yes
On Thu, 2022-09-29 at 08:12 +0000, James bond wrote:
(This is a sad noob user rant, please bear me. And sorry in advance for 'whataboutism'.)
IANAL but this is a horrible idea.
It's like parents turning off the internet entirely WiFi because the kid can't be able to watch 'bad' videos. Technically, it solves parents' problems but hampers the kid's study in many ways. Are we going over the board by touching all the way to down to Mesa?
It's pretty clearly delineated what's allowed and not allowed in Fedora's packaging/licensing guidelines. And Fedora is not obligated to package every single thing.
I mean, what's next?
- Remove all torrent software, because it can be used to download...
Juridiction=IANAL, Possibility
- Use LibreKernel because... Juridiction = IANAL, Possibility
- ...
Torrenting is not illegal. Torrenting copyrighting material is. And Fedora has an exception for binary firmware blobs.
This is like triggering the shotgun into your own house. What happens? Users/member of the house shift/leaves the house. I started with F34 and had to already go to heck to achieve a proper video acceleration. And now I hear about this. Truly disappointing and saddening. Reminds me of a possible youtube comment:
Redhat: How hard do you want to make your users suffer? Fedora: yes
This issue has been blown out of proportion. Most people will not be affected, AMD users can still use other codecs, and people are working on workarounds.
On Thu, Sep 29 2022 at 08:12:10 AM -0000, James bond prabesh432@gmail.com wrote:
I mean, what's next?
- Remove all torrent software, because it can be used to download...
Juridiction=IANAL, Possibility
- Use LibreKernel because... Juridiction = IANAL, Possibility
- ...
The difference is Fedora Legal is OK with torrent software and Linux firmware, but not OK with unapproved multimedia codecs. There's no point in trying to debate this on a public mailing list as the lawyers who make these decisions don't read the list.
I'm confident that Fedora Legal wants to allow as much as possible because they have worked with us on this in the past, which is why today Fedora is able to play MP3, AAC, and even H.264 (via OpenH264) when all three of these technologies were totally banned just a few years ago. In Fedora 38, we'll have a new service, fedora-autofirstboot, that installs OpenH264 for you with no user interaction, so soon users will be able to play most MP4s out-of-the-box with zero manual intervention required to make it work. (This is already ready, just not enabled yet in F37.) I expect our multimedia situation to improve even more in the future because I suspect there is a little more we can do here. But when Fedora Legal says we cannot do something, they really mean it and we have to respect that.
Michael
On 9/29/22 09:37, Michael Catanzaro wrote:
On Thu, Sep 29 2022 at 08:12:10 AM -0000, James bond prabesh432@gmail.com wrote:
I mean, what's next?
- Remove all torrent software, because it can be used to download...
Juridiction=IANAL, Possibility
- Use LibreKernel because... Juridiction = IANAL, Possibility
- ...
The difference is Fedora Legal is OK with torrent software and Linux firmware, but not OK with unapproved multimedia codecs. There's no point in trying to debate this on a public mailing list as the lawyers who make these decisions don't read the list.
I'm confident that Fedora Legal wants to allow as much as possible because they have worked with us on this in the past, which is why today Fedora is able to play MP3, AAC, and even H.264 (via OpenH264) when all three of these technologies were totally banned just a few years ago. In Fedora 38, we'll have a new service, fedora-autofirstboot, that installs OpenH264 for you with no user interaction, so soon users will be able to play most MP4s out-of-the-box with zero manual intervention required to make it work. (This is already ready, just not enabled yet in F37.) I expect our multimedia situation to improve even more in the future because I suspect there is a little more we can do here. But when Fedora Legal says we cannot do something, they really mean it and we have to respect that.
Could OpenH264 be hooked up to hardware acceleration somehow?
On Thu, Sep 29, 2022 at 3:41 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 9/29/22 09:37, Michael Catanzaro wrote:
On Thu, Sep 29 2022 at 08:12:10 AM -0000, James bond prabesh432@gmail.com wrote:
I mean, what's next?
- Remove all torrent software, because it can be used to download...
Juridiction=IANAL, Possibility
- Use LibreKernel because... Juridiction = IANAL, Possibility
- ...
The difference is Fedora Legal is OK with torrent software and Linux firmware, but not OK with unapproved multimedia codecs. There's no point in trying to debate this on a public mailing list as the lawyers who make these decisions don't read the list.
I'm confident that Fedora Legal wants to allow as much as possible because they have worked with us on this in the past, which is why today Fedora is able to play MP3, AAC, and even H.264 (via OpenH264) when all three of these technologies were totally banned just a few years ago. In Fedora 38, we'll have a new service, fedora-autofirstboot, that installs OpenH264 for you with no user interaction, so soon users will be able to play most MP4s out-of-the-box with zero manual intervention required to make it work. (This is already ready, just not enabled yet in F37.) I expect our multimedia situation to improve even more in the future because I suspect there is a little more we can do here. But when Fedora Legal says we cannot do something, they really mean it and we have to respect that.
Could OpenH264 be hooked up to hardware acceleration somehow?
Ask Cisco: https://github.com/cisco/openh264
On Thu, Sep 29 2022 at 09:41:07 AM -0400, Demi Marie Obenour demiobenour@gmail.com wrote:
Could OpenH264 be hooked up to hardware acceleration somehow?
A very interesting possibility. ;) It would certainly be nice to see OpenH264 get more development attention, to improve quality and implement new features like this.
Michael
Yeah same here. Worked for months to get video acceleration working on an nvidia card, then decided to switch to AMD, and now this. I get there's other codecs, but for the user who's been expressly needing those now-removed codecs finding out things no longer work is very annoying.
Really reminds me of the whole Linux on PS3 debacle, when Sony removed the feature after release.
On 2022-09-29 04:12, James bond wrote:
(This is a sad noob user rant, please bear me. And sorry in advance for 'whataboutism'.)
IANAL but this is a horrible idea.
It's like parents turning off the internet entirely WiFi because the kid can't be able to watch 'bad' videos. Technically, it solves parents' problems but hampers the kid's study in many ways. Are we going over the board by touching all the way to down to Mesa?
I mean, what's next?
- Remove all torrent software, because it can be used to download... Juridiction=IANAL, Possibility
- Use LibreKernel because... Juridiction = IANAL, Possibility
- ...
This is like triggering the shotgun into your own house. What happens? Users/member of the house shift/leaves the house. I started with F34 and had to already go to heck to achieve a proper video acceleration. And now I hear about this. Truly disappointing and saddening. Reminds me of a possible youtube comment:
Redhat: How hard do you want to make your users suffer? Fedora: yes _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hello,
Just a note. If someone from RPM Fusion who is interested in packaging full mesa-va-drivers package reads this, please, make sure that the package also contains valid AppStream metadata and is showing in GNOME Software / KDE Discover the same way as, for example, NVIDIA driver does. It is _unacceptable_ to force end users to search for and install the driver package via terminal. Thanks!
Regards, Daniel
Here is an example of the driver component AppStream metadata type: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Driver.htm...
You can probably ignore the <modalias> tag.
On Sun, 2022-10-09 at 10:25 +0000, Daniel Rusek wrote:
Hello,
Just a note. If someone from RPM Fusion who is interested in packaging full mesa-va-drivers package reads this, please, make sure that the package also contains valid AppStream metadata and is showing in GNOME Software / KDE Discover the same way as, for example, NVIDIA driver does. It is _unacceptable_ to force end users to search for and install the driver package via terminal. Thanks!
Regards, Daniel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Why is it unacceptable?
Because Fedora also targets regular users who are not experts and also because it would make it much easier for all users to find and install that package (for example by entering "h264" in GNOME Shell Overview on a RPM Fusion enabled system) instead of requiring them to search/install the package via dnf. If it will be available only via terminal, it will probably get ignored by many users, at least this is my opinion.
It is just a simple, short xml file, not a big deal for maintainers, but actually quite a big deal for many end users. If anyone from RPM Fusion needs a help with this file, feel free to drop me a line. :-)
On Sun, Oct 09, 2022 at 10:25:08AM -0000, Daniel Rusek wrote:
Hello,
Just a note. If someone from RPM Fusion who is interested in packaging full mesa-va-drivers package reads this, please, make sure that the package also contains valid AppStream metadata and is showing in GNOME Software / KDE Discover the same way as, for example, NVIDIA driver does. It is _unacceptable_ to force end users to search for and install the driver package via terminal. Thanks!
You can provide feedback at the review request https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426
After reading this thread and bz 2123998, I had thought that the Fedora 37 mesa packages retained accelerated video for open codecs (for AMD hardware). However, the Fedora wiki[1] indicates that even open codecs are no longer accelerated without third party packages. Is that true? (I don't think that I can test this, since I don't have any AMD GPUs, only Intel.)
1: https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-AP...
On Tue, Nov 15, 2022 at 5:27 PM Gordon Messmer gordon.messmer@gmail.com wrote:
After reading this thread and bz 2123998, I had thought that the Fedora 37 mesa packages retained accelerated video for open codecs (for AMD hardware). However, the Fedora wiki[1] indicates that even open codecs are no longer accelerated without third party packages. Is that true? (I don't think that I can test this, since I don't have any AMD GPUs, only Intel.)
This is not true. However, until recently, support for hardware accelerated open codecs was limited to Intel QuickSync Video, which is blocked on the VA-API driver landing in Fedora[1].
AMD VP9 decoding was added in VCN 1.0: https://en.wikipedia.org/wiki/Video_Core_Next
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1942132
On 2022-11-15 15:32, Neal Gompa wrote:
This is not true. However, until recently, support for hardware accelerated open codecs was limited to Intel QuickSync Video, which is blocked on the VA-API driver landing in Fedora[1].
AMD VP9 decoding was added in VCN 1.0:
Sorry, I'm still not clear on what I should take away from that, and that's probably my fault for summarizing what I'd read. BZ 2123998 suggested that mesa-22.2.0~rc3-1.fc37 had support for VAProfileVP9Profile0 and VAProfileVP9Profile2 in radeonsi_drv_video.so (after the patent-encumbered formats were disabled), but the wiki page says that VP8, VP9, and AV1 are no longer accelerated out of the box on AMD GPUs.
Is VP9 currently accelerated for AMD GPUs without third-party packages, or not?
Again, sorry if I'm being dense.
On Tue, Nov 15, 2022 at 7:52 PM Gordon Messmer gordon.messmer@gmail.com wrote:
On 2022-11-15 15:32, Neal Gompa wrote:
This is not true. However, until recently, support for hardware accelerated open codecs was limited to Intel QuickSync Video, which is blocked on the VA-API driver landing in Fedora[1].
AMD VP9 decoding was added in VCN 1.0:
Sorry, I'm still not clear on what I should take away from that, and that's probably my fault for summarizing what I'd read. BZ 2123998 suggested that mesa-22.2.0~rc3-1.fc37 had support for VAProfileVP9Profile0 and VAProfileVP9Profile2 in radeonsi_drv_video.so (after the patent-encumbered formats were disabled), but the wiki page says that VP8, VP9, and AV1 are no longer accelerated out of the box on AMD GPUs.
Is VP9 currently accelerated for AMD GPUs without third-party packages, or not?
Again, sorry if I'm being dense.
It is, provided the GPU supports it.
On 15/11/2022 23:25, Gordon Messmer wrote:
I had thought that the Fedora 37 mesa packages retained accelerated video for open codecs (for AMD hardware)
To accelerate H.264/H.265, you need to replace the stripped Fedora versions with the full versions from the RPM Fusion repository:
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld --allowerasing
However, the Fedora wiki[1] indicates that even open codecs are no longer accelerated without third party packages. Is that true?
On Intel, you need to install the libva-intel-driver (i915) and intel-media-driver (iHD) packages.
On NVIDIA, you're forced to use proprietary drivers as hardware acceleration on nouveau only works on very old GPUs.
On Wednesday, 16 November 2022 at 09:22, Vitaly Zaitsev via devel wrote:
On 15/11/2022 23:25, Gordon Messmer wrote:
I had thought that the Fedora 37 mesa packages retained accelerated video for open codecs (for AMD hardware)
To accelerate H.264/H.265, you need to replace the stripped Fedora versions with the full versions from the RPM Fusion repository:
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld --allowerasing
However, the Fedora wiki[1] indicates that even open codecs are no longer accelerated without third party packages. Is that true?
On Intel, you need to install the libva-intel-driver (i915) and intel-media-driver (iHD) packages.
Actually, it's either one or the other as they don't support the same CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for older ones (Ice Lake is the first one it doesn't support). See https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-AP... https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers
Regards, Dominik
On Wed, Nov 16, 2022 at 3:19 AM Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Wednesday, 16 November 2022 at 09:22, Vitaly Zaitsev via devel wrote:
On 15/11/2022 23:25, Gordon Messmer wrote:
I had thought that the Fedora 37 mesa packages retained accelerated video for open codecs (for AMD hardware)
To accelerate H.264/H.265, you need to replace the stripped Fedora versions with the full versions from the RPM Fusion repository:
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
--allowerasing
However, the Fedora wiki[1] indicates that even open codecs are no longer accelerated without third party packages. Is that true?
On Intel, you need to install the libva-intel-driver (i915) and intel-media-driver (iHD) packages.
Actually, it's either one or the other as they don't support the same CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for older ones (Ice Lake is the first one it doesn't support). See
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-AP... https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers
The fact that it's this confusing on the -devel list means it's going to be VERY confusing to end users. We need good documentation, which unfortunately has been one of our weak points, and it needs to be broadcasted everywhere.
Thanks, Richard
On 11/16/22 3:18 AM, Dominik 'Rathann' Mierzejewski wrote:
Actually, it's either one or the other as they don't support the same CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for older ones (Ice Lake is the first one it doesn't support).
To be pedantic there is some overlap in support in iHD and i965.
What will also rock your noggin is that i965 is faster than iHD.
On 2022-11-16 00:22, Vitaly Zaitsev via devel wrote:
To accelerate H.264/H.265, you need to...
I'm aware. My question was intended to be very specific to the statement made in Fedora's wiki with regard to open codecs like VP9 on AMD. I've since updated the wiki.