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

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 09:52:36 UTC