See also: IRC log
<trackbot> Date: 23 November 2011
<doublec> I'm here but not on phone, sorry
Next Tuesday, the specification will be published as a CR
Raphael: the group will be closed
at the end of the year
... we need to satisfy the exit criteria of CR, i.e. getting 2 implementations of all features to move forward
... Goal: we jhave
... about 10 test cases to approve for the UA
<foolip> Will we consider polyfills implementations, or only native browser/server implementations?
<tomayac> hooray for polyfills ;-)
not only browser implementations, but all, including polyfills
Thomas work should be included in an implementation report
<silvia> foolip: it's the W3C :-)
<foolip> You'd never get away with that if it were for any other browser feature, say document.querySelector.
<silvia> foolip: that's the HTML WG :-)
Thomas: I think they should be a valid implementation
Raphael: how much time you have to work on an implementation report?
<foolip> I think polyfills are great and useful, and respect tomayac's work, but don't think it's acceptable.
<foolip> In other words, if there are any features which don't have 2 implementation not counting polyfills, they should be dropped from the spec.
why don't you want to count the polyfills Philip ? I don't get this ...
<foolip> Specifically #track cannot be done with a polyfill yet
they are absolutely valid implementations
<foolip> The point of requiring implementations is to prove that it's possible to implement and ship. polyfills don't prove that, they don't have to deal with all of the internal issues you'd find in a native implementation
<tomayac> foolip, i fully agree
<scribe> ACTION: Davy starting from http://tomayac.com/mediafragments/implementationtests.html to generate a EARL report [recorded in http://www.w3.org/2011/11/23-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-241 - Starting from http://tomayac.com/mediafragments/implementationtests.html to generate a EARL report [on Davy Van Deursen - due 2011-11-30].
<tomayac> we're discussing your points
<tomayac> foolip, raphael postponed the discussion to later in the call
Only the reviewed test cases are used in the implementation report
<doublec> an example of an issue might be hitting the 'end' time in temporal fragments. The HTML media API doesn't provide a way to immediately stop playback on an end time which a polyfill will have trouble doing.
Davy: no, the non reviewed test cases are also used
<doublec> whereas a native api can get to the low level (hopefully) to do it
Davy: the individual
implementation reports contain all test cases
... but the global report only take the reviewed test cases
Raphael: the unreviewed TC starts at TC0095 until TC0102
scribe: 8 test cases
<foolip> doublec, does Firefox support stopping at the (exact) end time?
<doublec> I would argue that a testcase that uses smpte on a webm file doesn't seem to make sense, given that webm is not fixed framerate
<doublec> (referring to tc0100-ua and friends)
<doublec> foolip: it's close but not exact
<foolip> I agree, it seems to me there are no implementations of smpte
<doublec> foolip: and depends on audio buffering on platforms
<scribe> ACTION: Davy to contact Jack to get media resources to test TC0099 and TC0100 [recorded in http://www.w3.org/2011/11/23-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-242 - Contact Jack to get media resources to test TC0099 and TC0100 [on Davy Van Deursen - due 2011-11-30].
<foolip> doublec, fair enough :)
<doublec> foolip: which is why I knew that was a sticky point :)
<foolip> doublec, does currentTime lie or will it overshoot somewhat?
<tomayac> currentTime is best effort i'd say
<doublec> foolip it's supposed to be accurate but one of our audio backends cheats and only updates it after a blocking audio write on a thread is completed
<doublec> foolip: so is limited to the granularity of the amount of that write (this is linux)
<doublec> foolip: on android it's a complete guess
<foolip> doublec, ok, I won't object on the basis of that, seems like a QoI issue
<tomayac> timeupdate has no guarantees at all
<doublec> right, timeupdate is often 250ms
<tomayac> so frame-level addressing is completely impossible
<silvia> I have a problem with failing on all non-matching SMPTE formats
<doublec> tomayac: you can get better granuality doing a setInterval and checking currentTime
<doublec> tomayac: depending on implementation
<tomayac> yepp, but again w/o guarantees
<tomayac> so all that seems to make sense (and this is the only thing i've seen people use) is 1s granualarity
<tomayac> <video> abstracts away the codec details, so can't get down to frame-level, no notion of key frames, etc. and that's a good thing imho :-)
<silvia> OK, I can live with failing on non-matching SMPTE formats
<silvia> I'm hoping there won't be much use of SMPTE anyway
ok, and reviewed
<tomayac> silvia, all i've seen people use is npt, and all with seconds
ok, and reviewed (the media resource has indeed those 2 tracks)
<silvia> tomayac: yes, me too, and I've seen live streaming ppl ask for clock, but not smpte
<tomayac> i normalize npt in non-second format to seconds, which makes it easier w/ html5 video
ok, and reviewed
ok, and reviewed
<tomayac> imho, whatever currentTime accepts, dictates what we should do in practice (except for live streams of course)
Silvia: how the UA determines that the fragment is outside?
Davy: with the decoding pipeline,
the UA knows the resolution of the video
... I will write in the HTML what is the resolution of the media resource (already written in the rdf file)
<silvia> can we add that resolution to the example so it's clear it's outside?
... in fact 101 is incomplete since there is no name in the webm resource
... we have to create such a resource
... how can I create this resource
<doublec> webm doesn't provide the ability to do that
Silvia: using mkv merge ?
<silvia> WebM chaptering: http://matroska.org/technical/specs/chapters/index.html
<doublec> that's matroska
<doublec> is that included in webm?
<silvia> well, it's Matroska but would work in webm
<doublec> if it's not in the webm spec, it's not supported
<silvia> not per spec, but with most tools :)
<silvia> so, also, there is work happening on putting WebVTT into WebM, so that would likely be the better way in future
Raphael: 102 has the same problem
Davy: I will color the table in red
<Yves> 1/me taht would be great!
<Yves> s/1\/me taht would be great!//
Silvia: at some point, OGG and
WebM should have WebVTT so chapter names
... in the future, those test cases would be plausible
... hard to make the media resources now
<silvia> and Apple also wants to put WebVTT into MP4 tracks
Raphael: if no test case for the ID dimension and no implementation, then this feature will be removed from the spec
<silvia> right now you could use quicktime chapter markers in MP4 if you wanted to
<Yves> in CR we document what might be removed if not implemented
<Yves> or not implementable
<davy> Silvia, sounds good, I will try QuickTime to create such a MP4
<scribe> ACTION: Silvia to search for a media resource that contains a chapter name [recorded in http://www.w3.org/2011/11/23-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-243 - Search for a media resource that contains a chapter name [on Silvia Pfeiffer - due 2011-11-30].
<silvia> I made a point that we should not remove features from the specification that cannot now be demonstrated because we don't have the file formats for the Web yet
<silvia> If such features cannot go into REC, at least a TR or CR should continue to exist with these extra features
Davy: we will have 4 different
implementations with Thomas
... currently, 3 levels: passed, failed and not applicable meaning not yet implemented
... should the not applicable be just failed ones?
<Yves> having a new status 'not implemented' might be the best
Thomas: make a distinction between the implemented but failed and the not implemented
Davy: are we the first group to face this problem? In EARL there is not yet implemented status available
Raphael: I suggest to add a paragraph in the report to explain what Passed, Failed and Not Applicable
Erik: all features which are
weakly or not implemented should be marked at risk
... this is the case for the clock unit for specifying time for example
Raphael: I'm going to Davy and Chris, is clock something you plan to cover in your implementation?
<silvia> you need a streaming server for the clock unit, realistically
<doublec> raphael: no plans at this stage
Davy: we do that on the server
<silvia> we could ask Thomas Vander Stichele about that - he has previously implemented such a feature
<silvia> there was a thread on our mailing list at one stage
<doublec> raphael: mainly because we don't support any video playback that'd make it useful
<doublec> raphael: if we were to add such, I'd look at supporting it
Could you respond to this old thread, silvia, and re-activate this contact?
<silvia> let me try...
Erik: we had 3 actions from
... 2 minor edits ... done by Raphael
... a last one for the WAI WG
... Silvia, the track dimension is important for the a11y community, the mgt suggest to write a mail to the WAI WG to tell them this feature is at risk in Media fragment
Raphael: how important is this feature (track) for WAI?
Silvia: it is not that much WAI
at the moment, but more the HTML WG
... the track element in the media API
<doublec> right, we need the track HTML stuff to be implemented before doing the media fragment track support
Silvia: the track element is a textual track, it is for WebVTT
Thomas: latest Chromium has track support ... not sure for which format
Raphael: why browsers need to support the track element to support the media fragment track?
Silvia: because we need to expose what are the available tracks
<doublec> silvia: I was referring to http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-resources-with-multiple-media-tracks
<doublec> raphael: when I wrote 'we' I really meant 'I'. And I mean the person working on track support needs to do it before I work on adding media fragment track support (assuming they don't)
<doublec> raphael: (in firefox that is)
<silvia> I agree, that's what I was pointing out: we need #track for the multitrack API in HTML5
<foolip> Opera is similar, we couldn't support #track without first doing all the hard work to support the VideoTrack/AudioTrack APIs
Raphael: my question Chris is ... assuming the UA know what are the tracks available in a given media resource, how much implementation is to enable the selection of one of the tracks?
<doublec> raphael: I don't know yet - we don't expose tracks at all
<scribe> ACTION: Erik to mail implementers the likelihood to get the remaining features implemented in the coming weeks [recorded in http://www.w3.org/2011/11/23-mediafrag-minutes.html#action04]
<trackbot> Created ACTION-244 - Mail implementers the likelihood to get the remaining features implemented in the coming weeks [on Erik Mannens - due 2011-11-30].