I've been using VDPAU acceleration to play back Blu-Ray rips for a
while, but the extra layer is getting to be quite a hassle so I'm
trying to get decent performance via software decoding. It has
actually come a long way since the last time I tried and playing
Blu-Ray rips via mplayer is nearly watchable. I'm using a dual-core
3.1Ghz CPU and one of the cores is only taxed up to 60% during
playback, but frames are still being dropped constantly. Does anyone
know where the bottleneck might be?

- Grant

On 07/07/2010 05:17 AM, Grant wrote:

I've been using VDPAU acceleration to play back Blu-Ray rips for a
while, but the extra layer is getting to be quite a hassle so I'm
trying to get decent performance via software decoding. It has
actually come a long way since the last time I tried and playing
Blu-Ray rips via mplayer is nearly watchable. I'm using a dual-core
3.1Ghz CPU and one of the cores is only taxed up to 60% during
playback, but frames are still being dropped constantly. Does anyone
know where the bottleneck might be?


Not sure. Could be wrong CPU load display; which tool do you use to get
the CPU load?


Anyway, if you're not already doing so, you might want to try the
multithreaded version of mplayer so both CPU cores can do decoding.
It's in the "multimedia" overlay. More details here:


http://forums.gentoo.org/viewtopic-t-789673.html

>> I've been using VDPAU acceleration to play back Blu-Ray rips for a
>> while, but the extra layer is getting to be quite a hassle so I'm
>> trying to get decent performance via software decoding. *It has
>> actually come a long way since the last time I tried and playing
>> Blu-Ray rips via mplayer is nearly watchable. *I'm using a dual-core
>> 3.1Ghz CPU and one of the cores is only taxed up to 60% during
>> playback, but frames are still being dropped constantly. *Does anyone
>> know where the bottleneck might be?
>
> Not sure. *Could be wrong CPU load display; which tool do you use to get the
> CPU load?

I use top. On the mplayer list, people were saying they too get 60%
CPU load but no playback problems.

> Anyway, if you're not already doing so, you might want to try the
> multithreaded version of mplayer so both CPU cores can do decoding. It's in
> the "multimedia" overlay. *More details here:
>
> *http://forums.gentoo.org/viewtopic-t-789673.html

I really don't think it's a CPU issue. What other factors could be at
play? Could it be my nouveau video drivers?

- Grant

On 07/07/2010 05:33 AM, Grant wrote:
>>> I've been using VDPAU acceleration to play back Blu-Ray rips for a
>>> while, but the extra layer is getting to be quite a hassle so I'm
>>> trying to get decent performance via software decoding. It has
>>> actually come a long way since the last time I tried and playing
>>> Blu-Ray rips via mplayer is nearly watchable. I'm using a dual-core
>>> 3.1Ghz CPU and one of the cores is only taxed up to 60% during
>>> playback, but frames are still being dropped constantly. Does anyone
>>> know where the bottleneck might be?
>>
>> Not sure. Could be wrong CPU load display; which tool do you use to get the
>> CPU load?
>
> I use top. On the mplayer list, people were saying they too get 60%
> CPU load but no playback problems.
>
>> Anyway, if you're not already doing so, you might want to try the
>> multithreaded version of mplayer so both CPU cores can do decoding. It's in
>> the "multimedia" overlay. More details here:
>>
>> http://forums.gentoo.org/viewtopic-t-789673.html
>
> I really don't think it's a CPU issue. What other factors could be at
> play? Could it be my nouveau video drivers?
>
> - Grant
>
Regarding mplayer: There is another ebuild in the multimedia-overlay
that I prefer now to mplayer(-mt) and that also uses ffmpeg-mt :
media-video/mplayer-uau.

It fetches the mplayer-version from one of the mplayer-devs and creates
a binary called "mplayer-uau" which can be installed at the same time as
the official mplayer package.

Regarding your frame drops: it is highly likely that sound is the
problem. Please try playing the video with "-ao null" to see if that's
the case. I assume you use pulseaudio? Check if it has real time
capabilities (kill it, start it with verbose/debug in foreground, read
log). Also try "-ao alsa" and "-ao oss".

Your data-source (gard disk, network?) is fast enough? Copy 1GB into RAM
to be sure by ether using RAM-disk or cache-settings.

Try nvidia-binary. You'll get VDPAU in that case, which will result in
about 5% CPU usage when decoding h264!

Hope some of this helps...
Daniel

--
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887

You have dual core so*60% means:
50% (full one core) is for decoding,*
and the rest 10% is for audio, resizing etc.
You can't play the video correctly because your "decoder" is not multithreaded and uses just the one CPU at its fullest.

Try using multithreaded version of mplayer "mplayer-mt" (in some overlay probably) with "lavdopts=threads=2" in mplayer config.

On Wed, Jul 7, 2010 at 5:17 AM, Grant <emailgrant@gmail.com> wrote:

I've been using VDPAU acceleration to play back Blu-Ray rips for a

while, but the extra layer is getting to be quite a hassle so I'm

trying to get decent performance via software decoding. *It has

actually come a long way since the last time I tried and playing

Blu-Ray rips via mplayer is nearly watchable. *I'm using a dual-core

3.1Ghz CPU and one of the cores is only taxed up to 60% during

playback, but frames are still being dropped constantly. *Does anyone

know where the bottleneck might be?



- Grant

On 07/07/2010 12:35 PM, App Deb wrote:
> You have dual core so 60% means:
>
> 50% (full one core) is for decoding,
>
> and the rest 10% is for audio, resizing etc.
Oh - didn't think about this - yes... you could be seeing the wrong
thing in "top". If you have more than 1 CPU/Core you should push "1" in
"top" to get separate statistics per CPU/Core. Push "W" to save your
settings. (Use "s" to change statistics collection time, "1" sec. is good.)

Use "htop" to see threads. As far as I know "top" won't show those. So
you can't check if your multi-threaded mplayer is really using more than
1 thread/process.

BTW: On my core2duo 2,4 GHz I have no problems watching H.264 encoded
1080p videos with AAC sound. All decoding is done in software. When I
use original mplayer 720p is possible without problem, 1080p only with
low bitrate. For high bitrate 1080p I need the mt-version.

Daniel


>
> You can't play the video correctly because your "decoder" is not
> multithreaded and uses just the one CPU at its fullest.
>
> Try using multithreaded version of mplayer "mplayer-mt" (in some overlay
> probably) with "lavdopts=threads=2" in mplayer config.
>
> On Wed, Jul 7, 2010 at 5:17 AM, Grant <emailgrant@gmail.com
> <mailto:emailgrant@gmail.com>> wrote:
>
> I've been using VDPAU acceleration to play back Blu-Ray rips for a
> while, but the extra layer is getting to be quite a hassle so I'm
> trying to get decent performance via software decoding. It has
> actually come a long way since the last time I tried and playing
> Blu-Ray rips via mplayer is nearly watchable. I'm using a dual-core
> 3.1Ghz CPU and one of the cores is only taxed up to 60% during
> playback, but frames are still being dropped constantly. Does anyone
> know where the bottleneck might be?
>
> - Grant
>
>

On 7 July 2010 12:27, Daniel Troeder <daniel@admin-box.com> wrote:

> Use "htop" to see threads. As far as I know "top" won't show those. So
> you can't check if your multi-threaded mplayer is really using more than
> 1 thread/process.

What do you get when you press upper case 'H' in top?
--
Regards,
Mick

> Regarding mplayer: There is another ebuild in the multimedia-overlay
> that I prefer now to mplayer(-mt) and that also uses ffmpeg-mt :
> media-video/mplayer-uau.
>
> It fetches the mplayer-version from one of the mplayer-devs and creates
> a binary called "mplayer-uau" which can be installed at the same time as
> the official mplayer package.

I gave that a try and it smoothed everything right out, so I guess it
was a CPU issue after all. Thank you for your help. How is
mplayer-uau different from mplayer-mt? Maybe mplayer-mt can't be
installed alongside mplayer?

> Regarding your frame drops: it is highly likely that sound is the
> problem. Please try playing the video with "-ao null" to see if that's
> the case. I assume you use pulseaudio? Check if it has real time
> capabilities (kill it, start it with verbose/debug in foreground, read
> log). Also try "-ao alsa" and "-ao oss".

No change with "-ao null". I actually don't use pulseaudio.

> Your data-source (gard disk, network?) is fast enough? Copy 1GB into RAM
> to be sure by ether using RAM-disk or cache-settings.

It's running from an internal HD.

> Try nvidia-binary. You'll get VDPAU in that case, which will result in
> about 5% CPU usage when decoding h264!

I'm trying to move away from VDPAU. It fixes the performance issue
but the extra layer creates a new set of problems.

- Grant

> You have dual core so*60% means:
> 50% (full one core) is for decoding,
> and the rest 10% is for audio, resizing etc.
> You can't play the video correctly because your "decoder" is not
> multithreaded and uses just the one CPU at its fullest.
> Try using multithreaded version of mplayer "mplayer-mt" (in some overlay
> probably) with "lavdopts=threads=2" in mplayer config.

Does anyone know if mplayer-uau uses "-lavdopts threads=2" by default?
I tried with and without and there might have been a performance
increase with, but I'm not sure.

- Grant


>> I've been using VDPAU acceleration to play back Blu-Ray rips for a
>> while, but the extra layer is getting to be quite a hassle so I'm
>> trying to get decent performance via software decoding. *It has
>> actually come a long way since the last time I tried and playing
>> Blu-Ray rips via mplayer is nearly watchable. *I'm using a dual-core
>> 3.1Ghz CPU and one of the cores is only taxed up to 60% during
>> playback, but frames are still being dropped constantly. *Does anyone
>> know where the bottleneck might be?
>>
>> - Grant

On 07/07/2010 08:46 PM, Grant wrote:

Regarding mplayer: There is another ebuild in the multimedia-overlay
that I prefer now to mplayer(-mt) and that also uses ffmpeg-mt :
media-video/mplayer-uau.

It fetches the mplayer-version from one of the mplayer-devs and creates
a binary called "mplayer-uau" which can be installed at the same time as
the official mplayer package.


I gave that a try and it smoothed everything right out, so I guess it
was a CPU issue after all. Thank you for your help. How is
mplayer-uau different from mplayer-mt? Maybe mplayer-mt can't be


mplayer from multimedia overlay is a replacement for the regular,
official mplayer with the only change being ffmpeg-mt. It can't be
installed alongside regular mplayer because it's a replacement and
multithreading can be enabled/disabled at runtime.


mplayer-uau is a fork of MPlayer, previously known as "mplayer-git",
before the developer was kicked from the mplayer project for unknown
reasons. While mplayer from multimedia only adds the ffmpeg-mt patch,
mplayer-uau adds more patches.