| Summary: | Slow video playback with 40mbits mpeg2+vdpau | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Nathan-J. Hirschauer <nathanhi> |
| Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | mediainfo output of the video file | ||
(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. >> 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. (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. >> Ahh, I am using mplayer1.
Well, I also tried it with mplayer1 - The results are the same.
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. (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, (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. 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.
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.