W3C home > Mailing lists > Public > public-html-media@w3.org > September 2013

RE: [MSE] Issue on seeking from the end time position

From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
Date: Thu, 5 Sep 2013 20:59:59 +0900
To: Aaron Colwell <acolwell@google.com>
CC: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <DAB1CC3FAB54D3438F667F8E7B7599A202158607AE9E@JPTKYXMS218.jp.sony.com>
Hi Aaron,

Since I saw this issue in both Chrome version 28.9.1500.95 and IE11 version 11.0.9431.181, it would not be a bug in the MSE implementations.

I think the seeking behavior is affected when the readyState became “ended” by endOfStream(null). The both implementations , i.e. the append() and the appendBuffer(), follows the spec as described in “3.5.4 prepare append algorithm”.  Would you confirm that the sourceBuffer is reopen by the methods and the “source open” event is fired in the case of seeking ? If it is a right behavior, I can manage to address my issue. Also, it would be nice if there is a NOTE at “2.4.3 Seeking”

In the case that endOfStream() is not invoked but video.currentTime becomes equal to video.duration, the video.ended became true but the event of “ended” was not fired. I think that this is a bug of implementation. Right?  I will file the bug.
vide
Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation




From: Aaron Colwell [mailto:acolwell@google.com]
Sent: Wednesday, September 04, 2013 12:23 AM
To: Igarashi, Tatsuya
Cc: public-html-media@w3.org
Subject: Re: [MSE] Issue on seeking from the end time position

Hi,

This sounds like a bug in the MSE implementation. I'm assuming you are seeing this in Chrome, so please file a bug at http://crbug.com/ . Please include the version of Chrome, a simple page that reproduces the problem, and assign the Cr-Internals-Media-Source label to the bug.

Further discussion of this particular issue should probably not happen on this list. The seeking behavior should not be effected by where the seek was initiated from. The steps in the spec outline what the proper behavior should be, if Chrome isn't following the spec in this case, then we'll fix the implementation. Thanks for bringing the issue to my attention.

Aaron

On Sun, Sep 1, 2013 at 10:30 PM, Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>> wrote:
Thanks, Aaron.

The problem which I observed on seeking from the end time position is as follows;


1.     On seek event,  the web application invokes appendBuffer() to add the data at the new position.

2.     The prepare append algorithm described 3.5.4 runs. At step 3, the sub-steps reopen the source Buffer because the readyState of the mediaSource is “ended” by the endOfStream(null).

3.     The event of “sourceopen” is fired  and it seems to clear the currentTime state of the media element object and it cannot resume the seek algorithm as normal seeking.

I tried to resolve this issue by storing the currentTime on seek event and the web application resumes the seeking by itself.  But I think that it is better if the normal seeking steps described in 2.3.4 can run even in the case of the endOfStream(null) is invoked. So, I wonder that seeking from the end time position should change the currentState from “ended” to “open”.

You said that the transition from “ended” to “open” should only happen if the application appends more data. Does the transition described in the step 3 of the prepare append algorithm ?  Does the transition assume this case of seeking from the end time position ?

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation



From: Aaron Colwell [mailto:acolwell@google.com<mailto:acolwell@google.com>]
Sent: Friday, August 30, 2013 11:41 PM

To: Igarashi, Tatsuya
Cc: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: Re: [MSE] Issue on seeking from the end time position

I'm not sure I understand the problem you are having. The MediaSource.readyState being "ended" should not effect seekability. You should be able to seek whether the readyState is "open" or "ended". Why do you think there needs to be a transition from "ended" to "open"? I think this transition should only happen if the application appends more data, which is what the current spec says should happen.

Please provide more details so I can better understand the issue you are having.

Aaron

On Fri, Aug 30, 2013 at 2:33 AM, Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com<mailto: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<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation



Received on Thursday, 5 September 2013 12:00:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:01 UTC