Re: ACTION-158: Exhaustive list of Test Cases for the temporal dimension in the Media Fragment URI

OK, I have taken another shot at this and since I got no feedback
tried to include it into the specification.
During that, I found some points worthy of discussion, which I have
marked in the wiki page at
http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimensio with
DISCUSSION. Might be something for our meeting today.

Note that because of
http://www.bluishcoder.co.nz/2010/04/27/html5-video-seeking-and-redirects.html
any RANGE request that is being sent should never return a 200OK.

Cheers,
Silvia.


On Thu, Apr 15, 2010 at 12:57 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> 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 Wednesday, 28 April 2010 01:46:51 UTC