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