Re: [webkit-dev] Making sure the behavior of updating duration of HTMLMediaElement and MediaSource

[Peng (WebKit) Liu via webkit-dev]

Hi Yousuke,

I think WebKit’s behavior matches the spec.
The HTML5 spec says: “If no media data is available, then the attributes must 
return the Not-a-Number (NaN) value.” On the test page, there is no data 
appended to the media source, so there is no media data available for the video 
element.


Best regards
Peng

> On Dec 6, 2020, at 10:48 PM, Kimoto, Yousuke (SIE) via webkit-dev 
>  wrote:
> 
> Hi all,
> 
> I have a question about MediaSource's duration.
> 
> What is an expected result of "duration" after processing the following steps?
> 1) Creating HTMLMediaElement object.
> 2) Creating MediaSource object, which is set to the HTMLMediaElement of step 
> 1)
> 3) Updating MediaSource.duration with some numbers. (e.g. 10, 100 etc)
> 4) What does "duration" return?
> 
> The table below shows "duration" of HTMLMediaElement and MediaSource on web 
> browsers with the attached sample, and the results are different.
> (NOTE: the sample at the bottom of this mail is made as a part of LayoutTest 
> media-source.)
> 
>   |  HTMLMediaElement |  MediaSource |
> Chrome:   updated |updated   |
> Safari:NaN|updated   |
>GTK:NaN|updated   | *) MiniBrowser (GTK)
> Firefox: - |   -  | *) no durationchange event 
> happened.
> 
> Points:
> - Safari and GTK are the same results, it's natural because they use the same 
> implementation of "duration".
>   It doesn't update HMLMediaElement.duration because the HTMLMediaElement 
> object's readyState is HAVE_NOTHING.
> - Chrome updates HTMLMediaElement.duration and MediaSource.duration.
> - Firefox doesn't fire a "durationchange" event.
> 
> Could anyone can explain which behavior matches the W3C standards?
> 
> 
> 
> Reference:
> https://www.w3.org/TR/media-source/#duration-change-algorithm
> https://www.w3.org/TR/html51/semantics-embedded-content.html#durationChange
> 
> 
> Sample:
> 
> 
> 
>media-source-set-duration-before-append.html
>
>
>var source;
>function runTest() {
>findMediaElement();
>source = new MediaSource();
>waitForEventOn(source, 'sourceopen', sourceOpen);
>run('video.src = URL.createObjectURL(source)');
>}
>function sourceOpen() {
>waitForEventOn(video, 'durationchange', durationChange);
>run('source.duration = 10.0');
>}
> 
>function durationChange() {
>testExpected('source.duration', 10.0);
>testExpected('video.duration', 10.0);
>endTest();
>}
>
> 
> 
>
> 
> 
> 
> 
> Best Regards,
> 
> --
> Yousuke Kimoto
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reminder: include everything that you use in implementation files

[Peng (WebKit) Liu via webkit-dev]

Hi Brian,

Any way/option to turn off the unified build completely or partially in a local 
build? That would be very helpful for a developer to locally verify that header 
files are included correctly in a patch. Thanks!

Best regards
Peng

> On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
>  wrote:
> 
> Hello folks,
> 
> I'd like to remind everyone to please include what you use in .cpp,  .mm, and 
> other files. When reviewing patches, please
> ensure that new mentions of classes, structs, etc. within an implementation 
> file have a corresponding header include. 
> All of our headers have #pragma once, so there is no downside to being more 
> explicit.
> 
> I've been noticing an uptick in the number of unified sources-related build 
> failures. I can't remember the last nontrivial patch
> I wrote that did *not* include unrelated build fixes. Typically these 
> failures aren't found until EWS results come back, reducing developer 
> velocity.
> And obviosuly it's super annoying to encounter completely unrelated build 
> failures that must be nonetheless addressed.
> 
> Let's all do our part so that hacking on WebKit remains delightful.
> 
> Thanks,
> 
> Brian Burg (he/they)
>  WebKit Developer Experience
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev