On Sun, Jun 23, 2013 at 5:47 PM, Andy Furniss <adf.li...@gmail.com> wrote: > Ilia Mirkin wrote: >> >> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> >> --- >> >> These changes make MPEG2 I-frames generate the correct macroblock data (as >> compared to mplayer via xvmc). Other MPEG2 frames are still misparsed, and >> MPEG1 I-frames have some errors (but largely match up). > > > This messes up mpeg2 vdpau decode for my radeon - VDPAU_DRIVER=softpipe is > also affected (and then crashes after a few frames - but that's normal). > > xvmc is unaffected. > > Normally mpeg2 xvmc and vdpau decode look the same - almost right but not > quite. The same issues are visible with xvmc softpipe, so I don't think it's > hw.
Thanks for testing! Perhaps softpipe and radeon implement these stages inside of decode_macroblock? I'll take a look. My experience (while developing hardware-accel support for some nvidia cards) is that xvmc works flawlessly, and I'm just trying to adjust the vl/mpeg12 logic until the data it passes to decode_macroblock matches what mplayer passes through xvmc. However while this patch makes i-frames work, the rest don't. So if the decoding looks at all not-totally-broken for you with vdpau (and no hardware bitstream support), that might mean that there's some optional work passed to the decode_macroblock logic that doesn't happen with xvmc or something. I'll try to work out what's going on. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
