| Summary: | Review request: libav - Audio and video processing libraries | ||
|---|---|---|---|
| Product: | Package Reviews | Reporter: | A. Trande (sagitter) <trpost> |
| Component: | Review Request | Assignee: | RPM Fusion Package Review <rpmfusion-package-review> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | dominik, rosser.bjr, rpmfusion-package-review |
| Priority: | P1 | ||
| Version: | Current | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| URL: | https://libav.org/ | ||
| namespace: | |||
|
Description
A. Trande (sagitter)
2016-09-15 11:46:25 CEST
Scratch builds on f24-free: http://koji.rpmfusion.org/koji/taskinfo?taskID=32497 There is a configuration problem by activating "opencv" support; i'm contacting upstream. FYI, why do you need this library and not ffmpeg instead ?
You are using a build suffix, so it should co-install with ffmpeg-libs but then you cannot mix dependencies build with ffmpeg and thoses built with libva.
We probably need to adapt %{name}-enforcing_system_crypto_policies.patch for ffmpeg. Can you send your patch to ffmpeg upstream also (if needed).
(In reply to Nicolas Chauvet from comment #2) > FYI, why do you need this library and not ffmpeg instead ? > You are using a build suffix, so it should co-install with ffmpeg-libs but > then you cannot mix dependencies build with ffmpeg and thoses built with > libva. > I used ffmpeg too; 'libav' would be simply a (good?) alternative. For example, 'devede' uses both 'ffmpeg' and 'avconv' (from libav). > > We probably need to adapt %{name}-enforcing_system_crypto_policies.patch for > ffmpeg. Can you send your patch to ffmpeg upstream also (if needed). I followed instructions from Fedora guidelines. Let me see if i know how to patch 'ffmpeg'. 'libav-11' looks incompatible with 'opencv-3.1.0', it's disabled on Fedora >24. Package ready for reviewing. SPEC: https://drive.google.com/open?id=0Bz6cHSZ6ZzsYN2NXSUdFSUdpUkU SRPM: https://drive.google.com/open?id=0Bz6cHSZ6ZzsYbVdxcmhSX3ZYb1k Taken. Is there any real need for this package in RPMFusion? FFmpeg is almost 100% backwards compatible with libav. The one package that I thought still used bundled libav (gstreamer1-libav) actually switched back to FFmpeg last year. Most of the symbols in the provided libraries have the same names, so you'd have to be extremely careful not to end up with another package depending on both ffmpeg-libs and libav in the future. Since libvdpau-va-gl (the vaapi-to-vdpau bridge that's required to use Intel GPUs via vdpau) depends on ffmpeg-libs, this might be trickier than you think. Even renaming the libraries and their sonames won't help here. You'd have to rename the symbols, too. So, I'm against including this package in RPMFusion because it introduces a world of potential trouble without any clear technical benefits. But of course I'm open to any counter-arguments. (In reply to Dominik 'Rathann' Mierzejewski from comment #6) > Is there any real need for this package in RPMFusion? FFmpeg is almost 100% > backwards compatible with libav. The one package that I thought still used > bundled libav (gstreamer1-libav) actually switched back to FFmpeg last year. > > Most of the symbols in the provided libraries have the same names, so you'd > have to be extremely careful not to end up with another package depending on > both ffmpeg-libs and libav in the future. Since libvdpau-va-gl (the > vaapi-to-vdpau bridge that's required to use Intel GPUs via vdpau) depends > on ffmpeg-libs, this might be trickier than you think. Even renaming the > libraries and their sonames won't help here. You'd have to rename the > symbols, too. > We could set Conflicts tag to prevent 'libav' installation if FFmpeg is already installed (and viceversa). I don't know which one is the better today, but upstream says that 'FFmpeg' and 'libav' are different especially at API level. I think that if it's possible, we can provide both and leave the choice to the developers. (In reply to Antonio Trande from comment #7) ... > I think that if it's possible, we can provide both and leave the choice to > the developers. A very good quote about this: http://www.islinuxaboutchoice.com/ Package refused. Thanks to all. |