Bug 55470 – [Qt] Fix setting default volume issue when using gstreamer backend

• Status: RESOLVED
• Resolution: INVALID
• Component: Media

[Yi Shen]

Gstreamer's behaviour is thus:
    * Upon construction the default playbin gstreamer volume is always 100.
    * During media playback that volume will be changed by gstreamer to some previous volume. (the volume was successfully used previously,e.g. 50)

For MediaPlayerPrivateQt, it always tries to set the default volume to 100 as specified in HTML5 video spec. Since the Gstreamer back-end default volume is 100, calling setVolume(100) does nothing and no volume changing action is initiated. After start the playback, the volume changes to previous volume (e.g. 50)

QtMobility doesn't want to put a workaround to fix this issue, so I tried to put a workaround in MediaPlayerPrivateQt. (http://bugreports.qt.nokia.com/browse/QTMOBILITY-1319)

Any comments are welcome!

[Yi Shen]

Created attachment 84232 [details]
first try

[Alexis Menard (darktears)]

Comment on attachment 84232 [details]
first try

View in context: https://bugs.webkit.org/attachment.cgi?id=84232&action=review

> Source/WebCore/platform/graphics/qt/MediaPlayerPrivateQt.cpp:-52
> -

Not needed :)

[Yi Shen]

Created attachment 84260 [details]
updated with Alexis's suggestion

Thanks Alexis:)

[Alexis Menard (darktears)]

I asked Simon to look for me how behave the Gstreamer backend of WebKit. I couldn't find some workaround like this so I believe either it works so we need to figure out how we can do better or the bug is present too.

[Alexis Menard (darktears)]

It doesn't block QtWebKit 2.1.x because GStreamer is not used on Symbian.

[Alexis Menard (darktears)]

(In reply to comment #5)
> It doesn't block QtWebKit 2.1.x because GStreamer is not used on Symbian.

Or 2.1.x address some other platforms I'm not aware of?

[Yi Shen]

(In reply to comment #6)
> (In reply to comment #5)
> > It doesn't block QtWebKit 2.1.x because GStreamer is not used on Symbian.
> 
> Or 2.1.x address some other platforms I'm not aware of?

Alexis, you are right, this doesn't block 2.1.x :) I just want to fix it for Linux because it blocks some Layouttests on Linux.

[Simon Hausmann]

See also bug #54140 for a similar issue on the gstreamer side. It looks like the initial 1.0 volumen is safe to ignore (and ios seems to do the same).

[Alexis Menard (darktears)]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > It doesn't block QtWebKit 2.1.x because GStreamer is not used on Symbian.
> > 
> > Or 2.1.x address some other platforms I'm not aware of?
> 
> Alexis, you are right, this doesn't block 2.1.x :) I just want to fix it for Linux because it blocks some Layouttests on Linux.

Which layout tests? Because then I can look at them.

I think this bug is invalid for some reasons.

According to the spec :
http://www.w3.org/TR/html5/video.html

"The volume attribute must return the playback volume of any audio portions of the media element, in the range 0.0 (silent) to 1.0 (loudest). Initially, the volume must be 1.0, but user agents may remember the last set value across sessions, on a per-site basis or otherwise, so the volume may start at other values."

Which means that we are allowed to remember the last set value. It's not in theory wrong to let GStreamer set back the volume to the previous value. So the QtMultimedia "bug" is in fact is a behavior that we want. At least by not changing anything we follow the behavior of other GStreamer based app which will restore the latest successful value. I would say we should let it like it is for Linux.

Also what comfort me is that for GStreamer the system volume is always equal to the volume level of the loudest stream which means that we will always enforce the volume for the *entire* system to 100 at each time. I'd rather let it like it is.