x264 and ffmpeg - here we go again

[Julian Sikorski]

W dniu 30.10.2013 22:18, Nicolas Chauvet pisze:
> 2013/10/30 Sérgio Basto <sergio at serjux.com
> <mailto:sergio at serjux.com>>
> 
>     On Qua, 2013-10-30 at 07:22 +0100, Julian Sikorski wrote:
>     > W dniu 29.10.2013 22:11, Sérgio Basto pisze:
>     > > On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote:
>     > >> If we push ffmpeg 2.1 before we branch, we would ship F20 with a
>     > >> broken VLC, in that case?
>     > >
>     > > No, of course we won't ship VLC broken  .
>     > >
>     > > We just ship F20 in day of release or very closer until then we have
>     > > time to fix VLC .
>     > >
>     > I have just confirmed that VLC is not broken, it builds. I have cooked
>     > up a mock config containing a mix of F20 fedora repos and rawhide
>     > rpmfusion ones, and VLC was built successfully. I am rebuilding
>     > everything else as we speak. The results are likely to be even better
>     > than before, but I would like to be absolutely certain.
> 
>     Hi x264 stable git version just updated, some minutes ago , so I have
>     x264-0.138-1.20131030gitc628e3b.fc19.src.rpm to submit .
> 
>     May be do all mass rebuild together we will have less work , what do you
>     think ?
> 
>     About if we submit or not ? , don't want sounds rude, but my opinion
>     is : what we are waiting for ? :)
> 
>     May I bootstrap x264 ?
> 
> I'm not against it, but I should mention that there are few runtime
> issue that can arise even if the package is building fine. (such the one
> described in the ffmpeg2theora bugreport).
> 
> There is also an issue with gpac that trigger a patch in x264. I really
> think gpac is culpid here (and shouldn't rely on libpng or else). Any
> chances to fix it on your side ?
> 
> Beside that I'm fine with the update.
> Vlc 2.1.1 should rise-up soon, but the rdp API issue that is only in
> rawhide will not be fixed. librdp failed to version it's api appropriately.
> 
> Thx for the hard work.
> 
> 
> Nicolas (kwizart)
> 
With librdp out of the way, it looks as follows:

$ find -name success | sort
./audacious-plugins-freeworld-3.4.1-1.fc20/success
./chromaprint-tools-1.0-2.fc20/success
./dvbcut-0.6.1-14.svn179.fc20/success
./dvdstyler-2.6-0.1_rc2.fc20/success
./ffmpeg-2.1-1.fc20/success
./ffmpeg2theora-0.29-7.fc20/success
./ffmpegthumbs-4.11.1-1.fc20/success
./gpac-0.5.0-7.20130914svn.fc20/success
./guvcview-1.6.1-6.fc20/success
./libquicktime-1.2.4-12.fc20/success
./lightspark-0.7.2-4.20130827git.fc20/success
./minidlna-1.1.0-2.fc20/success
./mlt-0.9.0-1.fc20/success
./moc-2.5.0-0.10.beta1.fc20/success
./mpd-0.18-0.1.git0e0be02.fc20/success
./mplayer-1.1-14.20130811svn.fc20/success
./mpv-0.1.7-4.fc20/success
./openmw-0.26.0-6.fc20/success
./qmmp-plugins-freeworld-0.7.2-2.fc20/success
./vlc-2.1.0-2.fc20/success
./wxsvg-1.2.1-1.fc20/success
./x264-0.136-1.20131005git3361d59.fc20/success
./xbmc-13.0-0.1.Gotham_alpha8.fc20/success
./xine-lib-1.2.4-2.fc20/success
$ find -name fail | sort
./acoustid-fingerprinter-0.6-5.fc20/fail
./bino-1.4.2-4.fc20/fail
./bombono-dvd-1.2.2-4.fc20/fail
./ffmpegthumbnailer-2.0.8-6.fc20/fail
./kmediafactory-0.8.1-9.fc20/fail

If we do this, we should definitely do x264 first to save time. I think
runtime issues can be taken care of later, given they don't break our
buildroot.

Best regards,
Julian