Am 24.06.2013 18:39, schrieb Ilia Mirkin:
On Mon, Jun 24, 2013 at 4:48 AM, Christian König
<deathsim...@vodafone.de> wrote:
Am 23.06.2013 18:59, schrieb Ilia Mirkin:

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

NAK, zscan and mismatch handling are handled in vl/vl_zscan.c.

Please use/fix that one instead of adding another implementation.
Yes, I noticed these after Andy pointed out that my patch broke things
for him. Here's my situation, perhaps you can advise on how to
proceed:

NVIDIA VP2 hardware (NV84-NV96, NVA0) doesn't do bitstream parsing,
but it can take the macroblocks and render them. When I use my
implementation with xvmc, everything works fine. If I try to use vdpau
by using vl_mpeg12_bitstream to parse the bitstream, the data comes
out all wrong. It appears that decode_macroblock is called with data
before inverse z-scan and quantization, while mplayer pushes data to
xvmc after those steps. So should I basically have a bit of logic in
my decode_macroblock impl that says "if using mpeg12_bitstream then do
some more work on this data"? Or what data should decode_macroblock
expect to receive?

Yes exactly, for the bitstream case decode_macroblock gets the blocks in original zscan order without mismatch correction or quantification.

You can either do the missing steps on the gpu with shaders or on the cpu while uploading the data and use the entrypoint member on the decoder to distinct between the different usecases.

Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to