[Webkit-unassigned] [Bug 139813] [MSE] Implement per TrackBuffer buffered.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=139813

--- Comment #15 from Jer Noble <jer.noble at apple.com> ---
(In reply to comment #14)
> Failing test in this :
> https://build.webkit.org/results/
> Apple%20Yosemite%20Debug%20WK1%20%28Tests%29/r178455%20%281534%29/http/tests/
> media/media-source/mediasource-remove-actual.txt
> consist of 2 parts : mismatch of buffered, and DOMException.
> 
> Since I don't have any Mac around, I analyzed that file used to append:
> LayoutTests/http/tests/media/media-source/mp4/test.mp4
> 
> This file consists of 2 tracks:
> track 1: audio, 260 samples * 1024 duration / 44100 timescale = 6,037s
> track 2: video, 182 samples * 83 duration / 2500 timescale = 6.0424s
> 
> and there is initial duration from (moov.mvex.mehd duration 3622) /
> (moov.mvhd timescale 600) = 6,03666.
> 
> 
> * Mismatch buffered() part
> 
> It's the exact expected behavior after this patch, to use common
> intersection of ranges, which is 6.037, not 6.0424, so I believe that either
> this patch should should change `mediasource-util.js` "duration: 6.0424" to
> "duration: 6.037", or skip test and someone with Mac access would fix
> testcase later?
> I don't know how other tests will behave, my own mp4 parser doesn't handle
> trackId's yet.

I've had to modify those values (in mediasource-util.js) in the past, and it certainly seems reasonable to do so in this case.  Once you get another patch up, I can apply it and run them manually, and post the results.

> * Dom exception part
> 
> I'm not sure yet, but I suspect that this is because track2 extended
> duration to 6.042, and because of current "// FIXME: Re-number or update
> this section once" in streamEndedWithError() which reorders readystate
> change, setDurationInternal() uses buffered which was *not* extended to
> 'highest end time' (so 6.037, not 6.042) => calls setDurationinternal() with
> different old and new durations => sets updating to true =>
> "sourceBuffer.remove(1, 2);" has InvalidStateError, as it should wait for
> 'updateend'.

This is my understanding as well.

> This can be fixed by doing patch for that FIXME I mentioned (since that bug
> in spec already got resolved), but there could be perhaps check for is it
> safe to call remove?

I would opt for fixing the FIXME, rather than modifying the test in this case.

> Summing up, I'm not sure what should I do with this patch next. As for Jer
> Noble comment about nullifying buffered, instead of using additional flag -
> I'd like to change this in next patch with caching buffered for MediaSource. 
> 
> As I said I don't have Mac to properly change all those constants in test
> (like 1.029, 3.187, etc.) which probably will be off after this patch (so
> only changing segment duration to shorter version won't be enough).
> 
> 
> As a side note: I wonder shouldn't this be cleared in standard, because at
> the moment, when removal occurs, 'sourceended' being posted before
> 'updateend' seems wrong . I'd expect at 'sourceended' that if there was any
> removal it is done already, and updating is false, otherwise every user
> would have to add additional check before taking any action, for 'updating'
> which might or might not occur. I will probably ask this on W3 bugzila.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150115/cfd3f602/attachment-0002.html>