Mplayer and stuttering or choppy video/audio playback
Dariusz Piatkowski
I am running mplayer "SVN-r30994-OS2-4.4.2 (C) 2000-2010 MPlayer Team" with the
following config file:
=== START ===
#Write your default config options here!
vo=kva:snap
ao=kai:dart
#ao=kai:uniaud
geometry=50:50
#aspect=16:9
font=g:\psfonts\verdana.ttf
subfont=g:\psfonts\verdana.ttf
codecpath=g:\apps\multimedia\mplayer\codecs
#msglevel:all=9
=== STOP ===
My audio is a UniAudio based, nForce2 sound chipset, on Asus A7n8x Deluxe
motherboard. Using the 191-1922 UniAudio driver package. I had previously tried
all the previous ones, such as 114RCx series w/o much luck. Video card is an ATI
X800 XT, AGP based, using latest SNAP drivers.
Basically, playing back video in mplayer I get choppy playback, the video
freezes, audio stops momentarily, I usually see a CPU spike, the video then
resumes.
In comparison, playing the same video in VLC player or WarpVision does not
exhibit this problem.
Trying the latest builds of UniAudio drivers seems to somewhat cure the problem,
although it's really hard to say. I suspect the video more then the audio given
that other players do fine.
MrG
wrote:
try using the -cache switch. about 4 meg outta do
Dariusz Piatkowski
Thanks...I tried this, some videos this seems to help with, but others still
show the choppy playback. What I have now also noticed is that the videos which
show this issue also appear to exhibit audio 'issues' in VLC player.
So...I'm leaning towards an issue with the UniAudio drivers now..
Ilya Zakharevich
> try using the -cache switch. about 4 meg outta do
I use
-cache 8000 -cache-min 25
MPlayer still stutters at the beginning of (some?) files or after a seek
forward (when cache is about 98% full...); things get better later
(when cache is reported to be 49% full; go figure...). JFS cache is
at 64M, and CPU_Monitor shows about 60-70% usage (same as later in
video). Typical average bandwidth is about 1600Mb/sec or less...
I suspect some issues with JFS (wrong "prioritization"???); but I do
not know what happens with CPU meter. Maybe the system is too busy
for it to update the display...
Ilya
MrG
wrote:
try letting mplayer auto choose your video/audio modes instead of
forcing a mode. IIRC I had problems when I forced snap mode. also look
into the autosync/autoq switches. those 2 are standard in doze gui
implimentations. I would leave in the cache switch. can't hurt and
will help if you view any streaming videos. maybe bump it up to 8 or
12 meg. if the latest uniaud drivers don't cut it, you could also try
back leveling till you find a driver that works. good luck
Dariusz Piatkowski
Sir...that was pure GENIUS!!!
Seriously...I searched for this solution before and somehow never found
it...maybe it just didn't dawn on me...the 'autosync' parameter is what fixed
the issue for me. Anyways, it sounds like this parameter is meant to work around
sound driver/hardware limitations...in my case that's all that was needed.
I did try some of the post-processing options, however I found that while the
CPU did spike the quality really didn't improve much, while I did start seeing
horizontal 'scan bands' for the lack of better term. Almost as if the system
couldn't quite keep up with the framerate.
Thanks again, here is my current CONFIG for anyone's reference:
=== START ===
# Write your default config options here!
# VIDEO
vo=kva:snap
geometry=50:50
#aspect=16:9
#double="yes" # double buffering(recommended for subtitles)
autoq=100 # AUTO control the video quality
#vf=pp=de,hqdn3d # additional post-processing options
# AUDIO
ao=kai:dart
#ao=kai:uniaud
srate=48000
font=g:\psfonts\verdana.ttf
subfont=g:\psfonts\verdana.ttf
codecpath=g:\apps\multimedia\mplayer\codecs
# OTHER CONTROLS
#msglevel:all=9 # set the DEBUG level
#cache=4096 # set the TOTAL cache size
#cache-min=25 # fill 10% of TOTAL cache before playback start
autosync=30 # sync up video/audio by adjusting the algorithm
=== END ===
Dariusz Piatkowski
wrote:
Ilya,
'autosync=30' parameter fixed it for me. I am playing around with the 'cache' as
well...but for the most part I'm not doing my streaming video (most places seem
to want to stream FLASH).
Thanks!
Ilya Zakharevich
>> I use
>> -cache 8000 -cache-min 25
>> MPlayer still stutters at the beginning of (some?) files or after a seek
>> forward (when cache is about 98% full...); things get better later
>> (when cache is reported to be 49% full; go figure...). JFS cache is
>> at 64M, and CPU_Monitor shows about 60-70% usage (same as later in
>> video). Typical average bandwidth is about 1600Mb/sec or less...
>>
>> I suspect some issues with JFS (wrong "prioritization"???); but I do
>> not know what happens with CPU meter. Maybe the system is too busy
>> for it to update the display...
> 'autosync=30' parameter fixed it for me.
I'm already running with autosync=30. My full invocation (on OS/2;
Windows requires some more tuning) is
mplayer -doubleclick-time 0
-ass -ass-border-color 00000060 -ass-color FFFF0000 -ass-font-scale 1.2
-idx -sub-fuzziness 1 -autosync 30 -framedrop -cache 8000 -cache-min 25
-dvd-device v:
-unrarexec i:\UTILS\unrar.exe -codecpath I:/UTILS/codecs -priority abovenormal
Ilya
MrG
I'm happy you got it worked out.
Wow, look at us (os2/ecs) now. We have two, count em, two good video
players for our platform, both thanks to the efforts of KO Myung-Hun.