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

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:12 UTC