ffmpeg/4.4: Upgrade and properly handle component versioning

[jpilet]

This merge request upgrades ffmpeg/4.4 and adds support for component versioning.
ffmpeg is composed of several libraries. The release page shows versions of all libraries the ffmpeg package contain.

This MR proposes to propagate those versions to the corresponding conan components, so that consumers that check for components version work without modification. I came to this when working on installing gstreamer with conan (I will open a serparate MR for this).

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[CLAassistant]

All committers have signed the CLA.

[ghost]

I detected other pull requests that are modifying ffmpeg/all recipe:

• ffmpeg/4.3.2 #7530

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[jpilet]

I am now reading versions from the source code. Nothing strange added in conandata.yml.

[SSE4]

yes, this is useful. ffmpeg libraries might have different versions:

/usr/lib64/libavcodec.so.56
/usr/lib64/libavcodec.so.56.60.100
/usr/lib64/libavdevice.so.56
/usr/lib64/libavdevice.so.56.4.100
/usr/lib64/libavfilter.so.5
/usr/lib64/libavfilter.so.5.40.101
/usr/lib64/libavformat.so.56
/usr/lib64/libavformat.so.56.40.101
/usr/lib64/libavresample.so.2
/usr/lib64/libavresample.so.2.1.0
/usr/lib64/libavutil.so.54
/usr/lib64/libavutil.so.54.31.100
/usr/lib64/libpostproc.so.53
/usr/lib64/libpostproc.so.53.3.100
/usr/lib64/libswresample.so.1
/usr/lib64/libswresample.so.1.2.101
/usr/lib64/libswscale.so.3
/usr/lib64/libswscale.so.3.1.101

for the Mac failure, you need to add the following code below the line 529 (

conan-center-index/recipes/ffmpeg/all/conanfile.py

Line 529 in 57f7079

self.cpp_info.components["avcodec"].frameworks.append("AudioToolbox")

):

self.cpp_info.components["avdevice"].frameworks.append("AudioToolbox")

[jpilet]

Thanks for the tip! Let's see how it goes with your fix.

[SSE4]

Thanks for the tip! Let's see how it goes with your fix.

okay, it seems like I was wrong. the functions are from CoreAudio framework, not from the AudioToolbox: https://developer.apple.com/documentation/coreaudio/1422524-audioobjectgetpropertydata?language=objc
sorry for the inconvinience

[MartinDelille]

Just for curiosity: what is the goal of filling this version information? I don't find documentation about component version.

[SSE4]

Just for curiosity: what is the goal of filling this version information? I don't find documentation about component version.

one of the scenarios is to support pkg-config version expressions, like:

pkg-config --libs "libavcodec >= 56"

I think meson build files in GStreamer might be using it under the hood: https://gitlab.freedesktop.org/gstreamer/gst-libav/-/blob/master/meson.build#L19

[jpilet]

I think meson build files in GStreamer might be using it under the hood: https://gitlab.freedesktop.org/gstreamer/gst-libav/-/blob/master/meson.build#L19

this is exactly my use case :-)

[jpilet]

OK, I checked, there's no option fore coreaudio. But it seems linked with AudioToolbox.
So I add the framework only if audiotoolbox is on. Let's see if it works like this.

https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3437

[SSE4]

OK, I checked, there's no option fore coreaudio. But it seems linked with AudioToolbox. So I add the framework only if audiotoolbox is on. Let's see if it works like this.

https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3437

yes, looks good!

[prince-chrismc]

How big are the files? I am wondering if package_info runs more then once there might be an annoying performance issue...

See #4319

[SSE4]

these are relatively small text files, about 50 lines:
https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/version.h

[jpilet]

I do not know conan well enough. I do not know what is best. Here are the solutions I have in mind:

1. execute this code at package build time and create a file containing the versions.
   in package_info(), I could read this file
2. I could simply cache the version, so that if package_info() is called multiple times for the same instance, the files are read just once.
3. do both of these.
4. keep it like this. Reading 766 lines from 9 files (~27kb total) in package_info() is OK.

@prince-chrismc @SSE4 what solution seems best?

[SSE4]

keep it simple, no need for caching or creating an extra file for now :)

[MartinDelille]

I had another question: why ffmpeg 4.4 doesn't have three digit in its versioning scheme (like 4.2.1 and 4.3.2) ?

[jpilet]

I do not know. Maybe they think 4.4 looks better than 4.4.0?

[SSE4]

I had another question: why ffmpeg 4.4 doesn't have three digit in its versioning scheme (like 4.2.1 and 4.3.2) ?

it was always the case. they had 4.3, but not 4.3.0. and then added 4.3.1 and 4.3.2.

[conan-center-bot]

All green in build 10 (e6dbff200420479665a84e60865d105c49fb4e63):

• ffmpeg/4.4@:
  All packages built successfully! (All logs)

• ffmpeg/4.3.2@:
  All packages built successfully! (All logs)

• ffmpeg/4.2.1@:
  All packages built successfully! (All logs)

[uilianries]

LGTM

[SpaceIm]

@czoido @uilianries @SSE4

This trick doesn't work with new generator PkgConfigDeps. version attribute in cpp_info components is not documented, is it expected to be supported in conan v2? Should we use pkg_config_custom_content property instead (but I guess it would lead to 2 Version: x.x.x lines)?

conan-io/conan#10629