<Noriya> Noriya sakamoto Toshiba

<cyril> http://www.w3.org/community/inbandtracks/

<cyril> http://www.w3.org/community/inbandtracks/wiki/Main_Page

<scribe> scribe: olivier

cyril: the idea of this community group is to improve integration of media containers with HTML5 media elements
... there is a section in HTML5 on how to create text tracks from tracks that are in a media file like mp4, webm, ogg and so on
... it is however not complete
... for example in the case of mp4 it only talks about metadata tracks, but not subtitle trakc
... secondly, it is not easy to automatically map the video track to the video element. is it the main video, additional, etc
... so there is a need for better mapping
... onto the kind attribute
... third problem is that the tracks are not exposed if the format is not recognised
... e.g in the case of an audio codec, you could decode it in js, but you'd need the tracks to be exposed to js

israelh: how would you guarantee syncing

giuseppe: that's a use case on its own

use cases

1. mapping of descriptors to kind

2. mapping of text tracks not yet covered by html5 spec

3. mapping of other tracks

cyril: any thought? are any of the use cases more relevant?

giuseppe: at least 2 other groups were trying to work on this mapping
... so doing it at w3c should avoid redundancy

cyril: we started from a spec by cablelabs
... referenced by DLNA
... liaison with OIPF
... and there's the HTML5 spec itself

israelh: does live broadcast fit in this?

giuseppe: [scribe missed]

MarkV: the idea is that multiple browsers get the same mediastreams
... thanks of mapping they'd give the same messages, same order, same data

giuseppe: there are hints in the spec, but not normative

cyril: and not complete

<xiaoqian_> chair: cyril

Igarashi: sufficient to support live?

MarkV: we believe so
... will test by completing the mapping

cyril: everyone understands and agrees with use cases?

igarashi: switching between tracks is also in scope?

MarkV: we believe there are mechanisms to switch between tracks
... again, by completing the mapping will we be able to test that assumption

cyril: there's also MSE which can be used for that
... don't think the switching should be in scope of this CG

<cyril> olivier: how do we envision keeping this up-to-date when new formats appear?

<cyril> ... registry or updates ?

MarkV: wonder if we could keep it in same way as those auxiliary page kept by the whatwg

cyril: we'd need to coordinate closely with mpeg, dvb and providers of track content
... at the same time I think we will need basic mechanism to expose the track
... and if a specific mechanism is needed we can refine

igarashi: html5 media tf are currently thinking about a registry for MSE

cyril: that is a registry to define what is a segment

igarashi: we could use something similar

nigel: thinking of the split between payload of tracks and wrapper

[scribe missed question, sorry]

cyril: what you need is timing info
... browsers have parser, you would'nt want to do the mp2 TS parsing
... in js

MarkV: suggest looking at CableLabs spec

cyril: looking at html5 spec, each track has id, kind, language...
... how do you set those attributes in an interoperable way?
... looking at proposal for language descripor from MPEG2

<nigel> http://www.w3.org/community/inbandtracks/wiki/Main_Page

cyril: been working on intermediate solution
... you could preprocess your file, extract and expose using WebVTT

<cyril> http://concolato.wp.mines-telecom.fr/2013/10/24/using-webvtt-to-carry-media-streams/

cyril: strawman proposal
... could put the payload as base64, or just an offset into VTT
... as a way to expose any kind of track to HTML5
... would like to replace that with an interop standard
... ideally would generate not a text track cue but a data cue
... one problem is size
... you'd end up with whole stream in memory
... also, events. you'd receive an event for each cue
... ok for subtitles, might be too many at a time if using with HFR video

igarashi: is it just for text data?

cyril: any kind. text, xml, json, audio, video...
... you could use to support depth of video even if not natively supported
... so I would like to expose any kind of track
... and let the browser decide
... e.g. Eric Carlson says that they don't have access to all the tracks on some devices

israelh: so wouldn't be limited to certain types of tracks

MarkV: our scope is dealing with standard media streams
... it's already possible to add data to a track
... also if browser implementation gives you access to data tracks
... generally it's the audio and video that are not

cyril: generally not the case. all goes directly to the hardware

sheau: another issue is that timing information is convoluted
... without solving sync, don't you end up having independent track which end up diverging

giuseppep: sync is a different concern

sheau: @@

cyril: you could get as a track all the data with all the timing
... and do sync

igarashi: video is decoded by the UA
... so you'd have a delay between that and the timing info in your track
... because you don't have access to the timing of the player
... and you can't control it

cyril: you can query currenttime

igarashi: not accurate

Sylvia: not accurate, 100ms off

sheau: and it would drift

cyril: agree sync is a concern, but there is a need to do all the work on accessing the tracks first
... CG has just started
... start with work in Wiki
... decide whether to extend HTML5 spec or include

nigel_: does this help with situation where video is delivered in mpeg2 and data is provided out of band

cyril: if your timestamps match, yes

sylvia: and if there's no drift

nigel: question is whether we're exposing the right data
... fundamental question is how do we sync

sylvia: the UA does that for you
... you could do it yourself but we're not talking about that

cyril: we are talking about using the sync engine in the browser

MarkV: you could imagine writing an editor in browser
... but if you just have 2 tracks, use what is provided by the browser

cyril: question about scope
... MP4, MPEG2 TS, Matroska and OGG
... also RTP?
... DASH? HLS?
... think we may want to start with simple formats?

MarkV: do we need to treat Matroska and WebM separately?

DavidD: Matroska/WebM. it's just a subset
... webm is a subset

israelh: request for clarification
... is it about getting tracks, or preprocessing?

MarkV: the goal is just to define standard mapping
... to HTML5 standard APIs exposing those tracks
... our work is not needed if you're just playing

nigel: if you are thinking about DASH, a DASH player would be able to do all this already

MarkV: you could extract some data and do additional things with it

nigel_: managing sync of media tracks playing back is really hard
... question is whether w3c should be defining something that is already defined elsewhere

giuseppep: it's a mapping exercise

cyril: the first step is mapping
... second step is sync
... is it preprocessing, post processing?

israelh: that implies it's at playtime?

MarkV: typically, yes, but it would be whenever you get the data

cyril: if you can preload you could grab and prcess
... would still be best effort sync
... admin point - where do we host the work?

silvia: wiki is a good start

<cyril> ilivier: form my experience, if you choose early what you want to use, you have to show DoC

<cyril> some groups have been happy using GitHub and issue tracking

<cyril> if you want to use GitHub, start early

silvia: PLH has mentioned need to have bugs in w3c space, but there are talks of api

nigel: question of WG?

cyril: no, the CG does the work, targets the HTML Media TF
... there is also a mailing-list associated with the CG
... we've been discussing mpping for the id attribute

<nigel_> http://www.w3.org/community/inbandtracks/

giuseppep: editorial comment - would be more readable if attributes were in rows, and formats in cols

MarkV: (in response to Igarashi) - the goal is for this work to replace the cablelabs spec

cyril: every track interface has an id attribute
... how do we map between container id and the id of the text track
... so far we looked at media fragment identifiers

giuseppep: @@

cyril: I will report a good discussion, ~25 people. agreement on use cases.
... discussion on second priority use case for sync
... agreement on scope

[adjourn]

<silvia> Silvia Pfeiffer, NICTA

(quick round of intro, including latecomers)

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/??/Sylvia/
Found Scribe: olivier
Inferring ScribeNick: olivier

WARNING: No "Topic:" lines found.

Present: aizu Olivier Thereaux (BBC) JatinderMann igarashi israelh kinjim michael nigel Noriya Rossen Takahiro Youngsun_Ryu xiaoqian_

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 13 Nov 2013
Guessing minutes URL: http://www.w3.org/2013/11/13-inbandtracks-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report