- From: Hadar Weiss <hadar@peer5.com>
- Date: Fri, 30 Aug 2013 13:10:08 +0300
- To: "Igarashi, Tatsuya" <Tatsuya.Igarashi@jp.sony.com>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CAB6sZJnYGeXYWFD=sZUg+pvX5Hq-hqN+_nq-7mV4LcGU2bnN1A@mail.gmail.com>
>From our experience at Peer5, MSE doesn't change it state from 'ended' to 'open' upon seek. We played with that quite a bit, and decided eventually not to call EndOfStream at all. The experience on was inconsistent when user seeked to the end of the video, and without calling endOfStream we managed just fine. Maybe on current/future versions the behaviour is better though. We haven't checked that recently. Best, Hadar Weiss CTO, Peer5.com On Fri, Aug 30, 2013 at 12:33 PM, Igarashi, Tatsuya < Tatsuya.Igarashi@jp.sony.com> wrote: > Hi,**** > > ** ** > > I have a problem in the case of seeking from the end time position, i.e. > video.currentTime== video.duration. The following NOTE of EndOfStream() > descibles a very useful idea for the MPEG DASH and I use the > endOfStream(null) when all media segments are appended to the source > buffer. However this way does not allow to use the existing source buffer > as the seek algorithm since the ready state becomes from “open” to “ended” > by the endOFStream(null). I wonder that seeking from the end time position > should automatically change the readyState of the sourceBuffer from “ended” > to “open” if endOFStream() is called without an error. **** > > ** ** > > *NOTE* > > *This allows the duration to properly reflect the end of the appended > media segments. For example, if the duration was explicitly set to 10 > seconds and only media segments for 0 to 5 seconds were appended before > endOfStream() was called, then the duration will get updated to 5 seconds* > .**** > > ** ** > > Thank you.**** > > ** ** > > -***---***---***---***---***---***---***---***---***--***---***---***-**** > > Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)**** > > Information Technology Development Div, R&D Platform**** > > Sony Corporation**** > > ** ** >
Received on Friday, 30 August 2013 21:58:16 UTC