Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

> On 7 Aug 2018, at 5:24 pm, Boris Zbarsky  wrote:
> 
> OK.  Do you have any signals at all from Safari and Edge?  Even just knowing 
> "not opposed in current form but no concrete plans to implement" would be 
> useful, compared to them suddenly coming back with requests for changes in 
> the spec.

I’ll enquire on that…

https://wpt.fyi/results/media-source/mediasource-changetype-play.html 

https://wpt.fyi/results/media-source/mediasource-changetype.html 


> 
>> Google’s main interest for this is for ad insertions unfortunately, a bit 
>> sad when there’s so much potential.
> 
> Does this make the ad insertion case better for our users in some way, at 
> least?

It makes it easier for the site.
They typically gets ads from ad suppliers with h264/aac content ; for YouTube 
that allows to easily insert them in their vp9/opus content without having to 
convert them…

So previously, you would have to either pause the current video element, create 
a new one, and set it as overlay, and once done tear everything done.

Now, everything can be done inline, much smoother transitions

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Boris Zbarsky]

On 8/7/18 6:21 AM, Jean-Yves Avenard wrote:

We have web-platform-tests for this feature which have landed… We know that 
YouTube intends to use this new functionality as soon as available.
http://w3c-test.org/media-source/mediasource-changetype.html
http://w3c-test.org/media-source/mediasource-changetype-play.html


Right, I meant tested against actual sites.


As far as test is concerned, limiting the type of codecs used was an artificial 
limitation to start with. So the core code involved has always been exercised 
since the MSE rearchitecture (which came with 42)


Great, thank you.


Chrome has it implemented behind a pref too, we haven’t discussed with others 
to determine their intention on that…


OK.  Do you have any signals at all from Safari and Edge?  Even just 
knowing "not opposed in current form but no concrete plans to implement" 
would be useful, compared to them suddenly coming back with requests for 
changes in the spec.



Google’s main interest for this is for ad insertions unfortunately, a bit sad 
when there’s so much potential.


Does this make the ad insertion case better for our users in some way, 
at least?



The implementation behind changeType followed several iterations to reach that 
point.


Ah, OK.  That makes sense.


I hope I answered all your questions.


Yes, thank you.  This sounds reasonable to ship without a pref at all 
(which is the actual proposal here, just so everyone is clear), 
especially if we are fairly sure that Safari and Edge won't end up 
objecting to the spec.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

> On 6 Aug 2018, at 10:30 pm, Boris Zbarsky  wrote:
> 
> On 8/6/18 5:37 AM, Jean-Yves Avenard wrote:
>> enable by default changeType method on MediaSource’s Source Buffer
> 
> To be clear, this is enabling by default on all channels, right?

yes

> 
>> The method has been availably since 61 behind the preference 
>> media.mediasource.experimental.enabled
> 
> But not default-enabled anywhere, so not much tested?

We have web-platform-tests for this feature which have landed… We know that 
YouTube intends to use this new functionality as soon as available.
http://w3c-test.org/media-source/mediasource-changetype.html
http://w3c-test.org/media-source/mediasource-changetype-play.html

As far as test is concerned, limiting the type of codecs used was an artificial 
limitation to start with. So the core code involved has always been exercised 
since the MSE rearchitecture (which came with 42)

> 
> How stable is the spec?

Stable I believe and unlikely to change again.
There’s a few “v2” MSE features in the pipeline, but they typically will 
require more work.

> 
> What is the status of implementation or interest in other browsers?

Chrome has it implemented behind a pref too, we haven’t discussed with others 
to determine their intention on that…
IMHO, it’s the most useful addition made to MSE since it first came out.
It will greatly improve adaptative quality streaming.
I’m fairly keen to see how AV1 can be used more easily that way (which 
otherwise would be limited to only the most powerful machines out there)

Google’s main interest for this is for ad insertions unfortunately, a bit sad 
when there’s so much potential.


> 
> What is the status of interest from authors?

Media Capabilities and changeType was the 2 most requested features by all 
content providers we’ve met this year.

> 
> Put another way, if we thought this was a safe change why did we have it off 
> by default to start with?  Were there substantive changes to the code since 
> 61 that prevented us from enabling by default before now?

The implementation behind changeType followed several iterations to reach that 
point. At which time the Chrome team and us agreed on the current definition.

I had put it behind a pref to start with as there were no specs at all defined 
for it. It was developed as a proof of concept, to show on what could be 
achieved and how easily it could be done.

Our MediaSource implementation and architecture had been conceived from the 
ground up with this capability in mind… So we were the first to implement it 
and it was done very quickly.

We then had a few back and forth meetings with the Chromium media team until we 
agreed (with compromises) on the final draft.

I hope I answered all your questions.

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Boris Zbarsky]

On 8/6/18 5:37 AM, Jean-Yves Avenard wrote:

enable by default changeType method on MediaSource’s Source Buffer


To be clear, this is enabling by default on all channels, right?


The method has been availably since 61 behind the preference 
media.mediasource.experimental.enabled


But not default-enabled anywhere, so not much tested?

How stable is the spec?

What is the status of implementation or interest in other browsers?

What is the status of interest from authors?

Put another way, if we thought this was a safe change why did we have it 
off by default to start with?  Were there substantive changes to the 
code since 61 that prevented us from enabling by default before now?


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

Hi

> On 6 Aug 2018, at 9:12 pm, Nils Ohlmeier  wrote:
> 
> Which version of Firefox are you planing to ship this?
> 
> Thanks
>  Nils


Sorry, my bad.

63.. The feature was introduced in 61.

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Nils Ohlmeier]

Which version of Firefox are you planing to ship this?

Thanks
  Nils

> On Aug 6, 2018, at 02:37, Jean-Yves Avenard  wrote:
> 
> Summary:
> 
> enable by default changeType method on MediaSource’s Source Buffer, allowing 
> to change content type (codecs and/or container) on the fly…
> The method has been availably since 61 behind the preference 
> media.mediasource.experimental.enabled
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1481166 
> 
> 
> Detail:
> 
> Up to now, when using Media Source Extension, you had to create a source 
> buffer of a specific type using the MediaSource.addSourceBuffer method, 
> providing the mime type describing the container and optionally the codec. 
> You could then no longer change the container nor the codec.
> 
> Comes changeType , it allows to mix different codec within the same video 
> element.
> One particular use case would be to use different codecs according to the 
> selected resolution.
> 
> Like using AV1 for the very low bitrate due to the exceptional performance of 
> AV1 there, and switch later to VP9 or H264 as they are a bit more friendly 
> resource-wise.
> 
> JY___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



signature.asc
Description: Message signed with OpenPGP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

Summary:

enable by default changeType method on MediaSource’s Source Buffer, allowing to 
change content type (codecs and/or container) on the fly…
The method has been availably since 61 behind the preference 
media.mediasource.experimental.enabled

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1481166 


Detail:

Up to now, when using Media Source Extension, you had to create a source buffer 
of a specific type using the MediaSource.addSourceBuffer method, providing the 
mime type describing the container and optionally the codec. You could then no 
longer change the container nor the codec.

Comes changeType , it allows to mix different codec within the same video 
element.
One particular use case would be to use different codecs according to the 
selected resolution.

Like using AV1 for the very low bitrate due to the exceptional performance of 
AV1 there, and switch later to VP9 or H264 as they are a bit more friendly 
resource-wise.

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform