Re: ACTION-238: Review TC0002-S to TC0026-S (server test cases) (Media Fragments Working Group)

I find them all ok from then on, bar

TC0052-S	Unknown keys	
GET spatial_30fps.webm HTTP/1.1
Range: u=12&t:npt=3-
	
HTTP/1.1 200 OK
Content-Type: video/webm
	A syntactical invalid fragment results in a 200.	unreviewed

>>> Should this one not work and return the data for the known dimensions only? DISCUSS.


TC0053-S same

The last 4 can be mapped to times - I can send a fix if you like.

Cheers,
Silvia.

On Wed, Nov 23, 2011 at 8:53 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Also, 27 - 34 are OK.
> S.
>
> On Wed, Nov 23, 2011 at 8:51 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> I note that I reviewed the test cases that were on this page:
>> http://www.w3.org/2008/WebVideo/Fragments/TC/server-test-cases
>>
>> On Wed, Nov 23, 2011 at 8:51 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> Hi all,
>>>
>>> In the interest of helping us move to CR, I've just reviewed the test
>>> cases as per my action 238.
>>>
>>> TC0002-S        OK
>>>
>>> TC0003-S        OK
>>>
>>> TC0004-S        #t=a,b and a = 0, b = e
>>> GET spatial_30fps.webm HTTP/1.1
>>> Range: t:npt=0-9.97
>>>
>>> HTTP/1.1 206 Partial Content
>>> Content-Type: video/webm
>>> Content-Range: bytes 5466-3050247/3050248
>>> Content-Range-Mapping: {t:npt 0-9.97/0-9.97}={bytes 5466-3050247/3050248}
>>>        The media is delivered from 0 to e.     unreviewed
>>>
>>>>>> It seems to me that  if we request a file from beginning to end, the bytes range should cover from 0 to 3050248 rather than starting some bytes in (probably after the file header?) and ending a byte too short. DISCUSS?
>>>
>>>
>>> TC0005-S        OK
>>>
>>> TC0006-S        #t=a,b and a >= 0, a < b, a < e and b > e
>>> GET spatial_30fps.webm HTTP/1.1
>>> Range: t:npt=3-15
>>>
>>> HTTP/1.1 206 Partial Content
>>> Content-Type: video/webm
>>> Content-Range: bytes 887229-3050247/3050248
>>> Content-Range-Mapping: {t:npt 2.93-9.97/0-9.97}={bytes 887229-3050247/3050248}
>>>        The media is delivered from a to e, taking into account the random
>>> access points.  unreviewed
>>>
>>>>>> It seems to me that this should have "a>0" as the condition, and end at the end byte. If a=0 and b>=e, we should likely just return the full resource and not byte ranges? DISCUSS?
>>>
>>>
>>> TC0009-S        OK
>>>
>>> TC0011-S        OK
>>>
>>> TC0014-S        OK
>>>
>>> TC0015-S        OK
>>>
>>> TC0017-S        OK
>>>
>>> TC0018-S        SMPTE
>>> GET spatial_30fps.webm HTTP/1.1
>>> Range: t:smpte=0:00:03-0:00:07
>>>
>>> HTTP/1.1 206 Partial Content
>>> Content-Type: video/webm
>>> Content-Range: bytes 887229-2171226/3050248
>>> Content-Range-Mapping: {t:smpte
>>> 0:00:02:27-0:00:07:06/0:00:00-0:00:09:29}={bytes
>>> 887229-2171226/3050248}
>>>        The media is delivered from 3 to 7 seconds      unreviewed
>>>
>>>>>> The SMPTE examples don't provide conditions on a,b - is that on purpose? DISCUS?
>>>
>>>
>>> TC0019-S        OK
>>>
>>> TC0020-S        OK
>>>
>>> TC0021-S        SMPTE-25 applied to a non-25fps media resource
>>> GET spatial_30fps.webm HTTP/1.1
>>> Range: t:smpte-25=0:00:03-0:00:07
>>>
>>> HTTP/1.1 200 OK
>>> Content-Type: video/webm
>>>        The whole media resource is returned.   unreviewed
>>>
>>>>>> I don't think that's ok. SMPTE are just time markers. It's not like you can't resolve the time when a different SMPTE time is used. Here, clearly it resolved to 3-7 seconds. DISCUSS!!!
>>>
>>>
>>> TC0022-S        OK
>>>
>>> TC0023-S        SMPTE-30-drop
>>>
>>>>>> This one should not be different from the one before, because drop frames just mean that the frame counting is not contiguous. You still have to deliver from 3-7 seconds.
>>>
>>>
>>> TC0025-S        Clock
>>> GET spatial_30fps.webm HTTP/1.1
>>> Range: t:clock=2011-05-13T13:57:03Z-
>>>
>>> HTTP/1.1 206 Partial Content
>>> Content-Type: video/webm
>>> Content-Range: bytes 887229-3050247/3050248
>>> Content-Range-Mapping: {t:clock
>>> 2011-05-13T13:57:02.932Z-2011-05-13T13:57:09.967Z/2011-05-13T13:57:00Z-2011-05-13T13:57:09.967Z}={bytes
>>> 887229-3050247/3050248}
>>>        The media is delivered from 3 seconds to the end        unreviewed
>>>
>>>>>> This one will only work if the server actually has a mapping of the file to a date. If that is not available, then you may get a 200 OK and the full resource.
>>>
>>>
>>> TC0026-S        OK.
>>>
>>>
>>> Hope this helps.
>>>
>>> Cheers,
>>> Silvia.
>>>
>>>
>>> On Wed, Oct 5, 2011 at 8:23 PM, Media Fragments Working Group Issue
>>> Tracker <sysbot+tracker@w3.org> wrote:
>>>>
>>>> ACTION-238: Review TC0002-S to TC0026-S (server test cases) (Media Fragments Working Group)
>>>>
>>>> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/238
>>>>
>>>> On: Silvia Pfeiffer
>>>> Due: 2011-10-12
>>>>
>>>> If you do not want to be notified on new action items for this group, please update your settings at:
>>>> http://www.w3.org/2008/WebVideo/Fragments/tracker/users/32040#settings
>>>>
>>>>
>>>
>>
>

Received on Wednesday, 23 November 2011 10:02:44 UTC