On 12/18/22 00:24, Neal Gompa wrote:
On Sun, Dec 18, 2022 at 12:21 AM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 12/18/22 00:19, Neal Gompa wrote:
>> On Sun, Dec 18, 2022 at 12:18 AM Demi Marie Obenour
>> <demiobenour(a)gmail.com> wrote:
>>>
>>> On 12/17/22 05:31, Vitaly Zaitsev via devel wrote:
>>>> On 17/12/2022 06:29, Bob Hepple wrote:
>>>>> Now that we have ffmpeg-free we have an opportunity to move
wf-recorder
>>>>> to the mainstream and change the default codec to the
non-proprietary
>>>>> libopenh264.
>>>>
>>>> You still can't link against openh264 because Fedora can't ship
it an
>>>> even have in Koji's buildroot, you can only use dlopen().
>>>
>>> Could Fedora ship a shim library that exposed the same API and used
>>> dlopen() internally?
>>
>> In that case, why wouldn't we just adjust the program to dlopen() the
>> library itself? We already did it for ffmpeg and webrtc, after all.
>
> Because that requires per-program patches, whereas this approach does
> not.
And that approach means applications will crash instead of being
modified to gracefully handle the library missing.
If the libopenh264 API allows returning errors, then the shim could just
return an error from all API functions. Otherwise, that is what Requires:
is for. (Build stuff can use a stub package that never gets shipped.)
For the specific case of ffmpeg, another option would be to pretend that
the non-libopenh264 codecs exist, but have them just wrap libopenh264
internally.
--
Sincerely,
Demi Marie Obenour (she/her/hers)