Re: HME WG meeting minutes, Tue Aug 30

I landed a fix for #3662 (appendbuffer-quota-exceeded).
I'll produce new Chrome JSON now (with and without isobmff-support, on
tip-of-tree local build). These results won't be "filtered" vs
at-risk/removed features and won't include the interfaces.html sync to
current editor's draft that Jerry's working on.

On Thu, Sep 8, 2016 at 4:47 PM, Matt Wolenetz <wolenetz@google.com> wrote:

> That makes sense, Jerry - Chrome and FF were complying and firing load
> event earlier; the fix is to test when the tests are ready. If the lack of
> load event firing in Edge causes failures in the MSE IDL test, that would
> need to be fixed in Edge probably.
>
> Also, syncing interfaces.html to editor's draft of IDL makes sense. Please
> prepare a PR for that.
>
> On Thu, Sep 8, 2016 at 3:40 PM, Jerry Smith (WPT) <jdsmith@microsoft.com>
> wrote:
>
>> I don’t see any issue between the IDL test change and Edge.  It tells the
>> harness that the tests aren’t over until an explicit done is executed.
>> That prevents a quick load event from confusing the test.  Apparently only
>> Canary was setting the delay-the-load-event-flag to false on attachment,
>> and that was causing an earlier load that tripped the failure condition.
>> Edge doesn’t support this flag currently and so on this test at least
>> should be okay.  Correct?
>>
>>
>>
>> Is there any reason we don’t update the interface.html to reflect the
>> current editors draft?  That would eliminate the need for filtering on the
>> IDL test at least.  I’m willing to bug that change and create a PR.
>>
>>
>>
>> Jerry
>>
>>
>>
>> *From:* Matt Wolenetz [mailto:wolenetz@google.com]
>> *Sent:* Thursday, September 8, 2016 11:05 AM
>> *To:* Philippe Le Hégaret <plh@w3.org>
>> *Cc:* Jean-Yves Avenard <jyavenard@mozilla.com>; Paul Cotton <
>> Paul.Cotton@microsoft.com>; public-html-media@w3.org
>> *Subject:* Re: HME WG meeting minutes, Tue Aug 30
>>
>>
>>
>> Also, the IDL failures have been fixed by @tidoust (who made an excellent
>> find). The fix may expose issues in implementations which do not yet stop
>> delaying the load event immediately on attachment (Edge?).
>>
>>
>>
>> I'm working on addressing https://github.com/w3c/web-pla
>> tform-tests/issues/3662#issuecomment-245683923 (which, IIUC, FF is
>> failing or timing out against) as well as updating Chrome's results with a
>> tip-of-tree build for each of with-isobmff and without-isobmff support
>> today.
>>
>>
>>
>> Matt
>>
>>
>>
>> On Thu, Sep 8, 2016 at 11:03 AM, Philippe Le Hégaret <plh@w3.org> wrote:
>>
>>
>>
>> On 9/7/2016 11:27 PM, Jean-Yves Avenard wrote:
>>
>> Hi
>>
>> On 8 Sep 2016, at 5:03 AM, Philippe Le Hégaret <plh@w3.org> wrote:
>>
>> I regenerated test results and added a filter to eliminate
>> VideoPlaybackQuality and TrackDefault related:
>>    http://w3c.github.io/test-results/media-source/less-than-2.html
>>
>> We get a lot of errors on the idlharness tests which I'll look at as well.
>>
>> Philippe
>>
>> I’d love to know how you generate those reports, in particular the
>> Firefox results one.
>>
>> I used the online version of WPT
>> http://w3c-test.org/tools/runner/index.html
>>
>> with /media-source/
>>
>> using Firefox 51.0a1 (2016-09-08) (64-bit).
>>
>> I obtained http://w3c.github.io/test-results/media-source/FF51.json
>>
>> Because with the exception of any tracks related methods and the
>> VideoQuality::totalFrameDelay (which we will not add as we believe it
>> serves no purpose); all tests are PASS here using firefox 51.
>>
>> If you have the JSON file, I'm more than happy to replace mine with
>> yours. It's my preference in fact and I didn't think of asking you, sorry.
>>
>> It's highly possible I didn't set the proper flags when I ran the tests.
>> Just make sure you get the latest commits from WPT (or use the online
>> version).
>>
>> Philippe
>>
>>
>>
>
>