Bug 748747
| Summary: | Gstreamer-based apps don't display video when using software 3D rendering (clutter involved) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||
| Component: | mesa | Assignee: | Adam Jackson <ajax> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 16 | CC: | adel.gadllah, ajax, awilliam, bnocera, jdulaney, renault, tflink, xgarve | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | mesa-7.11-8.fc16 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-10-29 06:30:47 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 713568 | ||||||||
| Attachments: |
|
||||||||
|
Description
Kamil Páral
2011-10-25 09:14:42 UTC
Proposing as blocker: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" Using bare metal machine and forced fallback mode (with nouveau driver), totem playback works. Using bare metal machine and xdriver=vesa nomodeset kernel options, totem playback doesn't work, same symptoms as in KVM. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Note that this also affects Cheese (you can't see video from your webcam) and Empathy (video chat fails) that we've discovered. It's less of a straight-up obvious blocker than it was when everything was crashing, but still a big issue. I'm kind of on the fence over its blockeriness. Other votes? (In reply to comment #4) > Note that this also affects Cheese (you can't see video from your webcam) and > Empathy (video chat fails) that we've discovered. > > It's less of a straight-up obvious blocker than it was when everything was > crashing, but still a big issue. I'm kind of on the fence over its > blockeriness. Other votes? There is only a cosmetic difference between "crashes" and "does not work" ... for the user the result is the same "can't use the software". So not sure what your point is. So if the old bug is a blocker this one is as well. I'm pretty much in the same boat Adam is on this one. Definitely +1 NTH but I'm not as sure about delaying release because videos don't play w/ mesa Do we have any idea how hard this would be to fix? adel: the difference is cosmetic in the case of totem (although not entirely so, as you can at least use it to play music now), but it isn't in the case of empathy: before, empathy was entirely unusable, now, only video chat is broken. +1 blocker "Boot in safe graphics mode" uses vesa driver, and therefore this issue will be encountered every time user boots in safe graphics mode. I have seen countless systems myself where the only option to boot is to use safe graphics mode. Sometimes people even work in it for some time. Graphic drivers are a big pain in Linux. Unless this takes too long to fix for some reason, I vote +1 blocker (which implies +1 nth if blocker is not accepted). (In reply to comment #7) > adel: the difference is cosmetic in the case of totem (although not entirely > so, as you can at least use it to play music now), Yeah but its primary use is playing videos. > but it isn't in the case of > empathy: before, empathy was entirely unusable, now, only video chat is broken. Indeed. Cheese otoh is completely broken as well. I'm less interested in Cheese in a virtual machine. And it's worth pointing out that this does not seem to affect baremetal installs. So what we need to do is figure out whether this is a bug in the X driver in the guest, or in qemu itself.
Two things to test:
If you take a screenshot inside the guest while playing a video in totem (run gnome-screenshot(1) for instance), does the screenshot show the video correctly?
If using the vesa or cirrus drivers in the guest, does the behaviour differ if you enable ShadowFB in xorg.conf? Example:
Section "Device"
Identifier "vesa"
Driver "vesa"
Option "ShadowFB" "on"
EndSection
"And it's worth pointing out that this does not seem to affect baremetal installs." Yes, it does. We've already tested that and reported as much: "Using bare metal machine and xdriver=vesa nomodeset kernel options, totem playback doesn't work, same symptoms as in KVM." Bare metal with a native driver in fallback mode works, but then, it would be odd if it didn't. The fact that you're using fallback mode alone doesn't mean your hardware 3D magically stops working. But if you use bare metal in a config where there's no hardware 3D, you hit this bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 530521 [details] screenshot inside VM of totem playing video I did a fresh x86_64 install of F16 in a VM. When I take a screenshot inside the VM while a video is running, the part of the screen that is supposed to show the video is black. When I enable ShadowFB for vesa as requested in comment 11, I get the same results - audio but the part of the screen containing the video part is black. (In reply to comment #12) > "And it's worth pointing > out that this does not seem to affect baremetal installs." > > Yes, it does. We've already tested that and reported as much: Odd, could have sworn it worked on the machine I tested this on. For me it failed the same way it did for Tim, booting to vesa. I'll test with nouveau.noaccel, for giggles. with nouveau.noaccel, same fail. so it does seem like it just doesn't work unless you have 3D acceleration. Ok, I decided to test for this, and I'm hitting this with nouveau.noaccel as well as vesa on both of my bare metal test boxen. Oddly enough, I will also occasionally (probably 3 or 4% of the time) on my remaining F15 box (unless that's something else). Of course, my F15 box is kept up-to-date. I'm +1 for blocker. BTW, when video on F15 acts up, restarting the X server seems to fix it. taking a shot at mesa, this is not a totem bug. Comedy. clutter's using GLX_INTEL_swap_event now (and more power to it), which we enabled for both proper DRI2 drivers that can support it and for llvmpipe where we can't. Oops. mesa-7.11-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mesa-7.11-8.fc16 Fix looks good: I can play video in totem and record video and pictures from cheese when using qxl, nouveau or vesa. Playback of Big Buck Bunny OGG is a bit messy - garbage in the letterboxes, and it's a bit jerky - but it works. mesa-7.11-8.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. Hi. Maybe this helps you: http://www.fedoraforum.org/forum/showthread.php?t=271942 "Probably unrelated but my totem and rhythmbox weren't working due to a gstreamer problem. I fixed it by deleting my .gstreamer-0.10 directory in home." This solved everything for me. that has nothing at all to do with this bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |