Video and audio troubles with onstage shell

[pci]

If there's a video (or audio) element in a presentation, and onstage.html is used, then the audio starts coming out as soon as the video comes on the "future" iframe - whilst the presenter is still talking through the previous slide!

Also because of the communication lag between "present" and "remote" a horrible echo appears when the video slide is reached.

I would suggest always having video/audio muted in "future" and having "present" muted when "remote" exists.

Currently all messaging is done through postMessage, so either something like a "MUTE" and "UNMUTE"message needs adding (if so this belongs in issue #17) or we can use javascript to break into the iframe and turn the audio off from onstage.html (but that seems slightly like taking a hammer to the problem!)

[hsablonniere]

I also thought about that when I did some testing on onstage, incremental and protocol. Since I don't use video (yet) I didn't point it but...

I think you're right Philip. This is a serious issue. I would be in favor of not playing the video at all and sending "STOP_CONTENT" instead of "MUTE". What do think ?

[pci]

I agree an API solution is probably the way to go. The problem is that if "STOP_CONTENT" is called at the beginning, the javascript still launches the video when the slide comes into focus. Even if "STOP_CONTENT" is called at each slide turn they'll probably be a gap where the video/audio plays.

We probably need a permanent message like "NO_VIDEOS". But I quite like seeing the video that's coming up (for example try the new style template.html) which is why I favor "MUTE", however it can lead to the computer running three videos at once!

[hsablonniere]

Humm, embarassing. Your making a point. I think this should be tested in real conditions or almost and see which is be best and usable solution.

I'm almost convinced... :p

[paulrouget]

By default, video and audio should autoplay. In some conditions (onstage) we don't want the autoplay. Not sure we want to use the protocol for that.

What if, in the URL, we add something like slides.html?autoplay=false?

[hsablonniere]

I'm not against URL parameters, I think even if we use that and not protocol it should be addressed in the same issue/branch.

Philip wanted muted videos, I don't really care on the point, do we wan't autoplay=false or mutemedias=true or anything else...

[pci]

Url parameters are fine by me.

My only reason for suggesting mute over not playing the video is to give the presenter a head's up on which video is on the next slide, as a large number of videos just start black. But I don't feel strongly on the point and in some situations you can have the computer trying to play 3 videos at once (bad for low end/mobile!). So maybe autoplay=false is the way to go.

It's probably good to have any potential URL parameters on the same wiki page as the API so people don't have to route around for all the information.

[hsablonniere]

You could use poster attribute which allow you to choose the thumbnail displayed to replace black screen.

I agree with you that playing 3 videos at once just for that is not a good idea.

I also agree on putting URL parameters in the same wiki page as the API.

[paulrouget]

yes, yes and yes. Go for it!

[hsablonniere]

I have a working test for template.

How do we handle this in onstage. Future should have autoplay=false but what about present and remote ? If we want to enable auto play on remote no problem but how do we disable it on present without reloading ? If it safe to assume that onstage users will always use the remote popup ? I'm not sure about that...

Can we handle this stuff in the same PR/branch as the new protocol ?

[pci]

er..... good point - URL parameters don't really switch on and off so well!

The only (very hacky) way I can think of doing switching through URL parameters would be to use the history API to append the hash, e.g. history.pushState(stateObj, "page 2", "foo.html#autoplay=false"); and then have the slides check the hash on every slide change! But this would lead to pretty opaque and easy to break code.

Are we back to proposing an API solution then?

[paulrouget]

No autoplay on present, even if remote is not opened yet.

[paulrouget]

I don't think autoplay ever needs to be toggled.

[hsablonniere]

Ok for me.

So autoplay=0 for present and future and default behaviour for remote.

I did some tests and 0/1 is better than true/false. It's easier to convert to real boolean than text values.

I'll create a branch and a PR this evening.

[pci]

Ok, was going to say I'll update the wiki page but I see it's already been done :)

[paulrouget]

@pci Can you please verify that it is fixed now?

[pci]

Quick work hubert, great stuff! I'll check it out tonight

[pci]

Seems to work brilliantly!

The "!!+" had me stumped for quite a while :) That's a very neat trick.

The wiki said the default for autoplay was 0 (ie not playing) so I've changed it over.

Very happy to close this bug, great work!

[hsablonniere]

Yeah nice reflex for the wiki, thx...

[paulrouget]

Thanks guys.

[hsablonniere]

About the !!+ : I hesitated but I thought keeping all kind of parameters as string would be simpler since they're passed by the URL.

The easiest or shortest way to have string to kinda boolean was using 0 and 1 and this double implicit conversion.

Maybe some explanations in the documentation would be helpful.