I created a new mplayer snapshot (revision 29543) and also created a patch to make mplayer use ffmpeg-mt (http://gitorious.org/ffmpeg/ffmpeg-mt) instead of normal ffmpeg. ffmpeg-mt is a multi-threaded version of ffmpeg that speeds up H.264/AVC, MPEG-1 and MPEG-2 decoding on multi-core CPUs (useful for CPU intensive HD video, like 1080p or high-bitrate 720p). ffmpeg-mt is a Google Summer of Code project of ffmpeg and at some point will be included upstream. The patch is only applied if the "ffmpeg-mt" USE flag is set. If it's not set, the vanilla, mplayer-bundled ffmpeg is used. To use multithreading, you need to pass "-lavdopts threads=N" to mplayer. "N" is the amount of threads you want mplayer to utilize. A value of "2" should be enough even on quad cores to play 1080p HD video smoothly. If not, increase to 3 or 4. Of course higher numbers than the amount of CPU cores don't make sense and can even have negative results due to added overhead. If you use the SMPlayer front-end instead of raw mplayer, you only need to set the appropriate option in its configuration dialog ("Performance" section, "Threads for decoding" field.) I am attaching the ebuild patch to create mplayer-1.0_rc4_p20090821.ebuild from the existing mplayer-1.0_rc2_p20090731-r1.ebuild. I uploaded the mplayer snapshot to: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090821.tar.bz2 It can also be created by simply grabbing r29543 from SVN and deleting all ".svn" directories in case you don't trust random people posting source code snapshots ;) I uploaded the ffmpeg-mt patch here: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090821-ffmpeg-mt.patch It's a bit big to attach here. I think it's also a bit big to put in "media-video/mplayer/files" in portage. It might be better to use distfiles for it, so in that case the ebuild should be modified accordingly before committing it (if it gets committed, of course.) The patch can also be created by grabbing ffmpeg-mt from it's Git repo, replacing mplayer's libavcodec, libavformat and libavutil directories with those from ffmpeg-mt, and then inserting the following code somewhere in libavutil/common.h to avoid a linker error: static inline av_const uint16_t av_clip_uint16(int a) { if (a&(~65535)) return (-a)>>31; else return a; } With the "ffmpeg-mt" USE flag enabled, I can confirm (htop) that mplayer spawns the appropriate amount of threads and load is distributed equally among them (with the end effect being that on my dual core both cores are doing video decoding.)
Created attachment 201828 [details, diff] mplayer-1.0_rc2_p20090731-r1.ebuild.patch
Created attachment 202203 [details, diff] mplayer-1.0_rc2_p20090731-r1.ebuild.patch There has been a large update today to ffmpeg-mt (186 commits), bringing it close to upstream ffmpeg (while retaining the multi-threading additions, of course.) As a result, the patch applied with the "ffmpeg-mt" USE flag is much smaller now: 144K (29K if you compress it to bzip2) from the 549K it was previously. Also, the patch to libavutil/common.h is no longer required. New ebuild patch attached. The new links: mplayer r29549 snapshot: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090825.tar.bz2 (This goes to distfiles) ffmpeg-mt patch: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090825-ffmpeg-mt.patch (This goes to mplayer/files) You can also recreate the snapshot and patch yourselves as described in the first post, except that you don't have to patch libavutil/common.h anymore since ffmpeg-mt is up-to-date now.
Thanks Again, Nikos Chantziaras! here is a quick 'n' dirty checklist for other newbies like me: 1. deactivate avguard (it detects "silly" html within the mplayer download, and it will block compilation) 2. download mplayer-1.0_rc4_p20090825.tar.bz2 mplayer-1.0_rc4_p20090825-ffmpeg-mt.patch mplayer-1.0_rc2_p20090731-r1.ebuild.patch 3. mv mplayer-1.0_rc4_p20090825.tar.bz2 /usr/portage/distfiles 4. mv mplayer-1.0_rc4_p20090825-ffmpeg-mt.patch /usr/portage/media-video/mplayer/files 5. mv mplayer-1.0_rc2_p20090731-r1.ebuild.patch to /usr/portage/media-video/mplayer 6. cd /usr/portage/media-video/mplayer 7. patch -p1 mplayer-1.0_rc2_p20090731-r1.ebuild mplayer-1.0_rc2_p20090731-r1.ebuild.patch 8. cp mplayer-1.0_rc2_p20090731-r1.ebuild mplayer-1.0_rc4_p20090825.ebuild 9. vim mplayer-1.0_rc4_p20090825.ebuild and remove nvidia driver and settings dependency (for me only; I do not use portage; instead use the NVidia driver "run" download from http://www.nvidia.com/object/unix.html) 10. ebuild mplayer-1.0_rc4_p20090825.ebuild digest 11. vim /usr/portage/package-keywords; add ~media-video/mplayer-1.0_rc4_p20090825 12. emerge mplayer (assure that use flags "ffmpeg-mt" "vdpau" are set)
Er, you need to do this stuff in your local overlay. /usr/local/portage for example. See: http://www.gentoo.org/proj/en/overlays/userguide.xml In any event, seek advice about this on the gentoo-user mailing list or the Gentoo forums. It's best to keep bugzilla clean from support requests :)
Everything built fine for me (using an overlay, quite simple :) but I have not had a chance to benchmark vs normal mplayer.
Playing certain files (mpeg1 and mpeg2 videos, it seems) makes mplayer crash when I have both multi-threads and vdpau enabled, but exclusively vdpau or threads=2 is okay... just not both at the same time. The error is: [mpegvideo_vdpau @ 0xc9b780]invalid mb type in I Frame at 24 0 Here is my very scientific benchmark, using "top" as judge. :) I have a Core 2 Duo E6600 (overclocked to 3GHz) and Nvidia GeForce 9600GT using the proprietary nvidia-drivers. I have a 1920x1080 H.264 clip from camcorder that I used as a test. With normal mplayer output, it uses 74% CPU to play this movie (all on one core). With only -lavdopts threads=2, it uses around 80 to 85% in total BUT the load is distributed between the two cores, so at any given time neither goes higher than about 45%. I say it is working then. :) With only vdpau enabled, the decoding is offloaded to the graphics card so CPU usage by mplayer is just 3%! (and it can offload deinterlacing, too... nice)
This should have been a thread in http://forums.gentoo.org/viewforum-f-51.html, as it's very likely we will wait until FFmpeg-mt gets merged upstream...
I agree in general. It's just that mplayer is an extremely popular package. Also, ffmpeg-mt is widely used already (on Windows too, they have "ffdshow" over there which uses ffmpeg). It's just something that people want badly because there's no other solution currently for watching "heavy" video on Linux with cheap dual cores. At least in Windows they have commercial solutions, but in Linux the only alternative is a hacky approach to use the commercial "CoreAVC" codec. Note that ffmpeg-mt has become so popular that even mplayer upstream provides information about it in their homepage, right at the top. So perhaps an exception should be made due to the popularity of the "mt" branch, but also a fat message should be printed when this USE flag is enabled that ffmpeg-mt is considered experimental and that no bug reports should be filed against it (and perhaps that this USE flag might go away again in the future if mplayer stops being able to build with ffmpeg-mt.)
Created attachment 204623 [details, diff] Patch to create mplayer-1.0_rc4_p20090919.ebuild from mplayer-1.0_rc2_p20090731-r1.ebuild (current portage version). Another large update in ffmpeg-mt (197 commits), again bringing it in sync with upstream ffmpeg. New ebuild patch attached. This new ebuild should only require renaming in future updates, no re-patching. The new links for the mplayer and patch tarballs: mplayer r29694 snapshot: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 (This goes to $PORTDIR/distfiles) ffmpeg-mt patch: http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919-ffmpeg-mt.patch (This goes to <your local overlay>/media-video/mplayer/files) You can also recreate the snapshot and patch yourselves as described in the first post, except that you don't have to patch libavutil/common.h anymore since ffmpeg-mt is up-to-date now.
(In reply to comment #9) > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > (This goes to $PORTDIR/distfiles) The above file doesn't exist on any mirror that portage sources, including upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail.
(In reply to comment #10) > (In reply to comment #9) > > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > > (This goes to $PORTDIR/distfiles) > The above file doesn't exist on any mirror that portage sources, including > upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail. > For that matter, the above link gives a 404.
(In reply to comment #10) > (In reply to comment #9) > > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > > (This goes to $PORTDIR/distfiles) > The above file doesn't exist on any mirror that portage sources, including > upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail. Of course it doesn't exist; this ebuild, patch and tarball is not in portage. And it will probably stay this way. > > > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > > > (This goes to $PORTDIR/distfiles) > > The above file doesn't exist on any mirror that portage sources, including > > upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail. > > > For that matter, the above link gives a 404. Link works fine here. Maybe you tried the previous links from the older posts; only those won't work anymore since I deleted the files. You can see all files hosted there here: http://foss.math.aegean.gr/~realnc/mplayer
(In reply to comment #12) > (In reply to comment #10) > > (In reply to comment #9) > > > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > > > (This goes to $PORTDIR/distfiles) > > The above file doesn't exist on any mirror that portage sources, including > > upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail. > > Of course it doesn't exist; this ebuild, patch and tarball is not in portage. > And it will probably stay this way. When I said "which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail" how did you read that to mean that I was referring to something not in portage? # ls /usr/portage/media-video/mplayer ChangeLog Manifest files metadata.xml mplayer-1.0_rc2_p20090322.ebuild mplayer-1.0_rc2_p20090731-r1.ebuild mplayer-1.0_rc2_p20090731.ebuild mplayer-1.0_rc4_p20090919-r1.ebuild mplayer-9999.ebuild
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > (In reply to comment #9) > > > > http://foss.math.aegean.gr/~realnc/mplayer/mplayer-1.0_rc4_p20090919.tar.bz2 > > > > (This goes to $PORTDIR/distfiles) > > > The above file doesn't exist on any mirror that portage sources, including > > > upstream, which causes mplayer-1.0_rc4_p20090919-r1 version in portage to fail. > > > > Of course it doesn't exist; this ebuild, patch and tarball is not in portage. > > And it will probably stay this way. > When I said "which causes mplayer-1.0_rc4_p20090919-r1 version in portage to > fail" how did you read that to mean that I was referring to something not in > portage? Because this bug is about an mplayer patch to use ffmpeg-mt and is not in portage. Since your issue has nothing to do with mplayer-mt/ffmpeg-mt, you should open a new bug.
does anyone has a idea how to modify the patch to mplayer svn use?
This is not possible. A specific patch applies to specific code. If that code changes, the patch cannot apply anymore. All you can do is create a patch for a specific snapshot in time.
thanks, will try
Since this will not be pushed in portage, I'm closing this as UPSTREAM. Also, I will no longer provide ebuild patches against the portage version, but will post the full ebuild instead (which will be always based on the latest one in portage) which will fetch the tarball and patch automatically from my server without the need to put the tarball in distfiles and the patch in files manually. So if you're using this, stay in the CC list of this bug to get informed of updates and/or subscribe to the Gentoo Forums thread: http://forums.gentoo.org/viewtopic-t-789673.html
Created attachment 206719 [details] mplayer-1.0_rc4_p20091011.ebuild A new ffmpeg-mt update is available. 299 Git commits, again syncing it with latest upstream ffmpeg. This ebuild works stand-alone; as mentioned in my previous post, you don't need to download the tarball of the mplayer SVN snapshot nor the ffmpeg-mt patch. The ebuild will take care of that. Further, the ffmpeg-mt USE flag is enabled by default now.
Thanks. Works perfect
Created attachment 208653 [details] mplayer-1.0_rc4_p20091029.ebuild Update to 1.0_rc4_p20091029. 217 new ffmpeg-mt commits since the last ebuild and latest mplayer updates from SVN (revision 29800).
Created attachment 210095 [details] mplayer-1.0_rc4_p20091113.ebuild Update to 1.0_rc4_p20091029. 115 new ffmpeg-mt commits since the last ebuild and latest mplayer updates from SVN (revision 29906). Since mplayer 29851, the CONFIG_TV_TELETEXT configuration option is no more. Therefore, the "teletext" USE flag has been removed from the ebuild. Teletext is now always supported by mplayer without the need to drag-in TV support (and the support should be rather complete now).
Thanks for your ebuilds, Nikos. I used one of the earliest versions you posted to do the build, and it worked great. Is there any chance you could hack up an ebuild that pulled the sources from the repos? (Ofcourse, substituting the bundled ffmpeg with the -mt repo). I'm aware that it's a moving target, but it shouldn't be hard to pull specific revisions such as one that's right after a ffmpeg-mt to mplayer mainline sync. The reason I ask is that I'm not comfortable pulling random tarballs from the net. I reviewed the first version you posted. Also, it should make it trivial to do a version bump, and to build a tarball that doesn't need a patchfile..
(In reply to comment #23) > Thanks for your ebuilds, Nikos. I used one of the earliest versions you posted > to do the build, and it worked great. > > Is there any chance you could hack up an ebuild that pulled the sources from > the repos? (Ofcourse, substituting the bundled ffmpeg with the -mt repo). I'm > aware that it's a moving target, but it shouldn't be hard to pull specific > revisions such as one that's right after a ffmpeg-mt to mplayer mainline sync. I don't know how to use Git and SVN both in the same ebuild :P The one overrides the other. Pointers are welcome. > The reason I ask is that I'm not comfortable pulling random tarballs from the > net. The portage version works the same way. A custom tarball is used created by the maintainer of the ebuild, not an official tarball from upstream.
(In reply to comment #24) > I don't know how to use Git and SVN both in the same ebuild :P The one > overrides the other. Pointers are welcome. That's a good point, I've never tried that either. Instead of putting commands straight in the ebuild, how about switching to the development git repo at http://repo.or.cz/w/mplayer-build.git ? It tracks the main SVN repo as well as ffmpeg-mt, and has some other benefits like mkv ordered chapter support.
Created attachment 216034 [details] mplayer-1.0_rc4_p20100107.ebuild Update to 1.0_rc4_p20100107. 503 new ffmpeg-mt commits since the last ebuild and latest mplayer updates from SVN (revision 30234). Ebuild synced with latest from portage.
Thank you for your mplayer contributions, Nikos Chantziaras! This latest ebuild lost the "ffmpeg-mt" flag on my box. The use is set in my make.conf and has worked previously, but not this time. A quick look at the ebuild (I'm a newbie) suggests that if I have the ffmpeg ebuild installed (required for xine) that ffmpeg-mt won't install!? Are they mutually exclusive? TIA
OOPS! Please disregard my previous post - something else is likely wrong. Sorry!
Created attachment 216964 [details] mplayer-1.0_rc4_p20100120.ebuild Update to 1.0_rc4_p20100120. 339 new ffmpeg-mt commits since the last ebuild and latest mplayer updates from SVN (revision 30380). From MPlayer's homepage: Just a quick note, if you got some DVD's as a gift, mplayer -nocache dvdnav:// should play your new movies better than dvd://.
Created attachment 217767 [details] mplayer-1.0_rc4_p20100128.ebuild Update to 1.0_rc4_p20100128. ffmpeg-mt revision f3f3d11 (118 commits since the last ebuild) and latest mplayer updates from SVN (revision 30380). ebuild now grabs svgalib_helper-1.9.17-mplayer.tar.gz from my server since the original URL in the portage ebuild (http://dev.gentoo.org/~ssuominen/) does not work anymore.
(In reply to comment #30) > latest mplayer updates from SVN (revision 30380). Sorry, typo. It's revision 30452, not 30380.
Does this mplayer ebuild need ffmpeg-mt? What's the current status for this modified mplayer ebuild and the ffmpeg-mt ebuild as in bug #268392?
(In reply to comment #32) > Does this mplayer ebuild need ffmpeg-mt? No. > What's the current status for this > modified mplayer ebuild and the ffmpeg-mt ebuild as in bug #268392? I don't know about the ffmpeg-mt ebuild, but this one is maintained and I will post updates regularly.
Created attachment 219569 [details] mplayer-1.0_rc4_p20100214.ebuild Update to 1.0_rc4_p20100214. ffmpeg-mt revision ddc8310d (168 commits since the last ebuild) and latest mplayer updates from SVN (revision 30556). ebuild synced with latest portage version (1.0_rc4_p20100213).
Created attachment 223109 [details] mplayer-1.0_rc4_p20100311.ebuild Update to 1.0_rc4_p20100311. ffmpeg-mt revision d62b7c0 (743 commits since the last ebuild) and latest mplayer updates from SVN (revision 30881). ebuild synced with current portage version (there were USE flag changes).
FYI, I have this ebuild in my overlay, wirelay (in layman) and I keep it synced with Nikos' updates :) Thanks Nikos!
Thanks, Alex. I tried to submit this to the multimedia overlay, since it seems a more appropriate place, but there doesn't seem to be any interest from its maintainer, maybe due to lack of time. The multimedia overlay is practically empty anyway (there's only three (3) packages in it), so I guess I can point people to wirelay.
Created attachment 225603 [details] mplayer-1.0_rc4_p20100328.ebuild Update to 1.0_rc4_p20100328. ffmpeg-mt revision 8ba50a9 (328 commits since the last ebuild) and latest mplayer updates from SVN (revision 30976). ebuild synced with current portage version. There were USE flag changes. Also, mplayer doesn't support realcodecs anymore (media-libs/realcodecs), so this has been removed from the ebuild.
The multimedia overlay is actually a good idea, I didn't even remember we have that :P I've moved mplayer over there, adding your new ebuild in the process. Thanks :)
I spoke too soon... It seems that I can't push to the multimedia overlay although I am an admin. Until I get this figured out the new version will be available in wirelay as usual. I'll update this bug when the move is done :)
Looks like "nvidia" has been removed from the "VIDEO_CARDS=" line. Was this intended? Thanks for the ebuild and layman distribution!
(In reply to comment #41) > Looks like "nvidia" has been removed from the "VIDEO_CARDS=" line. > > Was this intended? This change is from the portage ebuild. Before that change, "nvidia" was only used as an additional guard for "vdpau". It had no other effect. Now you only need to set "vdpau" to enable VDPAU in mplayer. Also having "nvidia" in VIDEO_CARDS is not needed.
OK, problem with "multimedia" repo resolved, I've pushed your ebuilds. http://gitorious.org/gentoo-multimedia/gentoo-multimedia/commit/89659010ee6f0f23c48c790755e1ea593e5024cf http://gitorious.org/gentoo-multimedia/gentoo-multimedia/trees/master/media-video/mplayer :)
mplayer now fails with USE=xanim see bug 309931 too.
IIUC, xanim doesn't work on 64-bit systems. Need to wait 'til it catches up There's probably a better way; I simply ran: USE="-xanim" emerge -av mplayer
http://article.gmane.org/gmane.comp.video.mplayer.cvs/14135/match=xanimcodecsdir
Hmm, not sure whether this is related - but sound in mkv videos is totally off. As in, I can hear the soundtrack but not the dialogues. Anyone else with the same issue?
Created attachment 230267 [details] mplayer-1.0_rc4_p20100504.ebuild Update to 1.0_rc4_p20100504. ebuild synced with current portage version.
Seems like portage version have a ffmpeg-mt useflag but masked. Is related to this?
I don't see one. Unless you mean the "external-ffmpeg" flag. That ones makes mplayer use the system's ffmpeg lib instead of the default, bundled one.
My fault, It was an old ebuild in my local overlay.
in multimedia overlay, thanks. also, I removed it from wirelay, no need to have two copies :)
Created attachment 230313 [details, diff] Patch for win32 codecs lib After emerging, I could not watch video using win32codecs. Player complained about codecs not residing in /opt/RealPlayer/codecs. So, I crafted a small patch/hack for mplayer-1.0_rc4_p20100504.ebuild. Seems like official ebuild is also affected. I didn't reported it though :)
You will need to open a bug about this for the portage version. All this ebuild does is substitute the bundled ffmpeg with the -mt version. Everything else is kept in sync with the portage ebuild. That means that when the portage version is fixed, this ebuild will be too :)
(In reply to comment #54) > You will need to open a bug about this for the portage version. Here we are :) http://bugs.gentoo.org/show_bug.cgi?id=318453
Created attachment 230761 [details] mplayer-1.0_rc4_p20100508.ebuild (Sorry for bumping too soon, but ffmpeg-mt merged mainline yesterday.) Update to 1.0_rc4_p20100508. ffmpeg-mt revision 6abde3d, mplayer revision 31142. ebuild synced with current portage live (9999) ebuild.
(In reply to comment #56) > Created an attachment (id=230761) [details] > mplayer-1.0_rc4_p20100508.ebuild > > (Sorry for bumping too soon, but ffmpeg-mt merged mainline yesterday.) > > Update to 1.0_rc4_p20100508. ffmpeg-mt revision 6abde3d, mplayer revision > 31142. > > ebuild synced with current portage live (9999) ebuild. > Could you please push this to the multimedia overlay?
pushed :)
Created attachment 232357 [details] mplayer-1.0_rc4_p20100521.ebuild Update to 1.0_rc4_p20100521. ffmpeg-mt revision c91d7a2, mplayer revision 31188. ebuild synced with current portage live (9999) ebuild.
Created attachment 233551 [details] mplayer-1.0_rc4_p20100530.ebuild There was quite a bit of ffmpeg-mt Git activity since the last update. Update to 1.0_rc4_p20100530. ffmpeg-mt revision 11b1a8e, mplayer revision 31288.
(In reply to comment #60) > Created an attachment (id=233551) [details] > mplayer-1.0_rc4_p20100530.ebuild > > There was quite a bit of ffmpeg-mt Git activity since the last update. > > Update to 1.0_rc4_p20100530. ffmpeg-mt revision 11b1a8e, mplayer revision > 31288. > Bump to the multimedia overlay please.
Created attachment 235303 [details] mplayer-1.0_rc4_p20100614.ebuild Updated ffmpeg-mt (revision 5380fee) and mplayer (revision 31288.) Synced ebuild with current portage version.
(In reply to comment #62) > mplayer (revision 31288.) Wrong copy&paste. It's revision 31420.
what are you guys think of adding support for vaapi to this ebuild?
(In reply to comment #64) > what are you guys think of adding support for vaapi to this ebuild? Not possible for me since I can't use it; it would require Catalyst drivers which I don't use anymore.
Created attachment 236661 [details] mplayer-1.0_rc4_p20100626.ebuild Updated ffmpeg-mt (revision 7e928f6) and mplayer (revision 31559.) Temporarily removed "faad" USE flag and forced "--disable-faad" configure switch since it only compiles with bundled faad2 library.
(In reply to comment #65) > (In reply to comment #64) > > what are you guys think of adding support for vaapi to this ebuild? > > Not possible for me since I can't use it; it would require Catalyst drivers > which I don't use anymore. > I don't use it too but vaapi needs onlt libva
Created attachment 239371 [details] mplayer-1.0_rc4_p20100718.ebuild Updated ffmpeg-mt (revision 8232490) and mplayer (revision 31749.) Ebuild synced with portage.
Created attachment 240995 [details] mplayer-1.0_rc4_p20100802.ebuild Updated ffmpeg-mt (revision ff69da3) and mplayer (revision 31895.)
Created attachment 241195 [details] mplayer-1.0_rc4_p20100803.ebuild Small update. Fixes a bug in ffmpeg-mt affecting multithreading: http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt/commit/9ec9f0868de2df3d3448dec887e7440ebb006b27
Created attachment 242645 [details] mplayer-1.0_rc4_p20100811.ebuild Updated ffmpeg-mt (revision 9e981c8) and mplayer (revision 31951.)
Created attachment 246884 [details] mplayer-1.0_rc4_p20100910.ebuild Updated ffmpeg-mt (revision 0097d3b) and mplayer (revision 32128.)
(In reply to comment #72) > Created an attachment (id=246884) [details] > mplayer-1.0_rc4_p20100910.ebuild > > Updated ffmpeg-mt (revision 0097d3b) and mplayer (revision 32128.) > Sorry if the error does not belong here, but in this update, vf=ass config option is not recognized, producing: Option vf: ass doesn't exist. Error parsing option vf=ass,screenshot at line 18 Man page, however, does not reflect the option was dropped. Because of that, subtitle handling is also somewhat broken (ass is handled as srt).
(In reply to comment #73) > > Sorry if the error does not belong here, but in this update, vf=ass config > option is not recognized, producing: > Option vf: ass doesn't exist. > Error parsing option vf=ass,screenshot at line 18 > Man page, however, does not reflect the option was dropped. > Because of that, subtitle handling is also somewhat broken (ass is handled as > srt). The ebuild is the same (and kept in sync) as mplayer-9999 from portage, with only the ffmpeg-mt modification. So this has to be fixed in that one, and then the fix can propagate to this ebuild too.
Created attachment 249792 [details] mplayer-1.0_rc4_p20101004.ebuild Updated ffmpeg-mt (revision ed42183) and mplayer (revision 32419.) Ebuild synced with Portage.
(In reply to comment #73) I figured mplayer now requires >=libass-0.9.10 (hasn't been marked as stable yet) in the config.log. Once I emerged libass-0.9.11, ass rendering works again.
Created attachment 250543 [details] mplayer-1.0_rc4_p20101014.ebuild Updated ffmpeg-mt (revision 3f75218) and mplayer (revision 32476.) Ebuild synced with Portage. As a result, there are many changes and clean-ups (like removed gmplayer support.)
Created attachment 251811 [details] mplayer-1.0_rc4_p20101024.ebuild Updated ffmpeg-mt (revision 18893e1) and mplayer (revision 32533.)
Created attachment 253251 [details] mplayer-1.0_rc4_p20101105.ebuild Updated ffmpeg-mt (revision ea396d3) and mplayer (revision 32577.) Ebuild synced with Portage.
mplayer-1.0_rc4_p20101114 is in portage, any idea when an matching version if mt will be here?
(In reply to comment #80) > mplayer-1.0_rc4_p20101114 is in portage, any idea when an matching version if > mt will be here? When there's new commits to the ffmpeg-mt Git repository :) There are none till now.
Created attachment 257930 [details] mplayer-1.0_rc4_p20101216.ebuild Updated ffmpeg-mt (revision 2bbb64d) and mplayer (revision 32716.) Ebuild synced with Portage. Warning: This version has a bug where Ogg Vorbis audio in *.ogm files is not being played. Upstream ffmpeg bug: http://roundup.ffmpeg.org/issue2428 If this is important to you, continue to use 1.0_rc4_p20101105 and don't upgrade yet.
ffmpeg-mt has been merged in upstream ffmpeg now. The mplayer2 fork (I think) already has it, and I guess future mplayer ebuilds will also have it as a result of the upstream merge. So I think there's no need anymore for me keep doing these ebuilds.
thx.
