Re: ffmpeg for EL7

[Dominik 'Rathann' Mierzejewski]

On Thursday, 01 September 2016 at 19:21, Orion Poplawski wrote:
> 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.

+1 to ffmpeg28, ffmpeg31 etc. You just need to watch the ABI changes
carefully and make sure no package ends up depending on both.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg for EL7

[Orion Poplawski]

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.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Sérgio Basto]

Hi, 

Today I realized that ffmpeg-compat is not required by any package [1],
perhaps we may drop it (I still in review some packages that are lost
on migration for new infra (like subtitleripper)) .

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. 

Thanks.

[1] 
dnf --disablerepo='*' --releasever=25 --enablerepo=rpmfusion-free 
--enablerepo=rpmfusion-nonfree repoquery
 --whatrequires ffmpeg-compat --available --refresh 
dnf repoquery --whatrequires ffmpeg-compat --available 




On Sáb, 2016-08-27 at 19:38 +0100, Sérgio Basto wrote:
> 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 :
> > > > 
> > > > 
> > > > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> > > > > 
> > > > > 
> > > > > 2016-08-25 22:19 GMT+02:00 Orion Poplawski  > > > > 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 

Re: ffmpeg for EL7

[Sérgio Basto]

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 :
> > > 
> > > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> > > > 
> > > > 2016-08-25 22:19 GMT+02:00 Orion Poplawski  > > > >:
> > > > > 
> > > > > 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.2010
> > > > 0612svn.fc13.src.rpm
> > > > Here are the ABI from ffmpeg upstream: http://ffmpeg.org/downlo
> > > > 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.
> 
-- 
Sérgio M. B.

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/26/2016 01:17 PM, Orion Poplawski wrote:
> # yum install ffmpeg

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

Just to be clear:

# yum --disablerepo=* --enablerepo=ffmpeg list

Available Packages
ffmpeg2.8.x86_642.8.7-1.el7     ffmpeg
ffmpeg2.8-debuginfo.x86_64  2.8.7-1.el7     ffmpeg
ffmpeg2.8-devel.x86_64  2.8.7-1.el7 ffmpeg
ffmpeg2.8-libavdevice.x86_64
        2.8.7-1.el7     ffmpeg
ffmpeg2.8-libs.x86_64   2.8.7-1.el7     ffmpeg
ffmpeg3.0.x86_643.0.2-4.el7     ffmpeg
ffmpeg3.0-debuginfo.x86_64  3.0.2-4.el7     ffmpeg
ffmpeg3.0-devel.x86_64  3.0.2-4.el7 ffmpeg
ffmpeg3.0-libavdevice.x86_64
        3.0.2-4.el7     ffmpeg
ffmpeg3.0-libs.x86_64   3.0.2-4.el7     ffmpeg
ffmpeg3.1.x86_643.1.2-1.el7     ffmpeg
ffmpeg3.1-debuginfo.x86_64  3.1.2-1.el7     ffmpeg
ffmpeg3.1-devel.x86_64  3.1.2-1.el7 ffmpeg
ffmpeg3.1-libavdevice.x86_64
        3.1.2-1.el7     ffmpeg
ffmpeg3.1-libs.x86_64   3.1.2-1.el7 ffmpeg


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/26/2016 01:35 AM, Nicolas Chauvet wrote:
> 2016-08-26 0:23 GMT+02:00 Orion Poplawski :
>> On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
>>> 2016-08-25 22:19 GMT+02:00 Orion Poplawski :
 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.fc13.src.rpm
>>> 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."

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.

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

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/25/2016 02:01 AM, Nicolas Chauvet wrote:
> 2016-08-24 20:19 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>:
>> On 08/24/2016 11:35 AM, Nicolas Chauvet wrote:
>>> 2016-08-24 18:55 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>:
>>>> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
>>>>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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 pack

Re: ffmpeg for EL7

[Sérgio Basto]

On Sex, 2016-08-26 at 13:11 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> On Friday, 26 August 2016 at 09:35, Nicolas Chauvet wrote:
> [...]
> > 
> > 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.
> Nicolas, that was rather not excellent. Please explain why we can't
> have any version as long as they don't conflict for general usage?
> 
> 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.

Landing here, yes for me make sense f23 version (ffmpeg-2.8.7-1.fc23 )
is well tested 

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

I'm not seeing how we could install 2 versions of ffmpeg (I not read
all thread) but IMO ffmpeg-2.8.7 should be the main package . 

I peeked to Orion ffmpeg specs and I think main ffmpeg shouldn't have
versionsuffix , neither alternatives would work here ... 

Conclusion, IMHO ffmpeg-2.8.7 should be the main package and we could
build it right now and maybe later also ship one (just one) more
version of ffmpeg (3.1.2) , with versionsuffix if not conflicts, I
think will not have conflicts, but not as alternative
(/etc/alternatives) 

> What issues do you see with that plan? You said it yourself that
> 2.8.x
> is well-supported by the packages that depend on FFmpeg. By the time
> of the next ABI bump, I expect support for 3.x will have become
> equally good.
> 
> Regards,
> Dominik
-- 
Sérgio M. B.

Re: ffmpeg for EL7

[Dominik 'Rathann' Mierzejewski]

On Friday, 26 August 2016 at 13:11, Dominik 'Rathann' Mierzejewski wrote:
[...]
> 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.

What I mean by that is that we should maintain the current release
and the last before the bump to current ABI.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg for EL7

[Dominik 'Rathann' Mierzejewski]

On Friday, 26 August 2016 at 09:35, Nicolas Chauvet wrote:
[...]
> 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.

Nicolas, that was rather not excellent. Please explain why we can't
have any version as long as they don't conflict for general usage?

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.

What issues do you see with that plan? You said it yourself that 2.8.x
is well-supported by the packages that depend on FFmpeg. By the time
of the next ABI bump, I expect support for 3.x will have become
equally good.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-26 0:23 GMT+02:00 Orion Poplawski :
> On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
>> 2016-08-25 22:19 GMT+02:00 Orion Poplawski :
>>> 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.fc13.src.rpm
>> 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.

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> 2016-08-25 22:19 GMT+02:00 Orion Poplawski :
>> 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.fc13.src.rpm
> 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.

With ffmpeg-compat - it only provides the libs, not the binaries.
ffmpeg-compat doesn't conflict with any other ffmpeg package only if all of
the sonames are different, just like the ffmpeg2.8/3.0-libs packages I 
presented.

ffmpeg-compat-devel doesn't conflict because the .so and .pc files are moved
to %{_libdir}/ffmpeg-compat{,/pkgconfig}.  So to make use them you need to
pass -L%{_libdir}/ffmpeg-compat or set
PKG_CONFIG_PATH=%{_libdir}/ffmpeg-compat/pkgconfig, which is reasonable.

I couldn't get ffmpeg4vlc to build, but looking at %files:
- it ships binaries, so that conflicts with ffmpeg
- it uses --build-suffix=4vlc - I'm guessing this is added to the library
names - which I suspect is harder to make other projects make use of.  No idea.

So here's an updated set including 3.1 that move the libs and .pc files to
%{_libdir}/%{name}.  So none of the packages conflict.  To use you would
specify -L%{_libdir}/ffmpegX.X or set
PKG_CONFIG_PATH=%{_libdir}/ffmpegX.X/pkgconfig as with ffmpeg-compat-devel.

The problem here would come in with mixing ffmpeg3.0 and ffmpeg3.1, as without
the use of rpath or similar you could end up with a mix of versions of
libraries with the same soname.  So I would avoid having both 3.0 and 3.1 if
possible.

> My point is to have EL7 built with ffmpeg28 by default and eventually
> provide an alternative and newer ffmpeg for the binaries.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
# TODO: add make test to %%check section

#global branch  oldabi-
#global date20110612
#global rel rc1

%if 0%{?rhel} && 0%{?rhel} <= 6
%global _without_frei0r   1
%global _without_opencv   1
%global _without_vpx  1
%endif

%global versionsuffix 2.8
Summary:Digital VCR and streaming server
Name:   ffmpeg%{?versionsuffix}
Version:%{versionsuffix}.7
Release:1%{?date}%{?date:git}%{?rel}%{?dist}
%if 0%{?_with_amr:1}
License:GPLv3+
%else
License:GPLv2+
%endif
URL:http://ffmpeg.org/
%if 0%{?date}
Source0:ffmpeg-%{?branch}%{date}.tar.bz2
%else
Source0:http://ffmpeg.org/releases/ffmpeg-%{version}.tar.xz
%endif
Requires:   %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  bzip2-devel
%{?_with_celt:BuildRequires: celt-devel}
%{?_with_dirac:BuildRequires: dirac-devel}
%{?_with_faac:BuildRequires: faac-devel}
%{?_with_fdk_aac:BuildRequires: fdk-aac-devel}
BuildRequires:  freetype-devel
%{!?_without_frei0r:BuildRequires: frei0r-devel}
BuildRequires:  gnutls-devel
BuildRequires:  gsm-devel
BuildRequires:  lame-devel >= 3.98.3
%{?_with_jack:BuildRequires: jack-audio-connection-kit-devel}
%{!?_without_ladspa:BuildRequires: ladspa-devel}
BuildRequires:  libass-devel
%{!?_without_cdio:BuildRequires: libcdio-paranoia-devel}
#libcrystalhd is currently broken
%{?_with_crystalhd:BuildRequires: libcrystalhd-devel}
BuildRequires:  libdc1394-devel
Buildrequires:  libmodplug-devel
%{?_with_rtmp:BuildRequires: librtmp-devel}
BuildRequires:  libtheora-devel
BuildRequires:  libv4l-devel
BuildRequires:  libvdpau-devel
BuildRequires:  libvorbis-devel
%{?!_without_vpx:BuildRequires: libvpx-devel >= 0.9.1}
%ifarch %{ix86} x86_64
BuildRequires:  libXvMC-devel
%{?!_without_vaapi:BuildRequires: libva-devel >= 0.31.0}
%endif
%{?_with_amr:BuildRequires: opencore-amr-devel vo-amrwbenc-devel}

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-25 22:34 GMT+02:00 Orion Poplawski :
> As a tangential question - anyone know why the ffmpeg package doesn't use the
> %configure macro?
Because it's not based on autotools, so lot of expected behavior won't
match, produce warning if not errors.


-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Orion Poplawski]

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

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-25 22:19 GMT+02:00 Orion Poplawski :
> 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.fc13.src.rpm
Here are the ABI from ffmpeg upstream: http://ffmpeg.org/download.html#releases

My point is to have EL7 built with ffmpeg28 by default and eventually
provide an alternative and newer ffmpeg for the binaries.


-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/25/2016 02:01 AM, Nicolas Chauvet wrote:
> 2016-08-24 20:19 GMT+02:00 Orion Poplawski :
>> 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 ?

Well, Fedora has basically gone to rubber-stamping versioned packages that are
based on existing ones.  This seems pretty reasonable to me.  It also may not
make sense to package all versions.  Only the ones that get a lot of uptake
from other users.

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

The problem is that at some point you will need to update "ffmpeg", and this
will be painful.  Avoiding it completely helps with that.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Orion Poplawski]

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
sonames for all libraries.

If there was overlap, we could move the libraries into %{_libdir}/ffmpegX.X
and use ldconfig.  I was going to start looking at 3.1 next.

As Ralf noted, the -devel (and -debuginfo) packages conflict, though this
could be worked around as well.  Also, usually not necessary as you're
generally only building against one at a time.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
# TODO: add make test to %%check section

#global branch  oldabi-
#global date20110612
#global rel rc1

%if 0%{?rhel} && 0%{?rhel} <= 6
%global _without_frei0r   1
%global _without_opencv   1
%global _without_vpx  1
%endif

%global versionsuffix 3.0
Summary:Digital VCR and streaming server
Name:   ffmpeg%{?versionsuffix}
Version:%{versionsuffix}.2
Release:4%{?date}%{?date:git}%{?rel}%{?dist}
%if 0%{?_with_amr} || 0%{?_with_gmp}
License:GPLv3+
%else
License:GPLv2+
%endif
URL:http://ffmpeg.org/
%if 0%{?date}
Source0:ffmpeg-%{?branch}%{date}.tar.bz2
%else
Source0:http://ffmpeg.org/releases/ffmpeg-%{version}.tar.xz
%endif
Patch0: 0001-configure-add-direct-detection-of-libopencv.patch
Requires:   %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  bzip2-devel
%{?_with_faac:BuildRequires: faac-devel}
%{?_with_fdk_aac:BuildRequires: fdk-aac-devel}
%{?_with_flite:BuildRequires: flite-devel}
BuildRequires:  fontconfig-devel
BuildRequires:  freetype-devel
%{!?_without_frei0r:BuildRequires: frei0r-devel}
%{?_with_gme:BuildRequires: game-music-emu-devel}
BuildRequires:  gnutls-devel
BuildRequires:  gsm-devel
%{?_with_ilbc:BuildRequires: ilbc-devel}
BuildRequires:  lame-devel >= 3.98.3
%{!?_without_jack:BuildRequires: jack-audio-connection-kit-devel}
%{!?_without_ladspa:BuildRequires: ladspa-devel}
BuildRequires:  libass-devel
BuildRequires:  libbluray-devel
%{?_with_bs2b:BuildRequires: libbs2b-devel}
%{?_with_caca:BuildRequires: libcaca-devel}
%{!?_without_cdio:BuildRequires: libcdio-paranoia-devel}
%{?_with_chromaprint:BuildRequires: libchromaprint-devel}
#libcrystalhd is currently broken
%{?_with_crystalhd:BuildRequires: libcrystalhd-devel}
%if 0%{?_with_ieee1394}
BuildRequires:  libavc1394-devel
BuildRequires:  libdc1394-devel
BuildRequires:  libiec61883-devel
%endif
BuildRequires:  libgcrypt-devel
BuildRequires:  libGL-devel
%{?_with_mfx:BuildRequires: libmfx-devel}
Buildrequires:  libmodplug-devel
%{?_with_rtmp:BuildRequires: librtmp-devel}
%{?_with_smb:BuildRequires: libsmbclient-devel}
%{?_with_ssh:BuildRequires: libssh-devel}
BuildRequires:  libtheora-devel
BuildRequires:  libv4l-devel
BuildRequires:  libvdpau-devel
BuildRequires:  libvorbis-devel
%{?!_without_vpx:BuildRequires: libvpx-devel >= 0.9.1}
%ifarch %{ix86} x86_64
BuildRequires:  libXvMC-devel
%{?!_without_vaapi:BuildRequires: libva-devel >= 0.31.0}
%endif
%{?_with_webp:BuildRequires: libwebp-devel}
%{?_with_netcdf:BuildRequires: netcdf-devel}
%{?_with_amr:BuildRequires: opencore-amr-devel vo-amrwbenc-devel}
%{!?_without_openal:BuildRequires: openal-soft-devel}
%if 0%{!?_without_opencl:1}
BuildRequires:  opencl-headers ocl-icd-devel
%if 0%{?fedora} || 0%{?rhel} >= 8
Recommends: opencl-icd
%endif
%endif
%{!?_without_opencv:BuildRequires: opencv-devel}
BuildRequires:  openjpeg-devel
BuildRequires:  opus-devel
%{!?_without_pulse:BuildRequires: pulseaudio-libs-devel}
BuildRequires:  perl(Pod::Man)
%{?_with_rubberband:BuildRequires: rubberband-devel}
BuildRequires:  schroedinger-devel
BuildRequires:  SDL-devel
%{?_with_snappy:BuildRequires: snappy-devel}
BuildRequires:  soxr-devel
BuildRequires:  speex-devel
BuildRequires:  subversion
%{?_with_tesseract:BuildRequires: tesseract-devel}
#BuildRequires:  texi2html
BuildRequires:  texinfo
%{?_with_twolame:BuildRequires: twolame-devel}
%{?_with_wavpack:BuildRequires: wavpack-devel}
%{!?_without_x264:BuildRequires: x264-devel >= 0.0.0-0.31}
%{!?_without_x265:BuildRequires: x265-devel}
%{?_with_xvid:BuildRequires: xvidcore-devel}
BuildRequires:  zlib-devel
%{?_with_zmq:BuildRequires: zeromq-devel}

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/25/2016 07:39 AM, Ralf Corsepius wrote:
> 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.

Forward, not necessarily backward (compiled with 3.1, running with 3.0).  This
is where symbol versioning would help.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Ralf Corsepius]

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.


Ralf

Re: ffmpeg for EL7

[Dominik 'Rathann' Mierzejewski]

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.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg for EL7

[Ralf Corsepius]

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


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.
As you probably know, ffmpeg supports versioned executables, installdirs 
etc.


Building an ffmeg2* package which is installable in parallel to ffmpeg 
actually is pretty straight forward. Building a parallel installable 
ffmpeg2-devel, would be more difficult, though. However, provided 
packages are being built in chroots/mock/koji, these days, I do not see 
a pressing need for a parallel installable ffmpeg2-devel.



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.


Ralf

Re: ffmpeg for EL7

[Ralf Corsepius]

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

2016-08-25 7:13 GMT+02:00 Ralf Corsepius :

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.

Care to explain what's the issue ? works for me here.


Where shall I start? I am having such an amount of, partially serious 
partially less serious problems with it, I am having difficulties in not 
ranting ;)


So, let me just mention 3 most nagging ones:

1. vlc-3 very frequently (almost each time) eats up all memory (incl. 
swap) until the machine runs OOM and starts killing other programs rsp. 
other programs crash and even lockup machine entirely.


2. vlc-3 doesn't scale many videos correctly, which fc23's vlc-2.x had 
displayed correctly.


3. vlc-3 opens a dialog popup for streams it can't handle. vlc-2.x 
simply ignored them.



#1 is the real killer. It happens such kind of frequently I would 
estimate vlc-3.0's MTBF to ~2 minutes.


That said, I have no real idea about the causes, but am pretty sure 
there several causes interacting.


- From having monitored upstream activities, I know upstream vlc is 
struggling with concurrency and deadlock issues.
- From other display/graphics related issues I am having[1], I am also 
pretty sure some low level intel-GPU related stuff is bugged (kernel, 
libvdpau-intel, xorg-x11-*, ...)
- I am observing vlc issuing qt-warnings complaining about "Timers can 
not be stopped from another thread"



(Gnome3, NVIDIA)


xfce4, Intel IGP (i5-4570)

I haven't seen these issues with xfce4/NVidia, yet.

Ralf

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1365062
https://bugzilla.redhat.com/show_bug.cgi?id=1366824

Re: ffmpeg for EL7

[Nicolas Chauvet]

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

Now I'm more in favour of using ffmpeg 2.8x as a sane default here,
because it should works for all. it share the same ABI as ffmpeg-2.4x
(which is the one from f21 as we are supposed to branch from f20/f21)
Instead there is anachronism in choosing ffmpeg31/0. as the rule of
the game for EL is not to pick the last versions.



-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-25 7:13 GMT+02:00 Ralf Corsepius :
> 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.
Care to explain what's the issue ? works for me here. (Gnome3, NVIDIA)



-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Ralf Corsepius]

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.



SCLs are a major pain.


Definitely.

Ralf

Re: ffmpeg for EL7

[Orion Poplawski]

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

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

SCLs are a major pain.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Nicolas Chauvet]

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

-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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've taken Dominik's suggestion and queried[0] the ffmpeg developers.  We'll
see what they say.

[0] - http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198246.html

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-23 22:03 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>:
> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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.
>
> 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.
>

On a second thought, it might be possible to have ffmpeg-2.8x as
ffmpeg-compat and build the current ffmpeg 3.1x as ffmpeg as the
libraries have SONAME bumped, they should co-exist.
The main problem will be not to mix ffmpeg symbols from two differents
SONAME in a same process. With vlc and koji involded, it might be hard
to archeive...



-- 
-

Nicolas (kwizart)

Re: ffmpeg for EL7

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 23 August 2016 at 22:03, Orion Poplawski wrote:
> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
> > 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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.

FFmpeg has a 3 month release schedule, but upstream developers are
quite accommodating to keeping one of the older branches alive if
you ask politely and explain why. It's best to start at the newest
possible, obviously.

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

Let me know if you need any help. I'm not interested in being a
full-time maintainer of MPlayer in el7 (or el6), but I'll help
whenever I can.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg for EL7

[Orion Poplawski]

On 08/23/2016 12:15 PM, Nicolas Chauvet wrote:
> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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.

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.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

Re: ffmpeg for EL7

[Nicolas Chauvet]

2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@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.

Thx for bootstraping el7 !




-- 
-

Nicolas (kwizart)

ffmpeg for EL7

[Orion Poplawski]

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?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com