| Summary: | net-libs/webkit-gtk-1.6.1-r301 [gstreamer[alsa]] in www-client/midori-0.4.3: HTML5 video playback depends on ALSA device availability | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maxim Kammerer <mk> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | gstreamer, xfce |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Maxim Kammerer
2012-02-16 13:17:58 UTC
Sorry, I don't see a problem mentioned yet... Seems to be as designed. Well, in case of no access to /dev/snd/*, I would expect the sound to be muted during video playback, instead of complete failure of HTML5 video plugin. Same with using null ALSA output (in which case video playback doesn't fail, but plays too fast, somehow tied to the instantaneous speed of ALSA output). Midori upstream doesn't believe this is a Midori problem, rather GStreamer or webkit-gtk: 14:07 <+kalikiana> ssuominen: do other gstreamer apps like parole or totem work with that setup? then it's webkit, otherwise gstreamer media-video/totem-2.32.0-r2 works fine after disabling access to /dev/snd/* After disabling access to /dev/snd/* in the same manner, Midori fails to show video. After downloading big_buck_bunny.webm manually, Totem plays it fine. Situation in Epiphany 3.2.1: * if no access to /dev/snd/*, failure of HTML5 video plugin (same as with Midori) * null ALSA output -> CPU 100% (in Midori, playback is too fast, see above). Will be interesting to test this with webkit-1.8 (once it's added to the tree) and report to bugs.webkit.org if still valid (In reply to comment #7) > Will be interesting to test this with webkit-1.8 (once it's added to the > tree) and report to bugs.webkit.org if still valid 1.8 is now in Portage. Any chance the original reporter could retest? Will need to report upstream bug tracking system if the problem continues. (In reply to comment #8) > (In reply to comment #7) > > Will be interesting to test this with webkit-1.8 (once it's added to the > > tree) and report to bugs.webkit.org if still valid > > 1.8 is now in Portage. Any chance the original reporter could retest? Will > need to report upstream bug tracking system if the problem continues. (In reply to comment #8) > 1.8 is now in Portage. Any chance the original reporter could retest? Will > need to report upstream bug tracking system if the problem continues. With webkit-gtk-1.8.3-r300 + epiphany-3.2.1, same problem: * if no access to /dev/snd/*, failure of HTML5 video plugin (In reply to comment #10) > (In reply to comment #8) > > 1.8 is now in Portage. Any chance the original reporter could retest? Will > > need to report upstream bug tracking system if the problem continues. > > With webkit-gtk-1.8.3-r300 + epiphany-3.2.1, same problem: > > * if no access to /dev/snd/*, failure of HTML5 video plugin This needs to be reported to upstream then -> bugs.webkit.org To try to narrow down the issue, what happens if user has no access to /dev/snd/* when using playing a video file from shell: $ gst-launch-0.10 playbin2 uri=file:///somevideo.avi If the problem is not seen, then it should probably be forwarded to webkit upstream after checking with webkit-1.10/1.11. (In reply to comment #12) > To try to narrow down the issue, what happens if user has no access to > /dev/snd/* when using playing a video file from shell: > $ gst-launch-0.10 playbin2 uri=file:///somevideo.avi > > If the problem is not seen, then it should probably be forwarded to webkit > upstream after checking with webkit-1.10/1.11. |
