Bug#892442: mplayer: Please use 'pkg-config' to find FreeType 2
FYI: it should already be supported even by old version via --freetype-config="pkg-config freetype2". The committed fix just changes the default to exactly that. Just to clarify that you don't HAVE to update or backport the change to avoid this issue. On 18.03.2018, at 14:23, debian micove wrote: > Control: forwarded 892442 https://trac.mplayerhq.hu/ticket/2340 > > Hello: > > Thanks for the report upstream acknowledged the issue in the link above. > > Cheers, > Miguel > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On 05.09.2014, at 03:46, Reinhard Tartler wrote: > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer wrote: >>> At the end of the day, I need a source tarball that contains >>> maintained sources of a stand-alone libpostproc. I don't care too much >>> how it is created, as long as it doesn't result in code-duplication >>> with existing sources in Debian. >> >> would it work if libpostproc could be build and installed >> standalone from ffmpeg git / ffmpeg release tarballs? > > That would be exactly the code-duplication I referred to in the text > you've quoted. Combined with a release script doing rm of libav*? I think the problem is that libpostproc just isn't a viable stand-alone program, mostly due to complete lack of stand-alone testability not to mention test infrastructure. Keeping the separate git up-to-date certainly is an option but involves extra effort (though a lot less than making libpostproc testable stand-alone). I don't see a good way to split the libraries into separate repositories that does not involve either at least maintaining configure in each or seriously harming bisecting/regression testing. Release scripts that generate multiple tarballs seems more realistic than splitting the repository, in case that sounds like helpful to anyone... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#732159: Should this package be removed?
On Wed, Feb 19, 2014 at 08:24:01AM -0500, Reinhard Tartler wrote: > TBH, I'm a bit confused about your reply. I probably lost track of the point I was trying to make. I so far assumed that this issue was, bluntly put, about almost exclusively 1) MPlayer does not work against Libav But what you wrote sounded more like it's at least also 2) MPlayer has packaging issues I've mentioned this a few times over the years, I'd be interested in improving 2), and that is regardless of the status of this ticket. > On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger > wrote: > > On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote: > >> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger > >> wrote: > >> > What would constitute a constructive comment? > >> > >> Ideally "I am interested in making mplayer work against the libavcodec > >> that we have in Debian, and this is my work in progress". > > > > Well, I expect that making it build wouldn't be that hard, but it > > would be quite crippled and broken, > > and with the limited effort I > > am willing to spend on getting patches into Libav I won't be getting > > anywhere I would conclude from previous tries. > > I take this as that you (as upstream) do not want mplayer to be > compiled against libav. No it means "I feel unable to maintain support for that". And that is the same situation as right after the fork, nobody has stepped up since then to take on this task. (Yes, I am well aware that the mailing list climate was not helpful in attracting someone to do it, and I am sorry for that). > Besides, has development and support for mencoder been revived, or do > its developers still consider mencoder deprecated and/or obsolete? It's still on basic life support. So I don't think it should be considered a major concern. Still, ffmpeg/avconv in some cases still can't 100% replace it, especially if it's not the very latest of those, so I am of course still interested in not letting any users hang if there was some magic easy way to achieve it. > >> It was my sincere hope that this would be a sufficient incentive and > >> motivation to work on keeping mplayer/mencoder in debian. > >> Unfortunately, it seems I was wrong. > > > > Well, it was motivation to suggest several ways to get FFmpeg into > > Debian, since that is kind of the most realistic way to solve it, > > also since otherwise it won't be the version of MPlayer that > > is tested upstream. > > However so far this seems to be considered completely out of the > > question. > > Sorry, but taking mplayer as political argument to make pressure on > the FFmpeg vs. Libav conflict is not going to help anyone. Please have > this discussion elsewhere, e.g. in #729203. This was not mean political, this is about "solving" my point 1) above. If we agree that we see no way to solve/avoid that I think there is no point in dragging this out any further. > >> Personal remark here: mplayer was always problematic in Debian. Up to > >> today, it is not possible to even compile mplayer without removing its > >> internal copy of ffmpeg. > > > > Yes, no, maybe. I just looked into it. You have to provide matching > > copies of libavformat/internal.h (can be eliminated reasonably well if > > it's a concern) and libavutil/x86/asm.h (only issue here is that I don't > > like duplicating it). > > Nothing else is required. > > I missed that, did that change recently? I don't think so. I think it must have been like this at least a year, but no promises. I do not know if Debian might have used options like --enable-zr (that is the part that now no longer compiles), that one had hooks deep into FFmpeg, but I think it lost what little relevance it had years ago. > > I haven't tested the last release, and I don't know if only > > requiring these two headers I mentioned is good enough, > > but I would say it doesn't require an internal copy anymore. > > Well, if it was really only two (internal!) headers that it takes, why > doesn't mplayer embed them just like mplayer2 and mpv, and just ditch > the svn:external equivalent for git mechanism? This needs to be > disabled when packaging it for use with a system-provided libavcodec > anyways. If I make a copy of them I become responsible to maintain/update them. Which I'd only want to do if it's really the best solution to a significant problem. Plus, creating a ffmpeg/ directory automatically disables the automated FFmpeg download, so solving the one also fixes the other for you. > Nevertheless, if what you say is true, then current mp
Bug#732159: Should this package be removed?
On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote: > On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger > wrote: > > What would constitute a constructive comment? > > Ideally "I am interested in making mplayer work against the libavcodec > that we have in Debian, and this is my work in progress". Well, I expect that making it build wouldn't be that hard, but it would be quite crippled and broken, and with the limited effort I am willing to spend on getting patches into Libav I won't be getting anywhere I would conclude from previous tries. > > mplayer2 is unmaintained and as far as I can tell mpv has completely > > different command-line syntax at the least (though I am not well > > informed about either). > > It was my sincere hope that this would be a sufficient incentive and > motivation to work on keeping mplayer/mencoder in debian. > Unfortunately, it seems I was wrong. Well, it was motivation to suggest several ways to get FFmpeg into Debian, since that is kind of the most realistic way to solve it, also since otherwise it won't be the version of MPlayer that is tested upstream. However so far this seems to be considered completely out of the question. Which for me kind of leaves the question if the best MPlayer we can offer under these circumstances is worth it. > > Libav compatibility is not intentionally broken upstream, but it > > is not tested in any systematic way either (possibly not at all). > > This is not the primary concern or reason in the context of whether or > not to remove mplayer/mencoder from Debian. The reason is that there > is nobody who is interested enough to work on making it suitable in > Debian. Otherwise we wouldn't have to remove the package from > Debian/testing (jessie). This sounds to me like you see a difference between "Libav compatibility" and "suitable in Debian"? I'd be interested in that. > Personal remark here: mplayer was always problematic in Debian. Up to > today, it is not possible to even compile mplayer without removing its > internal copy of ffmpeg. Yes, no, maybe. I just looked into it. You have to provide matching copies of libavformat/internal.h (can be eliminated reasonably well if it's a concern) and libavutil/x86/asm.h (only issue here is that I don't like duplicating it). Nothing else is required. > This was only acceptable because I made sure > that its internal copy is only used at build-time, allowing mplayer to > access internal functionality that is not part of the public API. As far as I can tell none of that internal API usage remains, unless you enable certain special features like those old JPEG decoder cards (that actually don't compile anymore even against internal FFmpeg). > This > makes maintaining mplayer in Debian much more challenging, and > basically means that mplayer and libav always need to be updated in > lockstep. This has not been the case for some time. Well, at least not due to internal API usage. I believe there are a few "accessor" functions that MPlayer does not use when it should, but that's kind of a bug. > It is true that for quite some time I used my mplayer svn > commit privileges to make it possible to use libav instead of ffmpeg > as internal copy. I stopped doing this work, mainly because I felt > that these kind of work is not welcome inside mplayer. Well, "welcome" it is maybe from everyone's standpoint, but even some of the developers who welcome it least have added ifdefs to avoid breaking it even further. > Actually, I would be very interested in that, but not before > there was some mplayer release that stopped requiring an internal copy > of libav* I haven't tested the last release, and I don't know if only requiring these two headers I mentioned is good enough, but I would say it doesn't require an internal copy anymore. I even fixed configure so that if you have only those two files in ffmpeg/... it will default to compiling against a system FFmpeg. Making a new release is something that would be good to do anyway. _However_ none of this fixes the FFmpeg vs. Libav issues... > > Now, deb-multimedia.org provides it anyway so it won't leave people > > completely stranded, but I wonder if maybe there was a way to > > somehow point people there when they try something like > > "apt-get install mencoder"? > > I disagree that deb-multimedia.org is actually helping here. I would > rather recommend people that want to use mencoder on Debian to just > follow upstream's recommendation: compile it yourself, and statically > link against its internal copy of libavcodec. This is kind of messy on non-developer machines where it involves installing compilers an lots of -dev pack
Bug#732159: Should this package be removed?
On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote: > On Sun, Feb 16, 2014 at 11:21 AM, Moritz Mühlenhoff wrote: > > On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote: > >> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff > >> wrote: > >> > Package: mplayer > >> > Severity: serious > >> > > >> > Should this package be removed? If so, please reassign to ftp.debian.org > >> > > >> > - Last upload nearly two years ago > >> > - FTBFS for a long time > >> > - Incompatible with current libav > >> > - Alternatives exist (mplayer2, mpv) > >> > >> I tend to agree, however please keep in mind that this also removes > >> mencoder, for which no drop-in alternatives exist atm: Currently, two > >> packages depend on mencoder, toonloop and photofilmstrip: > > > > Shall we go ahead with the removal now? > > > > toonloop has been removed from testing half a year ago and the last > > maintainer upload was two years ago and photofilmstrip is already > > removed from jessie since half a year. popcon is marginal for both. > > > > We can ask FTP masters to remove mplayer forcefully despite the > > remaining reverse deps. > > In lack of any *constructive* comments about this, I would say yes, > let's remove them. What would constitute a constructive comment? mplayer2 is unmaintained and as far as I can tell mpv has completely different command-line syntax at the least (though I am not well informed about either). Libav compatibility is not intentionally broken upstream, but it is not tested in any systematic way either (possibly not at all). Though I agree that there is little point in keeping the outdated rc4 version. But one more point: I am not sure all programs using mencoder will have it as a dependency correctly. For example flvtool (exists only in stable though it seems) should be using mencoder for some tasks but does not list it as a dependency. Now, deb-multimedia.org provides it anyway so it won't leave people completely stranded, but I wonder if maybe there was a way to somehow point people there when they try something like "apt-get install mencoder"? I can see why you might have some concerns with that, but it would seem like a kind of user-friendly solution to me that doesn't require much effort from anyone... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#732159: Should this package be removed?
On 14.12.2013, at 23:53, John Paul Adrian Glaubitz wrote: > On 12/14/2013 11:07 PM, Reinhard Tartler wrote: >> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff wrote: >>> Package: mplayer >>> Severity: serious >>> >>> Should this package be removed? If so, please reassign to ftp.debian.org >>> >>> - Last upload nearly two years ago >>> - FTBFS for a long time >>> - Incompatible with current libav >>> - Alternatives exist (mplayer2, mpv) > > Well, to be honest, I think the problem is actually libav, not mplayer. > Most users prefer the original ffmpeg over libav from my own experience. > > And there are new upstream releases of mplayer which are actually more > frequent and active than mplayer2: > > - mplayer: current stable release 1.1.1, released May 6th, 2013 > - mplayer2: current stable release 2.0, released: March 24th, 2011 > > Even the latest git commit for mplayer2 is older than the current > stable release of mplayer. The latter seems much more active to me. > > So, what I'd rather like to see is that we get a proper ffmpeg > back in Debian again which would also allow to update mplayer > to the current upstream version. There is even an RFP for > that [1]. But I guess this is not going to happen. > > I'm still a bit sad that the split among the ffmpeg people > happened. > > Adrian > >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 I thought someone was working on it already, but I am happy to help out both with getting a parallel install of FFmpeg working (via a rpath hack for example, supported in FFmpeg configure but probably needs fixes to MPlayer's configure to work) and to a limited degree also making MPlayer work with Libav. However the latter would need a proper maintainer, and Libav misses quite a few features MPlayer needs, so it would be problematic and the result questionable IMHO. I am assuming nobody in Debian wants to compile MPlayer statically/against an "internal" copy of FFmpeg. Reimar ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#703646: mplayer: crashes when play mpg file from http
On 21 Mar 2013, at 21:41, "Alexander V. Kudrevatykh" wrote: > В Чт., 21/03/2013 в 21:04 +0100, Reimar Döffinger пишет: >> >> On 21 Mar 2013, at 20:46, "Alexander V. Kudrevatykh" >> wrote: >> >>> Package: mplayer >>> Version: 2:1.0~rc4.dfsg1+svn34540-1+b2 >>> Severity: normal >>> >>> When I trying to play mpg files from http (static file from lighttpd or from >>> upnp server) mplayer crashed. >>> Files were encoded with avconv and avplay successfully decodes such files. >>> Same file played from nfs/local file without crash. >>> Attached output of gdb. If you need file example I can provide it (or you >>> can >>> download file on url from gdb output). >> >> The gdb backtrace looks like you are using -lavdopts fast, is that the case? >> That option is expected to possibly crash with buggy/invalid files (and I >> think the current MPlayer documentation says so). > > Yes. It's really used, But if file buggy, why it isn't crashed when > playing from local file, not from http? Possible things I can think of: 1) Bug in MPlayer's http implementation corrupts data 2) Playing via http results in using a different demuxer 3) Bug in http server 4) Random changes in memory layout might result in just decode errors instead of crashes. > Without -lavdopts fast crash missing, thanks. Do you get decode errors? If so, do you also get them when playing the file locally? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#703646: mplayer: crashes when play mpg file from http
On 21 Mar 2013, at 20:46, "Alexander V. Kudrevatykh" wrote: > Package: mplayer > Version: 2:1.0~rc4.dfsg1+svn34540-1+b2 > Severity: normal > > When I trying to play mpg files from http (static file from lighttpd or from > upnp server) mplayer crashed. > Files were encoded with avconv and avplay successfully decodes such files. > Same file played from nfs/local file without crash. > Attached output of gdb. If you need file example I can provide it (or you can > download file on url from gdb output). The gdb backtrace looks like you are using -lavdopts fast, is that the case? That option is expected to possibly crash with buggy/invalid files (and I think the current MPlayer documentation says so). ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#702290: libmp3lame0: libmp3lame.so.0 exports too many symbols (e.g. "getbits")
Package: libmp3lame0 Version: 3.99.5+repack1-3 Severity: normal Tags: upstream patch Dear Maintainer, libmp3lame.so.0 currently exports lots of internal symbols. In particular the getbits symbol causes real-world issues due to symbol clashes, see e.g. http://users.softlab.ntua.gr/~ttsiod/mp3pro.html To reproduce run: nm -D /usr/lib/x86_64-linux-gnu/libmp3lame.so.0.0.0 | grep getbits Returns: 0003d030 T getbits 0003d0a0 T getbits_fast Expected: should not print anything, getbits is a too common name to export safely. mp3lame actually includes a .sym for use with libtool, but for some reason does not use it (probably because it does not actually work as-is). I sent a patch upstream, but I am unsure there is much activity, plus you might be in a better position to test if any applications rely on these internal symbols. Upstream bug report including (IMHO very simple) patch: https://sourceforge.net/tracker/?func=detail&aid=3606697&group_id=290&atid=300290 -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (700, 'unstable'), (600, 'experimental'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmp3lame0 depends on: ii libc6 2.17-0experimental2 ii multiarch-support 2.17-0experimental2 libmp3lame0 recommends no packages. libmp3lame0 suggests no packages. -- no debconf information Index: include/libmp3lame.sym === RCS file: /cvsroot/lame/lame/include/libmp3lame.sym,v retrieving revision 1.1 diff -u -r1.1 libmp3lame.sym --- include/libmp3lame.sym 14 Mar 2010 17:23:35 - 1.1 +++ include/libmp3lame.sym 4 Mar 2013 19:45:25 - @@ -1,232 +1,177 @@ lame_init - +lame_init_old lame_set_num_samples lame_get_num_samples - lame_set_in_samplerate lame_get_in_samplerate - lame_set_num_channels lame_get_num_channels - lame_set_scale lame_get_scale - lame_set_scale_left lame_get_scale_left - lame_set_scale_right lame_get_scale_right - lame_set_out_samplerate lame_get_out_samplerate - lame_set_analysis lame_get_analysis - lame_set_bWriteVbrTag lame_get_bWriteVbrTag - lame_set_decode_only lame_get_decode_only - +lame_set_ogg +lame_get_ogg lame_set_quality lame_get_quality - lame_set_mode lame_get_mode - +lame_set_mode_automs +lame_get_mode_automs lame_set_force_ms lame_get_force_ms - lame_set_free_format lame_get_free_format - - lame_set_findReplayGain lame_get_findReplayGain - lame_set_decode_on_the_fly lame_get_decode_on_the_fly - +lame_set_ReplayGain_input +lame_get_ReplayGain_input +lame_set_ReplayGain_decode +lame_get_ReplayGain_decode +lame_set_findPeakSample +lame_get_findPeakSample lame_set_nogap_total lame_get_nogap_total - lame_set_nogap_currentindex lame_get_nogap_currentindex - - lame_set_errorf lame_set_debugf lame_set_msgf - lame_set_brate lame_get_brate - lame_set_compression_ratio lame_get_compression_ratio - lame_set_preset - lame_set_asm_optimizations - - lame_set_copyright lame_get_copyright - lame_set_original lame_get_original - lame_set_error_protection lame_get_error_protection - lame_set_padding_type lame_get_padding_type - lame_set_extension lame_get_extension - lame_set_strict_ISO lame_get_strict_ISO - lame_set_disable_reservoir lame_get_disable_reservoir - lame_set_quant_comp lame_get_quant_comp lame_set_quant_comp_short lame_get_quant_comp_short - lame_set_experimentalX lame_get_experimentalX - lame_set_experimentalY lame_get_experimentalY - lame_set_experimentalZ lame_get_experimentalZ - lame_set_exp_nspsytune lame_get_exp_nspsytune - lame_set_msfix lame_get_msfix - lame_set_VBR lame_get_VBR - lame_set_VBR_q lame_get_VBR_q - +lame_set_VBR_quality +lame_get_VBR_quality lame_set_VBR_mean_bitrate_kbps lame_get_VBR_mean_bitrate_kbps - lame_set_VBR_min_bitrate_kbps lame_get_VBR_min_bitrate_kbps - lame_set_VBR_max_bitrate_kbps lame_get_VBR_max_bitrate_kbps - lame_set_VBR_hard_min lame_get_VBR_hard_min - lame_set_preset_expopts - lame_set_lowpassfreq lame_get_lowpassfreq - lame_set_lowpasswidth lame_get_lowpasswidth - lame_set_highpassfreq lame_get_highpassfreq - lame_set_highpasswidth lame_get_highpasswidth - lame_set_ATHonly lame_get_ATHonly - lame_set_ATHshort lame_get_ATHshort - lame_set_noATH lame_get_noATH - lame_set_ATHtype lame_get_ATHtype - lame_set_ATHlower lame_get_ATHlower - lame_set_athaa_type lame_get_athaa_type - lame_set_athaa_loudapprox lame_get_athaa_loudapprox - lame_set_athaa_sensitivity lame_get_athaa_sensitivity - lame_set_cwlimit lame_get_cwlimit - +lame_set_allow_diff_short +lame_get_allow_diff_short lame_set_useTemporal lame_get_useTemporal - lame_set_interChRatio lame_get_interChRatio - lame_set_no_short_blocks lame_
Bug#699648: ffmpeg: Please rebuild against correct libavcodec version
On 4 Feb 2013, at 14:45, Fabian Greffrath wrote: > Am 03.02.2013 16:49, schrieb Reimar Döffinger: >> In the linked ffplay report it was compiled against a newer version >> than the one it is run against though. There is no promise that >> will work. > > I don't think we are going to rebuild mplayer each time we update libav's > minor SONAME in Debian. This would nullify the advantage of shared libraries. That _should_ be ok, and MPlayer should ideally print this only as debug info in that case. I misread the report, the reported case should work fine. The case that is not ok is compiling MPlayer against a later version and then downgrade to a libav* version with a lower minor SONAME. Note that it does not nullify the main reason for dynamic linking either way: security updates. Those are (usually) easy to 100% verify that they do not break ABI and then you can just ignore those messages (if you even change the SONAME for these, if not there is no issue at all). We can also discuss other options, but the information that MPlayer is running against a different version than it was compiled against is useful IMHO, so I'm not in favour of removing this info completely. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#699648: ffmpeg: Please rebuild against correct libavcodec version
Fabian Greffrath wrote: >Am 03.02.2013 15:46, schrieb Reinhard Tartler: >> What exact version of mplayer do you use, and what is the exact >output? >> The bug is currently marked as affecting a version that does not >exist. > >And even if... > >I fail to see how this is a bug at all. The library ABI is stable as >long as the major SONAME is identical - which it is in this case. Who >cares if the minor SONAME is different at runtime from the one at >buildtime. We are not supposed to rebuild every application whenever >minor SONAME is bumped or are we? Why does mplayer even complain about >that? Very simple: sometimes the ABI is still broken unintentionally, sometimes the ABI is "made" compatible by declaring things as not part of the ABI (decoder names as a real example from the past), thus it is entirely reasonable to print this information and require bugs to be tested with matching versions. In addition FFmpeg only promises ABI _backwards_ compatibility. In the linked ffplay report it was compiled against a newer version than the one it is run against though. There is no promise that will work. Reimar ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#686570: mplayer doesn't play REALAUDIO format file
On Fri, Sep 21, 2012 at 03:16:51PM +0200, Fabian Greffrath wrote: > Am 03.09.2012 20:06, schrieb Reimar Döffinger: > >This information is incorrect. FFmpeg has a decoder for sipr and it > >works fine for the file. > >In fact, MPlayer compiled from latest SVN will play it (64 bit build, > >so no binary codecs involved). > >Libav which is used in Debian misses the equivalent to FFmpeg > >commit 1d0d63052b82c76e10c45cd38cdd27677de72e81 and thus MPlayer > >using it cannot play it and it potentially will have issues playing SIPR > >in other cases. > > Is this commit to libav all that is needed to play back this type of > files in mplayer? I believe so, but I won't make any promises. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#687594: Please document how to turn off a filter enabled in ~/.mplayer/config
On Thu, Sep 13, 2012 at 07:26:05PM -0700, Josh Triplett wrote: > At the moment, I have to do so by editing ~/.mplayer/config, removing > af=scaletempo, re-running mplayer, and seeking to that point. I haven't > found any way to disable a filter either from the command line or from > the UI. Ideally, I'd love to have a "disable filters" key; Bind a key to "af_clr" (see DOCS/tech/slave.txt - in MPlayer SVN, it seems Debian doesn't install that, it might be worth including it even though it is mostly targeted at frontend developers). > in the > absence of that, I'd love to have a command-line option to disable an > audio or video filter, so that I can override the config file rather > than editing it. -af-clr, and that one is documented in the MPlayer man-page, right at the start of the "AUDIO FILTERS" section. Disclaimer: I did not test that they actually work, but if not that should be a bug. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#686570: mplayer doesn't play REALAUDIO format file
On Mon, Sep 03, 2012 at 02:28:51PM +0200, Klaumi Klingsporn wrote: > Am / On Mon, 03 Sep 2012 19:43:39 +0800 > schrieb / wrote XIANGYU LIU : > > > ERROR: Could not open required DirectShow codec sipr3260.dll. > > To play this file your need proprietary sipr3260.dll which is -because > of legal reasons- not in Debian and only provided outside of Debian in > die w32codecs-Package, This information is incorrect. FFmpeg has a decoder for sipr and it works fine for the file. In fact, MPlayer compiled from latest SVN will play it (64 bit build, so no binary codecs involved). Libav which is used in Debian misses the equivalent to FFmpeg commit 1d0d63052b82c76e10c45cd38cdd27677de72e81 and thus MPlayer using it cannot play it and it potentially will have issues playing SIPR in other cases. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#683907: mencoder: Crashes with seg fault even after getting rid of dmo libraries
On Mon, Aug 06, 2012 at 02:21:41PM +0100, Grześ Andruszkiewicz wrote: > Sorry for the private email. > > As suggested, I downloaded this clip: > http://mirrorblender.top-ix.org/peach/bigbuckbunny_movies/big_buck_bunny_480p_stereo.avi > > and I get the same error with this file (as downloaded), which > suggests something is wrong with my configuration? Is there a way to > see which libraries are loaded, etc. to nail down this issue? > > ga@grzes:~/Spam/video$ mencoder big_buck_bunny_480p_stereo.avi -o > a.mpg -vf crop=346:240:2:24 -oac copy -ovc x264 -x264encopts > bitrate=3000 pass=1 nr=2000 Thank you for the instructions. I believe this to be fixed now in upstream MPlayer SVN r35061. As a workaround I believe -noslices should work. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#680595: mplayer: New upstream version 1.1
On 7 Jul 2012, at 11:52, Reinhard Tartler wrote: > tags 680595 help > stop > > On Sat, Jul 7, 2012 at 8:17 AM, Andreas Metzler > wrote: >> Package: mplayer >> Version: 2:1.0~rc4.dfsg1+svn34540-1+b2 >> Severity: wishlist >> >> 2012-06-10, Sunday :: MPlayer 1.1 released >> >> http://lists.mplayerhq.hu/pipermail/mplayer-announce/2012-June/69.html > > Note, this version of mplayer will probably require some non-trivial > work to make it compile against Debian's system libavcodec and > friends, as for this release upstream has focused on FFmpeg and did > not consider compilation against Libav. I didn't test it, but I am only aware of some features not working or not working well against Libav since they are not implemented there. I really don't think there should be any major compilation issues, and if someone reports any of the potential minor onea I can even have a look at fixing them myself. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#672706: Bug#672947: fcmatch.c:548: IA__FcFontMatch: Assertion `result != ((void *)0)' failed.
On Wed, May 16, 2012 at 09:04:26PM +0200, Reinhard Tartler wrote: > On Wed, May 16, 2012 at 1:07 PM, Fabian Greffrath > wrote: > > Am Montag, den 14.05.2012, 23:23 +0200 schrieb Alex Wilk: > >> mplayer: fcmatch.c:548: IA__FcFontMatch: Assertion `result != ((void *)0)' > >> failed. > > > > In line 1163 in file sub/font_load_ft.c of the mplayer2 source code the > > following code is called: > > > > Â Â Â Â fc_pattern = FcFontMatch(0, fc_pattern, 0); > > > > The third argument passed to FcFontMatch() is the *result pointer, which > > is 0 in this case. Newer versions of fontconfig seem to include an > > assertion that this may never be 0, so it fails. Simply passing > > "&result" instead of 0 (as in line 1153) should solve the problem here. > > > > I think the same applies to #672706 reported against mplayer. > > Excellent catch. For the reference, the code in question can be > inspected in the upstream gitweb here: > http://cgit.freedesktop.org/fontconfig/tree/src/fcmatch.c?id=2.9.0#n548 Actually the first FcFontMatch in that function is already fixed, it seems the second one was missed. I fixed it now too in MPlayer SVN (r34910), plus I added an initialization of the result variable (r34911) since FcFontMatch still seems to only set it on error which might result in very strange behaviour if the code ever is changed to use it. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#672706: Bug#672947: fcmatch.c:548: IA__FcFontMatch: Assertion `result != ((void *)0)' failed.
On Wed, May 16, 2012 at 01:07:11PM +0200, Fabian Greffrath wrote: > Am Montag, den 14.05.2012, 23:23 +0200 schrieb Alex Wilk: > > mplayer: fcmatch.c:548: IA__FcFontMatch: Assertion `result != ((void *)0)' > > failed. > > In line 1163 in file sub/font_load_ft.c of the mplayer2 source code the > following code is called: > > fc_pattern = FcFontMatch(0, fc_pattern, 0); > > The third argument passed to FcFontMatch() is the *result pointer, which > is 0 in this case. Newer versions of fontconfig seem to include an > assertion that this may never be 0, so it fails. Really funny of them to add an assertion for an argument they don't even have any documentation on. At least nothing that I could find describes what the meaning of it is, nor whether NULL is supposed to be valid or not... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#668543: mplayer: ogv video freezes with DRI failure
On Thu, Apr 12, 2012 at 06:25:10PM +0200, Adrian Knoth wrote: > mplayer fails to play an OGV conference livestream. I've dumped a few > seconds to > >http://adi.loris.tv/broken.ogv Either broken file or FFmpeg demuxer issue (e.g. ffmpeg fails to convert the file to AVI, see https://ffmpeg.org/trac/ffmpeg/ticket/1213). Nevertheless, workaround applied in upstream SVN r34857. -nocorrect-pts should allow you to play the fail even with your version. (for dumped files, you can also just seek "over" the problematic spot). ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#637611: mplayer: redirected stdin from /dev/null causes 100% busy loop
Old issue and not that much new to add, but still... On Sat, Aug 13, 2011 at 08:50:11PM +1000, Tim Connors wrote: > On Sat, 13 Aug 2011, Reimar Döffinger wrote: > > Behaviour is to make keyboard control of MPlayer more reliable mostly I > > expect. > > I think the MPlayer documentation says you must use -noconsolecontrols > > when using MPlayer without a terminal (in particular from cron jobs). > > The description in the manpage doens't cover this case (stdin being > /dev/null rather than a command file or the file being played). > > And it makes matters worse. CPU usage is still 100%, but I can't see why. > strace -f doesn't show it busy looping on file descriptor 0 - it's just > reading the input file and sending stuff to X11. Using latest SVN MPlayer: mplayer http://80.237.155.73:80 -dumpaudio -noconsolecontrols results in low CPU usage. As does mplayer http://80.237.155.73:80 -dumpaudio -nocache (giving specific examples, because the issue will _not_ be reproducible at all when dumping from a source that can be read faster than MPlayer can dump - which is why I never saw the issue when trying with a local file). > (yes, this is a candidate for the 'useless use of cat' awards, but > removing the cat doesn't let mplayer start, presumably because mplayer is > trying to read its first keyboard command, but does it using a blocking > read. No idea why it woks with the cat process attached! Figure that > out: > mplayer $args -dumpaudio -dumpfile < > /tmp/devblocker This is not MPlayer's fault, if you run this and look at the running processes you will see it hangs in the shell, before MPlayer is even started. No I have no idea why the shell (bash in my case) does that. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#655192: mplayer: Please build depend on rtmpdump
On Mon, Jan 09, 2012 at 07:32:37AM +0100, Reinhard Tartler wrote: > Package: mplayer > > From the buildlog: > > > Checking for RTMPDump Streaming Media library ... no > > I guess we just need to add a build dependency. MPlayer does not use it directly, and I think you use external FFmpeg. In that case you only need to make sure libavformat links against rtmpdump. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#653887: libavformat53 breaks mplayer
On 1 Jan 2012, at 15:26, Reinhard Tartler wrote: > On So, Jan 01, 2012 at 15:08:03 (CET), Julien Cristau wrote: > >> On Sun, Jan 1, 2012 at 08:25:00 +0100, Reinhard Tartler wrote: >> >>> I really think this is a bug in mplayer. ff_codec_wav_tags is and always >>> was an internal symbol, that is no longer exported since this commit: >>> >>> http://git.libav.org/?p=libav.git;a=commitdiff;h=8d74bf17c6d6280195854f4dadb19ef37d054566 >>> >>> This issue a long-standing wart in mplayer that should really be fixed >>> there. >>> >> Honestly, this is kind of a broken position IMO. The moment one of your >> reverse deps uses a symbol, it stops being internal, whatever your >> intentions were. > > Well, if you can show me that a number of other packages use > ff_codec_wav_tags, I agree to patch the symbol versioning script to make > it visible again. But TBH, I'd be surprised if you would find a single > other package. Please note that this is fixed since several months (actually I think since very shortly after this became an issue) in MPlayer svn. So you could update, backport the patch (well, unfortunately several since the first few tries were broken) or make the versioning script change as a temporary workaround you would _not_ have to carry around forever. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#650339: MPlayer version is outdated
On Tue, Dec 13, 2011 at 09:55:26AM +0100, Reinhard Tartler wrote: > retitle 650339 Please update to new upstream version later than svn r33824 > thanks > > On Di, Nov 29, 2011 at 00:59:20 (CET), jida...@jidanni.org wrote: > > > http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2019 says > > says "Anyway your MPlayer version is outdated and the issue is almost > > certainly fixed > > since r33824." > > So if a new version were to appear on Debian I could conveniently test > > it. > > Upstream mplayer will (most probably) not compile against Debian's > system libav version because it's too old. I do intend to upload a new > snapshot to experimental when I find the time to release it properly, > but even with this new version, mplayer needs some patches. Note that I mentioned the revision explicitly because backporting the patch should be trivial if you want. Compiling against mp3lib and making it the default would work, too. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#649153: Please provide a 'nogui' package
On Fri, Nov 18, 2011 at 03:45:02PM +0100, Reinhard Tartler wrote: > On Fr, Nov 18, 2011 at 11:13:16 (CET), Daniel Baumann wrote: > > > Package: mplayer > > Severity: wishlist > > > > Hi, > > > > it would be nice if you could split the mplayer package and provide a > > mplayer-nogui (or whatever name you find suitable) that provides an > > mplayer not linked against the whole xorg related stack (similar what > > marillat did). > > > > having a 'nogui' package is very usefull on server where we e.g. use > > mplayer in the backend to create preview thumbnails of videos that users > > uploaded, and obviously do not want to pull in the whole of x libraries. > > The "nogui" variant of mplayer is called 'mplayer' in Debian. The > gmplayer frontend used to be packaged as 'mplayer-gui'. I had to disable > it because it failed to build against the system libswscale.so in the > past. > > The X11 dependencies that you see are because of video output (vo) > modules that use X11 libraries, such as xv, opengl, x11, etc. > > I fear there is little that can be done about this. And even the > marillat mplayer-nogui package contains a lot of X11 related > dependencies: I think there are -nox package variants for some, the same _could_ be done for MPlayer (configure --disable-x11 I hope would work, though it might still pull it in indirectly e.g. via SDL and OpenGL-via-SDL so it might be some effort). Whether it's a good idea, particularly since I am afraid that setup is probably not tested all as much I'll leave to you... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#637611: mplayer: redirected stdin from /dev/null causes 100% busy loop
On Sat, Aug 13, 2011 at 12:50:19PM +1000, Tim Connors wrote:
> It seems that relatively recently there has been a regression where
> the keyboard reading from /dev/stdin doesn't do appropriate error
> checking. If /dev/stdin is redirected from /dev/null (eg, when
> mplayer is run from a cronjob), strace shows:
>
> select(1, [0], NULL, NULL, {0, 1}) = 1 (in [0], left {0, 9997})
> read(0, "", 256)= 0
> select(1, [0], NULL, NULL, {0, 1}) = 1 (in [0], left {0, 9997})
> read(0, "", 256)= 0
> select(1, [0], NULL, NULL, {0, 1}) = 1 (in [0], left {0, 9997})
> read(0, "", 256)= 0
> select(1, [0], NULL, NULL, {0, 1}) = 1 (in [0], left {0, 9996})
> read(0, "", 256)= 0
>
> The parent process is stuck read()ing with a return code that should
> imply EOF. mplayer appears not to check for EOF, so just reads again
> immediately. Fortunately, the worker process is still doing its job,
> but my poor dualcore CPU in my laptop is getting a bit warm.
>
> (If I simply redirect /dev/stdin to a named pipe with no writer
> connected to it, then mplayer doesn't even start up because it's
> blocking on read. So that's not a suitable workaround)
Behaviour is to make keyboard control of MPlayer more reliable mostly I
expect.
I think the MPlayer documentation says you must use -noconsolecontrols
when using MPlayer without a terminal (in particular from cron jobs).
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#637429: mplayer: corrupted top lines of DebConf11 OGV videos
On Thu, Aug 11, 2011 at 12:46:14PM +0200, Jakub Wilk wrote: > mplayer displays top lines of DebConf11 OGV videos[0] incorrectly. I > believe that this is a problem with the player, not with the files, > because mplayer in squeeze show them correctly. See the attached > frame dumps. > > [0] ftp://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/high/ If I remember correctly this is an issue with the FFmpeg decoder (probably one of the many slice-rendering issues, in which case -noslices helps). Using -vc theora to force the libtheora decoder should help as well (can be used in config file: "vc=theora,"). Both the latest SVN and the debian-multimedia versions seem unaffected, too, so the issue has most likely been fixed upstream. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629158: mplayer: cdda playback pauses every 15 seconds due to buffering
On Sat, Jun 04, 2011 at 11:43:56AM +0800, Michael Deegan wrote: > Playback of CDs is currently unusable as mplayer reads 15 seconds of audio > at a time, which seems to be long enough for the disk to spin down by the > time it wants to read the next chunk. This results in a 5 second pause > every 15 seconds during playback. Your analysis is incomplete, MPlayer does request chunks of about 176 kB about once per second. But then libcdparanoia comes with its absolutely stupid caching strategy and ends up grouping it into huge bunches of requests once every 15 seconds. Not sure which to recommend, but possible solutions are: 1) linking against libcdio which does not have the issue 2) fixing libcdparanoia to be behave better 3) using a large -cache to compensate for it 4) limit libcdparanoia's caching so it can't break things quite as badly I think I'd recommend you to go with 3) as a workaround and Debian to go with 1) (just using --disable-cdparanoia should pick up libcdio if libcdio-paranoia-dev is installed) and I've implemented 4) in MPlayer SVN (r33557, only tested against my CD drive, might not work as well with others). Disadvantage with 4) is that it probably decreases ripping performance, but I don't think many use MPlayer for that. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#604976: mplayer: signal 11 in module: decode_audio when changing speed and using -af hrtf
On Thu, Nov 25, 2010 at 10:55:55PM +0100, Thomas Arendsen Hein wrote: > When playing a DVD or any other file with 5.1 channel 48000 Hz audio using the > hrtf audio filter and either using -speed to change the playback speed or > using [ or ] keys to change it during play, mplayer crashes. Should be fixed by upstream SVN r32648. However note that 1) audio will still stop playing 2) it is just a NULL dereference So it is probably of little if any relevance really. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#602689: mplayer always crash with or without file to play ($1) = lzo1x_decode
On Sun, Nov 07, 2010 at 09:58:19AM +0100, gbulot wrote: > Package: mplayer > Version: 1.0~rc2-17+lenny3.2 > Severity: normal > > mplayer: symbol lookup error: /usr/lib/i686/cmov/libavcodec.so.51: undefined > symbol: lzo1x_decode Ancient MPlayer version with much more recent FFmpeg. That won't work together. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#601252: mplayer: video distortion with fftheora decoder
On Sun, Oct 24, 2010 at 01:29:08PM -0400, Nathan A. Stine wrote: > On Sun, 2010-10-24 at 19:12 +0200, Reimar Döffinger wrote: > > On Sun, Oct 24, 2010 at 12:55:39PM -0400, Nathan A. Stine wrote: > > > Package: mplayer > > > Version: 2:1.0~rc4~try1.dsfg1-1 > > > Severity: normal > > > > > > When watching a theora-encoded file and using fftheora to decode, mplayer > > > seems > > > to introduce some distortion at the top of the video file. This problem > > > does > > > not exist with the 3rd-party "standard" theora decoder. I checked the > > > file in > > > ffplay and did not find the same distortion, so I believe this is an > > > mplayer > > > bug. > > > > > > The file in question is here: > > > > > > http://ia331209.us.archive.org/0/items/Patent_Absurdity/Patent_Absurdity_HD_3540kbit.ogv > > > > > > A screenshot is attached to show the distortion. The video is encoded at > > > an > > > interesting resolution: 1280x1088, which may contribute to the problem. > > > > > > One or more of these FFmpeg revisions have not been backported to 0.6 I > > guess: > > r23537, (r25050 not directly related), r25051, r25052, r25073 > > If this was an FFmpeg problem, ffplay should give the same distortion as > mplayer, right? I was under the impression that if I can reproduce a > bug in mplayer and ffplay, I should submit it as an FFmpeg bug rather > than mplayer. Is this not the case? You did nothing "wrong" in reporting this as an MPlayer bug, however FFmpeg/ffplay does not use the slice rendering API (except possibly if you use the right libavfilter filters) so bugs that are exclusive to that will not be reproducible with ffplay even if (like in this case) it actually is an FFmpeg bug. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#601252: mplayer: video distortion with fftheora decoder
On Sun, Oct 24, 2010 at 12:55:39PM -0400, Nathan A. Stine wrote: > Package: mplayer > Version: 2:1.0~rc4~try1.dsfg1-1 > Severity: normal > > When watching a theora-encoded file and using fftheora to decode, mplayer > seems > to introduce some distortion at the top of the video file. This problem does > not exist with the 3rd-party "standard" theora decoder. I checked the file in > ffplay and did not find the same distortion, so I believe this is an mplayer > bug. > > The file in question is here: > > http://ia331209.us.archive.org/0/items/Patent_Absurdity/Patent_Absurdity_HD_3540kbit.ogv > > A screenshot is attached to show the distortion. The video is encoded at an > interesting resolution: 1280x1088, which may contribute to the problem. One or more of these FFmpeg revisions have not been backported to 0.6 I guess: r23537, (r25050 not directly related), r25051, r25052, r25073 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#595452: mplayer: Fails to play recent Matroska (MKV) files: "Track 1 has been compressed with an unknown/unsupported compression algorithm (3)"
On Sat, Sep 04, 2010 at 10:44:38PM +0200, Reinhard Tartler wrote: > BTW, I can reproduce this error with rc4 by forcing the native mkv muxer > with the opten '-demuxer mkv'. > > This means that this bug is not fixed in rc4 at all, but just masked > by using lavf by default! Note that there is a patch pending for it in the MPlayer dev list (and a few more as well). Unfortunately the patch submitter "disappeared" and I would have preferred to let him apply himself. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#591525: [PATCH] segfault in playtree.c
On Fri, Aug 06, 2010 at 01:22:12PM -0400, Reinhard Tartler wrote:
> I see. In this case, I propose this:
>
> Index: playtreeparser.c
> ===
> --- playtreeparser.c (revision 31931)
> +++ playtreeparser.c (working copy)
> @@ -367,6 +367,9 @@
>
>free(entries);
>
> + if (list)
> +return NULL;
> +
>entry = play_tree_new();
>play_tree_set_child(entry,list);
>return entry;
Condition inverted? I also don't know if the code
above can deal with NULL return, but in principle
I guess it should be right.
On checking again, this means that the parser code
will try to parse it as a different format.
Probably correct, but definitely a side-effect.
> Index: playtree.c
> ===
> --- playtree.c(revision 31931)
> +++ playtree.c(working copy)
> @@ -218,8 +218,15 @@
> play_tree_set_child(play_tree_t* pt, play_tree_t* child) {
>play_tree_t* iter;
>
> -#ifdef MP_DEBUG
> - assert(pt != NULL);
> + /* Roughly validate input data. Both, pt and child are going to be
> + * dereferenced, hence assure they're not NULL.
> + */
> + if (NULL == pt || NULL == child) {
> +mp_msg(MSGT_PLAYTREE,MSGL_ERR, "Detected malformed playlist file.
> Possible bug in paser?\n");
> +return;
> + }
> +
> +#ifdef MP_DEBUG || 1
Mostly ok, except the ifdef part of course and also I am not
sure this is only called for playlist files.
It should be something like "Internal error, attempt to
add an empty child or use empty playlist\n".
Also "NULL == pt" should be !pt etc.
Also, a spaces is missing before MSGL.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#506244: mplayer: Can't keep up with 64kbit/s Vorbis on 400MHz CPU
On Fri, Aug 06, 2010 at 06:32:01PM +0200, Diego Biurrun wrote: > I disagree slightly here since the issue does not only apply to > Vorbis/Tremor. For MP3 we have a similar situation: We default > to mp3lib, but ffmp3 is fixedpoint and thus faster on systems > without FPU. So a slightly more general framework on our side > might be adequate. Not really, the issue is the same: FFmpeg has a float and a fixed-point implementation, it needs to select the proper one automatically. The current approach is as silly as having a different decoder for MMX, SSE, SSE2 and expecting an application to manually select the right one. It's just not going to work. Also it is not just a matter of FPU or not, but also the relative speed of integer vs. FPU units. Apart from this, adding "ac=ffmp3,tremor," to the default config of FPU-less systems should work, it just is no good solution. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#506244: mplayer: Can't keep up with 64kbit/s Vorbis on 400MHz CPU
On Fri, Aug 06, 2010 at 05:07:14PM +0200, Diego Biurrun wrote: > On Fri, Aug 06, 2010 at 10:16:49AM -0400, Reinhard Tartler wrote: > > > > In case this works, Diego, Reimar, do you think it's worth to ship a > > different codecs.conf on arm-ish (arm, armel and armhf) platforms that > > prefer tremor over ffvorbis? Or can this preference perhaps be > > influenced by a configure switch? > > I have thought about this before, but I have no good idea how to solve > this. A different codecs.conf will work, but it's ugly. Maybe we > could add a fixedpoint flag to codecs.conf entries and prefer these > codecs on systems without FPU? > > Reimar? I think the approach that was discussed for FFmpeg was to only compile the faster variant. I has quite a few issues, but in principle only compiling in tremor support would select it. It would also work the other way round (and probably better), make tremor the default but only compile it in on FPU-less systems. In the case of MPlayer there may be some issues with that, e.g. the native ogg demuxer behaviour might change. Of course the best solution would have been if tremor hadn't been developed as a completely different library but instead was just a different configuration of libvorbis... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#591525: [PATCH] segfault in playtree.c
On Thu, Aug 05, 2010 at 08:48:59PM -0400, Reinhard Tartler wrote:
> On Thu, Aug 05, 2010 at 18:00:11 (EDT), Reimar Döffinger wrote:
>
> > On Thu, Aug 05, 2010 at 12:39:52AM -0400, Reinhard Tartler wrote:
> >> Hi Folks,
> >>
> >> This is a patch from Adrian Knoth to fix a
> >> segfault on empty playlists.
> >>
> >> This is Debian Bug: http://bugs.debian.org/591525
> >>
> >> Index: playtree.c
> >> ===
> >> --- playtree.c (revision 31912)
> >> +++ playtree.c (working copy)
> >> @@ -223,6 +223,13 @@
> >>assert(pt->entry_type == PLAY_TREE_ENTRY_NODE);
> >> #endif
> >>
> >> + /* Roughly validate input data. Both, pt and child are going to be
> >> + * dereferenced, hence assure they're not NULL.
> >> + */
> >> + if (NULL == pt || NULL == child) {
> >> + return;
> >> + }
> >> +
> >>//DEBUG_FF: Where are the children freed?
> >>// Attention in using this function!
> >>for(iter = pt->child ; iter != NULL ; iter = iter->next)
> >
> > Think I replied to the wrong place first: I think this is the wrong
> > place, at least it must be before the asserts.
>
> I've analyzed the stacktrace more, and I think there is a bug in
> parse_pls() in playtreeparser.c. In case there is no (valid) entry, the
> for loop in line 344 is executed 0 times. This leads to leaving the
> variable 'list' to '0', which in turn causes the crash. For this reason,
> I'm proposing this patch:
>
> Index: playtreeparser.c
> ===
> --- playtreeparser.c (revision 31930)
> +++ playtreeparser.c (working copy)
> @@ -368,6 +368,7 @@
>free(entries);
>
>entry = play_tree_new();
> + if (list)
>play_tree_set_child(entry,list);
>return entry;
> }
I don't know how the code is supposed to handle it, but I think that
and empty playlist should be considered invalid and the return value
should indicate this.
E.g. by returning NULL instead of an empty new playtree.
> However, I still think Adrians Patch isn't bad and in this case would
> have had the exact same behavior. If perhaps other parsers have a
> similar problems, Adi's patch would be more safe.
I am not against applying an improved version (with the checks before
the asserts) as an additional safety measure, however it should
also print an error message, IMO failing at that point is an
indication the playlist parser code had a bug and failed to detect
a malformed playlist file.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#591525: [PATCH] segfault in playtree.c
On Thu, Aug 05, 2010 at 12:39:52AM -0400, Reinhard Tartler wrote:
> Hi Folks,
>
> This is a patch from Adrian Knoth to fix a
> segfault on empty playlists.
>
> This is Debian Bug: http://bugs.debian.org/591525
>
> Index: playtree.c
> ===
> --- playtree.c(revision 31912)
> +++ playtree.c(working copy)
> @@ -223,6 +223,13 @@
>assert(pt->entry_type == PLAY_TREE_ENTRY_NODE);
> #endif
>
> + /* Roughly validate input data. Both, pt and child are going to be
> + * dereferenced, hence assure they're not NULL.
> + */
> + if (NULL == pt || NULL == child) {
> + return;
> + }
> +
Checking for NULL after dereferencing makes no sense, even if the
dereferencing is inside an assert.
Apart from that, pt and child are not _input_ data, they are
MPlayer-internal data, it is very likely the validation
should happen far earlier.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#585555: Please don't set the default audio output in /etc/mplayer/mplayer.conf
On Tue, Jun 15, 2010 at 11:18:18AM -0400, Pascal Gervais wrote: > > Also, I think having the sound device taken over by one program, > > leaving other programs with no sound, is a bigger issue than waiting > > a few seconds for mplayer to start playback. > > And I think having to wait six to seven seconds before MPlayer start my > playlist and that having to wait six to seven seconds between each > audio files of my playlist is a bug, an unacceptable behavior, a > regression that occurred when you decided to set pulseaudio as the > default audio output of MPlayer. > > Anyway, in case you are interested in finding what is wrong, here is > the outpout of MPlayer when it tries to find pulseaudio: > waitpid(): No child processes > AO: [pulse] Init failed: Internal error > Failed to initialize audio driver 'pulse' > > 'waitpid(): No child processes' is where MPlayer takes all that time > before starting each audio and video playback. Please use strace or something like that to figure out what is going on. You might also want to try MPlayer directly from SVN and them discuss the issue directly upstream (I'm also on the MPlayer-users list). It might be worth looking if you maybe have a broken or non-working pulseaudio binary around, because that is probably what MPlayer tries to start during that wait-time. I guess you can also avoid this by setting in /etc/pulse/client.conf autospawn = no (maybe that should be the default? People who want pulseaudio are supposed to have it started on login, so if it is not already started it probably is not wanted?) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#585555: Please don't set the default audio output in /etc/mplayer/mplayer.conf
On Sat, Jun 12, 2010 at 12:49:41PM +0200, David Henningsson wrote: > Wouldn't it be a better solution to try to troubleshoot why it takes so > long for the pa driver to detect that PA is not installed? Indeed, particularly since I don't have that issue when I do killall pulseaudio chmod a-x /usr/bin/pulseaudio mplayer -ao pulse, I get immediate fallback to OSS without any noticeable delay. Actually I only get a delay when the pulseaudio "server" must be started. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578622: mplayer on kfreebsd
On Thu, Apr 22, 2010 at 10:24:00PM +0200, Reinhard Tartler wrote: > This is because libvo/vo_directfb2.c #includes sys/kd.h, which in turn > includes sys/kbio.h, which defines another 'struct keymap'. Questionable name in a system header file. I guess the sys/kd include can't be just avoided? > In order to > fix this build error, I propose to rename the struct in mplayer, which > requires patching several files. The prefix should better be mp instead of m IMO. Otherwise I don't really mind it, although system header files with such generic names are quite a problem. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#567725: mplayer: gets SIGILL on Pentium II when playing an MPEG video with -vo caca
On Sun, Jan 31, 2010 at 09:32:05AM +0100, Reinhard Tartler wrote: > libswscale uses MMX2: > > > -- The GDB backtrace > > #0 0xb620657d in yuv420_rgb24_MMX2 (c=0x8601ec0, src=0xbfffcb70, > > srcStride=0xbfffcb40, > > srcSliceY=0, srcSliceH=16, dst=0x862c944, dstStride=0xbfffcb50) > > at > > /build/buildd-ffmpeg_0.5+svn20090706-5-i386-gCmK4F/ffmpeg-0.5+svn20090706/libswscale/yuv2rgb_template.c:292 > > This is the same bug as > https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/386397 > > As easy workaround, you can move /usr/lib/i686/cmov/libswscale.so.0 out > of the way. > > Not sure how to fix this properly. By doing what the first comment in that bug report says? Compile FFmpeg with --enable-runtime-cpudetection ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#561743: mplayer: segmentation fault when mouse-over on Preferences->Video->Panscan
On Sun, Dec 20, 2009 at 01:05:59PM +0100, Reinhard Tartler wrote: > Raghu Rao writes: > > > Please let me know if further information is needed. > > yes, could you please attach a full backtrace? > > See http://wiki.debian.org/HowToGetABacktrace or > https://wiki.ubuntu.com/Backtrace for more information how to do so. Just in case it might be interesting to you to make things easier for your users: If you compile MPlayer with --enable-crash-debug and start MPlayer with -crash-debug, it will automatically attach gdb and print a stack trace upon a crash (actually in case of a specific list of signals). ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
