Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
As far as I can see there is no bug. This is expected behavior with ALSA dmix. It has a fixed hardware output frequency, in your case 48000 Hz. Anything played through dmix will be resampled to 48000 Hz. mplayer2 could feed data to ALSA at 44100 Hz if it left ALSA resampling enabled, but the only difference that would make is that the resampling would happen on the ALSA side rather than on the mplayer2 side. There's no way hardware would support everything in the 4000-4294967295 range. That range only tells which rates ALSA is willing to resample to 48000 Hz. The values reported for the hw device, 44100 48000 96000 192000, are the ones your hardware can actually play without resampling. If you select the hw device then you should be able to play these rates without resampling (note that in contrast to dmix, using the hw device directly reserves the device and no other audio source can play at the same time). The only thing here that could potentially be improved would be to allow dmix to change the hardware playback rate depending on input streams, so it could switch the hardware rate to 44100 Hz if that's the rate of the only stream being played. But this would be nontrivial - what happens if another stream is opened at a different frequency, etc. ___ 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#670236: mplayer2: can't play video with resolution of 2542x1080
This is a limitation reported by libXv. It's likely due to limitations of your graphics hardware. You can try other output methods such as gl, but it's likely they won't work well either on such hardware. Using --xy=0.5 won't help, because that will try to do the scaling in hardware, but the limitation is about hardware input image size. You can force software scaling on CPU with options like --vf=scale=1920:-2. This would add a filter to do software scaling to a width of 1920 and a height that keeps the original aspect ratio, which should fit within the limitations of your hardware. You may want to adjust the value of 1920 if you have a monitor smaller or larger than 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#671362: mplayer2 crashes when trying to connect to remote pulseaudio server
Fixed upstream in bb908027178fe8bfd7d6e3fc255dea8c5051cd4a. ___ 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#663239: mplayer opens audio device in 48000 Hz for 44100 source material
On Sat, 2012-05-12 at 12:52 +0200, Kurt Roeckx wrote: On Sun, Apr 15, 2012 at 07:17:34PM +0300, Uoti Urpala wrote: This is expected behavior with ALSA dmix. It has a fixed hardware output frequency, in your case 48000 Hz. As far as I know this is just a default and has nothing at all to do with what the hardware supports, it's just a value in a config file. I meant it's fixed for each dmix instance; when ALSA dmix is using a hardware frequency of 48000 Hz, everything will be resampled to that. You can configure dmix to use a different frequency, but it won't adapt based on source audio. I know all this. That doesn't mean things can't be improved. Well, it certainly sounded like you didn't know all this; if you did, I can't see why you wrote The problem now is that mplayer does this in libao2/ao_alsa.c: in the original message, or reported this against mplayer2 at all (in addition to libasound2). What could be improved in mplayer2? ___ 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#673820: mplayer2: -ao pulse does not work
The issue in the log is due to the file being so short (0.5 seconds). This is the same as http://devel.mplayer2.org/ticket/166 The total amount of audio is not enough to trigger automatic start of playback. However, for some weird reason setting that amount lower triggered yet another Pulseaudio bug (it has a LOT of bugs), so mplayer2 doesn't currently do that. Unfortunately Pulseaudio 2.0 seems to be yet buggier again than previous versions - now seeking is _always_ buggy regardless of whatever else you do on my machine at least (after calling pa_stream_flush() it takes a long time before audio playback from the new position starts working right, leading to stopped audio and frozen video until then). So perhaps this issue could be fixed; OTOH that'd mean seeking would be broken with all Pulseaudio versions, even the older ones where it worked before. ___ 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#674145: mplayer2: mplayer does not stop after playing a file
Are you using Pulseaudio output (or ALSA redirected through Pulseaudio)? My first guess is that you're hitting one of Pulseaudio's numerous bugs, where it keeps falsely reporting that there's still a significant amount of unplayed audio left; the player keeps waiting for the audio to finish playing. ___ 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#674145: mplayer2: mplayer does not stop after playing a file
On Thu, 2012-05-24 at 13:47 +0200, Martin Ziegler wrote: mplayer said that the output device was pulse: AO: [pulse] Wenn I use mplayer with the option -ao alsa everything works fine. Thanks! This is most likely a Pulseaudio bug then. It might be interesting that the version of mplayer in the package mplayer does not hit this bug. It works also with the option -ao pulse. The old code in MPlayer 1 exits the main play loop after all audio has been buffered, regardless of the amount of audio not actually played yet (a flush all buffered audio operation is performed later). So it's expected that this Pulseaudio bug does not have the same effect. The problem with the old code is that the player can become unresponsive for relatively long periods during the flush operation, even with audio output drivers that function perfectly. It would be possible to add some workarounds on the player side for this bug. But I'm not sure whether that would be worth it, as there are so many bugs in Pulseaudio, and 2.0 broke more things again. Trying to work around just this bug feels somewhat pointless in this situation. The current situation where Pulseaudio has become the standard sound output method but seems to lack developers to fix even fairly blatant bugs in basic functionality is unfortunate. ___ 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#688800: mplayer2: can not seek wvc1 videos
On Wed, 2012-09-26 at 07:21 +0200, Reinhard Tartler wrote: wvc1 videos are unseekable in mplayer2. For example if I try to seek 10 seconds forward using right key, then the video freezes. A sample video is here: http://ftyps.com/unrelated/vc1_in_wmv.wmv I can reproduce the problem with the default libavformat demuxer: mplayer -demuxer lavfpref vc1_in_wmv.wmv But not with the internal asf demuxer: mplayer -demuxer asf vc1_in_wmv.wmv Interestingly, avplay does not have any problems with seeking: avplay vc1_in_wmv.wmv This doesn't mean that libavformat was bugfree, this may as well indicate a problem in the way how mplayer2 drives libavformat. Uoti, can you have a look at this? Thanks! This is a bug in the libavcodec VC-1 decoder. It outputs a frame from the old position after a seek flush. Actually, the codec object in vc1dec.c seems to be completely missing the needed .flush field entry. That it happens to work closer to normal with the internal demuxer is just a side effect of a different timing mode used with the old demuxer; the decoder misbehavior does not have the same effects in that case. ___ 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#739337: FTBFS with libav10
On Sat, 2014-03-08 at 13:11 -0500, Reinhard Tartler wrote: On Sat, Mar 1, 2014 at 7:05 AM, an...@khirnov.net wrote: Hi, the attached patch should fix this bug. Thanks for providing this patch for the debian mplayer2 packages. Unfortunately, it does not apply cleanly against the upstream version 6c87a98. Would you mind having another look at it? For reference, the debian package bases on: commit 6c87a981baa4972fd71c25dfddea017b5a972e89 I pushed some old not-quite-finished changes which replace lavcresample with lavrresample. While that had some remaining things to fix, it should be much better than just dropping lavcresample as in the patch. ___ 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#702533: mplayer2: continue from pause not working
This is most likely caused by misbehaving audio output. Especially PulseAudio is known to have bugs which cause such problems. However, you're using the mplayer2 version from experimental which has workarounds for those PulseAudio issues and should work for most people (unfortunately, Debian unstable still ships a version which is known to cause problems for a significant portion of users). Do you have PulseAudio active on your system? If you do, which audio output API are you using in mplayer2 - ao_pulse or ao_alsa? In the default Debian PulseAudio configuration, applications outputting sound with the ALSA API are redirected to PulseAudio, and this redirection mode is even more buggy than the native PulseAudio API (note that this applies only to the default ALSA device; if you configure mplayer2 to use an ALSA hardware device, that works fine and will not be redirected). In any case you can verify that the issue is caused by audio output by using --nosound or --ao=null (the latter is closer to normal playback with audio; it decodes audio but only outputs it with a dummy driver). ___ 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#797733: Please support dynamically disabling audio pitch correction
The following keybinding should do this: cycle options/audio-pitch-correction With "cycle" this will switch between on and off. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
