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
Without any actual investigation, this smells like a NV12 vs YV12 screwup.
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
(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...)
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 :)
Created attachment 104384 [details] luma plane, top field
Created attachment 104385 [details] luma plane, bottom field
Created attachment 104386 [details] chroma plane, top field
Created attachment 104387 [details] chroma plane, bottom field
As requested by Ilia, the above four are the raw data (unaltered by the ST ?) gathered from vlVdpVideoSurfaceGetBitsYCbCr(), prior to the colorspace conversion.
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.
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.
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).
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 :)
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 ...
Should be resolved in git. Thanks for reporting + testing!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.