Bug 39309

I tried this again after seeing how much work has been committed to g3dvl
recently, but nothing changed. Now I also tried it with MPEG1 videos: instead of the wrong rendering it enters an infinite loop before drawing the first frame.

(In reply to comment #0)
> Created attachment 49216 [details]
> screenshot.png
> 
> See the attached screenshot. The colored parts of the noise somewhat resemble
> the movements that should be on the screen, but gradually everything fades into
> dark green in about 3 seconds. There are no error messages on the console.
> 
> The video file is a DVD .VOB (it's a tv show recorded with a dvd recorder box):
> MPEG-PS file format detected.
> VIDEO:  MPEG2  352x288  (aspect 2)  25.000 fps  9682.0 kbps (1210.2 kbyte/s)
> 
> llvmpipe is also totally wrong, but in a completely different way.

I found and old radeon 9600 a couple of weeks ago and saw the same as you with -vc ffmpeg12vdpau.

With todays gits drm,ddx,mesa and drm-core-next kernel it just crashes.

Testing just -vo vdpau with sw decode it works but crashes if the window is resized this happened before as well as today.

Attached are the gdb traces.

Created attachment 57412 [details]
vdpau decode gdb bt full

Created attachment 57413 [details]
vdpau display resize bt full

Comment on attachment 57412 [details]
vdpau decode gdb bt full

The decode crash is fixed now, probably by one of the u_blitter changes (well it worked with those as head).

It still renders 95% noise though.

I've just pushed another fix, which only should made a difference on R300 hardware.

So please try again, since I don't have any more working R300 hardware.

Christian.

(In reply to comment #6)
> I've just pushed another fix, which only should made a difference on R300
> hardware.
> 
> So please try again, since I don't have any more working R300 hardware.
> 
> Christian.

It doesn't change anything for me.

FWIW until recently softpipe gave the same sw decode resize crash, but a recent commit has changed that (it crashes differently without resize). I won't pollute this bug with details.

What is your preference for info like this now - should I start using the new vdpau list or file bugs or keep using the mesa list?

I just tested vdpau on my RV515 and the the videos are displayed mostly green, but I can see faint outlines of people and objects.  It's likely that there are bugs in the shader compiler that are being uncovered by vdpau.  I've already caught a couple over the past few weeks.  Is there some way to turn off some of the decoding features to make it easier to isolate where the problem is?

(In reply to comment #2)

> Testing just -vo vdpau with sw decode it works but crashes if the window is
> resized this happened before as well as today.

After playing with gdb, valgrind and VDPAU_TRACE=1 I think I know why this is happening now.

Mplayer is asking for video surfaces of a certain size but not checking what size was allocated as the spec says it should. Because npot textures are not enabled  for r300 video, this makes it more noticeable than r600 which for SD will allocate buffers with lines = requested.

This is not the case for HD, mplayer asking for 1920x1080 will get 1088 - but by luck or design it/ffmpeg seem to use buffers big enough. I have found an exception to this - raw yuv, so I can now crash r600 as well as r300.

Enabling npot for r300 makes it almost always work just as r600 does. Is there a reason it's disabled? It seems to be enabled for 3D but not video.

This is all with s/w decode - enabling npot doesn't help the decode problems.

Valgrind does throw r300 errors for decode, example below, but I don't think that fixing them will help as xvmc has none but still decodes junk.

==17289== Invalid write of size 1
==17289==    at 0x5E4DB86: r300_dsa_inject_stencilref (r300_state.c:664)
==17289==    by 0x5EB553D: blitter_restore_fragment_states (u_blitter.c:427)
==17289==    by 0x5EB78A6: util_blitter_copy_texture_view (u_blitter.c:1060)
==17289==    by 0x5E4074C: r300_resource_copy_region (r300_blit.c:580)
==17289==    by 0x5E3EB42: r300_texture_transfer_destroy (r300_transfer.c:71)
==17289==    by 0x5EC4A8A: u_transfer_destroy_vtbl (u_resource.c:41)
==17289==    by 0x5EEE288: vl_zscan_layout (vl_zscan.c:411)
==17289==    by 0x5EE1EAD: vl_create_mpeg12_decoder (vl_mpeg12_decoder.c:857)
==17289==    by 0x5EDF353: vl_create_decoder (vl_decoder.c:73)
==17289==    by 0x5E36575: vlVdpDecoderCreate (decode.c:92)
==17289==    by 0x80F94AC: create_vdp_decoder (vo_vdpau.c:598)
==17289==    by 0x80FB0DD: control (vo_vdpau.c:1115)
==17289==  Address 0x5c13220 is 40 bytes inside a block of size 184 free'd
==17289==    at 0x4022BD8: free (vg_replace_malloc.c:427)
==17289==    by 0x5E4DEDC: r300_delete_dsa_state (r300_state.c:692)
==17289==    by 0x5EE2750: vl_mpeg12_destroy (vl_mpeg12_decoder.c:413)
==17289==    by 0x5E36382: vlVdpDecoderDestroy (decode.c:137)
==17289==    by 0x80F944B: create_vdp_decoder (vo_vdpau.c:574)
==17289==    by 0x80FB0DD: control (vo_vdpau.c:1115)
==17289==    by 0x81771E3: query_format (vf_vo.c:145)
==17289==    by 0x8148B8B: mpcodecs_config_vo (vd.c:195)
==17289==    by 0x82185D8: init_vo (vd_ffmpeg.c:511)
==17289==    by 0x821A0C6: get_format (vd_ffmpeg.c:944)
==17289==    by 0x857B3F9: mpeg_get_pixelformat (mpeg12.c:1224)
==17289==    by 0x8580D81: decode_chunks (mpeg12.c:1326)

I've just tested Mesa -git containing the following commit:

commit eb024c74885778ab1ffa6dc590116959bb526c2e
Author: Christian König <deathsimple@vodafone.de>
Date:   Wed Jun 6 17:53:58 2012 +0200

    st/vdpau: fix YCbCr down/up-loads for buffers larger than requested
    
    When the video buffer turns out to be larger than
    requested by the application we shouldn't upload
    or download more data into / from it original requested.
    
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39309
    
    Signed-off-by: Christian König <deathsimple@vodafone.de>

My RV350 still decodes green noise, given the following command line:

$ LD_LIBRARY_PATH=/home/chris/local-mesa/lib/vdpau mplayer -vo vdpau -vc ffmpeg12vdpau /video/xine/DVB-MPEG2-CAPTURE.ts

Sorry, I should have written "partially fixes..". It only fixes the crash, not the playback problems.

Created attachment 67147 [details]
before r300g: fix colormask with non-BGRA formats

Created attachment 67148 [details]
after r300g: fix colormask with non-BGRA formats

(In reply to comment #11)
> Sorry, I should have written "partially fixes..". It only fixes the crash, not
> the playback problems.

Decode on a 9600 has just been improved slightly by mesa commit -

1e51d368eb5360378218217ff35731896f48512f
r300g: fix colormask with non-BGRA formats

See attached r300-vdpau-before.png and after.

VDPAU support has been removed and it's not very useful on these GPUs anyway.