HTML Media Task Force Teleconference -- 12 Feb 2013

http://www.w3.org/2008/04/scribe.html

the number is 63342

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

kstreeter: 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

kstreeter: 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

<Michael_Thornburgh> joe: those comments were me, not KS

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_Thornburg: HLS spec says it must contain a random pt, does not say where

s/jphmsim/johnsim/

<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_Thornburg: 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_Thornburg: 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_Thornburg: I think it's OK to define behavior in this case as blackness

acolwell: will think about it some more

Bug: 20901

<acolwell> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20900

Bug: 20900

Michael_Thornburg: 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_Thornburg: 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_Thornburg: 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_Thornburg: 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_Thornburg: 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

s/\(him \=\= pa\l)//

s/\(him \=\= pal\)//

- DRAFT -

HTML Media Task Force Teleconference

12 Feb 2013

Attendees

Contents

Agenda

Open Actions

Baseline Docs

Outstanding Bugs

Summary of Action Items

Scribe.perl diagnostic output