In Midori (+gstreamer, +alsa), when trying to watch an HTML5 video (e.g., http://camendesign.com/code/video_for_everybody/test.html), if the user has no access to /dev/snd/{control*,pcm*p}, playback doesn't start. If using ALSA configuration (~/.asoundrc) as follows: ctl.!default { type null } pcm.!default { type null } playback is blazing fast. "Playing" music files to null with ALSA is also blazing fast, so apparently, video playback depends on ALSA for synchronization, too. USE flags: www-client/midori-0.4.3: libnotify nls unique -doc -gnome net-libs/webkit-gtk-1.6.1-r301: gstreamer introspection spell webgl (-aqua) -coverage -debug -doc -jit -test media-plugins/gst-plugins-meta-0.10-r6: X a52 aac alsa dts dv dvd ffmpeg flac lame mms mp3 mpeg ogg theora v4l vorbis vpx wavpack xv -dvb (-esd) -musepack -mythtv -oss -pulseaudio -taglib -vcd
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.
