[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
** Changed in: vlc (Ubuntu) Status: New => Invalid -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
** Attachment added: "xcb_xv vout fails" https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+attachment/4365499/+files/notworking_%E5%B0%8F%E5%BC%BA%20www%20%5B%E5%8B%95%E9%AD%84%E5%BD%B1%E9%9F%B3%5D%20%5BXMjgxMjEwNzUy%5D.mp4 -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
It's working again. It happened after I was changing a few things in the UI, and restarting if I wasn't sure the changes would be applied without it (like "Always on top" required a restart). It's possible it might have somehow been related to trying various output methods, and pressing stop button then restarting again after each one (required to use a new output device). I did this even with output methods I expected not to work, such as DirectFB video output and GNU/Linux framebuffer output. But if this is a way to fix the problem if it occurs, I don't know how to replicate it. I had previously tried restarting Xorg, then restarting my computer, which hadn't fixed it. As this bug is not confirmed to consistently affect even a single user, it's not a high-priority bug. I don't know if it could possibly be relevant that I disabled my syslog and kern.log by changing write permissions due to low disk space; it seemed like after that, a USB wireless device would take longer to start working. It might be waiting for logging to timeout or something, and not sure if this could somehow affect video rendering too. (Pausing the rsyslogd daemon causes more problems than just making the logs unwriteable.) -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
I wish I could say it was still working. But either it stopped working, or I confused "X11 video output (XCB)" for "XVideo output (XCB)" because it was late. XVideo output (XCB), or xcb_xv, is not working for me for most h264 videos, and the things I speculated about in my last comment did not affect this (including re-enabling logging and restarting rsyslogd). It's not directly related to video quality or the h264 'level' or profile. I can play a 3840x2160 h264 dash video from Youtube with no audio, but a 1280x720 h264 dash video from the same source, with a creation date in its metadata of just 7 minutes before the other video, won't play and gives the same errors in debug as in the original report. VP9 and VP8 work fine, h265 seems to work fine, mpeg4 (divx tag) works fine, apparently mpeg2 doesn't work either. Some files with the 'wmv' suffix don't work, with the same error. -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
On a particular Youtube video, using the formats listed through "youtube-dl -F ", Formats 266 (2160p), 264 (1440p), 160 (144p), and 18 (360p with audio) are successfully opened by the xcb_xv vout display module. Formats 137 (1080p), 136 (720p), 135 (480p), 134 (360p), 133 (240p), and 22 (720p with audio and more keyframes) result in an error. With a different video, format 18 is the only h264 format that can be opened, out of 10 formats. Format 18 works for two other videos as well. Out of four videos with format 160 tested, two worked. So it's possible there is a consistent explanation for which videos can be displayed, and which ones can't, though it might not be entirely predictable. Most h264 files from Youtube that aren't format 18 can't be opened. Youtube does use different processes for some of its videos, resulting in different frames being showed from a 60-fps source video or not having a certain pattern of '~18 frames of motion followed by 12 frames of stillness', but the fact that 'newer' formats (as evidenced by the higher format number) worked in the first video tested could have been a coincidence. -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
It's looking hardware-related, and I apologize for not being able to provide more detailed information about the source of the problem earlier. Right now at least, changing hardware-accelerated coding fixes the problem. I have an Nvidia GeForce 9650M GT GPU, with Nvidia driver version 331.113. The first and default option for hardware decoding is VDPAU, and selecting a different option (VA-API video decoder via DRM, or via X11) or disabling it lets all h264 videos be played with the XVideo XCB display module. This is still different from a week or two ago though. After testing, I found that VA-API video decoder via X11 was crashing on a windows media video file, or I wouldn't see it as a problem if VDPAU isn't working. It would be easier for me to report problems properly if I knew to what extent they could depend on hardware. I don't know if my bugs for hardware decoding, output modules etc. are hardware specific. I also found that videos that have a resolution change, through h264_mp4toannexb, cause VLC to crash if it's using hardware decoding. This is a different bug, and bugs are supposed to reported separately, but~ 'VA-API video decoder via DRM' only works in this case because it's failing to find a hardware decoding module. The others crash with a segmentation fault after the second video. If the second video has audio, it plays the audio and then crashes when it's finished with VDPAU (which doesn't display the video that accompanies the audio, possibly only because of the bug in the original report). If it's VA-API via X11, it crashes immediately at the second video before playing any audio from it. I would upload a sample video if requested. This is the output from ffmpeg with -f concat -auto_convert 1, which inserts the h264_mp4toannexb bitstream filter to H.264 streams in MP4 format. If this is done without the -auto_convert option, vlc simply stops playing the file, or rewinds it if on loop, without crashing. -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
Just to explain the practical relevance, the only situation I could really think of where you would want to have multiple video streams playing at once in VLC is when you want to play multiple angles that were recorded of the same event at the same time. I discovered VLC did this by accident when combining a video that didn't have its original sound due to the copyrights being blocked by YouTube with a different video that did have sound. Instead of just playing one video stream in the main window, a second window opened with the video stream that started late. If you don't care about synchronization and resizing videos independently in the player, there would be no reason to do this. A home security system with multiple camera views, for example, could either combine videos into one or or just record them separately, and probably wouldn't be using VLC for live streaming of different angles. -- 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
[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264
tl;dr: You cannot use XVideo output via VDPAU decoder. If you want to use the VDPAU decoder, you really really should use the VDPAU output (or leave output to auto). Otherwise, use OpenGL. XVideo cannot handle picture buffer padding and subpicture blending and is generally considered deprecated by Xorg developers. Alternatively, disable VDPAU decoding. Sorry but this is wontfix as far as I am concerned. -- 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
