Media Fragments Working Group Teleconference

 

 

<trackbot> Date: 12 August 2009

aacc is silvia

1. ADMIN

* Roll call

regrets from Guillaume and Conrad

* PROPOSED to accept the minutes of the 15 & 22 July 2009 telecon:

http://www.w3.org/2009/07/15-mediafrag-minutes.html

http://www.w3.org/2009/07/22-mediafrag-minutes.html

<mhausenblas> +1

<davy> +1

<raphael> +1

<erik> +1

<Yves> +1

* ACTION-92: Erik and Raphael to coordinate the writing of papers (ongoing ? re-raise around 15/09/09)

2. UC & REQUIREMENTS

* ACTION-68: Raphael to ask the Media Annotations WG to review our document

there are actions on the MA WG chair - Raphael will follow up

* To be discussed: Live Streaming UC (see Mail Silvia ? http://lists.w3.org/Archives/Public/public-media-fragment/2009Jul/0028.html)

<raphael> I will also ask this Friday at the HCG telecon

there are actually two questions:

* procedural question - how to extend the use cases document

* technical discussion

raphael: likes the extension, but we need to clarify
... difference between query and hash
... need to have a complete specification
... procedure: just write the specification and commit it

<scribe> ACTION: silvia to write specification for streaming use case [recorded in http://www.w3.org/2009/08/12-mediafrag-minutes.html#action01]

<trackbot> Created ACTION-94 - Write specification for streaming use case [on Silvia Pfeiffer - due 2009-08-19].

general agreement to the use case

mhausenblas: did you have a mobile use case to it?
... there may be additional requirements around requirements on resources for media addressing
... mobile area is a good selling point for media fragment use
... I will keep this in mind an highlight it if we need more requirements around this

3. SPECIFICATION

3.1 Syntax: (Yves)

* ACTION-49: Yves to Draft the HTTP-Range syntax for different units

(completing all the syntax for the two way handshake) (ongoing ? re-raise around 15/08/09, after IETF Meeting)

<raphael> ACTION: michael to review the new UC written by Silvia and check whether it will cover a mobile usage [recorded in http://www.w3.org/2009/08/12-mediafrag-minutes.html#action02]

<trackbot> Created ACTION-95 - Review the new UC written by Silvia and check whether it will cover a mobile usage [on Michael Hausenblas - due 2009-08-19].

Yves: reports on IETF meeting and extension of HTTP-Range syntax

<raphael> Scribe: Silvia

Yves: progress is made and once it's agreed, it should be ratified by IANA

<raphael> scribenick: silvia

Yves: have more info by the end of the month

(re-raise around 30/08/09)

* ACTION-93: Michael to revisit the TC and see which are affected by the temporal-optional-comma-decision

mhausenblas: was discussion on temporal-optional-comma-decision finalised?

<Yves> http://lists.w3.org/Archives/Public/public-media-fragment/2009Jul/0038.html

Franck made a counter-proposal

Yves: the trailing comma is not giving us anything useful
... I am fine with this proposal

<raphael> we are discussion Frank's proposal: remove case 2 and 4 which are redondant

silvia: happy with this proposal - it removes the option to specify the same case in two different ways

<raphael> +1 with this proposal

Yves is happy to change the grammar in the specification

<mhausenblas> +1

<scribe> ACTION: Yves to make change to temporal-optional-comma specification [recorded in http://www.w3.org/2009/08/12-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-96 - Make change to temporal-optional-comma specification [on Yves Lafon - due 2009-08-19].

<erik> +1

we now have working group agreement on this specification

+1

Yves will reply to Franck

RESOLUTION: the working group agrees to the temporal-optional-comma specification proposed by Franck

3.2 UA Server HTTP Communication (Conrad/Raphael)

* ACTION-69: Conrad to draw a representation of the general structure of

a media resource, for streamable formats (ongoing ? re-raise around 01/09/09, when having had full discussion)

<scribe> ongoing

raphael will follow up on this thread

4. TEST CASES: (Michael)

* See: http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases

TC0002: empty time segment - npt

empty time segment

e.g. #t=0,0

416, would yield an empty resource, hence client must have erred

<raphael> +1

+1

<davy> +1

<erik> +1

RESOLUTION: TC0002 is approved

TC0003: empty space segment

empty space segment

e.g. #xywh=0,0,0,0

416, would yield an empty resource, hence client must have erred

<raphael> +1

<davy> +1

<erik> +1

+1

RESOLUTION: TC0003 is approved

TC0004: empty space segment - aspect

empty space segment - aspect

#aspect=0:0

416, would yield an empty resource, hence client must have erred

<raphael> Yves; no restriction on the values except they must be integers

<raphael> ... many ratio out there already, and more can be proposed later on

<raphael> +1 for current proposal

Yves: capturing all the restrictions in the syntax itself is not necessary

+1

<davy> +1

<erik> +1

RESOLUTION: TC0004 is approved

--

TC0005: empty track segment

empty track segment

e.g. #track="" (I think)

416, would yield an empty resource, hence client must have erred

Yves: should it not rather mean the whole resource?

<raphael> I agree TC0005 is similar to TC0001

Yves: selection is based on nothing defined, so it is similar to TC0001 and should be all

mhausenblas: is there an implementation yet?

<raphael> Michael: search for implementation in the real world of the track thing. Does that exist at all?

yves: don't think so
... it's more a theoretical experiment right now

mhausenblas: if there are none, we are free to specify

<raphael> For consistency, I would prefer to have the same behavior than TC0001

<raphael> postpone ?

mhausenblas: I hesitate to propose to resolve it without more empirical experience

<raphael> We can look at what DVD players do ... when a command parameter ask to play a dvd with an empty track name

<raphael> ... my guess is that the default language is used ... and not err

silvia: let's look at it from a programmer pov - if I composed it through a tick list and no tracks were ticked, I'd probably expect all tracks to be delivered

<raphael> Correction, re TC0005

<raphael> Proposal: 200, the entire representation is returned

<mhausenblas> +1

<raphael> +1

<erik> +1

+1

<davy> +1

--

TC0006: empty named segment

e.g. #id="" (I think)

currently: 416, would yield an empty resource, hence client must have erred

Yves: we should apply the same logic as with TC0005

general agreement

<raphael> Proposal: 200, the entire representation is returned

<erik> +1

<raphael> +1

<mhausenblas> +1

<davy> +1

<raphael> Raphael notes that Silvia abstain and does not +1 on TC005

<raphael> Raphael notes that Silvia abstain and does not +1 on TC0006 (oups)

<Yves> we should probably revisit 07

<Yves> as the definition of "empty" is different depending on the axis

<mhausenblas> Yves, TC0007? Really?

<raphael> Should we add more Test Cases when there is an ID (or a Track) ... but not defined in the video

silvia: is considering the comparison between empty id and and id that doesn't exist
... but they are different

yves: we should add a test case for non-existing ID
... but when no ID is specified, it should refer to the full resource

--

revisit TC0007

Yves: since #t=, now refers to the full resource, we should revisit TC0007

#t=,&id='ID0'

<raphael> What about if you replace your input by: "#xywh=0,0,0,0&t=,"

<raphael> ?

scribe: should now refer to the named fragment ID0

<raphael> For now, can we change the status of TC0007 from approved to un-reviewed ?

Proposal: 200, return representation for named fragment ID0

<raphael> ... but keep the previous agreement in the record

silvia: can we add the new proposal then?

<mhausenblas> +1

<davy> +1

<raphael> +1

<mhausenblas> adding TC10mwith #t=0,0&id='ID0'

Michael: add a new test case 10, which captures the former intention of TC0007

<mhausenblas> and return 416 for TC10

this new test case will read #t=0,0&id='ID0'

<erik> +1

<raphael> +1 for michael proposal to add TC0010 ... I have also used before the example with an empty space segment

+1

<raphael> same for non existing track name ... non existing id

<raphael> so we need TC0011 and TC0012

adding a new test case TC0011 for non-existing id

e.g. #id="none"

<raphael> RESOLUTION: TC0005 is approved

<raphael> RESOLUTION: TC0006 is approved

reply: 416, would yield an empty resource, hence client must have erred

RESOLUTION: TC0005 is approved
... TC0006 is approved
... TC0007 to be changed as discussed
... TC010, TC011, TC012 to be added as discussed

erik: we have run out of time
... thanks everyone

<mhausenblas> great job, silvia!

<mhausenblas> +1 to Yves proposal!!!!

<mhausenblas> ;)

<yves> bye, zakim

<raphael> :-)

AOB

<raphael> none

<raphael> meeting adjourned