{minutes} HTML EME telcon 2013-02-12

http://www.w3.org/2013/02/12-html-media-minutes.html
 
- DRAFT -
HTML Media Task Force Teleconference

12 Feb 2013

See also: IRC log

Attendees

Present
Aaron_Colwell, Michael_Thornburgh, Mick_Hakobyan, acolwell, adrianba, boblund, ddorwin, jdsmith, joesteele, johnsim, kstreeter, markw, pal
Regrets
Chair
Aaron Colwell
Scribe
joesteele
Contents

Topics
Agenda
Open Actions
Baseline Docs
Outstanding Bugs
Summary of Action Items
trackbot-ng, start telcon
<trackbot> Date: 12 February 2013
<scribe> ScribeNick: joesteele
<acolwell> http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0020.html
Agenda

Previous minutes are here: http://www.w3.org/2013/01/29-html-media-minutes.html
Open Actions

none
Baseline Docs

acolwell: updated last week
Outstanding Bugs

<johnsim> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c11
Bug 19676
acolwell: can't be marked as fixed yet -- some discussions ongoing
... plan is to address several bugs at once and then do a spec update and check with pal
... update the spec by the next meeting -- all related to splicing behavior, top priority right now
johnsim: any comments?
<johnsim> http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0064.html
acolwell: re: email sent out -- should I focus on algorithms more?
... perhaps need a different document?
... email answered my question
johnsim: who asks splicing questions?
acolwell: pal
... discussions are around making a clear diagram of the actual behavior
... question back was -- who is the audience?
... might not be precise enough for implementors
Bug: 19784
<johnsim> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19784
acolwell: associated with that email thread
... discussions about a diagram for timestamp offset
... need to ensure that algorithm is correct first
... this was a splicing bug being addressed in next spec update
<johnsim> [MSE] transport stream constraints vs Apple's HLS http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0001.html
Bug: HLS discussion
acolwell: this is covered by the three following bugs - someone from Adobe to jump in?
Michael_Thornburgh: I opened those bugs
<johnsim> a) NEW Bug 20899 -loosen media segment random access point constraint https://www.w3.org/Bugs/Public/show_bug.cgi?id=20899
Michael_Thornburgh: based on discussion in the mailing list
... this was about loosening some of the spec constraints about structure of media segments
... to access HLS content as used today
... mentioned by David Singer
... allows reuse with minimum fuss
... ah -- wrong bug -- this is about not beginning with an access point
... a random access point
... rather than natural GOP boundaries
... was mentioned that media segments should not have to begin with random access pointss
johnsim: if this is done is JavaScript, how does random access happen, if segments do not begin with random access points?
... if UA is not parsing the XML (m3u8)
Michael_Thornburgh: the live streaming case is where I have seen this
... (prvious comment was from Aaron)
johnsim: not new bug -- filed on the 7th -- needs to have more speciifc language
acolwell: was planning on updating the text to say "must contain a random access point"
... instead of "must start with one"
... if segment doesn't start at a random access point -- drop frames until you see one
Michael_Thornburgh: if you are starting new playback, audio coudl start with blank picture, or audio could snap to first picture frame
... one should be chosen
pal: question -- if algorithm ends up starting earlier than timestamp offsets
... so diration is not the same as duration in frames -- how does that work?
acolwell: my assumption now is the duration would be the last timestamp minus the duration lost
Michael_Thornburgh: would like the video to be black until the random access point occurs
pal: so duration remains the same
markw: changing this is complex on the client side
markw: when you do bitrate switching, have to append same segment from both bitrates until you find the random access point
... problems occur when frame reordering happens
... might have a random access point from later in the segment
... but in this case have to download the same segment twice
... could impact the quality of experience just to make the encoding side a little simpler
kstreeter: don't necessarily want to constrain what is possible
... to be able to play HLS content already out there
... many APIs will choose to do this because of the amount of content available
markw: the assumption that random access points are at the beginning is reasonable
... we need to be convinced this is worthwhile
... individual UA could decide this is worhtwhile
kstreeter: could agree with that, defined for the bytestream format, more concerned about some of the other bugs
... that require signalling
acolwell: does this add a lot of extra complexity? we could just drop packets until that point?
... is that wrong?
... could arrange for random pts to have the properties you desire
... but in the case of live broadcast could just drop the frames until you see the random pt
... though that is why it would be usefull
pal: recommend focusing on describing a straightforward constrained scenario
... infinity of scenarios, can't describe them all
... want something implementable
... keep it simple, not try to describe non-integral units
... should not crap out, but what you do depends on many factors
... otherwise very hard to describe
johnsim: is part of the problem that the HLS spec is under-specified
Michael_Thornburgh: HLS spec says it must contain a random pt, does not say where
<pal> 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...
Michael_Thornburgh: use the timestamps for synching bit-rate changes, but otherwise is very light on specifying
... does have some constraints on codecs
... the audio might be relaxed in more recent version
... if you know your media your implementation doesn't have to be super complicated
... the generic HLS case could use the more complicated case, could result in blackness
... that's probably OK to.
<pal> 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)
Michael_Thornburgh: most media will probably start with random access points, but some may not and have a lesser experience
... that's ok -- decoder should not stop
... unnecesary constraint to start with random pt
pal: for content authors this would be confusing yes
Michael_Thornburgh: I think it's OK to define behavior in this case as blackness
acolwell: will think about it some more
<acolwell> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20900
Bug: 20900
Michael_Thornburgh: I opened this
... this is dropping the contraint about TS segments comprising complete access units
... real world encoders may not follow this constraint
... because of tricks to reduce TS stream overhead used today
... to reduce padding
... could be in a scenario where none of the segments have complete PES packets
... we should support this
acolwell: not sure why this was originally requested, someone else who knew more required this
boblund: think that came from Alex, a number of specs do require integral access units in PES packets
... think it was someone from Motorola Mobility with an email and explanation
<acolwell> http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0004.html
acolwell: here is the email
... maybe we can respond to this email
kstreeter: not sure this is what Gary was referring to
... need to be aware you might have data left at the end of the buffer and have to wait for more
... requires additional logic in your buffering layer
... more constrained profiles try to eliminate this
acolwell: don't have a particular preference
johnsim: if this doesn't reduce complexity, no need to include this constraint
acolwell: fine with removing the constraint and seeing what implementation experience tells us
kstreeter: that would please me
johnsim: I am ok with that
acolwell: ok I will remove the contraint
Bug 20901
Michael_Thornburgh: Also mine
<johnsim> c) NEW Bug 20901 -contiguous splice/append without knowing media segment internal timestamps https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901
Michael_Thornburgh: again discontinuity markers not fully specified in the HLS spec
... begins at time 0 in the M3U8
... the TS files are just appended in
... actual timestamp values are irrelevant except for moving track forward in an orderly fashion
... don't need to know what they are, just that they move forward
... would be nice to support that without having to write the parser in JS
acolwell: in general I agree, need to figure out how to address
... need an alternate way to handle append
... no matter what timestamps are, will set timestamps to be whatever is needed to set timestamp to 0
... just take what I have appended and put at end of what I have now
Michael_Thornburgh: might be more useful for multi-bitrate switching
... segments might no represent the same time
... might not be aligned
acolwell: not the only behavior, but would be an option
Michael_Thornburgh: append where you left off may not be what you want
... if you have a way of starting at 0 and moving forward with sequential appends that may be enough
... aborts may cause you to want to reset?
... a bitrate change timestamps stay consistent, discontinuity you want to pick up where you left off
... might be necessary to indicate a discontinuity across all tracks
... when you start appending all tracks are synchronize with the new timestamps
... could cause small gaps in the track
... further study and discussion is required
pal: currently the timestamp is relative to internal timestamp of media segments
... is that specifially to address the bit-rate scenario?
acolwell: just to make it simple for translating media timestamps to presentation timestamps
... we are out of time - lot's to think about
<pal> pal: what if timestampOffset was relative to global timeline, e.g. timestampOffset = 10 and internal timestamp = 1 at start, then implementation would simply add 9 to to internal timestamps
Summary of Action Items
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-02-12 17:06:27 $
Joe Steele

steele@adobe.com