Re: poor video playback performace with radeon
On Mon, 2011-09-05 at 15:37 +0300, Taneli Vähäkangas wrote: On Sun, Sep 04, 2011 at 11:44:44PM +0300, Taneli Vähäkangas wrote: I made some changes that make it not fail for I and P pictures (B pictures still fail that assertion). After the changes, the video I noticed that the problem is (likely) not in the frame type (I/P/B). Many videos, even commercial DVD titles, seem to have mistakes in the bitstream. For example the default mplayer codec will complain ac-tex damaged (or something similar). If such a situation is detected, what should be done in vl_mpeg12_bitstream.c? You should probably discuss this on the mesa-dev mailing list, and make sure Christian König sees it. I suspect he doesn't read this list. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Wed, Aug 17, 2011 at 04:40:05PM -0400, Alex Deucher wrote:
Easiest is to checkout the mesa git tree and build/install mesa from
there. Then when you make changes, all you need to do is rebuild and
install, no restart required.
Ah, now I'm getting somewhere. This is much faster method.
The bitstream decoder was modified quite a lot recently. It fails
for me with the following:
vl_mpg12_bs_decode: Assertion `consumed = num_bytes' failed.
I made some changes that make it not fail for I and P pictures (B
pictures still fail that assertion). After the changes, the video
displays quite nicely, but there's slow unwanted drifting downwards
(looks like half a pixel every few frames). The patch I used is
at the end of the message, does it make any sense?
Cheers,
Taneli
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
index 936cf2c..35636f0 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
@@ -527,7 +527,7 @@ static struct vl_vlc_entry tbl_B4[1 6];
static struct vl_vlc_entry tbl_B9[1 9];
static struct vl_vlc_entry tbl_B10[1 11];
static struct vl_vlc_entry tbl_B11[1 2];
-static struct vl_vlc_entry tbl_B12[1 10];
+static struct vl_vlc_entry tbl_B12[1 9];
static struct vl_vlc_entry tbl_B13[1 10];
static struct dct_coeff tbl_B14_DC[1 17];
static struct dct_coeff tbl_B14_AC[1 17];
@@ -710,9 +710,6 @@ static INLINE void
decode_dct(struct vl_mpg12_bs *bs, struct pipe_mpeg12_macroblock *mb, int
scale)
{
static const unsigned blk2cc[] = { 0, 0, 0, 0, 1, 2 };
- static const struct vl_vlc_entry *blk2dcsize[] = {
- tbl_B12, tbl_B12, tbl_B12, tbl_B12, tbl_B13, tbl_B13
- };
bool intra = mb-macroblock_type PIPE_MPEG12_MB_TYPE_INTRA;
const struct dct_coeff *table = intra ? bs-intra_dct_tbl : tbl_B14_AC;
@@ -747,7 +744,12 @@ entry:
if (intra) {
unsigned cc = blk2cc[blk];
-unsigned size = vl_vlc_get_vlclbf(bs-vlc, blk2dcsize[blk], 10);
+unsigned size;
+if (cc == 0) {
+ size = vl_vlc_get_vlclbf(bs-vlc, tbl_B12, 9);
+} else {
+ size = vl_vlc_get_vlclbf(bs-vlc, tbl_B13, 10);
+}
if (size) {
int dct_diff = vl_vlc_get_uimsbf(bs-vlc, size);
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Sun, Sep 04, 2011 at 11:44:44PM +0300, Taneli Vähäkangas wrote: I made some changes that make it not fail for I and P pictures (B pictures still fail that assertion). After the changes, the video I noticed that the problem is (likely) not in the frame type (I/P/B). Many videos, even commercial DVD titles, seem to have mistakes in the bitstream. For example the default mplayer codec will complain ac-tex damaged (or something similar). If such a situation is detected, what should be done in vl_mpeg12_bitstream.c? Cheers, Taneli ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Wed, Aug 10, 2011 at 09:57:06AM -0400, Alex Deucher wrote: Yes, src/gallium/auxiliary/vl is the location of the code. It currently supports XvMC and VDPAU for mpeg1/2. I see. It works, but the output is quite buggy, and features are missing. Is this to be expected? I think something goes wrong when decoding macroblocks in P and B frames. Intra macroblocks and thus I frames are correct. The dimming of the image over time (with even zero motion vectors) might be explained by predictors being discarded at wrong spots, but I could not find fault in the code. I have no clue yet as to what might cause every second line to be dark, but am looking at frame/field and 4:2:0 and 4:2:2 differences. However, debugging is really slow. My current workflow is to plug my changes to the xorg-edgers mesa source packages and build the binaries again. This takes about 70 minutes, and requires X restart. There must be a faster/more convenient way (especially since my changes end up only in libgallium, not other dlls), how do other people hack this part of the tree? Cheers, Taneli ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Wed, Aug 17, 2011 at 4:36 PM, Taneli Vähäkangas taneli.vahakan...@cs.helsinki.fi wrote: On Wed, Aug 10, 2011 at 09:57:06AM -0400, Alex Deucher wrote: Yes, src/gallium/auxiliary/vl is the location of the code. It currently supports XvMC and VDPAU for mpeg1/2. I see. It works, but the output is quite buggy, and features are missing. Is this to be expected? Yes, it's still a work in process. I think something goes wrong when decoding macroblocks in P and B frames. Intra macroblocks and thus I frames are correct. The dimming of the image over time (with even zero motion vectors) might be explained by predictors being discarded at wrong spots, but I could not find fault in the code. I have no clue yet as to what might cause every second line to be dark, but am looking at frame/field and 4:2:0 and 4:2:2 differences. There are known issues with interlaces videos. However, debugging is really slow. My current workflow is to plug my changes to the xorg-edgers mesa source packages and build the binaries again. This takes about 70 minutes, and requires X restart. There must be a faster/more convenient way (especially since my changes end up only in libgallium, not other dlls), how do other people hack this part of the tree? Easiest is to checkout the mesa git tree and build/install mesa from there. Then when you make changes, all you need to do is rebuild and install, no restart required. Alex Cheers, Taneli ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Tue, Aug 09, 2011 at 09:45:01AM -0400, Alex Deucher wrote: There is initial shader based decoding for gallium drivers in the mesa git tree. At the moment it only supports MPEG1/2, but Christian is looking into support for newer codecs. Would that be the code in (master branch) src/gallium/auxiliary/vl? Is there a way to try out the mpeg2 decoding functionality, for example a version of mpeg2dec that uses this code? Considering I have Radeon HD 5450, which I think is R800, would it work in practice? On a quick glance it appears that this could be used to support XvBA once MPEG4 features are implemented, is that right? Would that require changes outside the vl/ directory? Where / what kind? Cheers, Taneli ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Wed, Aug 10, 2011 at 4:16 AM, Taneli Vähäkangas taneli.vahakan...@cs.helsinki.fi wrote: On Tue, Aug 09, 2011 at 09:45:01AM -0400, Alex Deucher wrote: There is initial shader based decoding for gallium drivers in the mesa git tree. At the moment it only supports MPEG1/2, but Christian is looking into support for newer codecs. Would that be the code in (master branch) src/gallium/auxiliary/vl? Is there a way to try out the mpeg2 decoding functionality, for example a version of mpeg2dec that uses this code? Considering I have Radeon HD 5450, which I think is R800, would it work in practice? Yes, src/gallium/auxiliary/vl is the location of the code. It currently supports XvMC and VDPAU for mpeg1/2. On a quick glance it appears that this could be used to support XvBA once MPEG4 features are implemented, is that right? Would that require changes outside the vl/ directory? Where / what kind? XvBA is the API for using the UVD hardware in the proprietary Linux catalyst driver. There are no plans to support that API in gallium at the moment, although someone could if they wanted. Mpeg4 support would be most easily added to the existing VDPAU code. Alex ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
Dear Taneli, On 08/08/2011 11:50 PM, Taneli Vähäkangas wrote: Hello. Watching 1080p 25fps mpeg4 video content (from a blu-ray disc) is not possible, the display rate is less than 10fps. (The AACS decryption of the content has been done separately off-line, before watching.) I have tried vlc, mplayer and ffplay, which all exhibit the same problem. Given the system specs below, I'm afraid this is nothing out of the ordinary. H.264 in 1080p generally is quite demanding to decode, and your somewhat dated CPU just might not be up to the task. I have this hardware (from lshw): product: Cedar PRO [Radeon HD 5450] product: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (more info available by request, I don't know what would be relevant) You should try to get your hands onto a build of mplayer with the multithreading decoding features of ffmpeg enabled. I'm not sure that will yield real-time decoding of your video source, but it should improve performance a bit nonetheless. I distantly recall ATI/AMD implementing some GPU video decode acceleration API in their proprietary BLOB drivers, but I'm not sure how (or if, with your card) you can use that. I'm running ubuntu natty and have open source xserver-xorg-video-ati driver from xorg-edgers PPA, version: 1:6.14.99+git20110801.104b2d7c-0ubuntu0sarvatt~natty The free drivers don't support video decoding with GPU hardware assistance yet. The best you can do is choose Xv or OpenGL as the video output method in your player software (`mplayer -vo vx` or `mplayer -vo gl`) and have your CPU work at actually decoding and rendering the video data to that accelerated overlay, but that's as far as it gets these days. [...] In general, the system is responsive and for example watching dvds, glxgears or xmoto fullscreen is very smooth. There are two monitors connected, and I'm using metacity as window manager. That is to be expected. Please keep me cc:d in replies as I'm not on the list. If this is the wrong forum, could you kindly point me to a better one. [...] I think we're doing just fine here :) You should look into the ffmpeg-mt and possibly mplayer2 projects to learn how and where to get an appropriate build of those programs for your distribution. Using that second processor core of your CPU should improve the situation quite a bit - if it's still not enough, you'll have to get a beefier machine if you don't want to wait for shader-based video decoding (or UVD) support in the free drivers. -- with best regards: - Johannes Truschnigg ( johan...@truschnigg.info ) www: http://johannes.truschnigg.info/ phone: +43 650 2 17 xmpp: johan...@truschnigg.info Please do not bother me with HTML-eMail or attachments. Thank you. signature.asc Description: OpenPGP digital signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
Hello. Thanks for your prompt reply. On Tue, Aug 09, 2011 at 08:35:27AM +0200, Johannes Truschnigg wrote: Given the system specs below, I'm afraid this is nothing out of the ordinary. H.264 in 1080p generally is quite demanding to decode, and your somewhat dated CPU just might not be up to the task. I'd like to use the GPU, it should be better suited for the task, right? You should try to get your hands onto a build of mplayer with the multithreading decoding features of ffmpeg enabled. I'm not sure that will yield real-time decoding of your video source, but it should improve performance a bit nonetheless. I'll take a look. I distantly recall ATI/AMD implementing some GPU video decode acceleration API in their proprietary BLOB drivers, but I'm not sure how (or if, with your card) you can use that. I'll check out -- but I prefer open source. The free drivers don't support video decoding with GPU hardware assistance yet. This, and this: have to get a beefier machine if you don't want to wait for shader-based video decoding (or UVD) support in the free drivers. How much effort is that? How can I help? Where do I start? I'm no stranger to driver development (in kernel), but have never worked with X.org (or even XFree86) code. Cheers, Taneli ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Tue, Aug 9, 2011 at 6:39 AM, Taneli Vähäkangas taneli.vahakan...@cs.helsinki.fi wrote: Hello. Thanks for your prompt reply. On Tue, Aug 09, 2011 at 08:35:27AM +0200, Johannes Truschnigg wrote: Given the system specs below, I'm afraid this is nothing out of the ordinary. H.264 in 1080p generally is quite demanding to decode, and your somewhat dated CPU just might not be up to the task. I'd like to use the GPU, it should be better suited for the task, right? You should try to get your hands onto a build of mplayer with the multithreading decoding features of ffmpeg enabled. I'm not sure that will yield real-time decoding of your video source, but it should improve performance a bit nonetheless. I'll take a look. I distantly recall ATI/AMD implementing some GPU video decode acceleration API in their proprietary BLOB drivers, but I'm not sure how (or if, with your card) you can use that. I'll check out -- but I prefer open source. The free drivers don't support video decoding with GPU hardware assistance yet. This, and this: have to get a beefier machine if you don't want to wait for shader-based video decoding (or UVD) support in the free drivers. How much effort is that? How can I help? Where do I start? I'm no stranger to driver development (in kernel), but have never worked with X.org (or even XFree86) code. There is initial shader based decoding for gallium drivers in the mesa git tree. At the moment it only supports MPEG1/2, but Christian is looking into support for newer codecs. Alex ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
