As per summary, wmv playback fails with xine-lib-1.0 and 1.0-r1. This does not appear to be the same as this bug http://bugs.gentoo.org/show_bug.cgi?id=89312 I have win32 codecs in my USE line. emerge -uv xine-lib gives this- media-libs/xine-lib-1.0-r1 [1.0] +X +aac -aalib -alsa (-altivec) -arts -cle266 -debug -directfb +dvd -dxr3 -esd -fbcon +ffmpeg +flac +gnome -i8x0 -ipv6 -libcaca +mng +nls +nvidia +opengl +oss +png -samba +sdl -speex +theora -v4l -vidix +vorbis +win32codecs -xinerama +xv +xvmc 0 kB i.e it finds the win32codecs I've tried downgrading to xine-lib-1.0, unmerging win32codecs, xine-lib and xine-ui, and re-emerging xine-ui, which correctly picks up win32codecs and xine-lib for installation. win32codecs was updated to 20050412 last night, but this was broken with the previous version as well. When run from an xterm, xine quits with this when I load a wmv file - xine This is xine (X11 gui) - a free video player v0.99.3. (c) 2000-2004 The xine Team. xiTK received SIGSEGV signal, RIP. Aborted No wmv demuxer appears in /usr/lib/xine/plugins/1.0.0, and if I interrupts xine-lib config during emerge at the point where it lists the various codecs/demuxers being used, there doesn't appear to be any listing for a wmv demuxer. Maybe there is a conflict between some other USE flag I have set and win32codecs w.r.t. the xine-lib ebuild? Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: xine-lib ebuild does not appear to be configuring for wmv support wven though win32codecs are present on system and in USE flag is set. emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11.7 i686) ================================================================= System uname: 2.6.11.7 i686 AMD Athlon(tm) Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 14 2005, 03:09:01)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -mfpmath=sse -fomit-frame-pointer -momit-leaf-frame-pointer -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -mfpmath=sse -fomit-frame-pointer -momit-leaf-frame-pointer -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://foucault/gentoo-portage" USE="x86 3dnow 3dnowex X aac acpi avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl dga divx4linux dvd dvdr dvdread emboss encode fam ffmpeg flac foomaticdb fortran gdbm geoip gif gimpprint gnome gpm gstreamer gtk gtk2 imagemagick imlib joystick jpeg kde libg++ libwww mikmod mmx mmx2 mng motif mozilla mp3 mpeg ncurses nls nptl nptlonly nvidia ogg oggvorbis opengl oss pam pdflib perl png ppds python quicktime readline real rtc sdl slang sndfile spell sse ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis win32codecs wmf xine xml2 xmms xprint xscreensaver xv xvid xvmc zlib linguas_en_GB" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Please attach the config.log file for xine-lib.
Created attachment 56709 [details] config.log for xine-lib-1.0-r1 Attached
I ran xine with verbose=2 from an xterm and noticed this- gui_xine_open_and_play(): mrl: '/mnt/big/E viva Morientes.wmv', sub 'NONE', start_pos 0, start_time 0, av_offset 0, spu_offset 0. input_cache: read calls: 41, main input read calls: 15 input_cache: seek_calls: 53, main input seek calls: 5 xine: found input plugin : file input plugin load_plugins: probing demux 'asf' xine: found demuxer plugin: ASF demux plugin demux_asf: unknown GUID: 0x9fa6f672, 0x4018, 0x438d, { 0x80, 0x6b, 0xf6, 0xb2, 0xa5, 0xce, 0x15, 0x84 } demux_asf: audio conceal interleave detected (1 x 1 x 372) info_helper: can't find out current locale character set info_helper: can't find out current locale character set video discontinuity #2, type is 0, disc_off 0 waiting for audio discontinuity #2 info_helper: can't find out current locale character set info_helper: can't find out current locale character set info_helper: can't find out current locale character set demux_asf: stream: 1, bitrate 68571 bps demux_asf: stream: 2, bitrate 986849 bps demux_asf: video stream_id: 2, audio stream_id: 1 audio discontinuity #2, type is 0, disc_off 0 waiting for in_discontinuity update #2 vpts adjusted with prebuffer to 874482 load_plugins: plugin ffmpegvideo will be used for video streamtype 05. ffmpeg_audio_dec: increasing buffer to 98304 to avoid overflow. load_plugins: plugin ffmpegaudio will be used for audio streamtype 20. info_helper: can't find out current locale character set I noticed when xine-lib was building it gave a warning re internal/external ffmpeg mismatches ... might this be the problem? I tried re-emerging ffmpeg (without the thread USE flag which had somehow been set), and then xine-lib, but no joy. ffmpeg is ver. 0.4.9_p20050226-r3.
Created attachment 56716 [details] config.log (again) original attachment appears corrupt? (poss. due to gzipping)
Can you also attach the output of configure stage?
What's the best way to do this?
emerge xine-lib 2>&1 | tee output.log then ctrl-c when it starts compiling.
Created attachment 56876 [details] Configure output Is this sufficient?
Please tell which version of win32codecs you are using, but this sounds like a problem with upstream xine, as support is enabled on configure.
win32codecs is 20050412. This was updated from the previous version (which didn't play wmv files either) just a few nights ago.
Please try with xine-lib 1.0.1, and if it still doesn't work, try to report upstream, the problem seems to be with xine-lib not finding the right codec for your file, not gentoo-specific.
OK tried xine-lib-1.0.1, and it doesn't work with that either (or indeed even compile without the speex USE flag, and the xvmc vo driver has disappeared). I'll look into reporting this upstream then.
I've also been having problems with Xine and wmv lately. I can't really offer any insights, but I originally suspected ffmpeg. The ffmpeg USE flag was added to Xine recently, wasn't it? I thought that was the cause of my problems.
ffmpeg useflag is used to link xine to system ffmpeg library instead of using the one inside xine-lib itself. If you are using it, make sure you also have win32codecs useflag enabled in ffmpeg itself.
emerge -pv ffmpeg [ebuild R ] media-video/ffmpeg-0.4.9_p20050226-r5 -a52 +aac (-altivec) -debug -doc -dts +encode -ieee1394 +imlib +mmx -network +ogg +oss +sdl -threads +truetype -v4l +vorbis +xvid +zlib 0 kB So it looks like the current ffmpeg in ~x86 does not use the win32codecs USE flag. Should it? OK, just recompiled xine-lib with -ffmpeg (e.g. USE="-ffmpeg" emerge --oneshot xine-lib). The WMV files that didn't work now work OK. So this is an ffmpeg issue or an issue with xine working with external ffmpeg.
Sorry I though ffmpeg had win32codecs support, I didn't cared too much about it before as I'm on amd64. The problem so is with system ffmpeg which doesn't support win32codecs as they should. You should be able to configure xine to not use ffmpeg fromt he configuration, but I'll find a better fix asap.
OK well it would be good to get this fixed. I think xine-lib is the only package that uses ffmpeg (I don't use vlc), so I can just remove ffmpeg for /etc/make.conf until it gets fixed.
ffmpeg isn't and won't support win32codecs... ffmpeg is providing itself a set of codecs. I think that you may just change the codec family to use for certain media.
I'm not sure I understand that. The problem here appears to be that external ffmpeg support for xine-lib is broekn, but using the internal ffmpeg works OK. And how does one "change the codec family to use for certain media" - only a recompilation with -ffmpeg seems to fix this.
I had the same issue. I found out that by commenting out the libdir-pic.patch line in the ffmpeg ebuild and rebuilding it that I can now open wmv/asf files in apps that use xine-lib.
I've not tried this solution myself but I will do later. Maybe a bug report should be filed against ffmpeg?
Them problem seems to be that: external ffmpeg is newer than internal, so it supports more formats (that's why we have an useflag to use it, as xine's one sometimes fails to decode some formats). It seems to have also an experimental wmv3 decoder, and xine, with base configuration, tries to use ffmpeg before passing to closed win32codecs. ffmpeg fails to decode the file and reports error, xine doesn't try to get around this and fails. You can configure from xine advanced preferences the code priority, just move win32codecs above ffmpeg and it will use that directly. It's not a complete fix but for that one I think we should wait upstream which is dealing with new ffmpeg right now.
If Tom's findings are consistent though, it just means that the ffmpeg ebuild is not being built/configured correctly, not that there is an incompatability between it and xine. Simply building xine-lib with no ffmpeg USE flag is an adequate workaround for me. I see the priority options for the various codecs (configuration experience level needs to be Expert or above) in the 'Engine' tab - I'll maybe recompile xine-lib later and play around with these.
ffmpeg as no trouble into this, a part from having an experimental non-working wmv3 codec.
That is a user configuration issue. wmv3 isn't exactly a friendly/common format. mark priority and severity as should. once we sort out other more problematic bugs probably a simple change in the wmv3 codec priority will be added. In the mean time just set it on your own as others do for other proprietary format. Sorry but we are currently swamped in the gcc-4 preparation and on fixing other programs with other building issues.
I can confirm Tom's finding that commenting out the libdir-pic.patch in the ffmpeg-0.4.9_p20050226-r5 allows xine to play wmv files with the ffmpeg USE flag. Luca, (sadly) wmv is an increasingly popular format on the web. I know now there appear to be 2 workarounds to fix wmv playback for xine. What exactly does the libdir-pic patch for ffmpeg do? If it's just a matter of a one-line fix in the ffmpeg ebuild it would be a shame not to fix this because of commitments to gcc-4. There are a couple of threads on the forums popping up about wmv playback in xine as well.
It's an *enhancement* as xine-lib issue it's just a configuration problem, change codecs priorities and it works. Please *not* upgrade priorities and severity in future.
Which arch are you using Jonathan? the libdir patch just changes the $prefix/lib with $libdir defined as $prefix/$(get_libdir) in order to support lib64 on multilib systems... (and adds a missing pic flag in libavformat) Could you try to edit the patch and just remove "$(PIC)" ad tell me if is working for you that way?
Luca, I removed the 2 instances of $(PIC) in the CFLAGS lines at the foot of ffmpeg-libdir-pic.patch, re-emerged ffmpeg, re-emerge xine-lib with ffmpeg USE flag, and now .wmv files play OK on xine with external ffmpeg. This is on ~x86 (Athlon XP 3200) btw.
The $(PIC) present is a necessary fix for amd64. if you emerge it w/out pic useflag (and the patch with the $(PIC) in place) does it work?
Luca, I don't have the pic USE flag, and I never have.
Removing the two $(PIC) would probably disallow .so pic libraries from being built and then xine-lib can't use them, so it defaults to internal ffmpeg.
xine requires pic libraries to build plugins, removing that avoid the use of external ffmpeg. As the external ffmpeg has a preliminary support for WMV3 files, xine then tries to use that instead of the win32codecs binary, and fails to decode. There's no way to force the use of win32codecs beyond users' prefs for xine. That's the way to go. Please set the precedence of the codec in the settings and let xine use win32codecs before trying to use ffmpeg.
