11:29 p.m.
I am the packager for wf-recorder (a wl-roots/wayland screen recorder)
which presently resides in rpmfusion - it uses proprietary ffmpeg codecs by
default (libx246).
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. This woud be in rawhide/f38 and on.
This all works fine in testing on f37. The fly in the ointment is that if
ffmpeg/rpmfusion is installed in place of ffmpeg-free, then wf-recorder can
no longer access libopenh264 and fails with an error. There is a workaround
in the use of the option -c libx264.
Several solutions occur to me and I'm looking for guidance on which path to
take:
0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier.
A. compile wf-recorder as shipped by upstream with the default libx264 -
the '-c libopenh264' workaround would be needed if ffmpeg-free is
installed. This annoys users who install stock fedora.
B. compile wf-recorder with libopenh264 as the default - the '-c libx264'
workaround would be needed if ffmpeg/rpmfusion is installed and would annoy
those users.
C. leave wf-recorder in rpmfusion and create a wf-recorder-free package by
analogy to ffmpeg (this might be obscure as it's not likely to get much
publicity - and annoy everyone sooner or later)
D. the best option might be to choose a codec common to both ffmpeg and
ffmpeg-free. I'm not terribly au fait with the various codecs so which
would I choose? These codecs appear to be in both packages:
h263_v4l2m2m V4L2 mem2mem H.263 encoder wrapper (codec h263)
h264_amf AMD AMF H.264 Encoder (codec h264)
h264_nvenc NVIDIA NVENC H.264 encoder (codec h264)
h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel
Quick Sync Video acceleration) (codec h264)
h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264)
h264_vaapi H.264/AVC (VAAPI) (codec h264)
hevc_amf AMD AMF HEVC encoder (codec hevc)
hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec
hevc)
hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc)
hevc_vaapi H.265/HEVC (VAAPI) (codec hevc)
libaom-av1 libaom AV1 (codec av1)
libopenjpeg OpenJPEG JPEG 2000 (codec jpeg2000)
librav1e librav1e AV1 (codec av1)
libsvtav1 SVT-AV1(Scalable Video Technology for AV1) encoder
(codec av1)
libtheora libtheora Theora (codec theora)
libvpx libvpx VP8 (codec vp8)
libvpx-vp9 libvpx VP9 (codec vp9)
libwebp_anim libwebp WebP image (codec webp)
libwebp libwebp WebP image (codec webp)
mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec
mjpeg)
mjpeg_vaapi MJPEG (VAAPI) (codec mjpeg)
mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration)
(codec mpeg2video)
mpeg2_vaapi MPEG-2 (VAAPI) (codec mpeg2video)
mpeg4_v4l2m2m V4L2 mem2mem MPEG4 encoder wrapper (codec mpeg4)
vp8_v4l2m2m V4L2 mem2mem VP8 encoder wrapper (codec vp8)
vp8_vaapi VP8 (VAAPI) (codec vp8)
vp9_qsv VP9 video (Intel Quick Sync Video acceleration)
(codec vp9)
vp9_vaapi VP9 (VAAPI) (codec vp9)
12:16 a.m.
On 12/16/22 21:29, Bob Hepple wrote:
I am the packager for wf-recorder (a wl-roots/wayland screen
recorder)
which presently resides in rpmfusion - it uses proprietary ffmpeg codecs
by default (libx246).
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. This woud be in rawhide/f38 and on.
This all works fine in testing on f37. The fly in the ointment is that
if ffmpeg/rpmfusion is installed in place of ffmpeg-free, then
wf-recorder can no longer access libopenh264 and fails with an error.
There is a workaround in the use of the option -c libx264.
Several solutions occur to me and I'm looking for guidance on which path
to take:
0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier.
A. compile wf-recorder as shipped by upstream with the default libx264 -
the '-c libopenh264' workaround would be needed if ffmpeg-free is
installed. This annoys users who install stock fedora.
B. compile wf-recorder with libopenh264 as the default - the '-c
libx264' workaround would be needed if ffmpeg/rpmfusion is installed and
would annoy those users.
C. leave wf-recorder in rpmfusion and create a wf-recorder-free package
by analogy to ffmpeg (this might be obscure as it's not likely to get
much publicity - and annoy everyone sooner or later)
D. the best option might be to choose a codec common to both ffmpeg and
ffmpeg-free. I'm not terribly au fait with the various codecs so which
would I choose? These codecs appear to be in both packages:
Can you have it try the alternate codec if the first option fails to load?
12:40 a.m.
On 12/16/22 21:29, Bob Hepple wrote:
I am the packager for wf-recorder (a wl-roots/wayland screen
recorder)
which presently resides in rpmfusion - it uses proprietary ffmpeg codecs
by default (libx246).
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. This woud be in rawhide/f38 and on.
Thanks for considering that!
f37 would be nice too. ffmpeg-free is available in this release, so
nothing prevents moving wf-recorder to Fedora 37 repos.
This all works fine in testing on f37. The fly in the ointment is
that
if ffmpeg/rpmfusion is installed in place of ffmpeg-free, then
wf-recorder can no longer access libopenh264 and fails with an error.
There is a workaround in the use of the option -c libx264.
Several solutions occur to me and I'm looking for guidance on which path
to take:
0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier.
A. compile wf-recorder as shipped by upstream with the default libx264 -
the '-c libopenh264' workaround would be needed if ffmpeg-free is
installed. This annoys users who install stock fedora.
B. compile wf-recorder with libopenh264 as the default - the '-c
libx264' workaround would be needed if ffmpeg/rpmfusion is installed and
would annoy those users. > C. leave wf-recorder in rpmfusion and create a
wf-recorder-free package
by analogy to ffmpeg (this might be obscure as it's not likely to get
much publicity - and annoy everyone sooner or later)
Option C sounds like too much maintenance burden for a default option value.
D. the best option might be to choose a codec common to both ffmpeg
and
ffmpeg-free. I'm not terribly au fait with the various codecs so which
would I choose? These codecs appear to be in both packages:
h263_v4l2m2m V4L2 mem2mem H.263 encoder wrapper (codec h263)
h264_amf AMD AMF H.264 Encoder (codec h264)
h264_nvenc NVIDIA NVENC H.264 encoder (codec h264)
h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel
Quick Sync Video acceleration) (codec h264)
h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264)
h264_vaapi H.264/AVC (VAAPI) (codec h264)
hevc_amf AMD AMF HEVC encoder (codec hevc)
hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec
hevc)
hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc)
hevc_vaapi H.265/HEVC (VAAPI) (codec hevc)
libaom-av1 libaom AV1 (codec av1)
libopenjpeg OpenJPEG JPEG 2000 (codec jpeg2000)
librav1e librav1e AV1 (codec av1)
libsvtav1 SVT-AV1(Scalable Video Technology for AV1)
encoder (codec av1)
libtheora libtheora Theora (codec theora)
libvpx libvpx VP8 (codec vp8)
libvpx-vp9 libvpx VP9 (codec vp9)
libwebp_anim libwebp WebP image (codec webp)
libwebp libwebp WebP image (codec webp)
mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration)
(codec mjpeg)
mjpeg_vaapi MJPEG (VAAPI) (codec mjpeg)
mpeg2_qsv MPEG-2 video (Intel Quick Sync Video
acceleration) (codec mpeg2video)
mpeg2_vaapi MPEG-2 (VAAPI) (codec mpeg2video)
mpeg4_v4l2m2m V4L2 mem2mem MPEG4 encoder wrapper (codec mpeg4)
vp8_v4l2m2m V4L2 mem2mem VP8 encoder wrapper (codec vp8)
vp8_vaapi VP8 (VAAPI) (codec vp8)
vp9_qsv VP9 video (Intel Quick Sync Video acceleration)
(codec vp9)
vp9_vaapi VP9 (VAAPI) (codec vp9)
I'm not an expert enough to tell what to choose, but at least I can tell
what should be avoided:
- anything h264 or HEVC - these are patented and Fedora won't ship a
software implementation of the encoder for these. (except libopenh264,
but OSTree-based systems won't have even that).
- anything with words vaapi, qsv, v4l2m2m or amf - these only work
with a specific hardware
- image formats - jpeg or webp might be a bad choice for a screen recorder
Next I'm going to suggest to exclude Theora (a bit outdated) and AV1
(which is _slow_ and less widespread, especially in hw decoders).
Huh, that leaves us with VP8 and VP9. I don't know how these compare in
real-time encoding speed but I hope that VP9 encoder is fast enough for
hardware released after 2013 :)
Please, also consult with the upstream - wf-recorder includes default
parameters for libx264/libx265[1], so they could add a good preset for a
royalty-free encoder.
[1]:
https://github.com/ammen99/wf-recorder/blob/master/src/frame-writer.cpp#L47
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
4:31 a.m.
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().
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:18 p.m.
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?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
11:19 p.m.
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.
--
真実はいつも一つ！/ Always, there's only one truth!
11:21 p.m.
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
11:24 p.m.
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.
--
真実はいつも一つ！/ Always, there's only one truth!
11:29 p.m.
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)
8:34 a.m.
On Sunday, December 18, 2022, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 18/12/2022 06:18, Demi Marie Obenour wrote:
> Could Fedora ship a shim library that exposed the same API and used
> dlopen() internally?
>
I doubt. Lawyers will treat this as a patents violation.
Why would they? The patents apply to the algorithm, not to any API.
9:28 a.m.
On 18/12/2022 15:34, drago01 wrote:
Why would they? The patents apply to the algorithm, not to any API.
Help in circumventing patents. For the same reason, the RPM Fusion
repository can't be preloaded.
But technically MPEG LA still can sue Fedora because unsigned builds can
be downloaded from Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=21431
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:32 a.m.
On Sun, Dec 18, 2022 at 10:29 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 18/12/2022 15:34, drago01 wrote:
> Why would they? The patents apply to the algorithm, not to any API.
Help in circumventing patents. For the same reason, the RPM Fusion
repository can't be preloaded.
But technically MPEG LA still can sue Fedora because unsigned builds can
be downloaded from Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=21431
No, they cannot. If you try, you get redirected to a wiki page
explaining why you can't.
--
真実はいつも一つ！/ Always, there's only one truth!
4:34 p.m.
On Sun, Dec 18, 2022 at 3:29 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 18/12/2022 15:34, drago01 wrote:
> Why would they? The patents apply to the algorithm, not to any API.
Help in circumventing patents.
Your lawyer may vary in regards to the advice
they provide as to an organization's exposure
to claims of "contributory infringement" for any
specific case(*) but with exceptions(**), one
rarely wants to find out what a court in
Waco TX(***) might decide.
(*) And it is always about the details.
Generalities may provide guidance, but
the specifics matter (even things explicitly
stated as a violation may be allowed if
the details support an exception).
(**) There are sometimes individuals or
organizations who explicitly choose to take
an action in order to challenge specific laws
or regulations, but such cases can also come
with risks (and are often done in a way to
attempt to limit the potential losses).
(***) The venue shopping that ended up with
many patent related cases being brought in
Waco TX has been mostly eliminated, but
most organizations do not wish to go to any
court in the first place (even if you win you
lose after spending millions of dollars in legal
fees, and if you lose it can be orders of
magnitude more).
8:33 a.m.
* Demi Marie Obenour:
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?
Isn't GStreamer this API, and doesn't Fluendo provide compatible codecs?
Thanks,
Florian
8:35 a.m.
On Mon, Dec 19, 2022 at 9:33 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Demi Marie Obenour:
> 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?
Isn't GStreamer this API, and doesn't Fluendo provide compatible codecs?
Yup. They also apparently also developed a way to use GStreamer with
FFmpeg applications:
https://fluendo.com/en/products/enterprise/fluendo-ffmpeg/
Shame it's not open source and contributed to FFmpeg itself. That'd be
really useful...
--
真実はいつも一つ！/ Always, there's only one truth!
4:43 a.m.
On Sat, Dec 17, 2022 at 12:29 AM Bob Hepple <bob.hepple(a)gmail.com> wrote:
I am the packager for wf-recorder (a wl-roots/wayland screen recorder) which presently
resides in rpmfusion - it uses proprietary ffmpeg codecs by default (libx246).
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. This woud be in
rawhide/f38 and on.
This all works fine in testing on f37. The fly in the ointment is that if
ffmpeg/rpmfusion is installed in place of ffmpeg-free, then wf-recorder can no longer
access libopenh264 and fails with an error. There is a workaround in the use of the option
-c libx264.
Several solutions occur to me and I'm looking for guidance on which path to take:
0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier.
A. compile wf-recorder as shipped by upstream with the default libx264 - the '-c
libopenh264' workaround would be needed if ffmpeg-free is installed. This annoys users
who install stock fedora.
B. compile wf-recorder with libopenh264 as the default - the '-c libx264'
workaround would be needed if ffmpeg/rpmfusion is installed and would annoy those users.
C. leave wf-recorder in rpmfusion and create a wf-recorder-free package by analogy to
ffmpeg (this might be obscure as it's not likely to get much publicity - and annoy
everyone sooner or later)
D. the best option might be to choose a codec common to both ffmpeg and ffmpeg-free.
I'm not terribly au fait with the various codecs so which would I choose? These codecs
appear to be in both packages:
I suggest going with option D, and my suggestion is libvpx-vp9.
libvpx-vp9 is common to both and reasonably fast. I made a similar
change to O3DE some time ago for similar reasons:
https://github.com/o3de/o3de/commit/add4ad4ad42fe36b04e80b3ee4ab2358fe5fd35e
--
真実はいつも一つ！/ Always, there's only one truth!
6:48 p.m.
Thanks to all of you for the helpful hints!
I will release in f37 too as suggested - I understand that I can only
retire from rpmfusion in rawhide/f38, but I guess that's OK.
libvpx-vp9 does indeed work in both ffmpegs - the only downside is that it
takes >25s to terminate on SIGINT ^C (the normal way to stop wf-recorder).
Many users will grow impatient and use pkill/SIGTERM and get a corrupt mp4
file - I certainly did at first. Not the best experience. I have taken this
up with upstream.
libvpx (vp8) does not work at all - again, maybe an upstream issue.
So I don't have an ideal codec candidate that I am quite happy to unleash
on the world at the moment - upstream may give me a clue.
Or should I just go ahead with libvpx-vp9?
Cheers
Bob
On Sat, 17 Dec 2022 at 20:44, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Dec 17, 2022 at 12:29 AM Bob Hepple
<bob.hepple(a)gmail.com> wrote:
>
> I am the packager for wf-recorder (a wl-roots/wayland screen recorder)
which presently resides in rpmfusion - it uses proprietary ffmpeg codecs by
default (libx246).
>
> 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. This woud be in rawhide/f38 and on.
>
> This all works fine in testing on f37. The fly in the ointment is that
if ffmpeg/rpmfusion is installed in place of ffmpeg-free, then wf-recorder
can no longer access libopenh264 and fails with an error. There is a
workaround in the use of the option -c libx264.
>
> Several solutions occur to me and I'm looking for guidance on which path
to take:
>
> 0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier.
> A. compile wf-recorder as shipped by upstream with the default libx264 -
the '-c libopenh264' workaround would be needed if ffmpeg-free is
installed. This annoys users who install stock fedora.
> B. compile wf-recorder with libopenh264 as the default - the '-c
libx264' workaround would be needed if ffmpeg/rpmfusion is installed and
would annoy those users.
> C. leave wf-recorder in rpmfusion and create a wf-recorder-free package
by analogy to ffmpeg (this might be obscure as it's not likely to get much
publicity - and annoy everyone sooner or later)
> D. the best option might be to choose a codec common to both ffmpeg and
ffmpeg-free. I'm not terribly au fait with the various codecs so which
would I choose? These codecs appear to be in both packages:
>
I suggest going with option D, and my suggestion is libvpx-vp9.
libvpx-vp9 is common to both and reasonably fast. I made a similar
change to O3DE some time ago for similar reasons:
https://github.com/o3de/o3de/commit/add4ad4ad42fe36b04e80b3ee4ab2358fe5fd35e
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
6:53 p.m.
On Sat, Dec 17, 2022 at 7:49 PM Bob Hepple <bob.hepple(a)gmail.com> wrote:
Thanks to all of you for the helpful hints!
I will release in f37 too as suggested - I understand that I can only retire from
rpmfusion in rawhide/f38, but I guess that's OK.
libvpx-vp9 does indeed work in both ffmpegs - the only downside is that it takes >25s
to terminate on SIGINT ^C (the normal way to stop wf-recorder). Many users will grow
impatient and use pkill/SIGTERM and get a corrupt mp4 file - I certainly did at first. Not
the best experience. I have taken this up with upstream.
libvpx (vp8) does not work at all - again, maybe an upstream issue.
So I don't have an ideal codec candidate that I am quite happy to unleash on the
world at the moment - upstream may give me a clue.
Or should I just go ahead with libvpx-vp9?
What if you use libvpx-vp9 for video, opus for audio, and use an mkv
file extension? Does it work better?
--
真実はいつも一つ！/ Always, there's only one truth!
9:35 p.m.
What if you use libvpx-vp9 for video, opus for audio, and use an mkv
file
extension? Does it work better?
No, it doesn't ...
$ wf-recorder -c libvpx-vp9 -C opus -f recording.mkv
$ file recording.mkv
recording.mkv: Matroska data
... but it still takes a looong time to build the index.
On VP9:
Maybe I'll just settle on libvpx-vp9 and patch the source so that on SIGINT
it prints "SIGINT received: please wait for index building". That's the
easiest fix - but maybe we'll get 'oh fedora is soooo sloooow' whinges.
On VP8:
alabastr gave me the hint that using "--muxer webm" would make v8 work -
and it terminates quickly, so this is another possibility.
The only question is - is it naf to have a webm in an mp4? Also, is it too
naf to patch the source to force '--muxer webm' if codec is detected as
libvpx?
$ wf-recorder -c libvpx -m webm
Output file "recording.mp4" exists. Overwrite? Y/n: y
selected region 0,0 0x0
Using video filter: null
[libvpx @ 0x7f6d40001e80] v1.12.0
[libvpx @ 0x7f6d40001e80] Neither bitrate nor constrained quality
specified, using default CRF of 32 and bitrate of 256kbit/sec
Output #0, webm, to 'recording.mp4':
Stream #0:0: Video: vp8, yuv420p(pc), 1920x1080 [SAR 1:1 DAR 16:9],
q=2-31, 256 kb/s
^C
$ file recording.mp4
recording.mp4: WebM <<<<< TOO NAF?
On Sun, 18 Dec 2022 at 10:54, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Dec 17, 2022 at 7:49 PM Bob Hepple
<bob.hepple(a)gmail.com> wrote:
>
> Thanks to all of you for the helpful hints!
>
> I will release in f37 too as suggested - I understand that I can only
retire from rpmfusion in rawhide/f38, but I guess that's OK.
>
> libvpx-vp9 does indeed work in both ffmpegs - the only downside is that
it takes >25s to terminate on SIGINT ^C (the normal way to stop
wf-recorder). Many users will grow impatient and use pkill/SIGTERM and get
a corrupt mp4 file - I certainly did at first. Not the best experience. I
have taken this up with upstream.
>
> libvpx (vp8) does not work at all - again, maybe an upstream issue.
>
> So I don't have an ideal codec candidate that I am quite happy to
unleash on the world at the moment - upstream may give me a clue.
>
> Or should I just go ahead with libvpx-vp9?
>
What if you use libvpx-vp9 for video, opus for audio, and use an mkv
file extension? Does it work better?
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
10 p.m.
On Sat, Dec 17, 2022, 10:35 PM Bob Hepple <bob.hepple(a)gmail.com> wrote:
> What if you use libvpx-vp9 for video, opus for audio, and use an
mkv
file extension? Does it work better?
No, it doesn't ...
$ wf-recorder -c libvpx-vp9 -C opus -f recording.mkv
$ file recording.mkv
recording.mkv: Matroska data
... but it still takes a looong time to build the index.
On VP9:
Maybe I'll just settle on libvpx-vp9 and patch the source so that on
SIGINT it prints "SIGINT received: please wait for index building". That's
the easiest fix - but maybe we'll get 'oh fedora is soooo sloooow' whinges.
On VP8:
alabastr gave me the hint that using "--muxer webm" would make v8 work -
and it terminates quickly, so this is another possibility.
The only question is - is it naf to have a webm in an mp4? Also, is it too
naf to patch the source to force '--muxer webm' if codec is detected as
libvpx?
$ wf-recorder -c libvpx -m webm
Output file "recording.mp4" exists. Overwrite? Y/n: y
selected region 0,0 0x0
Using video filter: null
[libvpx @ 0x7f6d40001e80] v1.12.0
[libvpx @ 0x7f6d40001e80] Neither bitrate nor constrained quality
specified, using default CRF of 32 and bitrate of 256kbit/sec
Output #0, webm, to 'recording.mp4':
Stream #0:0: Video: vp8, yuv420p(pc), 1920x1080 [SAR 1:1 DAR 16:9],
q=2-31, 256 kb/s
^C
$ file recording.mp4
recording.mp4: WebM <<<<< TOO NAF?
It seems reasonable to me. VP8 + Opus on WebM is very well supported. Thou
should probably patch the default file extension in the code and
documentation too.
493
days inactive
495
days old
21 comments
9 participants
participants (9)
-
Aleksei Bavshin -
Bob Hepple -
Demi Marie Obenour -
drago01 -
Florian Weimer -
Gary Buhrmaster -
Neal Gompa -
Samuel Sieb -
Vitaly Zaitsev