W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

Re: Issue with updating/updateend

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Fri, 18 Apr 2014 00:59:12 +0200
Message-ID: <53505CC0.1040506@gmail.com>
To: Aaron Colwell <acolwell@google.com>
CC: "public-html-media@w3.org" <public-html-media@w3.org>

Le 17/04/2014 23:31, Aaron Colwell a écrit :
> On Thu, Apr 17, 2014 at 2:10 PM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>     What I mean here is that this API just does not work and can not,
>     unless I am proven incorrect, please answer "I still don't get the
>     rationale for 'updating' and why appendBuffer does not queue the
>     chunks by itself", first time I see a boolean against events,
>     looks very approximate, what's the use of this boolean in a stream
>     or promises context?
> This would force the UA to have to arbitrarily buffer an unlimited 
> amount of data.

Could you explain this please? The updating boolean can not stop the 
event loop, so data are coming, buffered, appended and apparently 
discarded at a certain point of time.

> The updating boolean is a form of backpressure.

Same question, how can this boolean be used for backpressure?

> SourceBuffer.appendBuffer() should always throw an exception if 
> updating is set to true.

Why can it not queue the chunk instead of throwing?

> Stream and Promises were not even available when the MSE 
> standardization process was started. The Stream API spec got rebooted 
> recently

Yes and I am part of the "reboot", and backpressure is still a kind of 
open issue while I have given my thoughts about this subject [1], this 
can not be solved with a boolean of course.

> so I don't think one can make a claim that converting to streams would 
> "just work". Unprefixed MSE implementations have been shipping for 
> quite some time and I don't think it makes sense at this point to 
> convert everything to Promises now. That would just create unnecessary 
> churn and pain for large existing deployments like YouTube, Netflix, 
> and others.

Maybe, streams for sure would help, now maybe I am missing a fundamental 
use of updating in this API, cf above questions.

>     And no I am not going to file a bug, just take the youtube player,
>     delay the chunks so the event loop breaks and you will see the
>     issue. You can continue ignoring, eluding, disconsidering it, that
>     will not solve it.
> I don't particularly care for this tone.

Me neither for yours.

> It doesn't make me want to help

I don't need help, just this API to work correctly.

> you especially if you are unwilling to provide a simple repro case 
> that helps isolate the problem you claim is occurring. Saying "just 
> take the youtube player" is not sufficient given that it is a massive 
> piece of JavaScript

It's a simple piece of js.

> and it isn't clear to me how to "delay the chunks" in the same way you 
> are doing it

I am not doing it, the network is, delaying chunks means you don't 
receive enough data and the event loop breaks.

> . If the problem is as fundamental as you claim, it should be trivial 
> for you to create some simple JavaScript to reproduce the problem. 
> Please try to be part of the solution and not simply complain.

I do not complain but taking time to report a potential problem and 
trying to solve it, now in the light of your answers I still don't know 
if we are facing a spec issue or a Chrome issue, I don't get the use of 
the updating boolean.

In order to avoid any misunderstanding, I would not be replying here 
late my time if I did not think there could be an issue,



[1] https://github.com/whatwg/streams/issues/13

> Aaron
>     Le 17/04/2014 20:16, Aaron Colwell a écrit :
>>     This is not a Chrome support channel. Please file a bug at
>>     http://crbug.com with a complete minimal repro attached and I can
>>     take a look.
>>     Aaron
>>     On Thu, Apr 17, 2014 at 10:46 AM, Aymeric Vitte
>>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>>         Insisting on this one, I spent quite a lot of time on this
>>         and it's still not working perfectly, maybe other
>>         implementations don't have the problem because they are not
>>         using a so small size of chunks and/or chunks are never
>>         delayed so the events chaining never stops.
>>         //on each chunk received do:
>>         append_buffer.push(chunk);
>>         //handle1
>>         if ((!source.updating)&&(append_buffer.length===1)) {
>>         source.appendBuffer(append_buffer.shift());
>>         }
>>         if (first_chunk) {
>>         source.addEventListener('updateend',function() {
>>                 //handle2
>>                 if (append_buffer.length) {
>>         source.appendBuffer(append_buffer.shift());
>>                 };
>>             });
>>         };
>>         This should work but it does not with Chrome, append_buffer
>>         reaches a size of 0, the last chunk is being appended, a new
>>         chunk is coming, updateend fires --> handle1 and handle2 can
>>         execute at the same time and append wrongly the same chunk.
>>         It's not supposed to be possible but this is what is
>>         happening, maybe related to concurrent access.
>>         A workaround is to maintain the events chaining by appending
>>         chunks of size 0 using a timeout, it's working most of the
>>         time but sometimes appending a chunk of size 0 fails too, for
>>         unknown reasons, on Chrome chrome:media-internals only says
>>         'decode error'.
>>         Specs issue or Chrome issue, I don't know, I still don't get
>>         the rationale for 'updating' and why appendBuffer does not
>>         queue the chunks by itself.
>>         Regards
>>         Aymeric
>>         Le 02/04/2014 22:46, Aymeric Vitte a écrit :
>>             The usual code is something like:
>>             if (!source.updating) {
>>             source.appendBuffer(append_buffer.shift());
>>             }
>>             if (first_chunk) {
>>             source.addEventListener('updateend',function() {
>>                     if (append_buffer.length) {
>>             source.appendBuffer(append_buffer.shift());
>>                     };
>>                 });
>>             };
>>             The use case is: chunks of 498 B and bandwidth rate of 1
>>             Mbps, and this does not work at all, at least with
>>             Chrome, it might be a Chrome issue and/or a spec issue.
>>             Because between two 'updateend' events, the 'updating'
>>             property can become false, therefore you can append a
>>             chunk at the wrong place, if your remove the first part
>>             of the code (or replace it by if (first_chunk)
>>             {source.append...}) then the buffer chaining can stop if
>>             for some reasons the chunks are delayed.
>>             With streams the problem will disappear, without streams
>>             there is a workaround, but as I mentionned in a previous
>>             post I don't find this behavior normal.
>>             Regards
>>             Aymeric
>>         -- 
>>         Peersm : http://www.peersm.com
>>         node-Tor : https://www.github.com/Ayms/node-Tor
>>         GitHub : https://www.github.com/Ayms
>     -- 
>     Peersm :http://www.peersm.com
>     node-Tor :https://www.github.com/Ayms/node-Tor
>     GitHub :https://www.github.com/Ayms

Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Received on Thursday, 17 April 2014 22:59:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:48 UTC