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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
