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?

On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: > 2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >> 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.

Seems reasonable for me. I've filed a request for a EL7 build of ocl-icd here: https://bugzilla.redhat.com/show_bug.cgi?id=1369574 > Thx for bootstraping el7 ! Thanks for making it possible! FWIW - I'm focusing on mplayer deps as that's my main use from rpmfusion.

2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: > 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.

2016-08-24 18:55 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: > On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: >> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >>> 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.

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.

On 08/24/2016 08:19 PM, Orion Poplawski wrote: > > > 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 would suggest to extend this approach to Fedora-24, to make packaging a vlc-2.x possible, because vlc-3.0 in fc24 is "just plain unusable" for me and vlc-2.x doesn't seem to support ffmpeg-3.0.

On 08/24/2016 11:35 AM, Nicolas Chauvet wrote: > 2016-08-24 18:55 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: >>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >>>> 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.

> 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.

On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:

> Specially as ffmpeg doesn't do symbol version, if one process has > dependencies using both version, it will crash. AFAIU, as long as these packages are properly linked (and not libraries not being dlopened), package deps on SONAMEs would conflict and thus prevent such problems.

On 08/25/2016 02:28 PM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: > [...] >>> Specially as ffmpeg doesn't do symbol version, if one process has >>> dependencies using both version, it will crash. >> AFAIU, as long as these packages are properly linked (and not libraries >> not being dlopened), package deps on SONAMEs would conflict and thus >> prevent such problems. > > The point is that not all SONAMEs change with each FFmpeg version bump, > so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same > SONAMEs. This would mean these are ABI compatible. I haven't tried to check and verify actual situation wrt. ffmpeg.

On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: > [...] >>> Specially as ffmpeg doesn't do symbol version, if one process has >>> dependencies using both version, it will crash. >> AFAIU, as long as these packages are properly linked (and not libraries >> not being dlopened), package deps on SONAMEs would conflict and thus >> prevent such problems. > > The point is that not all SONAMEs change with each FFmpeg version bump, > so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same > SONAMEs. Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different

On 08/25/2016 02:30 PM, Nicolas Chauvet wrote: > 2016-08-25 22:19 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >> On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote: >>> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >>>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: >>> [...] >>>>> Specially as ffmpeg doesn't do symbol version, if one process has >>>>> dependencies using both version, it will crash. >>>> AFAIU, as long as these packages are properly linked (and not libraries >>>> not being dlopened), package deps on SONAMEs would conflict and thus >>>> prevent such problems. >>> >>> The point is that not all SONAMEs change with each FFmpeg version bump, >>> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same >>> SONAMEs. >> >> Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different > I've strictly no question about how not to make conflict between > theses, so I'm not even looking at your spec since I don't think they > will bring any value to the "discution". > Please have a look at ffmpeg-compat for not conflicting with -devel > Also please have a look this for not conflicting with ffmpeg version > of the same ABI: > http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.20100612svn.fc... > Here are the ABI from ffmpeg upstream: http://ffmpeg.org/download.html#releases Well, I'll give you the courtesy of looking at your specs, even if you won't do the same for me.

The oldest FFmpeg branch currently listed on the download page is 2.5.x, which was branched in December 2014 and last updated in February 2016. The last major ABI bump was between 2.8 and 3.0. I do think that it makes sense to ship 2.8.7 and 3.1.2 in EPEL7 and drop 2.8.x when the next ABI-incompatible version is released. Upgrades between minor versions should be possible without rebuilds.

2016-08-26 0:23 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote: >> 2016-08-25 22:19 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >>> On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote: >>>> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >>>>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: >>>> [...] >>>>>> Specially as ffmpeg doesn't do symbol version, if one process has >>>>>> dependencies using both version, it will crash. >>>>> AFAIU, as long as these packages are properly linked (and not libraries >>>>> not being dlopened), package deps on SONAMEs would conflict and thus >>>>> prevent such problems. >>>> >>>> The point is that not all SONAMEs change with each FFmpeg version bump, >>>> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same >>>> SONAMEs. >>> >>> Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different >> I've strictly no question about how not to make conflict between >> theses, so I'm not even looking at your spec since I don't think they >> will bring any value to the "discution". >> Please have a look at ffmpeg-compat for not conflicting with -devel >> Also please have a look this for not conflicting with ffmpeg version >> of the same ABI: >> http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.20100612svn.fc... >> Here are the ABI from ffmpeg upstream: http://ffmpeg.org/download.html#releases > > Well, I'll give you the courtesy of looking at your specs, even if you won't > do the same for me. You are still in the "How not to make conflicts" question whereas this question is out of interest over "which version to choose for a general usage."

You are still in the false premise that you can have any versions as soon as they do not conflict for general usage and let packagers choose theirs.

You have also ignored several of my earlier comments, so I wouldn't say courtesy is on your side here.

This discussion has gone wrong, so I'm dropping here.

On Sex, 2016-08-26 at 13:25 -0600, Orion Poplawski wrote: > > On 08/26/2016 01:35 AM, Nicolas Chauvet wrote: > > > > > > 2016-08-26 0:23 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: > > > > > > > > > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote: > > > > > > > > > > > > 2016-08-25 22:19 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.c > > > > om > > > > > > > > > > : > > > > > > > > > > On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thursday, 25 August 2016 at 10:24, Ralf Corsepius > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Specially as ffmpeg doesn't do symbol version, if one > > > > > > > > process has > > > > > > > > dependencies using both version, it will crash. > > > > > > > AFAIU, as long as these packages are properly linked > > > > > > > (and > > > > > > > not libraries > > > > > > > not being dlopened), package deps on SONAMEs would > > > > > > > conflict and thus > > > > > > > prevent such problems. > > > > > > The point is that not all SONAMEs change with each FFmpeg > > > > > > version bump, > > > > > > so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have > > > > > > mostly the same > > > > > > SONAMEs. > > > > > Here is an attempt at ffmpeg2.8 and ffmpeg3.0.  This relies > > > > > on different > > > > I've strictly no question about how not to make conflict > > > > between > > > > theses, so I'm not even looking at your spec since I don't > > > > think they > > > > will bring any value to the "discution". > > > > Please have a look at ffmpeg-compat for not conflicting with > > > > -devel > > > > Also please have a look this for not conflicting with ffmpeg > > > > version > > > > of the same ABI: > > > > http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.20 > > > > 10 > > > > 0612svn.fc13.src.rpm > > > > Here are the ABI from ffmpeg upstream: http://ffmpeg.org/down > > > > lo > > > > ad.html#releases > > > Well, I'll give you the courtesy of looking at your specs, even > > > if you won't > > > do the same for me. > > You are still in the "How not to make conflicts" question whereas > > this > > question is out of interest over "which version to choose for a > > general usage." > I'm trying to be concerned with the question - "What happens when > the > version > needed for general usage changes?  How can that be done in the > least > impactful > way by planning for that transition now?" > > > > > > > You are still in the false premise that you can have any versions > > as > > soon as they do not conflict for general usage and let packagers > > choose theirs. > Why is this a false premise?  It seems perfectly reasonable to have > ffmpeg2.8 > to start, and add a ffmpeg3.X when there is a critical mass of > other > software > that requires it.  And then keep sliding this forward as necessary, > and then > when necessary dropping the old ffmpeg2.8, etc. when they are > unsupportable. > We're talking 8 more years for EL7 to be around. > The 8 years argument is good but one point is need keep it simple. From what I see, end use shouldn't have choices, we build applications against the main ffpmeg , we already have ffmpeg-compat, if in 4 years we need update ffmpeg, we update the main ffmpeg , if something still need old ffmpeg we can make one second ffmpeg-compat-2.8 or ffmpeg-3 (if want innovate) but when we need that ? in 4 years, now we need just one main ffmpeg . Don't like the idea have the possibility of install lots of versions of ffmpeg , end user just need one and shouldn't worry about what version is, your solution is more complicated, may give much more work and I don't see great benefits. > > > > > > > You have also ignored several of my earlier comments, so I > > wouldn't > > say courtesy is on your side here. > I certainly didn't do so intentionally.  I've just replied to an > earlier > email, perhaps that helps. > > > > > > > This discussion has gone wrong, so I'm dropping here. > Deep breath, start again. >

On 08/31/2016 07:11 PM, Sérgio Basto wrote: > Orion Poplawski, I'd like have an agreement on how put ffmpeg in epel7. > What you say ? may we have one ffmpeg ? , should we have multi ffmpegs > ? etc. So would I. But I seem to have offended Nicolas enough that discussion has stopped. I think that the ffmpegX.Y packages allow for a better transition in the future when 2.8 becomes unsupported, as well as allowing packages that need 3.1 to use it now. But it is definitely more complex and there may be other gotchas. However, I do feel that this is the way more and more packages are going, especially in EPEL. For example, with zabbix, we have zabbix20 and zabbix22, but no "zabbix". If the consensus is to ship 2.8 as ffmpeg now, and then presumably switch to 3.X later and ship ffmpeg-compat-2.8 later, that seems workable as well. Traditionally compat packages have only shipped runtime libs, but you could ship the full thing as well if needed.

As a tangential question - anyone know why the ffmpeg package doesn't use the %configure macro?

2016-08-24 20:19 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: > On 08/24/2016 11:35 AM, Nicolas Chauvet wrote: >> 2016-08-24 18:55 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >>> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: >>>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <orion(a)cora.nwra.com&gt;: >>>>> 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.

Specially as ffmpeg doesn't do symbol version, if one process has dependencies using both version, it will crash.

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.