Re: test cases - questions and discussion points for tomorrow

Hi Jack,

On 6/04/2011 0:02, Jack Jansen wrote:
> Here's various things that struck me. I've only glossed over the server test cases, as I'm a bit out of my water there and I need more time to review these.
>
> TC0004-UA - why don't the second and third http example have "include-setup" in the range request? I would assume the setup bytes are needed? Similar question for a couple of the following test cases.
Ok, here are the possible situations of a UA:
1) the UA didn't setup its decoding pipeline (i.e., knows for the moment 
nothing at all about the media resource): the UA will send an 
include-setup (i.e., t:npt=0-9.97;include-setup)
2) the UA did setup its decoding pipeline: now there are two 
possibilities: 2a) the UA is a smart UA which means it is able to do the 
mapping by itself. The resulting request is a byte range request (i.e., 
bytes 5459-3050234). 2b) the UA is not a smart UA which means that it 
requests time ranges (i.e., t:npt=0-9.97).

> TC0007-UA - this suggests that time ranges should look at timestamps in the media, correct? (We went back and forth on this issue, so I don't fully remember what the latest outcome was). But this means that the suggestion in section 7.3 (external clipping should cascade) is a bit unlogical. After all, http://www.example.com/clip.mp4?t=3,10#t=3,4 won't cascade either (unless the server does remapping of timestamps on queries)
Yes, correct (btw, I don't remember any discussion about this issue :)). 
Also, I don't think this has something to do with in or out of context. 
The timestamps in the media format determine the playback time of the 
frames, and yes, there could be time ranges where no frame is depicted. 
This compliant to our model [1] no?

> TC0009-UA The comment starting from "otherwise" isn't clear to me. I think it's meant to clarify that if the ua doesn't know the request will be out of range (and how would it know?) it will send a normal request, which happens to be out of range.
Yes, that was exactly what I wanted to say. Either the UA knows the 
duration and doesn't do anything, or the UA does not know anything about 
the resource and performs the request.

> TC0013-UA The foirst http request has range: bytes ???-???, is this an editors comment? I think this alternative is impossible: if the ua has prior knowledge of the byte ranges it knows that it's asking for the whole resource, so it should simply do so.
Ah, you're right, I will change this TC.

> TC0018-UA Unless I'm seriously mistaken this test case is wrong. After many discussions we decided that smpte timecodes would be content-based addressing, right? If that assertion is correct then the expected outcome and comment are incorrect, and would actually lead people to produce incorrect implementations. At the very least, the outcome should state something like "playback from the frame marked with timecode 00:00:03 in smpte-30" etc etc. Same for all other smpte tests.
I agree that the comment description should be changed. But, just to be 
clear, the expected request are correct right?

> TC0025-UA Same issue: this depends on data encoded in the media file (or metadata stored along with the mediafile) on the server.
Agreed.

> TC0027-UA I think the comment is incorrect, and also the ua should not issue any request. Same for the other parse errors.
We already agreed on this kind of behavior (see [2], which was the 
result of discussions of the F2F at Sophia). I just copied these TCs as 
they were.

> OFF-ON-A-TANGENT We state nowhere (AFAIK) whether our strings are case-sensitive. I assume they are, because of the BNF, but (a) we should state so somewhere, and (b) we should add a test that #T=1,3 doesn't work.
Agreed, I will add such a TC.

> TC0034-UA and friends: we miss one interesting test case: for percent-escaping the "=" (which IIRC shouldn't work). Same for escaping ampersand (which should work for something like track but not t).
I will add these TCs as well.

> TC0044-UA the comment is misleading. '-' isn't in our BNF, so this isn't a "negative number", it's simply a syntax error like t=banana. We don't have the concept of negative numbers in our spec:-) Same for TC0049-UA.
Agreed.

> TC0053-UA Is this indeeed what we specified, that duplicate axes are allowed as long as we only know the units on one of them??? If we indeed specified this that we should also test the reverse order (which is easier to get wrong:-)
Agreed.

> TC0054-UA This test suggests that we proscribe to first split on&, then ignore any field that has syntax errors. Is that indeed what we specified?
According to [3], I think it is.

> TC0055-UA We should also test that t=npt:3&t=smpte:00:00:03 fails. Even though I don't like the inconsistency with ignoring unknown units....
Agreed, will add this as well.

> TC0056-UA We should also add a couple of nasties here: tracks with a space or ampersand or some other magic character in their name.
Agreed.

Thanks a lot for this feedback!

Best regards,

Davy

[1] http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#side1
[2] 
http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimension#Temporal_dimension_syntax
[3] 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse

Received on Wednesday, 6 April 2011 07:11:55 UTC