[media-source] Confusing duration change consequences and inconsistent outcome for user agents.

jyavenard has just created a new issue for 
https://github.com/w3c/media-source:

== Confusing duration change consequences and inconsistent outcome for
 user agents. ==
In the updated spec, we have:
http://w3c.github.io/media-source/#duration-change-algorithm

> "5. If a user agent is unable to partially render audio frames or 
text cues that start before and end after the duration, then run the 
following steps:
> Note
> 
> This condition can occur because the coded frame removal algorithm 
preserves audio frames and text cues that start before and end after 
the duration.
> 
>     1. Update new duration to the highest end time reported by the 
buffered attribute across all SourceBuffer objects in sourceBuffers.
>     2. Update duration to new duration.
> "

I'll explain the issue with an example. Assuming we have a video 
sourcebuffer with the following 3 samples:
[0,2)[2,4)[4,6)

if we call remove with the arguments (3, 6), the resulting 
sourcebuffer will now contain:
[0,2)[2,4)

as a sample is only removed as : "Remove all media data, from this 
track buffer, that contain starting timestamps greater than or equal 
to start and less than the remove end timestamp." (from Coded Frame 
Removal)

The sample [2,4) isn't truncated.

When setting duration to 3 however, if the usage agent is able to 
partially render audio frames, then the resulting duration will stay 
3.
However, for a user agent enable to partially render audio frames, the
 duration will now be 

> "Update new duration to the highest end time reported by the 
buffered attribute across all SourceBuffer objects in sourceBuffers."

so duration for those user agents will be 4 instead.

Both type of user agents will have a buffered range of [0,4), yet one 
has a duration of 3 and the other 4 (which is even more confusing as 
we do not have to worry about audio frames here)

I don't believe that there is anything in the spec, indicating that 
playback would have to stop once currentTime reaches duration; on the 
contrary:
https://w3c.github.io/html/semantics-embedded-content.html#offsets-into-the-media-resource

> "The duration attribute must return the time of the end of the media
 resource, in seconds, on the media timeline. ".

When played, that last sample will update the duration, in which case 
once playback has ended we would have a final duration = 4.

As such, I believe that 

> "5.If a user agent is unable to partially render audio frames or 
text cues that start before and end after the duration, then run the 
following steps" should be removed to ensure consistency across user 
agents. Step 4 "Update duration to new duration."

 would need to be removed.

Additionally, as side effects of those steps that change the duration 
to what was originally set.
if you do:
mediaSource.duration = 3;
mediaSource.duration = 3;

as in both cases the duration was actually set to 4, the first step of
 the duration change algorithm 

> "1. If the current value of duration is equal to new duration, then 
return."

will always be false; and the durationchange event will be fired twice
 (this issue arised in the web-platform-test 
media-source/mediasource-duration.html which specifically check that 
durationchange event is not fired when setting the duration to the 
same value multiple times in a row).

As a workaround for this issue, I suggest that in the final step, 
prior "Update the media duration to new duration and run the 
HTMLMediaElement duration change algorithm."

we do: "If the value of old duration is equal to new duration, then 
return."
This will ensure that no durationchange event will be fired.


Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/124 using your GitHub 
account

Received on Saturday, 16 July 2016 02:21:56 UTC