[Slackbuilds-users] ffmpeg update - request for testers

Heinz Wiesinger HMWiesinger at gmx.at
Fri Jun 13 09:44:02 UTC 2008


Antonio Hernández Blas wrote:
> Hi Heinz Wiesinger:

Hi again. I had a little discussion about this topic over at mplayer-users 
mailing list. Just wanted to provide you with the answers I got :)

> " I first thought about an update right after the release of a new
> Slackware-version,"
> Before the release of Slackware 12.1 that was i wanted to do, also i
> asked to rworkman if that would be possible (if i can remember, all he
> said me is(more or less) "wait for the maintainer consideration") but
> anyway, I still have the idea that apps from svn/cvs should be updated
> right after a Slackware release, so we can use them like in 1 year
> without worry of them ;)
>
> "As MPlayer is using ffmpeg internally we can probably state that the
> version used by MPlayer is pretty stable."
> It's that, or we can state that they are pretty different too. Are the
> changes made by MPlayer to ffmpeg(the internal) also done in
> ffmpeg(the official)?

MPlayer is using external references for the ffmpeg libraries it uses. So 
whenever a change is committed to ffmpeg's svn it's automatically also in 
mplayer's. As a consequence it is the same code.

> "MPlayer is also adjusting the interface to x264 in svn, which means
> that the perfect combination of those two would be snapshots of about
> the same time. Updating x264 and leaving MPlayer behind would probably
> end up with roblems on runtime."
> If you take a look into their configure script
> (http://svn.mplayerhq.hu/mplayer/trunk/configure?view=co), you can see
> something like this http://pastebin.ca/1029547. They search for the
> value of X264_BUILD in /usr/include/x264.h(greater than 53), which in
> my x264 update is '#define X264_BUILD 59", so i don't see any problem
> here.
>
> And finally, look the version of ffmpeg in gentoo and arch:
> http://www.gentoo-portage.com/AJAX/Ebuild/63099 (svn revision 11878 -
> fmpeg-0.4.9_p20080326.ebuild)
> http://aur.archlinux.org/packages/ffmpeg-svn/ffmpeg-svn/PKGBUILD (svn
> revision 13107)
> Both are updated, in *this* year :)
>
> Ok, anyway, i'm not saying your ideas are wrong, i understand them but
> at this moment i think we can make the updates without any problem,
> until the next slackware release.

So here's what I have been told over at mplayer-users:
MPlayer uses x264 in two ways. One way is mplayer directly, which uses merely 
the high-level api of x264, which is considered pretty stable. The other is 
via ffmpeg's libs. Those use more internal api calls which do still change 
and might cause problems.
The default use of x264 is via mplayer's own libraries (ie libmpcodecs), which 
should also work if we update just x264. However there might be issues if we 
leave MPlayer behind, at least with the included ffmpeg libs.

Basically from my point of view we should at least update ffmpeg and x264 when 
updating MPlayer to a new version. Updating x264 or ffmpeg later on might 
probably work or not. It's probably best considered at that moment.

There's also the option to use svn-version of MPlayer. From what I read the 
release-tarballs are not considered more stable than the svn-version.

The full thread can be read here:
http://lists.mplayerhq.hu/pipermail/mplayer-users/2008-June/073322.html

> BTW, i have execute this command to see wich could be the other apps
> that should take care of this update(/var/cache/slackbuilds/ is were i
> sync SBo repository):
> find /var/cache/slackbuilds/ -name "README" -exec grep ffmpeg {} \;
> -exec echo -e "{}\n" \;
> As i can see, they are: kino, transcode, ffmpegthumbnailer and motion, (MOC
> too)
>
> Can another SBo admin/user give an opinion about this topic?  that
> would be nice, i don't want to get a date with Heinz Wiesinger at the
> end of all this threat hahahaha :)

Me neither :P

Grs,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20080613/e4f53b85/attachment.sig>


More information about the SlackBuilds-users mailing list