Nouveau - Aug 2014 - [Bug 82255] New: [VP2] Chroma planes are vertically stretched during VDPAU playback

https://bugs.freedesktop.org/show_bug.cgi?id=82255

          Priority: medium
            Bug ID: 82255
          Assignee: nouveau at lists.freedesktop.org
           Summary: [VP2] Chroma planes are vertically stretched during
                    VDPAU playback
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: emil.l.velikov at gmail.com
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: Drivers/DRI/nouveau
           Product: Mesa

Created attachment 104158
  --> https://bugs.freedesktop.org/attachment.cgi?id=104158&action=edit
VDPAU_TRACE=1 vlc

Using VLC and flashplayer causes h264 video streams to be incorrectly rendered.
Both chroma planes are stretched and wrapped over vertically (x2) while the
luma plane seems correct.

Note: the issue does not appear with every h264 encoded clip and never happens
with mplayer (a bug in mplayer perhaps ?).


The following clip [1] is known to exhibit the issue, attaching VDPAU_TRACE=1
log of VLC playback.


How to enable/force VLC (v2.1.5) + VDPAU:
 - Fire up VLC
 - Navigate to Tools>Preferences>Input/Codecs
 - Set "Hardware-accelerated decoding to VDPAU.
 - Save and play a video.

If VDPAU is seemingly unused by VLC (high CPU usage), check the VLC log:
 - Navigate to Tools>Messages
 - Change the Verbosity level to "2(debug)". Elapsed events/messages
with
higher level are not stored, as such you will need to restart playback.

Last minute update:
Interesting... seem like for every h264 clip that I can find, VLC exhibits this
problem. I have a sneaky suspicion that VLC is using xcb_xv for presentation,
which could have something to do with all this.


-Emil


[1] "Fantastic Four: Rise of the Silver Surfer ? 720p Trailer" from
http://www.h264info.com/clips.html

http://downloads.dvdloc8.com/trailers/divxdigest/fantastic_four_rise_of_the_silver_surfer-trailer.zip

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140806/b0f28868/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Without any actual investigation, this smells like a NV12 vs YV12 screwup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140806/d6fb0cad/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #2 from Emil Velikov <emil.l.velikov at gmail.com> ---
A quick look at the log:

 - VLC always creates/opens multiple vpdau devices (offending flashplayer does
the same).
 - VLC does not seem to render/present via VDPAU.

vdp_decoder_create
vdp_video_surface_create

vdp_decoder_render
vdp_video_surface_get_bits_y_cb_cr
vdp_decoder_render
....

vdp_video_surface_destroy
vdp_decoder_destroy

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140806/ec0962fa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #2)
> A quick look at the log:
> 
>  - VLC always creates/opens multiple vpdau devices (offending flashplayer
> does the same).
>  - VLC does not seem to render/present via VDPAU.
> 
> vdp_decoder_create
> vdp_video_surface_create
> 
> vdp_decoder_render
> vdp_video_surface_get_bits_y_cb_cr
> vdp_decoder_render
> ....
> 
> vdp_video_surface_destroy
> vdp_decoder_destroy
OK, so it's only using vdpau for decoding, not for displaying. Could be that
the get_bits_y_cb_cr thing is messed up (and/or I didn't set enough bits on
the
vp2 surfaces to make it not mess up...)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140806/074dfc15/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #4 from Emil Velikov <emil.l.velikov at gmail.com> ---
A couple of interesting bits:

The surface produced by the vdpau state-tracker is exactly the same one
displayed on the screen - there seems to be no nv12 <> yv12 screw-up in
VLC.
On the other hand the vlVdpCopyNV12ToYV12 function, converts the original data,
based on the assumption that both fields are interleaved while it seems that
they are both continuous one after the other. The other two conversion
functions follow the same field 0 and 1 (top+bottom ?) are interleaved.

All of them are added with commit e6c2afa9ceacc188690deba9da7b46bf1a0a9027
(st/vdpau: add format conversions for GetBitsYCbCr) with VLC in mind :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140807/f5ee5f12/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #5 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104384
  --> https://bugs.freedesktop.org/attachment.cgi?id=104384&action=edit
luma plane, top field

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/54af9448/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #6 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104385
  --> https://bugs.freedesktop.org/attachment.cgi?id=104385&action=edit
luma plane, bottom field

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/12c7e992/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #7 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104386
  --> https://bugs.freedesktop.org/attachment.cgi?id=104386&action=edit
chroma plane, top field

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/a65529b3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #8 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104387
  --> https://bugs.freedesktop.org/attachment.cgi?id=104387&action=edit
chroma plane, bottom field

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/51c75ad0/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #9 from Emil Velikov <emil.l.velikov at gmail.com> ---
As requested by Ilia, the above four are the raw data (unaltered by the ST ?)
gathered from vlVdpVideoSurfaceGetBitsYCbCr(), prior to the colorspace
conversion.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/eff85375/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

Emil Velikov <emil.l.velikov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #104384|text/plain                  |application/octet-stream
          mime type|                            |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/c912f2da/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #10 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104388
  --> https://bugs.freedesktop.org/attachment.cgi?id=104388&action=edit
First frame, post vlVdpCopyNV12ToYV12().

Fetched at libvdpau_trace level. Result should be the same if done in mesa but
I haven't checked.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/976280b7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #11 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 104390
  --> https://bugs.freedesktop.org/attachment.cgi?id=104390&action=edit
First frame, post colorspace conversion, without interleaving

vlVdpCopyNV12ToYV12 interleaves the top and bottom field of the chroma plane
during conversion. If one hacks around it, the attached (almost good) frame is
produced.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140810/305cd056/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
The source data is messed up. Just look at the luma/chroma planes that you
captured.

The overall image is 1280x544. Which means that each field is 1280x272. And
chroma would be 640x136

These look great:
gm display -size 1280x272 gray:sv0-texture0
gm display -size 1280x272 gray:sv0-texture1

These... don't:
gm display -size 640x136 gray:sv1-texture0
gm display -size 640x136 gray:sv1-texture1

Note that texture1 has *some* stuff in it... and trying to display it as

gm display -size 1280x68 gray:sv1-texture1

Shows *some* stuff, but not that much. Of course, vdpau *generally speaking*
works on vp2, so it's highly unlikely that the decoding step is entirely
broken. It must be some bit of sampler view setup, I guess.

I'm also guessing that you somehow messed up capturing the contents of the
chroma since it should have had 2 components, not 1 (which is probably why the
1280 stride works out for the chroma image that has something in it).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140901/a0dad9fe/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #13 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 105558
  --> https://bugs.freedesktop.org/attachment.cgi?id=105558&action=edit
dump vdpau texture data

(In reply to comment #12)
> The source data is messed up. Just look at the luma/chroma planes that you
> captured.
> 
> The overall image is 1280x544. Which means that each field is 1280x272. And
> chroma would be 640x136
> 
> These look great:
> gm display -size 1280x272 gray:sv0-texture0
> gm display -size 1280x272 gray:sv0-texture1
> 
> These... don't:
> gm display -size 640x136 gray:sv1-texture0
> gm display -size 640x136 gray:sv1-texture1
> 
> Note that texture1 has *some* stuff in it... and trying to display it as
> 
> gm display -size 1280x68 gray:sv1-texture1
> 
> Shows *some* stuff, but not that much. Of course, vdpau *generally
speaking*
> works on vp2, so it's highly unlikely that the decoding step is
entirely
> broken. It must be some bit of sampler view setup, I guess.
> 
Never said that's it's entirely broken. Pardon if it came out like that
:)
> I'm also guessing that you somehow messed up capturing the contents of
the
> chroma since it should have had 2 components, not 1 (which is probably why
> the 1280 stride works out for the chroma image that has something in it).
>
Feel free to point out how I should capture them. The patch used can be found
in the attachment :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140901/d149e632/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

--- Comment #14 from Emil Velikov <emil.l.velikov at gmail.com> ---
Created attachment 105560
  --> https://bugs.freedesktop.org/attachment.cgi?id=105560&action=edit
Ilia's earlier patch

The patch that you've linked earlier on IRC works like a champ for both vlc
and
flashplayer. Thanks !!!

Both of program still cause some dmesg spam, perhaps caused due to the multiple
(guessing two but could be more) vdpau instances, leading to concurrency issues
? I feel that one is unrelated to the original report though :\

VLC

DATA_ERROR INVALID_BITFIELD
ch 4 [0x003f92e000 vlc[17648]] subc 3 class 0x8297 mthd 0x0200 data 0x00007fc1
trapped write at 0x00901c78c0 on channel 0x0003f92e [vlc[17648]]
PGRAPH/PROP/RT0 reason: PT_NOT_PRESENT
DATA_ERROR INVALID_BITFIELD
TRAP_PROP - TP 0 - RT_FAULT - Address 00901c78c0
TRAP_PROP - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00000000, e20: 00001100,
e24: 00030000
TRAP_PROP - TP 1 - RT_FAULT - Address 00901c7900
TRAP_PROP - TP 1 - e0c: 00000000, e18: 00000000, e1c: 00000010, e20: 00001100,
e24: 00030000
ch 4 [0x003f92e000 vlc[17648]] subc 3 class 0x8297 mthd 0x0200 data 0x00007fc1
trapped write at 0x00901c8500 on channel 0x0003f92e [vlc[17648]]
PGRAPH/PROP/RT0 reason: PT_NOT_PRESENT
DATA_ERROR INVALID_BITFIELD
TRAP_PROP - TP 0 - RT_FAULT - Address 00901c8c80
TRAP_PROP - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00130030, e20: 00001100,
e24: 00030000
TRAP_PROP - TP 1 - RT_FAULT - Address 00901c9a80
...


flashplayer

DATA_ERROR INVALID_VALUE
ch 4 [0x003f92e000 plugin-containe[17913]] subc 3 class 0x8297 mthd 0x0204 data
0x000e6008
DATA_ERROR INVALID_VALUE
TRAP_PROP - TP 0 - RT_LINEAR_MISMATCH - Address 0000000000
TRAP_PROP - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00000000, e20: 00001100,
e24: 0002007a
TRAP_PROP - TP 1 - RT_LINEAR_MISMATCH - Address 0000000000
TRAP_PROP - TP 1 - e0c: 00000000, e18: 00000000, e1c: 00000010, e20: 00001100,
e24: 0002007a
ch 4 [0x003f92e000 plugin-containe[17913]] subc 3 class 0x8297 mthd 0x0204 data
0x006b7008
DATA_ERROR INVALID_VALUE
ch 4 [0x003f92e000 plugin-containe[17913]] subc 3 class 0x8297 mthd 0x0204 data
0x00d6f008
TRAP_PROP - TP 0 - RT_FAULT - Address 00000e6000
TRAP_PROP - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00000000, e20: 00001100,
e24: 00030000
TRAP_PROP - TP 1 - RT_FAULT - Address 00000e6040
TRAP_PROP - TP 1 - e0c: 00000000, e18: 00000000, e1c: 00000010, e20: 00001100,
e24: 00030000
...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140901/5d297be9/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=82255

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Should be resolved in git. Thanks for reporting + testing!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140901/5f74b5b6/attachment.html>