W dniu 22.09.2014 o 16:57, Sérgio Basto pisze:
On Seg, 2014-09-22 at 06:50 +0200, Julian Sikorski wrote:
> W dniu 22.09.2014 o 05:35, Ralf Corsepius pisze:
>> On 09/21/2014 11:20 PM, Sérgio Basto wrote:
>>> On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
>>>> Dear all,
>>>>
>>>> ffmpeg-2.4 was released recently which means we have another rebuild
>>>> coming up. I have done a test and only 4 packages have failed, which is
>>>> not bad given the extent of API changes:
>>>> - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct
a52_ctx' has
>>>> no member named 'frame'
>>>> - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not
declared
>>>> in this scope
>>>> - kmediafactory: videofile.cpp:74:45: error:
'av_find_stream_info' was
>>>> not declared in this scope (mencoder needs to be rebuilt first)
>>>> - vlc: configure: error: libavcodec versions 56 and later are not
>>>> supported yet.
>>>>
>>>> Given that we are close to branching (?), what would be the good time to
>>>> do the rebuild?
>>>
>>> yes, I don't see any problem, I can do the mass rebuild of others
>>> packages, no problem.
>>>
>>> My question if we ever put this updates on F20 ?
>>
>> No. If I understand correctly, this is an API/ABI incompatible upgrade
>> and not an ordinary update. This means, unless there are very good
>> reasons (e.g. security critical bug fixes), which make such upgrades
>> inevitably necessary, such upgrades are harmful and should not happen.
>> Keep in mind, people might build other packages based on your packages,
>> which might break because of your upgrade.
>>
>>> I'd like put it at
>>> least on update-testing.
>> Sorry, but this can't work.
>>
>> Ralf
>>
> I tend to agree with Ralf here. Having said that, I believe we should do
> something about F-20. It is currently tracking ffmpeg-2.1 branch, which
> seems to be unmaintained [1]. Looking at the API changes [2], updating
> to 2.2/2.3 should be relatively painless.
Hi, as you may know, I have some difficulties in deal with foreigner
language (English). IIUC , upgrade to ffmpeg-2.3 in F-20 , also have
API/ABI incompatible.
Of course I'm not saying put ffmpeg-2.4 in F-20 without testing , 2.3
is tested on F-21 Alpha , I have 2 machines and one vm , and don't found
any bug .
For me is fine put ffmpeg-2.3 / x264-0.142 in F-20 updates-testing , but
as Ralf point out, we are breaking some rules .
> Best regards,
> Julian
>
> [1]
http://ffmpeg.org/olddownload.html
> [2]
http://upstream-tracker.org/versions/ffmpeg.html
Hello,
my apologies, I should have expressed myself more clearly. The reason I
was suggesting 2.3 as an alternative to 2.4 is that it is less
disruptive. Please have a look at the soname versions below:
- ffmpeg-2.1:
libavutil 52. 48.101
libavcodec 55. 39.101
libavformat 55. 19.104
libavdevice 55. 5.100
libavfilter 3. 90.100
libavresample 1. 1. 0
libswscale 2. 5.101
libswresample 0. 17.104
libpostproc 52. 3.100
- ffmpeg-2.3:
libavutil 52. 92.100
libavcodec 55. 69.100
libavformat 55. 48.100
libavdevice 55. 13.102
libavfilter 4. 11.100
libavresample 1. 3. 0
libswscale 2. 6.100
libswresample 0. 19.100
libpostproc 52. 3.100
As you can see, the major versions are all the same for everything
except libavfilter. In contrast, ffmpeg-2.4 has the following:
libavutil 54. 7.100
libavcodec 56. 1.100
libavformat 56. 4.101
libavdevice 56. 0.100
libavfilter 5. 1.100
libavresample 2. 1. 0
libswscale 3. 0.100
libswresample 1. 1.100
libpostproc 53. 0.100
Every single library got a soname bump.
The
upstream-tracker.org website reveals that no symbols were removed
between ffmpeg-2.1 and ffmpeg-2.3. Conversely, ffmpeg-2.4 has 20 symbols
removed vs 2.3.3.
Finally, the reason I was suggesting moving away from ffmpeg-2.1 is due
to the top of the "Old releases" page [3]:
These releases are not actively maintained and thus we discourage their use.
Best regards,
Julian
[1]
http://ffmpeg.org/olddownload.html