[whatwg] Volume and Mute feedback on <video>

[Ian Hickson]

On Mon, 31 May 2010, Silvia Pfeiffer wrote:
> 
> I just came across a curious situation in the spec: IIUC, it seems the 
> @volume and @muted attributes are only IDL attributes and not content 
> attributes. This means that an author who is creating an audio-visual 
> Webpage has to use JavaScript to turn down (or up) the loudness of their 
> media elements or mute them rather than just being able to specify this 
> through content attributes.

What is the use case for overriding the user's defaults in this way?

I guess I could see a use case for muting (e.g. video ads often start 
off muted), but declaring the default volume seems very strange.


> However, if I have multiple videos on a page, all on autoplay, it would 
> be nice to turn off the sound of all of them without JavaScript. With 
> all the new CSS3 functionality, I can, for example, build a spinning 
> cube of video elements that are on autoplay or a marquee of videos on 
> autoplay - all of which would require muting the videos to be bearable. 
> If we added @muted to the content attributes, it would be easy to set 
> the muted state without having to write any JavaScript.

I guess that could make sense.

Would we want to make .muted simply reflect the content attribute, so 
that the user enabling/disabling muting changes how the DOM is serialised? 
Or would we go for another attribute, say mute="", as the default, and 
have the IDL attribute be set by that attribute when loading, and then be 
independent of it? The latter seems better I guess.


> As for the @volume attribute, I think it would be similarly useful if an 
> author could control the loudness at which a video or audio file starts 
> playing back, in particular if he/she knows it is actually a fairly 
> loud/quiet file.

Given that the default is 1.0 (the loudest setting), it would only really 
let authors make things quieter. It's not clear that there are that many 
use cases for that.


On Mon, 31 May 2010, bjartur wrote:
>
> If you need the audio to be muted you should use CSS. If you need to 
> control volume dynamically you need scripting.

I don't know that I'd agree with that really. It's not purely 
presentational -- the concept applies regardless of how the video is 
presented, so long as it has an audio component.

(Note that CSS3 Speech doesn't apply here, since that's specifically for 
audio browsers, not for screen browsers that happen to play audio.)


On Tue, 1 Jun 2010, Alex Bishop wrote:
> 
> A less esoteric use case is videos in advertisements, which often begin 
> to play as soon as the ad loads but remain silent until the user 
> explicitly chooses to enable sound (the theory being that the motion of 
> the video will pique the user's interest and compel them to switch on 
> the audio).
> 
> If there were a muted content attribute, such a video could be inserted 
> into an ad using code as simple as this:
> 
> <video src="buystuff" autoplay loop muted></video>
> 
> (In most cases, script would probably be used to allow the user to 
> enable sound but it's possible that the ad might rely on the 
> user-agent's own controls for this.)

You'd have to include the controls="" attribute for that, but yes, indeed.


On Wed, 9 Jun 2010, Kevin Marks wrote:
>
> Setting volume above 1.0 can be very useful if the original is too 
> quiet. For example, Quicktime allows a volume of 300% to amplify quiet 
> tracks

On Thu, 10 Jun 2010, Silvia Pfeiffer wrote:
>
> I don't think that is possible in the way that the volume attribute is 
> currently defined as a value between [0;1]. That is an orthogonal, but 
> still important question about the volume attribute then.

On Thu, 10 Jun 2010, Ashley Sheridan wrote:
> 
> Or you could just raise the volume of the audio track itself. I think 
> being able to raise the volume like this (beyond 100% of what it is) 
> with script just makes it something more likely to be abused (think how 
> the TV adverts always seem twice as loud as the programs they surround) 
> and so will end up getting blocked more often.

Yeah.


On Thu, 10 Jun 2010, Silvia Pfeiffer wrote:
>
> That requires editing the resource. Think about it from a process
> point-of-view: you're a Web developer and have been given a set of media
> resources to put on a Website. As you put it all together, you notice that
> the volume of the different files is different and thus playing them back
> next to each other will create a very confusing user experience. Do you
> really want to shoot the files back to the production to adjust the volume
> settings so they are all similar? If you're under time pressure, you'd
> probably much prefer just setting a volume attribute on each so they all
> play back with the same level.

What if you notice that each file uses different fonts for titles, or each 
video is colour-corrected differently, or uses a different lens, or has a 
different aspect ratio, or four are filmed during the day and one during 
the night and the latter one really stands out in a bad way? I don't think 
we should assume that just because we can do post-processing in the 
client, it's the right thing to do. :-)


On Wed, 9 Jun 2010, Hay (Husky) wrote:
>
> i'm currently building a Javascript based interface for the <video> 
> element. One of the things that really seem to be lacking from the 
> specification (and hence, browsers too) is a distinct 'muted' event that 
> occurs whenever you set the muted property to 'true' or 'false'. Of 
> course, the 'volumechange' event occurs, but that also happens whenever 
> you set the volume so you have to check every time the event occurs if 
> it originated from a change on the volume or muted property. Because 
> these two capabilities of the <video> element have different properties, 
> it seems to make sense to let them trigger different events too (or have 
> the muted property trigger 'volumechange' as well).

Yeah, this is a trade-off. We wanted to have one event that fired for 
both, because otherwise it's easy to make UI that fails to take into 
account that there are two things going on. But we also didn't want to 
fire multiple events per change, because that makes it really easy to end 
up in a situation where by the time you receive the event, the current 
situation has changed (since the events get queued). I'm not sure what the 
best situation is. I intend to look at how people use onvolumechange over 
the next year or so and see how much trouble this is causing.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'