Bug 50618 - Slow video playback with 40mbits mpeg2+vdpau
Summary: Slow video playback with 40mbits mpeg2+vdpau
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-02 09:21 UTC by Nathan-J. Hirschauer
Modified: 2013-11-25 14:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
mediainfo output of the video file (2.92 KB, text/plain)
2012-06-02 09:21 UTC, Nathan-J. Hirschauer
Details

Description Nathan-J. Hirschauer 2012-06-02 09:21:14 UTC
Created attachment 62425 [details]
mediainfo output of the video file

When playing an MPEG2-video with high bitrate (>40 MBps) on my Mobility Radeon HD 3450 (best graphics card EVER! :3) with VDPAU I get very low framerates when using hardware video decoding, cpu decoding is fine, here a quick comparison (no -benchmark results because mplayer did something weird there):

The mediainfo output of the video file is attached to the bug report.

CPU usages with different mplayer parameters:

mplayer without vdpau: MPlayer: 44,7%; Xorg: 12,8% -> Runs fine, 26fps

mplayer -vo vdpau: MPlayer: 43,4%, Xorg: 12,6% -> Runs also file, 26fps

mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% (**** Your system is too SLOW to play this!  ****) -> Too slow! 1-10 fps

You may contact me via IRC (freenode, #radeon -> nathanhi) for the video file. I'm using mesa from git (git-775ba11), Xorg 1.12.1.902, xf86-video-ati git-c1b9b2c, libdrm git-481234f and Kernel 3.3.7.
Comment 1 Andy Furniss 2012-06-02 11:33:15 UTC
(In reply to comment #0)


> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% (**** Your
> system is too SLOW to play this!  ****) -> Too slow! 1-10 fps

I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws an unknown vdpau parameter for me.

FWIW R600 + -vc ffmpeg12vdpau doesn't quite produce perfect output anyway. There are some cumulative errors that build between I frames. Depending on content and how close you look they may or may not be obvioius.
Comment 2 Nathan-J. Hirschauer 2012-06-02 12:06:12 UTC
>> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% (**** Your
>> system is too SLOW to play this!  ****) -> Too slow! 1-10 fps
>
> I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws an
> unknown vdpau parameter for me.

-vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you using mplayer1 or 2?

Source: man mplayer2:

fps=<number>
Override autodetected display refresh rate value (the value is needed for framedrop to allow video playback rates  higher  than
                      display refresh rate, and for vsync-aware frame timing adjustments).  Default 0 means use autodetected value.  A positive value
                      is interpreted as a refresh rate in Hz and overrides the autodetected value.  A negative value disables all  timing  adjustment
                      and framedrop logic.
Comment 3 Andy Furniss 2012-06-02 13:29:04 UTC
(In reply to comment #2)
> >> mplayer -vo vdpau:fps=-1 -vc ffmpeg12vdpau: MPlayer: 14%, Xorg: 6,3% (**** Your
> >> system is too SLOW to play this!  ****) -> Too slow! 1-10 fps
> >
> > I am curious what -vo vdpau:fps=-1 means. Using svn mplayer that just throws an
> > unknown vdpau parameter for me.
> 
> -vo vdpau:fps=-1 disables all framedrop logic and timing adjustments. Are you
> using mplayer1 or 2?

Ahh, I am using mplayer1.

Maybe trying with that would be worth a go - or maybe 40mbit is just too much for onboard GPU.

I use a "real card" so even if 40mbit worked for me, it wouldn't mean anything for you I guess.

I'll make one and try soon - AFK for tonight.
Comment 4 Nathan-J. Hirschauer 2012-06-02 14:15:58 UTC
>> Ahh, I am using mplayer1.

Well, I also tried it with mplayer1 - The results are the same.
Comment 5 Christian König 2012-06-03 03:58:12 UTC
Those integrated chipsets like IGPs and APUs current don't have a full power management implementation. So they are running with whatever is the (very slow) default speed the BIOS is programming at boot.

Alex is working on advanced power management, so I'm not so deep into it, but AFAIK this should be improving in the near future.

Also it is not limited to MPEG2 decoding with the 3D engine, 3D in general is far to slow on those chipsets.

Christian.
Comment 6 Pasi Kärkkäinen 2012-06-04 03:18:50 UTC
(In reply to comment #5)
> Those integrated chipsets like IGPs and APUs current don't have a full power
> management implementation. So they are running with whatever is the (very slow)
> default speed the BIOS is programming at boot.
> 

Uhm.. at least my Mobility Radeon HD3650 runs very *hot* as a default.. so hot that most/many liveCD Linux distros crash before the computer boots to the desktop. Or then Linux does emergency thermal shutdown halfway the boot sequence as a safety measure.. 

The default radeon driver power_profile ("default") seems to be broken at least on this graphics card. When I manually switch to power_profile "low" the temperature of the laptop goes down 10-20 degrees celsius.

> Alex is working on advanced power management, so I'm not so deep into it, but
> AFAIK this should be improving in the near future.
> 

Oh, this is good news. Any more info about it? 

Thanks,
Comment 7 Andy Furniss 2012-06-04 03:39:30 UTC
(In reply to comment #3)

> I use a "real card" so even if 40mbit worked for me, it wouldn't mean anything
> for you I guess.
> 
> I'll make one and try soon - AFK for tonight.

I tried and there doesn't seem any problem for me with 42mbit.

For me using GPU will only beat CPU in a benchmark if I pretend I have a low clock single core.

mpeg2 decode on x86 CPUs is well optimised - maybe mplayer2 used threads by default, but whatever if have >1 core and use them I don't think you will ever beat s/w decode with your GPU.
Comment 8 Christian König 2013-11-25 14:28:15 UTC
Since DPM is available for a while now I think we can close this bug.

Any objections?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.