- From: <bugzilla@jessica.w3.org>
- Date: Fri, 24 May 2013 00:26:47 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22138 Aaron Colwell <acolwell@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acolwell@google.com --- Comment #2 from Aaron Colwell <acolwell@google.com> --- (In reply to comment #0) > Related to issue #21375, when removing frames from one buffer (need random > access point flag = true), is there a time relationship to other track > buffers to adjust those as well? I don't understand. Track buffers are self-contained. There should not be any decoding dependencies across tracks. > If coded B/P frames are removed from the > buffer, because the corresponding I frame is gone already, this will also > shift the time line of that media stream. Will that shift be communicated to > the other tracks to discard content from those as well, although it may not > be necessary (audio = each frame can be a RAP)? Why would the timeline shift? Removing a B/P frame doesn't change the timestamps on any of the other frames. It just triggers removal of any frame that depends on the frame that was removed. This may cause holes to appear in the timeline, but it would not cause any frames that remain in the buffer to move their position in the timeline. A removal in one track buffer does not trigger removal in any of the other track buffers. > > NOTE: This issue arises from joint discussions between the Open IPTV Forum, > HbbTV and the UK DTG. These organizations originally sent a liaison > statement to the W3C Web & TV IG which is archived here; > > https://lists.w3.org/Archives/Member/member-web-and-tv/2013Jan/0000.html > (W3C member only link) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 24 May 2013 00:26:54 UTC