ffmpeg for EL7
Orion Poplawski
orion at cora.nwra.com
Fri Aug 26 21:17:40 CEST 2016
On 08/25/2016 02:01 AM, Nicolas Chauvet wrote:
> 2016-08-24 20:19 GMT+02:00 Orion Poplawski <orion at cora.nwra.com>:
>> On 08/24/2016 11:35 AM, Nicolas Chauvet wrote:
>>> 2016-08-24 18:55 GMT+02:00 Orion Poplawski <orion at cora.nwra.com>:
>>>> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
>>>>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion at cora.nwra.com>:
>>>>>> Does anyone here have any ffmpeg knowledge that would give a reason for
>>>>>> preferring anything other than the current ffmpeg 3.1.1 for EL7? Does ffmpeg
>>>>>> have a long-term-support branch?
>>>>> There is issue with stable vlc-2.2x which I plan to have in el7, also
>>>>> the current kodi 0.16 version doesn't cope well with ffmpeg 3.1x
>>>>> I think it's easier to have ffmpeg 3.0x in el7, but then I don't know
>>>>> other dependencies that might have issue.
>>>>
>>>> Given the pain of later updates, it might be worth waiting a bit for vlc 3.0
>>>> and kodi 0.17 to land (or get sufficiently stable).
>>>
>>> I don't expect vlc-3 in EL7 as a first step. VLC 2.2x is there and
>>> more relevant for long term support, and specially since EL8 shoudn't
>>> be that far away for vlc-3x.
>>
>> Okay, although based on past timescales I wouldn't expect EL8 until Q4 2017.
> yep, will have a strong stable vlc-3 by then ;)
>
>>> Based on that ffmpeg-2.8x seems a more relevant ABI to start with EL7.
>>> And later we can still update the whole multimedia stack with
>>> ffmpeg-3.1+ vlc3+ koji17 then introduce a fmpeg-2.8x as ffmpeg-compat
>>> to keep "stable ABI"
>>>
>>> This has always been a problem to build latest ffmpeg in stable
>>> release without to break ABI. we should probably have a "SCL build of
>>> ffmpeg" for those that will only rely on the ffmpeg binaries or fast
>>> moving projects using the ffmpeg libraries.
>>
>> One suggestion that's been getting more traction on the EPEL side of things is
>> to just start with versioned packages that can co-exist. So start with
>> ffmpeg2.8 and ffmpeg3.0 from the start.
>
> I don't quite understand the proposition related to ffmpeg. Using
> version in name doesn't seem to say which one should be chosen by
> default for link.
At run-time this is handled by soname. At build time, we have a couple options:
- Only one package could provides the "ffmpeg-devel" name - this would be the
"preferred" one. Packages that needed a different version could require the
versioned name.
- This would also be the default version for people doing "yum install ffmpeg".
or as I've done it now, where they all provide the base name, so you get the
latest when you ask for just ffmpeg, but you can BR/R the versioned one if
necessary. This also allows any installed version to satisfy the generic
"ffmpeg"/"ffmpeg-devel" requires.
# yum install ffmpeg
Resolving Dependencies
--> Running transaction check
---> Package ffmpeg3.1.x86_64 0:3.1.2-1.el7 will be installed
--> Processing Dependency: ffmpeg3.1-libs(x86-64) = 3.1.2-1.el7 for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavcodec.so.57(LIBAVCODEC_57)(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavdevice.so.57(LIBAVDEVICE_57)(64bit) for
package: ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavfilter.so.6(LIBAVFILTER_6)(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavformat.so.57(LIBAVFORMAT_57)(64bit) for
package: ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavresample.so.3(LIBAVRESAMPLE_3)(64bit) for
package: ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavutil.so.55(LIBAVUTIL_55)(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libpostproc.so.54(LIBPOSTPROC_54)(64bit) for
package: ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libswresample.so.2(LIBSWRESAMPLE_2)(64bit) for
package: ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libswscale.so.4(LIBSWSCALE_4)(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavcodec.so.57()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavdevice.so.57()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavfilter.so.6()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavformat.so.57()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavresample.so.3()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libavutil.so.55()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libpostproc.so.54()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libswresample.so.2()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Processing Dependency: libswscale.so.4()(64bit) for package:
ffmpeg3.1-3.1.2-1.el7.x86_64
--> Running transaction check
---> Package ffmpeg3.1-libavdevice.x86_64 0:3.1.2-1.el7 will be installed
---> Package ffmpeg3.1-libs.x86_64 0:3.1.2-1.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================
Package Arch Version Repository Size
========================================================================
Installing:
ffmpeg3.1 x86_64 3.1.2-1.el7 ffmpeg 1.4 M
Installing for dependencies:
ffmpeg3.1-libavdevice x86_64 3.1.2-1.el7 ffmpeg 82 k
ffmpeg3.1-libs x86_64 3.1.2-1.el7 ffmpeg 5.9 M
Transaction Summary
========================================================================
Install 1 Package (+2 Dependent packages)
> Specially as ffmpeg doesn't do symbol version, if one process has
> dependencies using both version, it will crash.
At least with ffmpeg 2/3, all sonames are different.
> Also ffmpeg as a 3month release cycle, does it mean a new review each time ?
>
> Using ffmpeg/ffmpeg-compat or ffmpeg-compat28 means to use ffmpeg by
> default then ffmpeg-compat28 (with only libs) for the few projects
> that needs it.
As I see it, the problem with shipping as "ffmpeg", is that at some point
you'll have to upgrade it to a major new version. And EL folk don't like
having that thrust on them. With the ffmpegX.Y model, they can have explicit
control over which version it installed and when to change from one to the next.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion at nwra.com
Boulder, CO 80301 http://www.nwra.com
More information about the rpmfusion-developers
mailing list