Re: [packman] FFmpeg 2.3 and vlc-beta (fourth attempt)
LB aloisio@... writes: I tried ffmpeg 2.4 but it breaks too many things Please do not use FFmpeg 2.3 To the best of my knowledge, recompiling an application with FFmpeg 2.4 that works with 2.3 is supposed to work fine, if you encounter any problems, please report them! Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] VLC fix
Manfred Tremmel manfred@... writes: I've packaged ffmpeg 1.2 and 1.2.1 in the past and got back to 1.0.x. Three or four packages didn't work correctly with 1.2.x (no compile problems, but runtime problems). Could you point me to the bug reports? If this is only about libavutil, you should be able to find better fixes imo. I don't think, we should switch to 1.2! FFmpeg 1.2 is actively maintained... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PMBS] SR 227 Essentials/ffmpeg
Manfred Tremmel manfred@... writes: I had big problmes in the past between incompatible ffmpeg libs with the same so number. Please always report such problem either on ffmpeg.org/trac or via PM. I do not (easily) remember an ABI break. What I do remember is projects that use internal FFmpeg functions (that are not exported in private headers), I don't think there is anything FFmpeg developers can do about it... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Live555 build?
Rodney Baker rodney.baker@... writes: OK, thanks Manfred. Pascal also replied. Is it sufficient then to install the -devel package to be able to build mplayer (and ffmpeg?) with live555 support? FFmpeg does not support live555. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] RPM Suse 12.1 Avidemux
Hi! Lutz Nowack mail@... writes: peinlicher Fehler. Das muss natürlich AC3 (aften) heissen... Asche auf mein Haupt. Ich kenne avidemux nicht sehr gut, aber aften wird nicht mehr weiterentwickelt, die beste Version des AC-3 encoders ist jetzt in libavcodec. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Tumbleweed: avformat_close_input needed by mlt missing from libavformat53
Pascal Bleser pascal.bleser@... writes: Well, mlt doesn't even use that function (avformat_close_input), but uses av_close_input_file() instead. Afaict, both functions are defined in current FFmpeg and 0.9. Or am I wrong? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Stripped-down ffmpeg?
todd rme toddrme2178@... writes: Currently programs openSUSE offers stripped-down versions of libraries like like gstreamer and vlc that exclude codecs that cannot be legally distributed. As best as I can tell this is not the case, however, for ffmpeg. Packman used to distribute a version of FFmpeg that could not be legally re-distributed. This was fixed some time ago, if you believe that Packman's FFmpeg version contains any code that cannot be legally distributed, please be more specific. (And note that there may be jurisdictions where it is not allowed to spread such possibly harmful claims.) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] MPlayer broken for .flv files
Olaf Hering olaf@... writes: Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory This is reproducible with current Packman MPlayer: MPlayer-config.patch (part of Packman's patches against MPlayer source) assumes that if vo vdpau does not work, [vo.vdpau] profile will not be used. I don't know if this is intended to work (I suspect the profile is loaded before vdpau-initialisation fails), but I can at least confirm that it definitely doesn't work. Apart from that: If joystick is not wanted, it can be disabled at compilation time, no reason to do it at runtime. vo=vdpau,xv should not be needed, it is the current default (if this default changes, there likely will be a good reason) The bug was reported earlier: http://thread.gmane.org/gmane.comp.package-management.packman/5434 Unfortunately, I didn't understand that the user had not manually added the profile. (I had originally mildly protested against the changed config file, though.) Workaround is to either delete /etc/mplayer/mplayer.conf or just the lines vo=vdpau,xv and vc=ff Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] RFC: improve MPlayer build in packman
Kshitij Kulshreshtha kkhere.geo@... writes: using the attached patch in the MPlayer build on pmbs will not build the internal ffmpeg copy in the MPlayer tree but only use it for internal header-files and will link with the preinstalled ffmpeg libraries from the ffmpeg package. This would remove some features from MPlayer. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] AC3 encoder broken - simply noise
Carl Eugen Hoyos cehoyos@... writes: In the past, there was one AC3 encoder in FFmpeg. It expected int16, and had the name ac3. Now there are two encoders: One with the name ac3 expecting floats, and one that's called ac3_fixed (the same one as the older one, just with another name) that expects int16. If the (new) ac3 encoder is fed with ints, it will produce noise. This should have significantly improved now: The ac3 encoder now accepts both int and float, AVCodecContext-sample_fmt has to be set to the correct format (AV_SAMPLE_FMT_S16 or AV_SAMPLE_FMT_FLT). (For compatibility, there still exists the ac3_fixed encoder.) There might be a bug in FFmpeg that it does not refuse to encode if the application did not explicitly announce to provide float data, but I can't confirm this since I don't know much about the encoding interface. If this was ever correct, I suspect it is still a problem (a common bug in applications - not setting sample_fmt - was invisible due to a bug in FFmpeg). Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] RFC: improve MPlayer build in packman
Kshitij Kulshreshtha kkhere.geo+suse@... writes: using the attached patch in the MPlayer build on pmbs will not build the internal ffmpeg copy in the MPlayer tree but only use it for internal header-files and will link with the preinstalled ffmpeg libraries from the ffmpeg package. This would remove some features from MPlayer. Are you sure? Which features are those? Yes, some video filters cannot be built with shared libavcodec, please see configure for details. Do they explicitly require static linking with ffmpeg, instead of just using private header files? You cannot solve the problem you claim to have (I do not understand it) by including internal headers: They are internal because you must not include them to build a project that uses shared libavcodec. If you look into the patch in my last email, you will notice that all files that were conditioned on defining FFMPEG_A are still built with this patch using private header-files from the local copy of ffmpeg, but ffmpeg itself is not compiled. So you suggest to provide users with a MPlayer version that is guaranteed to break if they decide to update their libavcodec library? I don't think that would be a good idea. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] RFC: improve MPlayer build in packman
Kshitij Kulshreshtha kkhere.geo+suse@... writes: Do they explicitly require static linking with ffmpeg, instead of just using private header files? You cannot solve the problem you claim to have (I do not understand it) by including internal headers: They are internal because you must not include them to build a project that uses shared libavcodec. Fortunately it is not a problem or a bug. The aim of the patch was to simply reduce build load on the pmbs. If packman packagers don't want to use it for whatever reasons, that's their choice. If internal headers are internal, and you're so opposed to them being included in external packages, why have you (you are a mplayer and ffmpeg developer) still included them in these filters? The filters need FFmpeg internals for their purpose: At the time they were written, no FFmpeg filter layer existed, so they could only be written the way they are. If you look into the patch in my last email, you will notice that all files that were conditioned on defining FFMPEG_A are still built with this patch using private header-files from the local copy of ffmpeg, but ffmpeg itself is not compiled. So you suggest to provide users with a MPlayer version that is guaranteed to break if they decide to update their libavcodec library? I don't think that would be a good idea. If a user uses packman's MPlayer it is almost certain that they're also using packmans ffmpeg (libavcodec etc). (Disclaimer: I don't know much about shared libraries.) I believe the general idea is that you compile an application against a shared library, and if you update the library later, you do not have to recompile the application. If you build MPlayer with the filters (not) mentioned above, and you update libavcodec later, you have no guarantee that MPlayer still works because some of the used functions are not part of the public API. (I know that one of the negative effects of the traitor's fork is that some API breaks from the fork are pulled into FFmpeg, and my argument is therefore partly void, but I currently see no easy solution for this problem. Please report all regressions you see.) Note that there is a (very small) performance penalty for using shared libavcodec, and I believe MPlayer is one of the few applications where you want to avoid it. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] AC3 encoder broken - simply noise
Manfred Tremmel manfred@... writes: In the past, there was one AC3 encoder in FFmpeg. It expected int16, and had the name ac3. Now there are two encoders: One with the name ac3 expecting floats, and one that's called ac3_fixed (the same one as the older one, just with another name) that expects int16. If the (new) ac3 encoder is fed with ints, it will produce noise. Wouldn't it be usefull go keep the ac3 encoder using int16 and add the new one as ac3_float instead of breaking compatiblility with existing programms? Given that many programs have now changed their code, I am not sure if this is the best solution (but I do not have a better suggestion). Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] ffmpeg not in monolithic repository
İsmail Dönmez idoenmez@... writes: Video filters code is directly dumped from MPlayer with zero peer review. You do realise that the video filters were heavily tested when they were written and ever since? (The problem with the reviewed video filters in both FFmpeg and the fork is that they are often worse than their originals.) FFmpeg as it is one man's project So I guess Baptiste, Reimar, Aurelien, Stefano and the others do not count as men? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] ffmpeg not in monolithic repository
Neil Darlow neil@... writes: On Sunday 03 Apr 2011 23:13:23 Carl Eugen Hoyos wrote: But it contained a regression before it was merged into FFmpeg. So libav introduced features that were less than perfect while the ffmpeg project chose to wait until they were? That is how FFmpeg development is done, yes. (Note that the main criticism about the project maintainer was that he paid too much attention on reviews and not enough on development. He has now switched to a more active development style that implies less reviews, but the most obvious exploitable issues and regressions that are part of the fork are still refused in FFmpeg.) Fortunately, you do not have to believe me to know that this is not correct, you just have to read the explanation from the ffmpeg-mt developer: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/124245 My information was taken from the libav website's explanation for their existence. Maybe I should have consulted the ffmpeg project for their perspective on why libav came about. I'm sure there are reasons, both good and bad, on both sides. I am looking forward desperately for the bad reasons on the FFmpeg side ;-) (Although, on a more theoretical basis, I don't know how FFmpeg's reasons for people to fork after they unsuccessfully tried to take over the project can a) exist and b) be bad.) Note that FFmpeg contains several features missing in the fork, video filters among them. (No features from the fork are missing in FFmpeg, the fork just contains less fixes for user-reported bugs.) I don't know how to interpret that. libav removed features from ffmpeg. Do you claim that or is this something that you interpreted from my mail? While the fork actually has removed features by breaking API/ABI, I do not know of features (things the application can do) that were removed, I just know that the fork currently has less features than FFmpeg because they prefer not to pull new features (and bug fixes) from FFmpeg. Is there an inference that libav removed troublesome features or it is that their development model provides less manpower or time for bug fixes. I fear I am not capable of answering the question why the fork misses most bug-fixes from FFmpeg development - both security and usability-wise. Correctness of my statement apart, I am sure that Manfred switched from ffmpeg to libav for good reasons. The reason I posted here is that I would like to hear those reasons (after all, I may miss something that happens - or is planned or promised - in the fork but not in FFmpeg - this knowledge could be used to improve development in FFmpeg). I also expect he was aware of any defiencies introduced by making the switch before he committed to doing so. Given how you believed what the people who forked claim on their homepage were true, how should he? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] ffmpeg not in monolithic repository
Neil Darlow neil@... writes: libav had multithreading support before ffmpeg. But it contained a regression before it was merged into FFmpeg. That was, apparently, one of the issues leading to the fork. The ffmpeg lead developer was reluctant to add the feature but was forced to do so after libav released with it. Fortunately, you do not have to believe me to know that this is not correct, you just have to read the explanation from the ffmpeg-mt developer: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/124245 Note that FFmpeg contains several features missing in the fork, video filters among them. (No features from the fork are missing in FFmpeg, the fork just contains less fixes for user-reported bugs.) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Bug? Mplayer
Gabriel Sichardt jastgasi@... writes: Loading extension-related profile 'vo.vdpau' Grundsätzlich sind Fehlermeldungen mit einem profile, das nicht Teil der Fehlermeldung ist, schwer zu analysieren. Playing /media/Medion-ext3/video/Hollywood Cops.m2t. TS file format detected. VIDEO MPEG2(pid=511) AUDIO A52(pid=515) NO SUBS (yet)! PROGRAM N. 1000 VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) Load subtitles in /media/Medion-ext3/video/ Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory Du hast keine Nvida-binary Treiber installiert (oder sie sind fehlerhaft), [vdpau] Error when calling vdp_device_create_x11: 1 == Forced video codec: ffmpeg12vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffmpeg12vdpau] vfm: ffmpeg (FFmpeg MPEG-1/2 (VDPAU)) versuchst aber dennoch, VDPAU (hardware-beschleunigtes) Decodieren zu aktivieren. Das kann nicht funktionieren. Die aktuelle Packman MPlayer Version (ist zwar veraltet, aber) funktioniert für mich mit -vc ffmpeg12vdpau, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] w32codec-all 20100303-0.pm.1.1 (openSUSE 11.3/i586)
Gerd Lehmann wsl-einbeck@... writes: habe eine Frage zu den w32Codecs. gibt es die nicht für Suse 11.3 64bit? Ich habe die w32 installiert, aber der M-Player greift anscheinend nicht drauf zu. Abgesehen davon, daß ein 64bit MPlayer w32Codecs nicht unterstützt: Wozu eigentlich? Ich kenne fast keine Datei, die das Paket benötigt (und habe deshalb schon wiederholt vorgeschlagen, es aus packman zu entfernen: Ich wäre überrascht, wenn es nicht für einen wesentlichen Teil des Netzwerkverkehrs verantwortlich wäre). Carl Eugen PS: Ein Beispiel für eine nicht-unterstützte Datei könnte dazu führen, daß das Format in Zukunft unterstützt wird... ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] mplayer suggestion ...
Pascal Bleser pascal.ble...@... writes: * vo=vdpau,xv This is not a good idea, if the default has problems, please tell (me). Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Pascal Bleser pascal.ble...@... writes: So the idea with option 3 would be to provide both: - we would keep the current approach in the regular repository (or repositories) - we would also *additionally* provide a frozen repository with the essential packages (as said, ffmpeg, mplayer, mad, gstreamer, ...), and only update those when there are critical bugfixes or security fixes (I of course can't speak for gstreamer - we believe it simply serves no real-world purpose and that is of course meant polemically - and I don't think any Packman user needs mad, I at least can't imagine a situation. Was mad really updated lately?) There is nothing stable that you could use as frozen repository in FFmpeg and MPlayer (there were only too few updates to Packman MPlayer in the last months). So far, the so-called releases always were ancient (and therefore unusable) at the time of the release. They only exist because it allows to add FFmpeg to the Ubuntu repositories. End-users should never get in touch with them (and no bug-reports are accepted for anything else than latest svn). While this may sound as if, it is not meant polemically, I am just trying to stop you from doing something that does not help any user (and you seem to agree that it would mean some extra work)! If you have a bandwidth problem, I suggest to remove win32-codecs, I don't think anybody needs it and it can be downloaded from mplayerhq. Carl Eugen PS: There will be a version bump for libavcodec etc. in the not too far away future and that will of course change your situation slightly. But since it is unknown when it happens and it did not happen for the last two (?) years, I suggest you care about it when it happens. (And such a bump has of course no effect on Packman MPlayer.) ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Hi! Pascal Bleser pascal.ble...@... writes: Option 3: debianista Another approach to several projects/repos could also be to split into stable and unstable or, rather, to freeze the versions of codecs and multimedia packages with every openSUSE release (and only update on critical bugfixes and security issues). I'd like to *strongly* discourage this! Please believe me that this does not solve *any* (possible) problems. (for FFmpeg and MPlayer, I am not sure what else could be meant with codecs and multimedia packages and I don't know how well or how badly this would work for other projects). I don't immediately see what's wrong with 1), but I may not see the important things there. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Shorten License
Pascal Bleser pascal.ble...@... writes: Solved, as discussed on the other thread. No, afaict faac is still listed as GPL v2 or later and the description says FAAC is licensed under the GPL. Correct, I didn't check there. Fixed too (building as we speak) Thank you! Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Shorten License
Pascal Bleser pascal.ble...@... writes: On 2010-11-15 13:34:25 (+0100), Carl Eugen Hoyos c...@... wrote: [...] Thank you, next problem is (lib)faac, it is also listed as GPL, but it is actually non-free: http://www.audiocoding.com/faac.html (Making it impossible to distribute FFmpeg linked to faac.) Solved, as discussed on the other thread. No, afaict faac is still listed as GPL v2 or later and the description says FAAC is licensed under the GPL. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] libavcore needs latest libavutil
Manfred Tremmel manf...@... writes: Ok, you are right. I've reed the GPL and LICENSE file from ffmpeg and yes, I've made a mistake. I've also turned of building libfaac support in my daily snapshot. Thank you! FYI, after zypper update ffmpeg, libavfilter is still outdated. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] libavcore needs latest libavutil
Hi! When I updated (only) ffmpeg today, libavcore was installed, but libavutil was not automatically updated, leading to this output: $ ffmpeg ffmpeg: relocation error: /usr/lib64/libavcore.so.0: symbol av_default_item_name, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference Allow me to repeat that Packman currently violates FFmpeg copyrights by distributing a non-free binary (that may not be redistributed). Note that the GPL (which Packmans version of FFmpeg contains code for) requires all parts of the software to be licensed under the GPL (or a compatible software license) which is not the case for the binary Packman distributes (=Packman risks to permanently loose the right to distribute GPL'ed software in this package). Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] libavcore needs latest libavutil
Manfred Tremmel manf...@... writes: Am Montag, 15. November 2010 schrieb Pascal Bleser: On 2010-11-15 14:53:26 (+0100), Pascal Bleser pascal.ble...@... wrote: On 2010-11-15 12:27:40 (+), Carl Eugen Hoyos ceho...@... wrote: When I updated (only) ffmpeg today, libavcore was installed, but libavutil was not automatically updated, leading to this output: $ ffmpeg ffmpeg: relocation error: /usr/lib64/libavcore.so.0: symbol av_default_item_name, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference Seems like ffmpeg is missing explicit Requires on the libraries that spawn out of it. On a side not: thank you very much ffmpeg upstream to not care about releases and proper SONAMEs, this is really a mess we have to take care of as packagers, and it's a major pain in the bottom *sigh* This never should happen if you do a zypper up or zypper dup is done, because there's allways updated the complete package. That is exactly what I did today (I did not update manually) and the libraries where NOT updated (which - one could argue - might be ok, because this works most of the time, but not with the introduction of libavcore which needs a newer libavutil; additionally, it probably makes no sense regarding the cause of the update). Let me repeat that I think it is very good of Packman not to use (so-called) released versions of FFmpeg, but to update regularly. [...] Allow me to repeat that Packman currently violates FFmpeg copyrights by distributing a non-free binary (that may not be redistributed). Note that the GPL (which Packmans version of FFmpeg contains code for) requires all parts of the software to be licensed under the GPL (or a compatible software license) which is not the case for the binary Packman distributes (=Packman risks to permanently loose the right to distribute GPL'ed software in this package). You mean because of faac ? AFAICS, ffmpeg is built without faac support. At least it is now. It's build with libfaac support! But I can't see the problem. Everything inside the ffmpeg package is part of the ffmpeg tarball (libfaac.c includes lgpl licence), even the includes out of libfaac which are included are lgpl licencesd. It's linked against a shared library (libfaac) which contains lgpl and proprietary code like it's provided from the faac project. If compiling gpl software against proprietary libs is not allowed, every Windows and MacOS GPL software is illegal because they all link direct or indirect against proprietary libs of the underlying Operation System. Please actually read the licenses before making such statements (that do not really add confidence): The system libraries are explicitely mentioned in the licenses (that - iirc - were written at a time when no free system libraries existed for real world applications). Let me add the following: Originally, we all did not know that libfaac was never free software, so we (FFmpeg developers) can hardly blame anybody who distributes an old FFmpeg version compiled as GPL and linked against libfaac. Since I've explained now that libfaac is non-free and you cannot link a GPL'ed software against a non-free library, please stop distributing such binaries. Thank you, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] libavcore needs latest libavutil
Pascal Bleser pascal.ble...@... writes: I turned it off for now, needs clarification whether that's actually a badass feature everybody needs. Or not. FFmpeg contains a native AAC encoder. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] ffmpeg 0.6.25512svn-2.pm.3.1 (openSUSE 11.3/x86_64)
Manfred Tremmel manf...@... writes: Sorry, my fault. libfaad is no longer needed for ffmpeg, looks like i've also removed libfaac support. I'll reenable it ASAP. Apart from the copyright violation, the following in the spec file look suspicious: All references to dca are useless since a very long time (libdca-devel and libdca0), I can't imagine what libmp4v2-devel should be good for and the spec file still contains references to liba52-devel (unused for several years) and G.729-devel (I have never heard of that). Any reason why libopenjpeg is not enabled? It is impossible to decode jpg2k without it. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] ffmpeg 0.6.25512svn-2.pm.3.1 (openSUSE 11.3/x86_64)
Manfred Tremmel manf...@... writes: http://forums.opensuse.org/english/get-help-here/applications/448483- ffmpeg-libfaac.html directly related to these packages? Any suggestions to resolving this problem? Sorry, my fault. libfaad is no longer needed for ffmpeg, looks like i've also removed libfaac support. I'll reenable it ASAP. Please don't! You cannot legally distribute an FFmpeg executable with libfaac support and GPL support enabled: GPL requires that all source files of the executable are distributed under the GPL, libfaac is proprietary software (that cannot be distributed under the rules of the GPL). (Note that my comment should not imply that it is legal to distribute FFmpeg without GPL symbols but with libfaac enabled, it is just not as simple to argue and I am sure nobody wants to loose x264 support.) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] w32codec-all 20100303-0.pm.1.1 (openSUSE 11.3/i586)
Bruno Friedmann br...@... writes: and I'm trying to understand how we can have those f**cking dll inside a 64bits env. Thy should not be needed for any real-world sample (VC-1 interlaced - which is not supported by libavcodec - often does not work with them either) and they are very slow. Do you know if there's a way to do that ? Just compile a 32-bit MPlayer. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] ffmpeg 0.6.25320svn-1.pm.2.1 (openSUSE 11.3/x86_64)
Cristian Morales Vega cmorv...@... writes: I'm receiving this error when compiling against the new ffmpeg package: /usr/include/libavcodec/opt.h:32:27: fatal error: libavutil/opt.h: No such file or directory And it's just true. libavcodec/opt.h includes a libavutil/opt.h that doesn't exists. Fixed in r25420. Thanks for (confirming the) report, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Shorten License
Hi! Package information lists GPL as license for Shorten (audio codec). Looking at the source package, the COPYING file seems to contain a proprietary software license... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] MPlayer
Hi! For several years, playing H264 PAFF samples (like most 1080i samples recorded from DVB) was not possible with MPlayer's native mpegts demuxer (which still is the default for playing ts recordings) without seeing horrible A/V desync. Even playing them with -demuxer lavf showed jitter problems (at least on some display devices). These timing problems where finally fixed last week, I did not receive any problem reports since, so I strongly recommend to update MPlayer. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] FFmpeg
Manfred Tremmel manf...@... writes: I would suggest not to use released versions, but to continue updating to latest svn whenever new features are available (that would be AAC+v2 aka Parametric Stereo atm). It's not easy to keep all programms working with new svn snapshots. It would be great if you could report such problems: We spend a lot of time trying to avoid them and I don't know of any API regressions / none are reported on roundup. Not seldom api changes make it necessary to patch programms. I would be glad to keep 0.6 for a while. As I said, API did not change for over a year, please report all such problems! Consider --disable-libavfilter when building the ffmpeg executable. avfilter is enabled. I know, I just wanted to tell you it triggers a few regressions. And btw, the libavfilter summary is wrong and all summaries spell FFmpeg wrongly. I'll fix this with the next rebuild. I've named it ffmpeg but rpmlint was not happy with it, so I've replased the first f with a upercase F. That's why you should use FFmpeg, please! PS: If you want to have the latest snapshots, just take a look at http://packman.jacobs-university.de/suse/testing/xine-cvs/ It's my personal testing tree with daily snapshots of libxine and needed libs (like ffmpeg and x264). There may be a misunderstanding: I don't need latest snapshots from packman (I am using daily snapshots), but Packman's users have a right to decode AAC+, imo. ;-) And while you are at it, please remove libfaac from your build, there is a native AAC encoder, and we start to chase license violators. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] FFmpeg
Cristian Morales Vega cmorv...@... writes: FFmpeg always had the fame of *the* API/ABI unstable library. That's probably why API hasn't changed for more than one year;-) When match_ext was substituted for av_match_ext it was done in a way av_match_ext was never part of public API, please stop trolling! CE ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] FFmpeg
Hi! I saw you updated to FFmpeg 0.6 I would suggest not to use released versions, but to continue updating to latest svn whenever new features are available (that would be AAC+v2 aka Parametric Stereo atm). Consider --disable-libavfilter when building the ffmpeg executable. And btw, the libavfilter summary is wrong and all summaries spell FFmpeg wrongly. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Fix include path for librtmp
Carl Eugen Hoyos ceho...@... writes: Both rtmpdump-2.2b (the version Packman is currently using) and rtmpdump-2.2e install headers into a librtmp subdirectory. Packmans installs the headers without using a subdirectory. Please fix, Carl Eugen Any news on this? Applications that conform to librtmp's Makefile (like MPlayer and FFmepg) do not compile with Packman's version of librtmp. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] WebM-Support für ffmpeg und MPlaye r
Henning Paul henningp...@... writes: ich hab' mal interessehalber libvpx (WebM) paketiert und die Patches für MPlayer und ffmpeg in die jeweiligen Pakete eingebaut. Vielleicht ist es ja von Wert für Euch. http://www.ant.uni-bremen.de/~paul/tmp/libvpx-git20100607-1.src.rpm http://www.ant.uni-bremen.de/~paul/tmp/MPlayer-1.0rc2_r31189-2hnch.src.rpm http://www.ant.uni-bremen.de/~paul/tmp/ffmpeg-0.5.23289svn-2hnch.src.rpm Wären updates auf neuere Versionen nicht die einfachere Lösung? mplayer -demuxer lavf funktioniert nun wirklich mit PAFF samples (andererseits ist mplayer -vf pp -vc mpeg12 seit heute kaputt, also vielleicht die Version von gestern?) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Mplayer
Stephan von Krawczynski sk...@... writes: # mplayer clip1.mpg mplayer: error while loading shared libraries: libvdpau.so.1: cannot open shared object file: No such file or directory Das sieht nach einem Packman-Abhängigkeitsfehler aus - da will ich mich aber nicht zu viel einmischen;-) Ich hatte r29903 aber auf dieser Liste extra erwähnt: http://thread.gmane.org/gmane.comp.package-management.packman/3131/focus=3172 [...] Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vdpau] Error when calling vdp_device_create_x11: 1 Ich verstehe zwar, daß das nicht schön ist, aber ähnliche Fehlermeldungen kommen auch für lirc, den Joystick und mpegpes, das sollte also akzeptabel sein. [...] VO: [xv] 352x240 = 352x262 Planar YV12 Das ist jetzt genau richtig, es wird statt vdpau ein anderes vo gewählt (xv). Wie man sieht versucht libvdpau nun das nvidia Backend zu laden, was nicht geht. Das ist schon allein deshalb merkwuerdig, weil mein System gar keine nvidia Hardware hat, sondern ATI radeon. Ja, aber die Nvidia Besitzer unter den Packman Benutzern freuen sich, und für den Rest sollte MPlayer noch immer funktionieren... MPlayer oeffnet im uebrigen ein Fenster, dessen Inhalt schwarz ist, ganz gleich was fuer ein Video-Format man probiert (mpg, wmv, flv, ...). Vielleicht funktioniert xv für Deine ATI Karte nicht? Was passiert bei mplayer -vo gl:yuv=2 (oder nur gl)? Selbstverstaendlich habe ich auch schon probiert libvdpau_nvidia zu installieren, dann landet man hier: Das sollte nicht erforderlich sein;-) Um die häßlichen Zeilen im output abzustellen, am besten in ~/.mplayer/config folgende Zeilen hinzufügen: vc=-mpegpes, vo=-vdpau, oder vo=-vdpau,-xv, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] MPlayer 1.0rc2_r29796-2.pm.2 .6 (openSUSE 11.2/x86-64)
Ahmed xfit...@... writes: whenever I play any multimedia file using Mplayer, I got an error message Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory. My acer notebook is equipped with ATI Radeon Graphic Card, thus I cannot install Nvidia proprietary driver in order to fix this issue. Which is not necessary, you just have to install the open-source VDPAU wrapper library: http://packman.links2linux.de/package/libvdpau I'm sure that many other linux users like me use ATI or even intel graphic cards. I wish you could re-build the packages without the VDPAU feature pre-enabled/configured. I would not appreciate that solution... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] wma not functioning in openSUSE-11.2
oldcpu old...@... writes: Test files: * wma: http://www.theflute.co.uk/htmlMain/samplemusicW.htm (try the file Allegro ) wmav2, supported even by older versions of MPlayer * wmv: http://www.jhepple.com/support/sample_movies1.htm (try NiceDay.wmv file at the bottom of the page) Same audio, video can only be decoded correctly with the binary codec (available for x86-32 only). Note that I cannot test 11.2, I just wanted to explain that audio is certainly supported by - even older versions of - libavcodec (=FFmpeg, MPlayer) for these samples. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] libvdpau 0.2-0.pm.2.1 (openSUSE 11.2/i586)
Pascal Bleser pascal.ble...@... writes: We package that shim library, that only contains the headers and the trace (non-)implementation. I just committed a patch to MPlayer svn that avoids dynamically loading libvdpau.so.1, but links at compile time against that (open-source) library if it is installed. So to compile the next version of pm-mplayer, you need libvdpau (and libvdpau-nvidia is obsolete, afaict). Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] Win32-Codecs 20071007-0.pm.1 (openSUSE 11.1/i586)
Michael Schueller schueller-ber...@... writes: Ich hab vorhin gerade noch mal die ffmpeg und libffmpeg0 erneut installiert (drüber gebügelt), aber trotzdem kein Ton bei allen Playern. Keine Ahnung was hier los ist. Vollständige, ungeschnittene Ausgabe von mplayer datei (und ffmpeg -i datei)? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] libvdpau 0.2-0.pm.2.1 (openSUSE 11.2/i586)
Pascal Bleser pascal.ble...@... writes: Carl: anything wrong with that approach? I'm not sure I fully understand your reply above. Sorry, my answer was of course related to the old nvidia-vdpau-devel package, I had not yet seen the new package (which is probably correct - since hardware for the only alternative implementation, S3, is unavailable, I did not yet think much about it and can't really judge.) Sorry for the noise, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] nvidia-vdpau-devel
Hi! Nvidia released a new version of the VDPAU headers (which allow MPEG4 ASP decoding and high-quality scaling with supported - rare - hardware). MPlayer will hopefully soon support the new features. Please update nvidia-vdpau-devel to version 190.32: ftp://download.nvidia.com/XFree86/Linux-x86/190.32 Thank you, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] Win32-Codecs 20071007 (openSUSE 11.0/i586)
VKS Kraiburg vkskraib...@... writes: Desshalb meine Frage: Welche Paket muß ich zusätzlich installieren? Welches Repositorie muss ich zusätzlich einbindn um das entsprchende Paket installieren zu können. Zuerst zum Betreff: Um Audio CDs oder DVDs abspielen zu können, sind die win32 Codecs nicht hilfreich. Sie waren früher erforderlich, um einige nicht sehr ausgefallene Medienformate abzuspielen (aber nie CD und DVD). Inzwischen werden sie nur mehr für sehr ausgefallene Formate benutzt (weshalb ich hier schon empfohlen habe, sie ganz aus dem Packman Verzeichnis zu entfernen, da sie möglicherweise für einen wesentlichen Teil des Datenverkehrs verantwortlich sind). CDs und DVDs spiele ich gern mit Kaffeine ab, es geht auch mit vlc (und natürlich mit MPlayer, da ist allerdings die Kommandozeile hilfreich). Für alle diese Programme im Yast Software Repositories wählen und sicherstellen, daß Packman Repository eingetragen ist (ein Teil der genannten Programme mag auch in den ooenSUSE Repositories zu finden sein, aber nur in einer unbrauchbaren Version). Soviel ich weiß, darf nie das vlc und das Packman Repository gleichzeitig aktiv sein. Dann im Yast Software Management starten, Kaffeine und vlc suchen (eventuell auch MPlayer und SMPlayer als Alternative), auswählen (sicherstellen, daß die gewählten Versionsnummern pm enthalten, also brauchbar sind) und akzeptieren. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Please add opencore amr support
Hi! Support for libamr was removed today from FFmpeg's repository: http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2009-July/023560.html Instead, support for opencore amr was added some time ago (does not support wb encoding). Please add opencore-amr to Packman, so amr decoding will still be supported in the future. (I don't know the official repository, but I just tried http://sourceforge.net/projects/opencore-amr/ and I had to add -fPIC to CXXFLAGS in amrnb/Makefile and amrwb/Makefile.) Thank you for your work, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Possible problems with MPlayer r29116
Hi! Thank you for re-packaging MPlayer, I believe the new version is a huge improvement compared to the older one I was using! (which may not have been latest...) VDPAU works fine, as does wmapro on 64bit! I want to point to two problems (one of which I am responsible for...): I only tested the 64bit version and realized that it prefers ffwmapro over binary drivers. In case this is not wanted (and ffwmapro is also compiled for 32 bit), the patch against etc/codecs.conf could be changed so that status says working instead of untested (untested is always preferred, iirc). The second problem is much more serious, imo: The 9-seconds sample in the sony-hdr-cx6-avchd directory in http://samples.mplayerhq.hu/V-codecs/h264 is broken as - afaik - every PAFF sample (they somehow play with -mc 10 -delay -0.n), it used to work in earlier MPlayer versions. While some PAFF samples never worked, this one can be fixed by reverting two changes in MPlayer's ffmpeg: svn up -r 17574 libavcodec/h264_parser.c libavformat/utils.c Note that I don't expect this revert to introduce new problems (for this version), because the changes *fix* many PAFF samples for ffmpeg/ffplay, but just break them for mplayer. (Even with the revert, the sample still only works for -demuxer lavf -correct-pts which is default for current MPlayer.) Thanks again, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] MPlayer VDPAU
Manfred Tremmel manf...@... writes: The only xine implementation I found is here: http://www.jusst.de/vdpau/filedetails.php?repname=xine-vdpaupath=%2F src%2Flibvdpau%2Fvdpau_h264.c It is a nice example of include all the problems of Nvidia's original implementation. I hope that is not the final version The patch from http://www.jusst.de/vdpau/files/xine-lib-1.2/ is, what I've included in my 1.2 build. It's not part of the offical version, maybe there are good reasons for... Yes, that is the tarred version of the link above. I just wanted to say Boy, this is ugly and buggy, but then, the copyright notices are actually much more interesting, especially given todays discussions on ffmpeg-devel;-) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] [PM] MPlayer 1.0rc2_r27637-3.pm.3 (openSUSE 11.1/i586)
Manfred Tremmel manfred.trem...@... writes: ob man die mplayer-mt--Version im Packman repo anbieten könnte. Übrigens nochmal vielen Dank für die gute Arbeit des Packman-Teams! Zur Info, ffmpeg und xine-lib sind mit pthread Support compiliert. Die auf xine-lib aufbauenden Player sind damit in der Lage multithreaded zu decodieren. In den video Optionen unter processing.ffmpeg_thread_count kann die Anzahl zu verwendender Threads festgelegt werden. Das gilt für H264 natürlich nur für slice-basierte Videos, die (z.B.) mit x264 gar nicht (mehr) hergestellt werden können. H264 soll aber auch mit ffmpeg-mt noch Probleme haben... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] MPlayer
Hendrik Vogelsang hvo...@... writes: Attached is a patch especially useful for x86-64, it contains the future wmapro implementation from ffmpeg-soc repository. With this patch, binary codecs should not be necessary anymore (in case you have bandwidth problems). Is that in your svn already? It is in ffmpeg-soc: svn://svn.ffmpeg.org/soc/wmapro If you don't want to use it for x86-32 (where wmadmo is available), I still recommend it for x64, because I fear it will still take some time to get into ffmpeg-svn. The only possible problem is the change to avcodec.h: wmapro also works without this change (with warnings about too large frames from time to time), but the change also fixes some flac files. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] MPlayer VDPAU
Manfred Tremmel manf...@... writes: I'll build it with vdpau support. While I fear nobody is currently using it: Please do so! I don't have a GPU which supports vdpau (end even if I had, I wouldn't use it as longe there's no free driver which supports it), but I've tested the vdpau supported codecs on my non vdpau computers. It doesn't have any negativ effect (it workes like before and I can't see any speed differences), so why not including it? As I said, please include, but I'd like to add that contrary to what you might have read lately from seamingly competent sources, ffmpeg itself does *not* support vdpau currently. I contains code that allows video players with vdpau support to actually use hardware accelerated decoding. AFAIK, (sadly) only MPlayer currently uses this approach. Since packman's MPlayer uses static libavcodec (as it should), it does not make much difference if your ffmpeg binary supports vdpau (for video players) or not. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] MPlayer VDPAU
Manfred Tremmel manf...@... writes: I contains code that allows video players with vdpau support to actually use hardware accelerated decoding. AFAIK, (sadly) only MPlayer currently uses this approach. Since packman's MPlayer uses static libavcodec (as it should), it does not make much difference if your ffmpeg binary supports vdpau (for video players) or not. Maybe others will use it, we have different players using external ffmpeg (libxine, vlc, gstreamer, maybe more). I hope so. vlc will (hopefully), since they are still working on it. The only xine implementation I found is here: http://www.jusst.de/vdpau/filedetails.php?repname=xine-vdpaupath=%2Fsrc%2Flibvdpau%2Fvdpau_h264.c It is a nice example of include all the problems of Nvidia's original implementation. I hope that is not the final version. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] ***SPAM*** Re: MPlayer VDPAU
Manfred Tremmel manf...@... writes: I've just sent ffmpeg to our PMBS, ffmpeg has dumped version to 0.5 Could you wait until it is officially released? I don't care very much, but I remember troubles with vlc, am I correct? The release should take place soon, afaict. (there are no official releases, there's no 0.5 tarball arround, but that's more release then we has since many years) in the release notes. I'll build it with vdpau support. While I fear nobody is currently using it: Please do so! Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] MPlayer VDPAU
Hi! MPlayer is planning a release atm. I wanted to explain that it is possible to build the executable with vdpau support without actually linking against a library: Only the header files (vdpau.h and vdpau_x11.h, both BSD licensed) have to be present in /usr/include/vdpau on the building environment, configure autodetects them and the executable tries to load the library dynamically when -vo vdpau is selected. Happy building, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Directory for libopenjpeg include files
Carl Eugen Hoyos ceho...@... writes: libopenjpeg-devel-1.3-0.pm.1 installs the header file into /usr/include/openjpeg, but the original Makefile installs it into /usr/include/libopenjpeg, and that is where FFmpeg's configure expects it. http://www.openjpeg.org/svn/trunk/Makefile Note that I was talking nonsense, the correct location of the header file is /usr/include/openjpeg.h Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Directory for libopenjpeg include files
Toni t...@... writes: libopenjpeg-devel-1.3-0.pm.1 installs the header file into /usr/include/openjpeg, but the original Makefile installs it into /usr/include/libopenjpeg, and that is where FFmpeg's configure expects it. http://www.openjpeg.org/svn/trunk/Makefile the package use cmake, so this Makefile is outdated. Which OS are we talking about? http://www.openjpeg.org/svn/trunk/README.linux clearly states: make install (and doesn't talk about cmake) So, Makefile is relevant for us, imo. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Directory for libopenjpeg include files
Hi! libopenjpeg-devel-1.3-0.pm.1 installs the header file into /usr/include/openjpeg, but the original Makefile installs it into /usr/include/libopenjpeg, and that is where FFmpeg's configure expects it. http://www.openjpeg.org/svn/trunk/Makefile Please fix, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Fehlermeldung bei w32codec-all-20071007-0.pm.1.i586.rpm
Manfred Tremmel manf...@... writes: PS: w32codec-all ist mit Sicherheit das unnötigste Paket, das wir bei Packman haben. Ich installiere das schon lange auf keinem Rechner mehr. Und wie siehst Du dann DVDs oder Videos (avi, mov)? Machst Du nicht? Freilich schau ich und zwar mit Kaffeine. Aber für was bräuchte ich w32codec-all? wmapro (=wmav3). wird sich aber in Kürze erledigt haben, dann könnt ihr das Paket auch ruhig löschen: Es wird dann recht schwierig sein, eine Datei zu finden, die es braucht. Ich halte für möglich, daß das recht viel Bandbreite sparen würde... Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] kaffeine 0.8.7 packman - screensaver starting during movie playback
Hi Manfred! Manfred Tremmel [EMAIL PROTECTED] writes: A 2.pm.2 Build version will be available soon. Can you test it and tell me, if it fixes the problem? Unfortunately, after installing 2.pm.2, I can confirm that while watching DVB-T with kaffeine, the screensaver still gets activated after some time. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] yasm
Hi! Newest ffmpeg needs yasm to compile all possible optimizations. Unfortunately, yasm that ships with opensuse 10.3 is too old. Could you add yasm 0.7.1 to Packman? Thank you, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] New libdirac version
Hi! A new version of libdirac was released: 0.10 Please build it, it's rather difficult to build mplayer-cvs if libdirac-devel-0.9.1 is installed. Thank you, Carl Eugen ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] Re: Packman security policy questions
Hi! Aniruddha [EMAIL PROTECTED] writes: I don't know what world you're living in but we're not paid to do this, we do it during our spare time, and it's a considerable effort and amount of time, health, and commitment going into this from every single member of the team. It's totally unrealistic and just plain impossible for us to provide SLAs, maximum response time guarantees or whatever. Get real. If you want a really secure environment (_if_ you actually need that level of paranoia), then only use the packages that come with the distribution. I fear that would not increase the security a lot. And as the Subversion team likes to put it: patches are welcome Pascal, in the world I live people don't regards questions as personal attacks. Nor do they feel the need to talk in a demeaning manner. How tempting it might be I am not going to lower myself to this level of discussion. I only read this list to see mplayer bug-reports and I don't post here often, but to make one thing very clear: Pascals answers were very polite and surprisingly patient. Tonis answer was not that patient, but be assured that on many lists, questions that are as unanswerable as yours are ignored at best. Your mail, OTOH, makes it very clear that *you* take things far too personal and you overreact. I know one or two mailing list operators that would already have banned you. To get on topic as you ask: Being a programmer, I can assure you, what you ask for can not be produced: Whoever promises you what you are asking for is simply lying (or has no clue). If, for example, any OSS project promises you maximum response time, they are cheating. (And that's not the only impossible point.) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] Re: Neuster Mplayer unter Opensuse 10.3 i586
Hi! Ina Busch [EMAIL PROTECTED] writes: der Ton bei mpeg-Videos ist praktisch nicht vorhanden bzw. ist total verzerrt. Keine Einstellung brachte Besserung, bin bald verzweifelt! Wollte hiermit diesen Fehler melden und dich um Nachbesserung bzw. Überprüfung bitten. Vollständige Ausgabe von mplayer -v filename? Beispieldatei? (Meine mpeg Dateien funktionieren mit rc2pm wunderbar.) Carl Eugen ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] Re: [PM] MPlayer 1.0rc2 (openSUSE 10.3) i586
Hi! Jörg Geßner [EMAIL PROTECTED] writes: das ging aber schnell mit dem Update! Leider kann ich immer noch keine mpg-Dateien abspielen, da der Ton nicht ab spielbar ist . Mein selbst gebackener Mplayer funktioniert einwandfrei! Wo ist der Fehler?? (Opensues 10.3/i586) Vollständige Ausgabe von mplayer -v für svn und rc2? Beispieldatei (Meine Mpgs funktionieren noch)? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] Re: MPlayer compilation
Hi! Chris Arnold [EMAIL PROTECTED] writes: OK, i got it working. I used gmplayer -vo x11 filename from the CL and this played it just like it use to. The question is, how to make it always use x11? Don't. -vo x11 is very slow. Try to find out why configure doesn't activate xv or gl (less configure.log) and install the missing libraries. Once fixed, you can add vo=xv to ~/.mplayer/config. Btw, mplayer output always tells you which vo is used. Carl Eugen PS: If you have a problem with packmans mplayer, use this mailing list; if you have a problem with mplayer svn, please use mplayer-users. ___ Packman mailing list Packman@links2linux.de http://www.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Re: xvmc with xine
Hi Manfred!
Manfred Tremmel [EMAIL PROTECTED] writes:
Am Donnerstag, 6. September 2007 19:54 schrieb Carl Eugen Hoyos:
But, unfortunately, I'm on 10.0:
Sorry, haven't seen this.
./configure --build=%{_target_platform} --prefix=%{_prefix} \
[...]
\ %if %suse_version 1020
--disable-xvmc --with-xv-path=/usr/X11R6/%{_lib} \
%endif
--with-arts \
--enable-syncfb --with-internal-vcdlibs
(from libxine1.spec)
Could you rebuild without --disable-xvmc?
No, I can't. I haven't disabled it for fun, it simply doesn't compile on
10.2 with enabled xvmc, the used xorg version is to old.
On 10.2, it is not disabled, but compiled atm.
It does compile on 10.0, where it is disabled.
Carl Eugen
___
Packman mailing list
Packman@links2linux.de
http://www.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] xvmc with xine
Hi Manfred! I compile the package against xorg's libXvMC Shouldn't it be linked against libXvMCW? If I understand it correctly, the W stands for wrapper and should allow any XvMC library (specified by /etc/X11/XvMCConfig). Or is this wrong? Carl Eugen ___ Packman mailing list Packman@links2linux.de http://www.links2linux.de/cgi-bin/mailman/listinfo/packman
