This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22138 - Frame removal
Summary: Frame removal
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: PRE_LAST_CALL
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-22 14:15 UTC by Jon Piesing (OIPF)
Modified: 2013-06-11 15:23 UTC (History)
7 users (show)

See Also:


Attachments

Description Jon Piesing (OIPF) 2013-05-22 14:15:28 UTC
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? 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)?

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)
Comment 1 Aaron Colwell 2013-05-23 18:30:53 UTC
Marking all pre-Last Call bugs
Comment 2 Aaron Colwell 2013-05-24 00:26:47 UTC
(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)
Comment 3 Jon Piesing (OIPF) 2013-05-28 19:08:32 UTC
The questions in the previous comment have been pointed out to the person who originated this question and who has agreed to respond to them here directly.
Comment 4 Paul Cotton 2013-06-11 15:23:13 UTC
(In reply to comment #3)
> The questions in the previous comment have been pointed out to the person
> who originated this question and who has agreed to respond to them here
> directly.

The TF is resolving this bug as NEEDSINFO since we have not yet heard back on this matter.  Please reopen the bug if you can provide additional data.

/paulc
HTML WG co-chair