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)
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:
- 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?
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:
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 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().
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?
On Sun, Dec 18, 2022 at 12:18 AM Demi Marie Obenour demiobenour@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.
On 12/18/22 00:19, Neal Gompa wrote:
On Sun, Dec 18, 2022 at 12:18 AM Demi Marie Obenour demiobenour@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.
On Sun, Dec 18, 2022 at 12:21 AM Demi Marie Obenour demiobenour@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@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.
On 12/18/22 00:24, Neal Gompa wrote:
On Sun, Dec 18, 2022 at 12:21 AM Demi Marie Obenour demiobenour@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@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.
On Sunday, December 18, 2022, Vitaly Zaitsev via devel < devel@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.
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
On Sun, Dec 18, 2022 at 10:29 AM Vitaly Zaitsev via devel devel@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.
On Sun, Dec 18, 2022 at 3:29 PM Vitaly Zaitsev via devel devel@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).
* 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
On Mon, Dec 19, 2022 at 9:33 AM Florian Weimer fweimer@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...
On Sat, Dec 17, 2022 at 12:29 AM Bob Hepple bob.hepple@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:
- 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!
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@gmail.com wrote:
On Sat, Dec 17, 2022 at 12:29 AM Bob Hepple bob.hepple@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:
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, Dec 17, 2022 at 7:49 PM Bob Hepple bob.hepple@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?
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@gmail.com wrote:
On Sat, Dec 17, 2022 at 7:49 PM Bob Hepple bob.hepple@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, Dec 17, 2022, 10:35 PM Bob Hepple bob.hepple@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.
-
Aleksei Bavshin -
Bob Hepple -
Demi Marie Obenour -
drago01 -
Florian Weimer -
Gary Buhrmaster -
Neal Gompa -
Samuel Sieb -
Vitaly Zaitsev