Bug 82255 - [VP2] Chroma planes are vertically stretched during VDPAU playback
Summary: [VP2] Chroma planes are vertically stretched during VDPAU playback
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-06 16:24 UTC by Emil Velikov
Modified: 2014-09-01 22:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
VDPAU_TRACE=1 vlc (113.17 KB, text/plain)
2014-08-06 16:24 UTC, Emil Velikov
Details
luma plane, top field (340.00 KB, application/octet-stream)
2014-08-10 17:55 UTC, Emil Velikov
Details
luma plane, bottom field (340.00 KB, application/octet-stream)
2014-08-10 17:55 UTC, Emil Velikov
Details
chroma plane, top field (85.00 KB, application/octet-stream)
2014-08-10 17:56 UTC, Emil Velikov
Details
chroma plane, bottom field (85.00 KB, application/octet-stream)
2014-08-10 17:56 UTC, Emil Velikov
Details
First frame, post vlVdpCopyNV12ToYV12(). (1020.00 KB, application/octet-stream)
2014-08-10 18:25 UTC, Emil Velikov
Details
First frame, post colorspace conversion, without interleaving (1020.00 KB, application/octet-stream)
2014-08-10 18:47 UTC, Emil Velikov
Details
dump vdpau texture data (1.16 KB, patch)
2014-09-01 12:57 UTC, Emil Velikov
Details | Splinter Review
Ilia's earlier patch (4.83 KB, patch)
2014-09-01 13:08 UTC, Emil Velikov
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Emil Velikov 2014-08-06 16:24:37 UTC
Created attachment 104158 [details]
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
Comment 1 Ilia Mirkin 2014-08-06 16:28:43 UTC
Without any actual investigation, this smells like a NV12 vs YV12 screwup.
Comment 2 Emil Velikov 2014-08-06 16:35:27 UTC
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
Comment 3 Ilia Mirkin 2014-08-06 16:39:00 UTC
(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...)
Comment 4 Emil Velikov 2014-08-07 10:40:17 UTC
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 :)
Comment 5 Emil Velikov 2014-08-10 17:55:07 UTC
Created attachment 104384 [details]
luma plane, top field
Comment 6 Emil Velikov 2014-08-10 17:55:41 UTC
Created attachment 104385 [details]
luma plane, bottom field
Comment 7 Emil Velikov 2014-08-10 17:56:02 UTC
Created attachment 104386 [details]
chroma plane, top field
Comment 8 Emil Velikov 2014-08-10 17:56:27 UTC
Created attachment 104387 [details]
chroma plane, bottom field
Comment 9 Emil Velikov 2014-08-10 17:58:04 UTC
As requested by Ilia, the above four are the raw data (unaltered by the ST ?) gathered from vlVdpVideoSurfaceGetBitsYCbCr(), prior to the colorspace conversion.
Comment 10 Emil Velikov 2014-08-10 18:25:56 UTC
Created attachment 104388 [details]
First frame, post vlVdpCopyNV12ToYV12().

Fetched at libvdpau_trace level. Result should be the same if done in mesa but I haven't checked.
Comment 11 Emil Velikov 2014-08-10 18:47:48 UTC
Created attachment 104390 [details]
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.
Comment 12 Ilia Mirkin 2014-09-01 06:50:28 UTC
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).
Comment 13 Emil Velikov 2014-09-01 12:57:55 UTC
Created attachment 105558 [details] [review]
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 :)
Comment 14 Emil Velikov 2014-09-01 13:08:30 UTC
Created attachment 105560 [details] [review]
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
...
Comment 15 Ilia Mirkin 2014-09-01 22:53:04 UTC
Should be resolved in git. Thanks for reporting + testing!


bug/show.html.tmpl processed on Jan 16, 2017 at 19:21:17.
(provided by the Example extension).