15:59:45 RRSAgent has joined #html-media
15:59:45 logging to http://www.w3.org/2013/02/12-html-media-irc
16:00:54 markw has joined #html-media
16:01:26 jdsmith has joined #html-media
16:02:00 johnsim has joined #html-media
16:02:34 kstreeter has joined #html-media
16:02:52 adrianba has joined #html-media
16:03:43 acolwell has joined #html-media
16:05:20 zakim, who is on phone
16:05:20 I don't understand 'who is on phone', johnsim
16:05:35 zakim, who is on call
16:05:35 I don't understand 'who is on call', johnsim
16:06:07 http://www.w3.org/2008/04/scribe.html
16:06:14 zakim, who is on line
16:06:14 I don't understand 'who is on line', Mick_Hakobyan
16:06:20 zakim, who is here?
16:06:20 sorry, acolwell, I don't know what conference this is
16:06:21 On IRC I see acolwell, adrianba, kstreeter, johnsim, jdsmith, markw, RRSAgent, Zakim, pal, ddorwin, joesteele, Michael_Thornburgh, Mick_Hakobyan, trackbot
16:06:35 the number is 63342
16:06:40 zakim, this is HTML_WG
16:06:40 ok, adrianba; that matches HTML_WG()11:00AM
16:07:10 zakim, who is on the phone?
16:07:10 On the phone I see Mick_Hakobyan, joesteele, Michael_Thornburgh, pal, markw, KevinStreeter, [Microsoft], ddorwin, [IPcaller], +1.303.503.aabb, Aaron_Colwell
16:07:40 zakim, [IPcaller] is me
16:07:40 +johnsim; got it
16:08:21 trackbot-ng, start telcon
16:08:23 RRSAgent, make logs public
16:08:25 Zakim, this will be 63342
16:08:25 ok, trackbot; I see HTML_WG()11:00AM scheduled to start 8 minutes ago
16:08:26 Meeting: HTML Media Task Force Teleconference
16:08:26 Date: 12 February 2013
16:08:55 ScribeNick: joesteele
16:09:13 Chair: Aaron Colwell
16:09:22 http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0020.html
16:09:27 Topic: Agenda
16:09:37 Zakim, who is here?
16:09:37 I notice HTML_WG()11:00AM has restarted
16:09:38 On the phone I see Mick_Hakobyan, joesteele, Michael_Thornburgh, pal, markw, KevinStreeter, [Microsoft], ddorwin, johnsim, +1.303.503.aabb, Aaron_Colwell
16:09:38 On IRC I see acolwell, adrianba, kstreeter, johnsim, jdsmith, markw, RRSAgent, Zakim, pal, ddorwin, joesteele, Michael_Thornburgh, Mick_Hakobyan, trackbot
16:10:13 zakim, aabb is boblund
16:10:13 +boblund; got it
16:10:42 zakim, who is here
16:10:42 johnsim, you need to end that query with '?'
16:10:49 zakim, who is here?
16:10:49 On the phone I see Mick_Hakobyan, joesteele, Michael_Thornburgh, pal, markw, KevinStreeter, [Microsoft], ddorwin, johnsim, boblund, Aaron_Colwell
16:10:51 On IRC I see acolwell, adrianba, kstreeter, johnsim, jdsmith, markw, RRSAgent, Zakim, pal, ddorwin, joesteele, Michael_Thornburgh, Mick_Hakobyan, trackbot
16:11:08 Previous minutes are here: http://www.w3.org/2013/01/29-html-media-minutes.html
16:12:08 Topic: Open Actions
16:12:18 none
16:12:30 Topic: Baseline Docs
16:12:40 acolwell: updated last week
16:13:02 Topic: Outstanding Bugs
16:13:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c11
16:13:30 Bug 19676
16:13:45 acolwell: can't be marked as fixed yet -- some discussions ongoing
16:14:05 ... plan is to address several bugs at once and then do a spec update and check with him
16:14:15 (him == Pierce)
16:14:30 s/Pierce/pal/
16:15:17 acolwell: update the spec by the next meeting -- all related to splicing behavior, top priority right now
16:15:29 johnsim: any comments?
16:15:52 http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0064.html
16:16:08 acolwell: re: email sent out -- should I focus on algorithms more?
16:16:20 ... perhaps need a different document?
16:16:29 ... email answered my question
16:16:38 johnsim: who asks splicing questions?
16:16:42 acolwell: pal
16:17:01 acolwell: discussions are around making a clear diagram of the actual behavior
16:17:09 ... question back was -- who is the audience?
16:17:23 ... might not be precise enough for implementors
16:17:50 Bug: 19784
16:17:50 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19784
16:18:01 acolwell: associated with that email thread
16:18:17 ... discussions about a diagram for timestamp offset
16:18:29 ... need to ensure that algorithm is correct first
16:18:55 ... this was a splicing bug being addressed in next spec update
16:19:01 [MSE] transport stream constraints vs Apple's HLS http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0001.html
16:19:11 Bug: HLS discussion
16:19:30 acolwell: this is covered by the three following bugs - someone from Adobe to jump in?
16:19:50 Michael_Thornburgh: I opened those buga
16:19:52 a) NEW Bug 20899 -loosen media segment random access point constraint https://www.w3.org/Bugs/Public/show_bug.cgi?id=20899
16:20:01 ... based on discussion in the mailing list
16:20:08 s/buga/bugs/
16:20:28 Michael_Thornburgh: this was about loosening some of the spec constraints about structure of media segments
16:20:37 ... to access HLS content as used today
16:20:48 ... mentioned by David Singer
16:20:55 ... allows reuse with minimum fuss
16:21:17 Michael_Thornburgh: ah -- wrong bug -- this is about not beginning with an access point
16:21:25 ... a random access point
16:21:35 ... rather than natural GOP boundaries
16:21:53 ... was mentioned that media segments should not have to begin with random access pointss
16:22:26 johnsim: if this is done is JavaScript, how does random access happen, if segments do not begin with random access points?
16:22:36 ... if UA is not parsing the XML (m3u8)
16:22:59 Michael_Thornburgh: the live streaming case is where I have seen this
16:23:05 BobLund has joined #html-media
16:23:48 ... (prvious comment was from Aaron)
16:24:04 q+
16:24:07 +??P8
16:24:12 johnsim: not new bug -- filed on the 7th -- needs to have more speciifc language
16:24:13 -boblund
16:24:32 zakim, ??p8 is me
16:24:32 +BobLund; got it
16:24:33 acolwell: was planning on updating the text to say "must contain a random access point"
16:24:40 ... instead of "must start with one"
16:25:05 ... if segment doesn't start at a random access point -- drop frames until you see one
16:25:35 kstreeter: if you are starting new playback, audio coudl start with blank picture, or audio could snap to first picture frame
16:25:40 ... one should be chosen
16:26:04 pal: question -- if algorithm ends up starting earlier than timestamp offsets
16:26:18 ... so diration is not the same as duration in frames -- how does that work?
16:27:01 acolwell: my assumption now is the duration would be the last timestamp minus the duration lost
16:27:21 kstreeter: would like the video to be black until the random access point occurs
16:27:36 pal: so duration remains the same
16:27:47 markw: changing this is complex on the client side
16:27:57 joe: those comments were me, not KS
16:28:21 ... when you do bitrate switching, have to append same segment from both bitrates until you find the random access point
16:28:35 ... problems occur when frame reordering happens
16:28:53 ... might have a random access point from later in the segment
16:29:09 ... but in this case have to download the same segment twice
16:29:32 q+
16:29:33 ... could impact the quality of experience just to make the encoding side a little simpler
16:29:38 q+
16:29:57 q+
16:30:05 kstreeter: don't necessarily want to constrain what is possible
16:30:14 ... to be able to play HLS content already out there
16:30:41 Zakim, ack markw
16:30:41 I see kstreeter, acolwell, pal on the speaker queue
16:31:03 kstreeter: many APIs will choose to do this because of the amount of content available
16:31:23 markw: the assumption that random access points are at the beginning is reasonable
16:31:34 ... we need to be convinced this is worthwhile
16:31:47 ... individual UA could decide this is worhtwhile
16:32:12 kstreeter: could agree with that, defined for the bytestream format, more concerned about some of the other bugs
16:32:17 ... that require signalling
16:32:19 q+
16:32:29 Zakim, ack kstreeter
16:32:29 I see acolwell, pal, Michael_Thornburgh on the speaker queue
16:33:15 acolwell: does this add a lot of extra complexity? we could just drop packets until that point?
16:33:24 ... is that wrong?
16:34:02 acolwell: could arrange for random pts to have the properties you desire
16:34:19 ... but in the case of live broadcast could just drop the frames until you see the random pt
16:34:26 ... though that is why it would be usefull
16:34:39 Zakim, ack colwell
16:34:39 I see acolwell, pal, Michael_Thornburgh on the speaker queue
16:35:08 Zakim, ack acolwell
16:35:09 I see pal, Michael_Thornburgh on the speaker queue
16:35:34 pal: recommend focusing on describing a straightforward constraint scenario
16:35:46 ... infinity of scenarios, can't describe them all
16:35:55 ... want something implementable
16:36:15 s/constraint scenario/constrained scenario/
16:36:39 pal: keep it simple, not try to describe non-integral units
16:36:52 ... should not crap out, but what you do depends on many factors
16:37:06 Zakim, ack pal
16:37:06 I see Michael_Thornburgh on the speaker queue
16:37:14 pal: otherwise very hard to describe
16:37:49 jphnsim: is part of the problem that the HLS spec is under-specified
16:38:17 Michael_Thornburg: HLS spec says it must contain a random pt, does not say where
16:38:29 s/jphmsim/johnsim/
16:38:55 pal: very difficult to specify algorithm that take into account all possible scenarios: varying frame/sample rates, in/out points outside of edit unit boundaries, etc...
16:38:57 Michael_Thornburg: use the timestamps for synching bit-rate changes, but otherwise is very light on specifying
16:39:13 ... does have some constraints on codecs
16:39:19 -BobLund
16:39:25 ... the audio might be relaxed in more recent version
16:40:03 ... if you know your media your implementation doesn't have to be super complicated
16:40:22 +??P21
16:40:34 zakim, ??p21 is me
16:40:34 +BobLund; got it
16:40:39 ... the generic HLS case could use the more complicated case, could result in blackness
16:40:47 ... that's probably OK to.
16:40:55 pal: more realistic to focus on precisely describing splicing in common scenarios, but perhaps recommend that implementations not die on others (but even then there are no guarantees)
16:41:08 ... most media will probably start with random pts, but some may not and have a lesser experience
16:41:16 ... that's ok -- decoder should not stop
16:41:33 ... unnecesary constraint to start with random pt
16:41:47 pal: for content authors this would be confusing yes
16:41:55 q+
16:42:21 Michael_Thornburg: I think it's OK to define behaviors in this case as blackness
16:42:34 s/define behaviors/define behavior/
16:42:41 q-
16:42:44 q-
16:42:44 acolwell: will think about it some more
16:42:52 Zakim, ack Michael_Thornburg
16:42:52 I see no one on the speaker queue
16:43:14 Bug: 20901
16:43:26 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20900
16:43:26 Bug: 20900
16:43:38 Michael_Thornburg: I opened this
16:44:02 ... this is dropping the contraint about TS segmenets comprising complete access units
16:44:14 ... real world encoders may not follow this constraint
16:44:35 ... because of tricks to reduce TS stream overhead used today
16:44:48 ... to reduce padding
16:45:09 ... could be in a scenario where none of the segments have complete PES packets
16:45:20 s/segmenets/segments/
16:45:30 ... we should support this
16:45:58 acolwell: not sure why this was originally requested, someone else who knew more required this
16:46:09 q+
16:46:21 boblund: think that came from Alex, a number of specs do require integral access units in PES packets
16:46:38 ... think it was someone from Motorola Mobility with an email and explanation
16:46:47 http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0004.html
16:46:52 acolwell: here is the email
16:47:18 acolwell: maybe we can respond to this email
16:47:29 kstreeter: not sure this is what Gary was referring to
16:47:51 ... need to be aware you might have data left at the end of the buffer and have to wait for more
16:48:05 ... requires additional logic in your buffering layer
16:48:15 ... more constrained profiles try to eliminate this
16:48:24 acolwell: don't have a particular preference
16:48:32 Zakim, ack kstreeter
16:48:32 I see no one on the speaker queue
16:49:00 johnsim: if this doesn't reduce complexity, no need to include this constraint
16:49:24 acolwell: fine with removing the constraint and seeing what implementation experience tells us
16:49:31 kstreeter: that would please me
16:49:41 johnsim: I am ok with that
16:49:59 acolwell: ok I will remove the contraint
16:50:06 Bug 20901
16:50:15 Michael_Thornburg: Also mine
16:50:16 c) NEW Bug 20901 -contiguous splice/append without knowing media segment internal timestamps https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901
16:50:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901
16:51:08 Michael_Thornburg: again discontinuity markers not fully specified in the HLS spec
16:51:19 ... begins at time 0 in the M3U8
16:51:31 ... the TS files are just appended in
16:51:55 ... actual timestamp values are irrelevant except for moving track forward in an orderly fashion
16:52:08 ... don't need to know what they are, just that they move forward
16:52:23 ... would be nice to support that without having to write the parser in JS
16:52:46 acolwell: in general I agree, need to figure out how to address
16:52:59 ... need an alternate way to handle append
16:53:22 ... no matter what timestamps are, will set timestamps to be whatever is needed to set timestamp to 0
16:53:38 ... just take what I have appended and put at end of what I have now
16:53:57 Michael_Thornburg: might be more useful for multi-bitrate switching
16:54:07 ... segments might no represent the same time
16:54:10 ... might not be aligned
16:54:24 acolwell: not the only behavior, but would be an option
16:54:47 Michael_Thornburg: append where you left off may not be what you want
16:55:12 ... if you have a way of starting at 0 and moving forward with sequential appends that may be enough
16:55:24 ... aborts may cause you to want to reset?
16:55:31 -BobLund
16:55:58 ... a bitrate change timestamps stay consistent, discontinuity you want to pick up where you left off
16:56:19 ... might be necessary to indicate a discontinuity across all tracks
16:56:36 ... when you start appending all tracks are synchronize with the new timestamps
16:56:43 ... could cause small gaps in the track
16:56:57 q+
16:57:01 ... further study and discussion is required
16:57:27 pal: currnetl the timestamp is relative to internal timestamp of media segments
16:57:43 ... is that specifially to address the bitrate scenario?
16:58:12 acolwell: just to make it simple for translating media timestamps to presentation timestamps
17:00:16 acolwell: we are out of time - lot's to think about
17:00:32 Zakim, who is here?
17:00:32 On the phone I see Mick_Hakobyan, joesteele, Michael_Thornburgh, pal, markw, KevinStreeter, [Microsoft], ddorwin, johnsim, Aaron_Colwell
17:00:35 On IRC I see BobLund, acolwell, adrianba, kstreeter, johnsim, jdsmith, markw, RRSAgent, Zakim, pal, ddorwin, joesteele, Michael_Thornburgh, Mick_Hakobyan, trackbot
17:00:37 -pal
17:00:40 -KevinStreeter
17:00:42 -[Microsoft]
17:00:44 -johnsim
17:00:44 -Mick_Hakobyan
17:00:44 rrsagent, generate minutes
17:00:44 I have made the request to generate http://www.w3.org/2013/02/12-html-media-minutes.html joesteele
17:00:45 -Aaron_Colwell
17:00:48 -ddorwin
17:00:49