Media Fragments Working Group Teleconference

21 Oct 2008



Erik, Davy, Yves, Guillaume, Silvia, Raphael, Colm_Doyle, Fons_Kuijk, Jack, Frank
Erik, Raphael




<raphael> trackbot, start telcon

<trackbot> Date: 21 October 2008

<raphael> Scribenick: raphael

<scribe> Scribe: Erik

<scribe> scribenick: erik


1. Continuity/Discontinuity

silvia: URI-scheme could cover multi-part (if needed)

silvia/jack: if multiple fragments in one URL, hierarchy structure could be problem ... SMIL can do that

jack: something for v2?

raphael: still a lot of issues, postpone a bit

jack: will influence syntax somehow pretty soon

conclusion for continuity/discontinuity: postponed a bit, but keep in mind

2. spatial fragment shape

jack: non-rectangular shape is only important if animation is also covered

silvia/davy/erik: rectangular is most feasable, most important, easiest to implement

raphael: we should look at what SVG-group did

conclusion for spatial fragment shape: rectangular shape to start with

silvia/jack: non-rectangular shapes on images are do-able, but for video rectangular is only valid use case

3. container & substreams

silvia: container formats are enough to consider

jack: is there any important codecs/containers missing?

davy explains codecs wiki-page

silvia: should also add SNOW (wavelet based) from FFMPEG

<Yves> http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co

silvia: also in audio codecs framing is not deterministic

davy: but more easy to jump into audio than it is to jump into video

silvia: MPEG-1 has different kinds of encapsulation, good to have but more difficult to handle
... only make assumption about general structure of resource (not about coding & decoding)
... FLAC is already framed

Erik will update codec page ... including SNOW, AVS, SVC, OMS, Speex, MLP

Silvia: raw formats are even easier to handle then codecs

davy explains container wiki-page

<guillaume> raw "WAV" or "YUV" have a more direct / linear time to byte mapping

erik/davy to check if .mp4 can have references to other files as indexing could be more complex

davy/jack/raphael: player that doesn't understand some "boxes", probably will skip it and play what it understands

jack: what about encrypted AAC?

silvia: DRM is another ballgame

raphael: we will mention the limitations of our solutions (cfr. DRM-stuff)

silvia: within OGG you always need the header instead of mp3 for example

erik/davy will update container wiki-page ... adding AU, XVID, DIVX & check consistency with media resource model of silvia

silvia: substreams are just another point of view of fragments adressing
... solve spatial & temporal adressing issue, but see that it is extendable (generic scheme) for e.g. substreams
... create a syntax spec. that is extensible

jack: certainly keep that in mind when talking about syntax starts

conclusion of substreams (e.g. tracks, ...): postpone decision, but certainly create syntax that is extensible to incorporate this at a later time

4. in-context vs. out-of-context

jack: only jump to specific "paragraph" in isolation or jump to "paragraph" in context of whole document

silvia: just an application issue

yves: applications should be independant of our addressing scheme

raphael: fragment point of view ... context awareness
... application point of view ... should be context independant according to the addressing scheme

yves: implementation should be able to choose (as in browsers nowadays)

<raphael> Example of a bad fragment: http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/

conclusion of in-context vs. out-of-context: we want to make sure that fragment is aware of "full" resource

<raphael> scribenick: raphael

TOPICS: URI Fragment / URI Query

URI Fragment / URI Query

Yves drawing on the board

scribe: User requests http://www.example.com/foo#t=1,20
... UA is smart, knows that the URI without the hash part will be sent to the server
... UA can ask in the local hhtp cache if the resource is here
... it requires the browser vendors do some clever things with the hash part
... browsers do that already with an XPATH expression after the #

Jack: difference is here that browsers do that before sending to the server the request of the resources, so browsers have no clue what is the mime type of the resource

Yves: case 1 = Base URI is a video
... send a range request: second 1-20
... server sends back a content range: second 1-20 + the content type
... no need of the four-way handshake?

Silvia: I have a pretty big problem, because of the possibility of caching the fragments in the proxies

Yves: we would need dedicated video proxies
... that understand seconds?
... the proxies will be able to cache it
... case 2 = Base URI is text
... the range unit cannot be applied to the resource
... the server will provide the right content header and the resource
... in this case, the UA will seek to the id = 't=1,20' of the text resource

Jack: put garbage behind the # ... the UA wil display the all resource

Yves: case 3 = Base URI is a video
... the server does not know how to handle range request with seconds
... will send the whole resource

Raphael: we can in this case do a 4-way handshake

Yves: case 4 = Base URI is a text on an old fashioned web server
... works as in case 2

This solution is a mix between a 2-way and a 4-way handshake

Jack: how the case 3 works with a old fashioned web server

Yves: we can have services on proxy, that will do the work, i.e. do the cropping
... in the worst case, the whole video is sent

Jack: what about adding http extra headers?

Yves: adding extra http headers will make old fashioned web servers ignoring them
... http is a 'must ignored'
... does not break previous implementations

<guillaume> Jack: Couldn't we have a "must understand"?

<erik> Jack: our addressing scheme should come up with half of the solution, the other half should come from HTTP (or other) protocol

Silvia: look at the HTTP/1.1, RFC2616, sec 10.4.17 ... 416 Requested Range Not Satisfiable

<jackjansen> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17

Silvia: we didn't consider that in TemporalURI since we assumed we will not change the browsers

Yves: not that a problem to change the browsers

Jack: are the browser vendors the only people we want to talk

Yves: browsers, media players, proxies such as Squid
... we need to talk to all of them
... TAG will be happy because we are making a good use of the '#'
... I'm editor of HTTP 1.1 bis in IETF

Sivlia: I want to dig how we can implement this solution
... look at the RFC2396, section 4: URI References

<nessy> http://www.ietf.org/rfc/rfc3986.txt

Sivlia: again a way of encoding the mime-type of the resource in the fragment scheme

Jack: Larry said yesterday that who owns the mime-type owns the def of fragment of a resource

Silvia: Read the section 4 of RFC3986 !!! the new one
... the fragment is never sent to the network
... oups, read the section 3.5 !!!

raphael: wonders if we link to the good URI in the wiki !!! Need to check

Silvia: how can we define the mime-type implicitely in the URI scheme

All: problem, is the '(' allowed in a fragment of a textual document?

Jack: then the construct xpath(...) would have a problem

Silvia: check, parenthesis is not allowed
... so the mf() scheme of MPEG-21 is fine, as well as the XPATH scheme
... we could use the same trick
... Possible syntax: #fragment(..., ..., ...) and a comma separated list

Jack: of course this will be a functional notation

Silvia: can also use the '&' as it is done in cgi, and we can concatenate as many as we want parameters
... we need to have a discussion whether a fragment is a function or not

Jack: if want to be extensible, we would need to have a sort of functional syntax

Silvia: keep it simple should be the motto
... that might throw away the multi-fragments functionality

Jack: we think our projection on the time/space/track axes are commutative, all the parameters can be applied in any order
... if this is the case, we can have a flat list parameter = value and we do not need a functional syntax
... do we agree on that ?

Guillaume: I don't ...

Silvia: in the case of a non-functional notation, I would like to have the first character giving an hint to the UA which kind of resources we are dealing with
... I would recommend to give the very first character to do that

Yves: it won't work
... anybody can do the same
... SVG is both image and text

Silvia: let's reformulate: I would put the very first character to distinguish between an HTML resource or non-HTML resource
... I would avoid to have '(' and ')' because it implies functional notation
... we could use ':'

Yves: this is syntax ... it is not important


Erik: Weekly teleconference, day and hour

Proposal: have the weekly telecon on Wednesday, 10:00 AM UTC
... from now on ... until we get someone from the US West coast in the group
... have the weekly telecon on Wednesday, 09:30 AM UTC


<nessy> +1

<erik> +1

<davy> +1

<Yves> +1

<guillaume> +1

<scribe> ACTION: Yves to request a new time slot on the Zakim bridge [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01]

<trackbot> Created ACTION-7 - Request a new time slot on the Zakim bridge [on Yves Lafon - due 2008-10-28].

Erik: 2nd F2F meeting will be in Ghent in Belgium, on 9 and 10 of December
... Observers will be allowed

Quick straw poll: 6 people will make it + possibly more

scribe: Silvia and Guillaume will participate remotely

<scribe> ACTION: setup Zakim for the 2nd face to face meeting [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02]

<trackbot> Sorry, couldn't find user - setup

Possible groups we will interact with: SYMM, SVG, HTML5, TAG, HTTP

Raphael: we need to agree on a roadmap
... for creating editor's draft to have quickly feedback
... I would suggest to have a document that contains the Use Cases + descriptions + sketch of the solutions we have foreseen
... 2-way handshake, 4-way handshake, etc.

Silvia: I can create a new wiki page cleaning up the existing UCs

URI Fragment / URI Query

Guillaume: go back to the commutative property of a non functional syntax for expressing the syntax of the fragment

Jack: first investigate the '#' scenario
... wait for the feedback of the other groups
... see if it works before considering the '?'

Everybody nodds and agrees with Jack

Silvia: in a way, we have defined how to do this communication server side with a '#'

Fragment Name and Description

Problems: gives a name to a fragment, how to communicate this to the server?

Silvia: URI#;name=test ... a Range request: fragment test
... and then a 4-way handshake

Jack: do we envision that the UA will pass to the server what is after the hash through http headers?

Silvia: be carreful of the number of new http headers we will create
... same http header but new headers

<nessy> http://www.iana.org/assignments/message-headers/perm-headers.html

Raphael: we consider the names will be unique
... if there are multiple occurences of a name within the same resource, then the UA might go to the first one

Jack: are these names UTF-8 encoded strings?
... can we have Japanese characters into these names?
... I want to do names ... and moreover, the syntax can cope with any names which are allowable in other media formats

<nessy> quicktime example: http://peepcode.com/pages/quicktime-chapter-track

<nessy> jumping directly to chapters inside a quicktime chapter track

Jack: we might need some quoting characters for the names
... if there is a quicktime addressing naming scheme, we need to learn about

Silvia: will look for

Status of a Media Fragment

<guillaume> "frame label" or "named anchors" for Flash http://noscope.com/journal/2004/04/named-anchors looking for example

Raphael: might be relevant if we want to explicitely create new resources

Yves: explains the latest Internet Draft, with the HTTP Header Linking
... can be used to point to the parent resource

<scribe> ACTION: Yves to look at more deeply if it is possible to use the current HTTP header linking for a fragment to point to its parent resource [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-8 - Look at more deeply if it is possible to use the current HTTP header linking for a fragment to point to its parent resource [on Yves Lafon - due 2008-10-28].

<nessy> xpointer registry http://www.w3.org/2005/04/xpointer-schemes/

Jack: there is XPointer ... why is it still a WD since 2001?

<jackjansen> Xpointer spec: http://www.w3.org/TR/WD-xptr

Yves: I will ask Liam Quin what's going on

<Yves> http://www.w3.org/TR/xptr-framework/

<jackjansen> XPointer rec that google cannot find: http://www.w3.org/TR/2003/REC-xptr-framework-20030325/

Silvia: is XPointer only valid for XML documents?

Jack: yep, you're right

Raphael: XML is a structured document, this is not our case, should not copy the syntax

All: looking at http://www.ietf.org/rfc/rfc5147.txt

Silvia: should be added to my current #<something> list
... '#<alpha>' [HTML], '#mf(...)' [MPEG-21], '#line=' or '#char=' [RFC5147]

<jackjansen> One of the rfc5147 authors had an article at Hypertext 2005 on the subject, see http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf

<jackjansen> (refers to various people we know, too:-)

Server, Cache and Proxies

It is desirable that new and old proxies are able to cache fragments

Yves: a proxy does not necessarily cache only resources
... should not be a problem with the solution we have sketched


RTSP has a scheme for temporal URI ... but not for spatial URI

Silvia: we need to look at how they do that and potentially tell them to adopt our scheme

Davy: shoutcast should work over http

Guillaume: mms is huge

<davy> scribenick: davy


<jackjansen> Two papers on potential use cases for fragment (please don't share too widely just now, definitive versions later):

<jackjansen> http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf

<jackjansen> http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf

raphael: the following should be in a UC & requirements doc

1. Addressing

3 dimensions: temporal, spatial, track

scribe: another dimension: named fragments

2. UA -> Server communication

scribe: only for http
... 2-way handshake and 4-way handshake

jack: use cases should be described before this

raphael: silvia will clean up the wiki, at next teleconf, we will see what we have and take a decision
... description of the use cases could be used as examples for the addressing part

jack: should existing technologies be present in the doc?

raphael: that would be great, but we will not have the time before the second f2f
... it is a todo
... smil, svg view, mpeg-21, temporal uri, ...

silvia: does SMIL have an addressing scheme? If not, it should not be addressed

guillaume: point is what does the technologies already do

jack: indeed, think functionality

raphael: URI solutions: XPointer, RFC3986, Temporal URI, SVG view, MPEG-21 Part 17
... non-URI solutions: SMIL, SVG, MPEG-7

silvia: bottom-line is about fragment identification possibilities by comparing these technologies

jack: also add TimedText and CMML to the non-URI solutions

silvia: add HTML 5

raphael: add RTSP to point 2 (UA->Server communication)

<jun> PDF Open Parameters: http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf

raphael: what about MMS and all the P2P protocols (e.g., subcast, pplive, ...)

silvia: find out if these specs support fragments

erik: are these P2P protocols open?

raphael: yes, I think so, they are mainly built by Chinese people

davy: is MMS not depricated?

<jackjansen> WMP11 does play MMS: http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/

silvia: most protocols will have http or rtsp+udp as underlaying layer

raphael: in other groups: the whole group is editor
... is this the solution we want?

silvia: we are a small group, so it would not be a big problem

raphael: editor as group, then no explicit names are given

jack: are editors the text writers or the contributers?

yves: there is also an acknowledgements section

raphael: I volunteer to write about point 2

jack: related technologies: we should have a comparison based on point 1
... I will prepare a first version of point 3, erik & davy prepare a second version
... is creating a movie which will be used as test case for the technologies

guillaume: I also want to add some examples for existing technologies

raphael: could we have some dummy implementations for point 2

yves: I have a Java implementation of a web server

raphael: is there any existing Java cropping software?

silvia: there is one for mp3

yves: we would also need customization of the browser code

erik: all doc preparation on the wiki

guillaume: introduce 4. Syntax

raphael: adjourns the meeting

Summary of Action Items

[NEW] ACTION: setup Zakim for the 2nd face to face meeting [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02]
[NEW] ACTION: Yves to look at more deeply if it is possible to use the current HTTP header linking for a fragment to point to its parent resource [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03]
[NEW] ACTION: Yves to request a new time slot on the Zakim bridge [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/10/26 10:50:37 $