MPlayer cross-platform UNIX movie player, user discussion

Marc MERLIN | 7 Aug 2012 17:59

minimal CPU requirement to play high bitrate 1080p video in software?

I thought it would be an FAQ, but some searching didn't turn anything up.

My HTPC has an intel GM35 which does not support libva/vaapi from what I was
told.

The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 1080p 20MB/s
encoded H264 mkv just isn't fast enough.

I noticed that decoding is only done on one of the two CPUs. Is there a way
to switch to a codec that can use both CPUs?
If not, here's mplayer -v output if that helps. If there are other compile
options I could use, or a different codec or video output I could force, let
me know.
(for instance, is 'xv' still my best output option?)

> MPlayer SVN-r34707-4.6.1 (C) 2000-2012 MPlayer Team
> CPU vendor name: GenuineIntel  max cpuid level: 10
> CPU: Intel(R) Core(TM)2 Duo CPU     E8400   <at>  3.00GHz (Family: 6, Model: 23, Stepping: 6)
> extended cpuid-level: 8
> extended cache-info: 402686016
> Detected cache-line size is 64 bytes
> Testing OS support for SSE... yes.
> Tests of OS support for SSE passed.
> CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSSE3: 1
> Compiled with runtime CPU detection.
> Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay
> get_path('fonts') -> '/home/mythtv/.mplayer/fonts'
> Configuration: --prefix=/usr --confdir=/etc/mplayer --enable-xvmc --enable-menu --enable-radio
--enable-radio-capture --disable-arts --language=all --target=i586-linux
--enable-runtime-cpudetection --enable-debug --enable-mga --enable-3dfx --enable-tdfxfb --disable-gui

(Continue reading)

Vladimir Mosgalin | 7 Aug 2012 19:06

Re: minimal CPU requirement to play high bitrate 1080p video in software?

Hi Marc MERLIN!

 On 2012.08.07 at 08:59:55 -0700, Marc MERLIN wrote next:

> I thought it would be an FAQ, but some searching didn't turn anything up.
> 
> My HTPC has an intel GM35 which does not support libva/vaapi from what I was
> told.
> 
> The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 1080p 20MB/s
> encoded H264 mkv just isn't fast enough.
> 
> I noticed that decoding is only done on one of the two CPUs. Is there a way
> to switch to a codec that can use both CPUs?

Yes, try adding
lavdopts = threads=2
to mplayer config. Also maybe threads=3 will provide better results.

As for "minimum CPU requirements", it's hard to answer that because it
heavily depends on video bitrate and subtitle effects and such. It is
very possible to put even modern 4-core cpu on its knees if one is using
insane bitrate like 50 mbit/sec (with CABAC and lots of referenced
frames) in h264 accompanied by subtitles with lots of complex effects
like karaoke, blur, image rendering and such.

--

-- 

Vladimir

(Continue reading)

Reimar Döffinger | 7 Aug 2012 20:00

Picon

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Tue, Aug 07, 2012 at 08:59:55AM -0700, Marc MERLIN wrote:
> I thought it would be an FAQ, but some searching didn't turn anything up.
> 
> My HTPC has an intel GM35 which does not support libva/vaapi from what I was
> told.
> 
> The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 1080p 20MB/s
> encoded H264 mkv just isn't fast enough.
> 
> I noticed that decoding is only done on one of the two CPUs. Is there a way
> to switch to a codec that can use both CPUs?
> If not, here's mplayer -v output if that helps. If there are other compile
> options I could use, or a different codec or video output I could force, let
> me know.
> (for instance, is 'xv' still my best output option?)

Normally yes, but...

> > 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.
-vo gl should be able to handle 10-bit directly (on many cards at least).

Marc MERLIN | 7 Aug 2012 20:59

Re: minimal CPU requirement to play high bitrate 1080p video in software?

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.

(Continue reading)

Reimar Döffinger | 8 Aug 2012 07:05

Picon

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On 7 Aug 2012, at 20:59, Marc MERLIN <marc_mplayer <at> merlins.org> wrote:
> 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?

It's those starting with V: that give the current playback time. With xv the second % number should be about
the CPU usage for conversion.

>> -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 :)

Yes, that happens when 16 bit textures are not working.
It should be working with Mesa driver versions released this year if using the i965 driver (the i915 is more
complicated, I have a hack that makes it decode to around 8 shades of grey instead - a result I don't
understand yet...).

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

Not completely sure, but I suspect for your GPU it would work with something newer like mesa 8.0.3 or such.
_______________________________________________
MPlayer-users mailing list

(Continue reading)

Marc MERLIN | 8 Aug 2012 07:34

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Wed, Aug 08, 2012 at 07:05:11AM +0200, Reimar Döffinger wrote:
> On 7 Aug 2012, at 20:59, Marc MERLIN <marc_mplayer <at> merlins.org> wrote:
> > 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?
> 
> It's those starting with V: that give the current playback time. With xv the second % number should be about
the CPU usage for conversion.

mplayer -v Game.of.Thrones.S01.Ep01.1080p.BluRay.DTS.x264-ESiR.mkv  2>&1|
grep V:
Sorry, I tried:
mplayer -v file.mkv 2>&1| grep V:
and I got nothing out of it.

> Yes, that happens when 16 bit textures are not working.
> It should be working with Mesa driver versions released this year if using the i965 driver (the i915 is more
complicated, I have a hack that makes it decode to around 8 shades of grey instead - a result I don't
understand yet...).
> 
> > I have libgl1-mesa-dri 7.11.2-1 on debian 64bit on my laptop.
> 
> Not completely sure, but I suspect for your GPU it would work with something newer like mesa 8.0.3 or such.

(Continue reading)

Reimar Döffinger | 8 Aug 2012 07:45

Picon

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Tue, Aug 07, 2012 at 10:34:06PM -0700, Marc MERLIN wrote:
> On Wed, Aug 08, 2012 at 07:05:11AM +0200, Reimar Döffinger wrote:
> > On 7 Aug 2012, at 20:59, Marc MERLIN <marc_mplayer <at> merlins.org> wrote:
> > > 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?
> > 
> > It's those starting with V: that give the current playback time. With xv the second % number should be
about the CPU usage for conversion.
> 
> mplayer -v Game.of.Thrones.S01.Ep01.1080p.BluRay.DTS.x264-ESiR.mkv  2>&1|
> grep V:
> Sorry, I tried:
> mplayer -v file.mkv 2>&1| grep V:
> and I got nothing out of it.

You don't need any -v or anything to get it.
If you don't get anything you probably disabled it in your config file,
try -noquiet or -noconfig all

> > Yes, that happens when 16 bit textures are not working.
> > It should be working with Mesa driver versions released this year if using the i965 driver (the i915 is
more complicated, I have a hack that makes it decode to around 8 shades of grey instead - a result I don't

(Continue reading)

Marc MERLIN | 9 Aug 2012 07:47

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Wed, Aug 08, 2012 at 07:45:14AM +0200, Reimar Döffinger wrote:
> > Thats said, -vo xv and -vo gl look about the same to me and seem to take the
> > same amount of CPU.
> > Is -vo gl better somehow?
> 
> It has a lot more features. That may or may not matter for you.
> It does display the OSD and subtitles at full screen resolution instead
> of just the video resolution for example.
> It also is slightly more likely to have working vsync on a secondary
> display.
> Probably lots of small stuff I don't remember right now.

I wanted to thank you for that code.
I just switched from xv to gl on my mythtv, and I can now adjust colors,
tint, and brightness, and the tearing problems I had are gone.

Thanks,
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/

Carl Eugen Hoyos | 8 Aug 2012 09:48

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

Marc MERLIN <marc_mplayer <at> merlins.org> writes:

> > 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?

The packager of your MPlayer version intentionally compiled it with 
several hundred known regressions (that are not reproducible with 
MPlayer), some of them may be security relevant.
That is not necessarily connected to your problem (I don't know).

Carl Eugen

Ron Johnson | 8 Aug 2012 12:32

Picon

Packaged regressions

On 08/08/2012 02:48 AM, Carl Eugen Hoyos wrote:
[snip]
> The packager of your MPlayer version intentionally compiled it with
> several hundred known regressions (that are not reproducible with
> MPlayer), some of them may be security relevant.
> That is not necessarily connected to your problem (I don't know).
>

How can we enumerate them so as to question the packager?

--

-- 
If adults of legally sound mind must be told what foods they
are not allowed to buy, then those people are not competent
to choose (i.e. vote for) their own leaders.

Carl Eugen Hoyos | 8 Aug 2012 12:53

Picon

Re: Packaged regressions

Ron Johnson <ron.l.johnson <at> cox.net> writes:

> On 08/08/2012 02:48 AM, Carl Eugen Hoyos wrote:
> [snip]
> > The packager of your MPlayer version intentionally compiled it with
> > several hundred known regressions (that are not reproducible with
> > MPlayer), some of them may be security relevant.
> > That is not necessarily connected to your problem (I don't know).
> 
> How can we enumerate them so as to question the packager?

Enumerate the regressions or the packages?

Carl Eugen

Ron Johnson | 8 Aug 2012 12:56

Picon

Re: Packaged regressions

On 08/08/2012 05:53 AM, Carl Eugen Hoyos wrote:
> Ron Johnson <ron.l.johnson <at> cox.net> writes:
>
>> On 08/08/2012 02:48 AM, Carl Eugen Hoyos wrote:
>> [snip]
>>> The packager of your MPlayer version intentionally compiled it with
>>> several hundred known regressions (that are not reproducible with
>>> MPlayer), some of them may be security relevant.
>>> That is not necessarily connected to your problem (I don't know).
>>
>> How can we enumerate them so as to question the packager?
>
> Enumerate the regressions or the packages?
>

The regressions...

--

-- 
If adults of legally sound mind must be told what foods they
are not allowed to buy, then those people are not competent
to choose (i.e. vote for) their own leaders.

Carl Eugen Hoyos | 8 Aug 2012 22:13

Picon

Re: Packaged regressions

Ron Johnson <ron.l.johnson <at> cox.net> writes:

> 
> On 08/08/2012 02:48 AM, Carl Eugen Hoyos wrote:
> [snip]
> > The packager of your MPlayer version intentionally compiled it with
> > several hundred known regressions (that are not reproducible with
> > MPlayer), some of them may be security relevant.
> > That is not necessarily connected to your problem (I don't know).
> 
> How can we enumerate them so as to question the packager?

(I should have added that the Debian maintainers have repeatedly 
stated they do not care about such bugs, no matter if they are 
security relevant or not.)
As you probably know, FFmpeg is an integral part of the MPlayer 
source code, your version was compiled against one of FFmpeg's 
forks. This specific fork is known to contain several hundred 
regressions, some of them possibly security relevant.
Fortunately, you don't have to trust my word about this:
Simply test fixed bugs from the FFmpeg bug tracker with avconv, 
and open bugs from the fork's bug tracker with FFmpeg. 
(You can also test open bugs from the FFmpeg bug tracker with 
avconv and closed bugs from the fork's bug tracker with FFmpeg, 
but you will not get many interesting results.)
Also consider testing old open bugs from roundup, some are also 
only fixed in FFmpeg.

Of course, not every FFmpeg bug is reproducible with MPlayer, 
but many are.

(Continue reading)

Marc MERLIN | 9 Aug 2012 07:46

Re: Packaged regressions

On Wed, Aug 08, 2012 at 08:13:43PM +0000, Carl Eugen Hoyos wrote:
> (I should have added that the Debian maintainers have repeatedly 
> stated they do not care about such bugs, no matter if they are 
> security relevant or not.)
> As you probably know, FFmpeg is an integral part of the MPlayer 
> source code, your version was compiled against one of FFmpeg's 
> forks. This specific fork is known to contain several hundred 
> regressions, some of them possibly security relevant.
> Fortunately, you don't have to trust my word about this:
> Simply test fixed bugs from the FFmpeg bug tracker with avconv, 
> and open bugs from the fork's bug tracker with FFmpeg. 
> (You can also test open bugs from the FFmpeg bug tracker with 
> avconv and closed bugs from the fork's bug tracker with FFmpeg, 
> but you will not get many interesting results.)
> Also consider testing old open bugs from roundup, some are also 
> only fixed in FFmpeg.
> 
> Of course, not every FFmpeg bug is reproducible with MPlayer, 
> but many are.
> 
> Allow me to add that some people have repeatedly stated that 
> there is (at least) one severe regression in FFmpeg over the 
> mentioned fork; unfortunately, so far nobody was able to 
> explain what this regression is about or how it can be 
> reproduced.

Thank you for that info.

So I'm actually using the custom packages from Christian Marillat who has
doing a much better job than standard debian for maybe 10 years now?

(Continue reading)

Carl Eugen Hoyos | 9 Aug 2012 09:29

Picon

Re: Packaged regressions

Marc MERLIN <marc_mplayer <at> merlins.org> writes:

> Thank you for that info.
> 
> So I'm actually using the custom packages from Christian Marillat 
> who has doing a much better job than standard debian for maybe 
> 10 years now?
> 
> http://www.deb-multimedia.org/

Was the version on your desktop (E8400) really from marillat?
It did not look like a marillat version to me.

Carl Eugen

Reimar Döffinger | 7 Aug 2012 20:03

Picon

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Tue, Aug 07, 2012 at 08:59:55AM -0700, Marc MERLIN wrote:
> My HTPC has an intel GM35 which does not support libva/vaapi from what I was
> told.

Oh, and I forgot: No GPU I know of supports hardware-accelerated
decoding of 10-bit H.264, so no point in even thinking about
hardware-acceleration for that.

Carl Eugen Hoyos | 7 Aug 2012 20:24

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

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.)

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

Carl Eugen

Ron Johnson | 7 Aug 2012 20:28

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On 08/07/2012 10:59 AM, Marc MERLIN wrote:
> I thought it would be an FAQ, but some searching didn't turn anything up.
>
> My HTPC has an intel GM35 which does not support libva/vaapi from what I was
> told.
>
> The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 1080p 20MB/s
> encoded H264 mkv just isn't fast enough.
>
> I noticed that decoding is only done on one of the two CPUs. Is there a way
> to switch to a codec that can use both CPUs?
> If not, here's mplayer -v output if that helps. If there are other compile
> options I could use, or a different codec or video output I could force, let
> me know.
> (for instance, is 'xv' still my best output option?)
>
[snip]
>> VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar 420P 10-bit little-endian)
>> VO: [xv] 1920x1080 => 1920x1080 Planar YV12  [zoom]

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.

--

-- 
If adults of legally sound mind must be told what foods they
are not allowed to buy, then those people are not competent
to choose (i.e. vote for) their own leaders.

Reimar Döffinger | 7 Aug 2012 20:33

Picon

Picon

Re: minimal CPU requirement to play high bitrate 1080p video in software?

On Tue, Aug 07, 2012 at 01:28:53PM -0500, Ron Johnson wrote:
> On 08/07/2012 10:59 AM, Marc MERLIN wrote:
> >I thought it would be an FAQ, but some searching didn't turn anything up.
> >
> >My HTPC has an intel GM35 which does not support libva/vaapi from what I was
> >told.
> >
> >The CPU is a dual core duo 3Ghz (E8400) and playing 7MB/s 1080p 20MB/s
> >encoded H264 mkv just isn't fast enough.
> >
> >I noticed that decoding is only done on one of the two CPUs. Is there a way
> >to switch to a codec that can use both CPUs?
> >If not, here's mplayer -v output if that helps. If there are other compile
> >options I could use, or a different codec or video output I could force, let
> >me know.
> >(for instance, is 'xv' still my best output option?)
> >
> [snip]
> >>VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar 420P 10-bit little-endian)
> >>VO: [xv] 1920x1080 => 1920x1080 Planar YV12  [zoom]
> 
> 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.

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.

(Continue reading)

Return

Return to gmane.comp.video.mplayer.user.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane