- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Apr 2013 16:38:35 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21375 --- Comment #4 from Aaron Colwell <acolwell@google.com> --- (In reply to comment #3) > (In reply to comment #2) > > Change committed. > > https://dvcs.w3.org/hg/html-media/rev/f7f2b7226543 > > > > Added text to clarify what should happen if detailed information about the > > exact decoding dependencies is not available. > Thanks, the text helps but I don't think it covers everything. > > "Remove all coded frames between the coded frames removed in the previous > step and the next random access point after those removed frames." > > What if you have no RAP picture as in videos using Gradual Decoding Refresh, > where it's the decoding of N consecutive frames that produces a RAP. > > Also, what if you have an Open GoP ? Removing up to the next RAP does not > guarantee that the frames after the RAP will be decodable. > > Basically, there should be only simple SAP (as defined in DASH) in the > sequence for this to work. Sorry for the delayed response. I think we only have to worry about SAP types 1 & 2 since that is what the ISO BMFF bytestream section spec defines as a RAP. WebM currently doesn't use the other SAP types. I'm not sure what the story is for MPEG2-TS, but at least the defined behavior ...encourages... closed GOPs. Worst case scenario, removal is too aggressive for these other SAP types which either encourages the UA to collect more detailed dependency info OR encourage content owners to insert type 1 or type 2 SAPs where necessary. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 23 April 2013 16:38:37 UTC