Well I'm linking this unrelated thing just for the lulz http://pastebin.com/1htuH2jX
But I have found that all the videos that appear to 'work' using the combination of VDPAU hardware decoding and xcb_xv as the vout display module only due so because the decoder profile is above the limits for the hardware's settings. Specifically, it appears my graphics card is rated in VDPAU up to h264 profile 4.2, while anything that is detected as being at level 5 or above will not use hardware acceleration with VDPAU. Other hardware acceleration options, like VA-API with X11, do attempt to decode videos above this level even if they're not fast enough to do so but they are also not affected by the bug that's the subject of this report. 'Ultrafast' output from x264 (using ffmpeg) is reported in vlc as being level 6. 'Format 18' in YouTube is reported as level 6 as well. The video sample reported as working attached to the original report shows up as level 51, meaning level 5.1, as it omits the decimal point for some reason. The larger YouTube videos that worked did so because they are level 5 or 5.1 as well. It's unclear whether the videos that are reported as being level 6 are shown as such incorrectly. I think I didn't bother to test all the options that the ultrafast preset in x264 uses, but I did notice that when playing a video output from the ultrafast preset, my 'GPU Utilization' as reported in the Nvidia X Server settings was high, whereas normally for VLC it isn't high. A quick summary, the hardware acceleration options in VLC mostly use the 'Video Engine Utilization', instead of the 'GPU Utilization'. In contrast, totem (which might be using ffmpeg plugins though) uses GPU Utilization, and no Video Engine Utilization at all. It might vary a bit depending on the options (the 'overlay output' and 'direct rendering' settings affect it too I think), but disabling hardware acceleration in VLC causes 'Video Engine Utilization' to go to zero, while GPU Utilization is unaffected and still significantly lower than totem. I think in this case, CPU use is higher than what totem uses but only a little. So vlc might be using the same options as totem when decoding and playing a video output from the ultrafast preset in x264, and it's possible this is a legitimate reason for it to be reported as level 6 in vlc's debug output. For videos that are reported as level 5, it's generally some predictable thing, like using more than 4096 macroblocks, or some combination of macroblocks and number of reference frames or framerate. None of these seem likely to apply to the 'ultrafast' preset or YouTube's format 18 (which are small videos, around 480x360, with a framerate of around 25) but it's possible the 'working' video attached to the original report is using a high number of reference frames. As a totally unrelated issue which should have its own bug report, there doesn't seem to be any way to avoid having VP9 videos display lots of bad frames when decoding is too slow, and it sort of seems like the VP9 decoder might only use one thread as CPU use does not go to maximum. Even with 'hurry up' for ffmpeg decoding, and 'drop late frames' and 'skip late frames' (even though it says it's for mpeg2 video) turned off, large-sized VP9/webm videos from YouTube still end up with problems when played on a slow computer, where frames degenerate into incorrectly-decoded output with no apparent visual relationship to the original video. ffmpeg's output of VP9 videos also sometimes has problems when viewed on vlc (in a different problem, the avconv fork of ffmpeg wasn't even able to copy VP9 videos into a new webm container without problems and repeated outputs having varying lengths) but I think that was an ffmpeg problem, not a vlc one. Ideally Google would help to fix bugs in software that doesn't deal with their codecs very well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1440254 Title: Recent update broke XVideo/XCB output for h264 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
