Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

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.

https://github.com/intel/media-driver/issues/925
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Richard Shaw]

On Wed, Nov 16, 2022 at 3:19 AM Dominik 'Rathann' Mierzejewski <
domi...@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-API_Video_decoding_on_Intel
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Dominik 'Rathann' Mierzejewski]

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-API_Video_decoding_on_Intel
https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Vitaly Zaitsev via devel]

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.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Tue, Nov 15, 2022 at 7:52 PM Gordon Messmer  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.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Tue, Nov 15, 2022 at 5:27 PM Gordon Messmer  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



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

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-API_Video_decoding_on_AMD

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Daniel Rusek]

Thanks!

Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tomasz Torcz]

On Sun, Oct 09, 2022 at 10:25:08AM -, 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


-- 
Tomasz TorczOnce you've read the dictionary,
@ttorcz:pipebreaker.pl  every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Daniel Rusek]

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. :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Daniel Rusek]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Sun, 2022-10-09 at 10:25 +, 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-le...@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?


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Daniel Rusek]

Here is an example of the driver component AppStream metadata type: 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Driver.html

You can probably ignore the  tag.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Daniel Rusek]

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-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Luya Tshimbalanga]

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.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[stan via devel]

On Fri, 30 Sep 2022 22:19:44 +0200
Björn Persson  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Björn Persson]

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


pgpzmooEtzlFN.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Simon Farnsworth via devel]

> On 29 Sep 2022, at 21:37, drago01  wrote:
> 
> 
> 
> On Wednesday, September 28, 2022, Clemens Lang  > wrote:
> Hi,
> 
> Michael J Gruber mailto:m...@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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Neal Gompa]

On Thu, Sep 29, 2022 at 10:37 PM drago01  wrote:
>
>
>
> On Wednesday, September 28, 2022, Clemens Lang  wrote:
>>
>> Hi,
>>
>> Michael J Gruber  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[drago01]

On Wednesday, September 28, 2022, Clemens Lang  wrote:

> Hi,
>
> Michael J Gruber  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gary Buhrmaster]

On Thu, Sep 29, 2022 at 12:56 PM Kevin P. Fleming  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[stan via devel]

On Wed, 28 Sep 2022 19:24:34 +0200
Julian Sikorski  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Catanzaro]

On Thu, Sep 29 2022 at 09:41:07 AM -0400, Demi Marie Obenour 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> In Fedora 38, we'll have a new service,
> fedora-autofirstboot, that installs OpenH264 for you with no user
> interaction

Installing restrictively licensed stuff (see the patent license) with no 
user interaction is not really helpful.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Steve Cossette]

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-le...@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-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Thu, Sep 29, 2022 at 3:41 PM Demi Marie Obenour
 wrote:
>
> On 9/29/22 09:37, Michael Catanzaro wrote:
> > On Thu, Sep 29 2022 at 08:12:10 AM -, James bond
> >  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



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Demi Marie Obenour]

On 9/29/22 09:37, Michael Catanzaro wrote:
> On Thu, Sep 29 2022 at 08:12:10 AM -, James bond 
>  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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 29 Sep 2022, at 12:52, Tommy Nguyen  wrote:
> 
> 
> 
>> On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel 
>>  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-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Catanzaro]

On Thu, Sep 29 2022 at 08:12:10 AM -, James bond 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Kevin P. Fleming]

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.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Clemens Lang]

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

--
Clemens Lang
RHEL Crypto Team
Red Hat


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Leigh Scott]

> 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_costless_software
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Leigh Scott]

> 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-h264-and-h265/

The unlikely happens all the time, I still can't believe the result in the 
Johnson & Johnson 'Talc' case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

> On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel 
>  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-le...@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. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Kevin Kofler via devel]

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-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Leigh Scott]

> 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Thu, 2022-09-29 at 08: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?

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.



signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[James bond]

(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-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Thu, Sep 29, 2022 at 4:43 AM Gary Buhrmaster
 wrote:
>
> On Tue, Sep 27, 2022 at 8:06 PM David Airlie  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gary Buhrmaster]

On Tue, Sep 27, 2022 at 8:06 PM David Airlie  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)?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

On 9/28/22 6:45 PM, David Airlie wrote:

Please take a look at the rawhide changes I just pushed. This should
split things out sufficiently.


Thanks, Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

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  wrote:
>
> On Thu, Sep 29, 2022 at 1:46 AM David Airlie  wrote:
> >
> > On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
> > >
> > > Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> > > >
> > > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal 
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > since this mesa change ( 
> > > > > 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 ).
> > > > >
> > > > > 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/07e1e0b1628d9c55d3858c4655409768c5c0b5de?branch=rawhide
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Thu, Sep 29, 2022 at 1:46 AM David Airlie  wrote:
>
> On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
> >
> > Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> > >
> > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > since this mesa change ( 
> > > > 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 ).
> > > >
> > > > 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/07e1e0b1628d9c55d3858c4655409768c5c0b5de?branch=rawhide



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
>
> Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> >
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > >
> > > Hi,
> > >
> > > since this mesa change ( 
> > > 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 ).
> > >
> > > 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 19:40, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel
> mailto:devel@lists.fedoraproject.org>> wrote:
>> 
>>> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
>>> 
>>> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  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___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel
 wrote:
>
> > On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
> >
> > On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  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.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Simon Farnsworth via devel]

> On 28 Sep 2022, at 14:27, Neal Gompa  wrote:
> 
> On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Julian Sikorski]

Am 28.09.22 um 15:27 schrieb Neal Gompa:

On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Demi Marie Obenour]

On 9/28/22 08:21, Neal Gompa wrote:
> On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  
> 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 

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Blaise Pabon]

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  wrote:

> On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber 
> wrote:
> >
> > > On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  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-le...@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
>


-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Catanzaro]

On Wed, Sep 28 2022 at 06:49:42 AM +, Tommy Nguyen 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher  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.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Ian Pilcher]

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?

--

Google  Where SkyNet meets Idiocracy


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Neal Gompa]

On Wed, Sep 28, 2022 at 2:41 PM Michael J Gruber  wrote:
>
> > On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber 
> >  >
> > 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-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  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 ;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Simo Sorce]

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.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Neal Gompa]

On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber  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* 

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Clemens Lang]

Hi,

Michael J Gruber  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?

--
Clemens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Michael J Gruber]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Wed, 2022-09-28 at 15:11 +0800, yanqiy...@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 ).
> > 
> > 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-le...@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-le...@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.



signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:50 AM Tommy Nguyen  wrote:
>
>
>
> On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
> > On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen 
> > 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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191
> > > :
> > >
> > > > 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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[yanqiyu01]

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-le...@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-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

On Wed, 2022-09-28 at 08:40 +0200, Neal Gompa wrote:
> On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen 
> 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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191
> > :
> > 
> > > 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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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 


[1] https://rpmfusion.org/CommonBugs


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Adam Williamson]

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/le...@lists.fedoraproject.org/thread/WUQNAB4EPWSJMMVECL2TZGKB5KIDESII/#WUQNAB4EPWSJMMVECL2TZGKB5KIDESII
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:38 AM Tommy Nguyen  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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191:
>
> > 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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322383#post1322383


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

[Adam Williamson]

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?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tommy Nguyen]

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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191:

> 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.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Nicolas Chauvet]

Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
>
> On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> wrote:
> >
> > Hi,
> >
> > since this mesa change ( 
> > 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 ).
> >
> > 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:12 AM Julian Sikorski  wrote:
>
> Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:
> > Hi,
> >
> > since this mesa change (
> > 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 
> >  ).
> >
> > 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.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Julian Sikorski]

Am 27.09.22 um 20:01 schrieb Frantisek Zatloukal:

Hi,

since this mesa change ( 
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  ).


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-vulkan-mesa-gallium3d/1321663-mesa-can-now-be-built-with-select-video-codecs-disabled-for-software-patent-concerns?p=1322191#post1322191

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Tom Seewald]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:53 AM Michael Cronenworth  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Neal Gompa]

On Tue, Sep 27, 2022 at 9:53 PM Michael Cronenworth  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Dan Horák]

On Wed, 28 Sep 2022 05:36:01 +1000
David Airlie  wrote:

> On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth  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/le...@lists.fedoraproject.org/message/M4LTGLHY5JX42IHC45WNWB5FH2JIFMAS/


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:11 AM Chris Adams  wrote:
>
> Once upon a time, David Airlie  said:
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > > since this mesa change ( 
> > > 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 ).
> > >
> > > 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Peter Robinson]

On Tue, Sep 27, 2022 at 8:11 PM Chris Adams  wrote:
>
> Once upon a time, David Airlie  said:
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > > since this mesa change ( 
> > > 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 ).
> > >
> > > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Chris Adams]

Once upon a time, David Airlie  said:
> On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> wrote:
> > since this mesa change ( 
> > 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 ).
> >
> > 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?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  wrote:
>
> Hi,
>
> since this mesa change ( 
> 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 ).
>
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Mesa in F37- vaapi support disabled for h264/h265/vc1

[Frantisek Zatloukal]

Hi,

since this mesa change (
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 ).

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!

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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