Wine versione >= 1.3.6 needs gstreamer and its plugins as rdpend, or --without-gstreamer needs to be specified. I tried reproducing mp3 files, but wine reports many errors. After emerging "media-plugins/gst-plugins-mad" error messages disappear. For sure there are also other missing deps for other formats. Reproducible: Always Steps to Reproduce: Reproduce mp3 sounds in wine. Actual Results: wine unknown_type Could not find a filter for caps: audio/mpeg
added to the tree ... thanks ! http://sources.gentoo.org/app-emulation/wine/wine-9999.ebuild?r1=1.65&r2=1.66 http://sources.gentoo.org/app-emulation/wine/wine-1.3.6.ebuild?r1=1.1&r2=1.2
Is it enought? Somewhere I read about gstreamer-plugins-ugly or videos fail to reproduce: http://bugs.winehq.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=&content="gstreamer-plugins-ugly" Isn't there any splitted plugin package which supports yuv videos instead of this big one? These are gstreamer's functions wine-1.3.6 is using: Gstreamer_AudioConvert Gstreamer_Mp3 Gstreamer_Splitter Gstreamer_YUV P.S.: Wine-1.3.7 is out with enhanced gstreamer support, maybe other function are used. TIP: If wine installs correctly with gstreamer use active but you have problems in running win executables, you can disable the library "winegstreamer" in the libs section of winecfg without recompiling it again.
On amd64 and with USE="win32", wine fails: checking for gst_pad_get_caps_reffed in -lgstreamer-0.10... no configure: error: gstreamer-0.10 32-bit development files not found, gstreamer support disabled This is an error since --with-gstreamer was requested.
There was a similar problem with mp3 support, see bug #283860 and bug #299490 .
amd64 multilib problems are not wine's problem and not related to this bug. read the top level wine configure script. it only links against the two packages i added to DEPEND -- gstreamer and gstapp. for the subdecoders (mp3/whatever), those are requests made to the gstreamer stack at runtime and can be added/removed on the fly. i'm not sure depending on a specific plugin is correct since the architecture is arbitrary by design.
(In reply to comment #5) > amd64 multilib problems are not wine's problem and not related to this bug. You don't support 32bit wine on amd64 hosts? That's new. You've added $(use_with gstreamer) to the ebuild but don't care that your change makes emerging wine with USE="win32" impossible?
(In reply to comment #6) > You've added $(use_with gstreamer) to the ebuild but don't care that your > change makes emerging wine with USE="win32" impossible? Correction: of course it's not impossible. USE="win32 -gstreamer" should work fine. Nonetheless: somethings broken. And it's related to this bug.
no, it's not. take your comments to the correct bug.
(In reply to comment #8) > no, it's not. take your comments to the correct bug. > app-emulation/emul-linux-x86-soundlibs?
(In reply to comment #9) > (In reply to comment #8) > > no, it's not. take your comments to the correct bug. > > > > app-emulation/emul-linux-x86-soundlibs? > http://bugs.gentoo.org/show_bug.cgi?id=346321
do not comment about amd64 multilib on this bug
