[MPlayer-users] minimal CPU requirement to play high bitrate 1080p video in software?

[Marc MERLIN]

On Tue, Aug 07, 2012 at 08:00:41PM +0200, Reimar Döffinger wrote:
> > > VDec: using Planar 420P 10-bit little-endian as output csp (no 3)
> 
> Your specific file is a 10-bit H.264 file, which and XVideo does not
> support 10-bit surfaces (at least no implementation I know of does),
> which means using xv needs and additional software conversion.
> Unfortunately you cut the status line output, otherwise I could have
> told you approximately how much performance that costs.

Sorry. What do those lines look like so I can find them?
(full -v output is very spammy, I wanted to cut that down a bit).

> -vo gl should be able to handle 10-bit directly (on many cards at least).

Actually I did try -vo gl, and it decodes in black, 2 shades of grey, and
white, so it's not great :)

On Tue, Aug 07, 2012 at 06:24:11PM +0000, Carl Eugen Hoyos wrote:
> Marc MERLIN <marc_mplayer <at> merlins.org> writes:
> 
> > The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 
> > 1080p 20MB/s encoded H264 mkv just isn't fast enough.
> 
> This is fast enough for nearly everything real-world.
> (I use the same CPU passively cooled for some time and 
> I don't remember many videos that did not play real-time, 
> especially not at 24fps.)

Good news is that it seems fine now that I'm using both cores.

> What Reimar said (use -vo gl) will probably make all the difference, but
> please note that the MPlayer version you have on the dual core (desktop)
> looks to me as if it was intentionally broken by the packager.

which piece is broken from what you saw?

> Compiling yourself has the advantage that without runtime-CPU-detection
> (that is needed for packaged binaries) MPlayer runs a tiny bit faster.

If I have to go there, I could do it again. It's been 10 years since my last
time, and I remember how hellish it was back then :)
That said, since both CPUs can play fast enough now, adding 2% extra perf by
avoiding a test/branch for what CPU optimizations to use, may not be worth
it, unless you found something else that looks very broken with the package.

On Tue, Aug 07, 2012 at 01:28:53PM -0500, Ron Johnson wrote:
> If your case supports it, I'd install a (small, cheap, fanless) Nvidia 
> G210 card, since with vdpau and the binary driver it supports almost 
> everything except 10-bit video.

I'm not really interested in closed source drivers if I can avoid them :)

On Tue, Aug 07, 2012 at 08:33:28PM +0200, Reimar Döffinger wrote:
> As I said, his use case is exactly 10-bit video.
> So unless the built-in card has problems with -vo gl
> (I think it doesn't as long as you use the latest Mesa drivers)
> that would be a waste of time, money and electricity.

Interesting, even on my laptop with a brand new intel CPU, it's also only 2
shades of grey. I get (oh, hi, I see a familiar name in the logs :) ).

VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar 420P 10-bit little-endian)
Trying filter chain: vo
VDec: using Planar 420P 10-bit little-endian as output csp (no 3)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO Config (1920x1080->1920x1080,flags=4,'MPlayer',0x52303234)
VO: [gl] 1920x1080 => 1920x1080 Planar 420P 10-bit little-endian  [zoom]
VO: Description: OpenGL
VO: Author: Reimar Doeffinger <Reimar.Doeffinger at gmx.de>
[gl] GLX chose visual with ID 0xa0
[gl] Running on OpenGL 'Mesa DRI Intel(R) Ivybridge Mobile ' by 'Tungsten Graphics, Inc', version '2.1 Mesa 7.11.2'
[gl] Settings after autodetection: ati-hack = 0, force-pbo = 0, rectangle = 0, yuv = 2
[gl] Creating 2048x2048 texture...
[gl] Resize: 320x200

I have libgl1-mesa-dri 7.11.2-1 on debian 64bit on my laptop.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/