ffmpeg-2.4 released

[Julian Sikorski]

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