- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 15 Apr 2010 12:57:42 +1000
- To: raphael.troncy@eurecom.fr, Yves Lafon <ylafon@w3.org>
- Cc: Media Fragment <public-media-fragment@w3.org>
All, As per my action from yesterday's meeting, I've gone through the wiki page and made adjustments, see http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimension . All the test cases should now be covered. I've even made a drawing on a piece of paper to test that I've covered all possibilities. If there are no objections, I will include this in the next few days directly into the spec and update section 6.2. Cheers, Silvia. On Thu, Apr 15, 2010 at 12:21 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > All, in particular Yves, > > I just came across an interesting problem in our spec. > > In section 4.3.1 we have an example: > t=10, # => results in the time interval [10,end) > > But our production rule states: > npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( > "," npttime ) > > Making this a invalid specification. > > I don't think we want this, since there is not really a difference > between t=10 and t=10, > > Thus I suggest to adapt the production rule to: > npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( > "," npttime ) / ( npttime ",") > > Cheers, > Silvia. > > > On Wed, Apr 7, 2010 at 12:02 PM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> 2010/4/7 Raphaël Troncy <raphael.troncy@cwi.nl>: >>> >>>> 10, 11 and 12 have to be diversified based on whether a lies before or >>>> after the beginning of the media resource. In fact, we need to >>>> introduce something like s=start time and e=end time everywhere. Thus >>>> we need to adapt/introduce the following: >>>> >>>> no5: t=a,b with s<=a, a<b, b<=e => play a to b >>>> introduce no5a: t=a,b with a<s, a<b, s<b, b<=e => play s to b >>>> introduce no5b: t=a,b with a<s, a<b, b<s, b<=e => empty fragment >>>> (these include no6 now) >>>> >>>> no7: t=a,b with s<=a, a<b, a<e, b>e => play a to e >>>> no7a: t=a,b with a<s, a<b, a<e, b>e => play s to e >>>> no7b: t=a,b with a<b, a=>e, b>e => empty fragment >>>> (this last one includes no8 and no9) >>>> >>>> no10: t=a, with a>=s, a<e => play a to e >>>> no10a: t=a, with a<s, a<e => play s to e >>>> >>>> no14: t=,a with a>s, a< d => play s to a >>>> no14a: t=,a with a<=s, a<d => empty fragment >>> >>> OK, so for all these test cases, you assume fairly that the start time of a >>> media resource is not necessarily 0. Is this a frequent case? How many media >>> files out there have this property? >> >> It doesn't matter how many exist, but that this case can occur. Thus >> we have to cover it in the test case. >> >> >>>> Yup, listed above as a/b numbers and additional conditions to the ones >>>> in the existing list. Mostly related to missing out on defining the >>>> "start" time of the resource. >>> >>> I would add all these ones if the group feels it is necessary, i.e. there >>> _are_ videos that will fall in these cases. >> >> >> Yes, there definitely will be. The first media fragment server that >> provides media fragment queries will create such resources. As we >> encourage people to implement such services, we should also provide >> for the possibility that such files will exist. Even if only 0.1% of >> all files that now exist have that property. >> >> Cheers, >> Silvia. >> >
Received on Thursday, 15 April 2010 02:58:36 UTC