- From: <bugzilla@jessica.w3.org>
- Date: Fri, 05 Apr 2013 17:32:25 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431 David Singer <singer@apple.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |singer@apple.com --- Comment #8 from David Singer <singer@apple.com> --- I think we have to be careful to distinguish to between editing operations: I want 30 seconds of this content appended after a 3-second green-screen, and then after all that I need 2 minutes of this other content; from segmentation/delivery operations: I want to deliver this content in roughly 5-second segments. In the first, it's important that cues get truncated to match the edits. This is a content-level operation. In the second, segmentation software typically doesn't look at or below the content level. If there are 'long duration' video frames (e.g. a slide-show, a slow time-lapse), that's the way it is. The VTT-in-MP4 work has focused on making it possible to random access, edit, splice, fragment long cues to make segmentation easier, and so on, and know whether some cue is still active. What Silvia suggests -- a repetition that is labelled as such -- is indeed possible. The DASH work explicitly considered that segment boundaries may be 'ragged edges' -- some tracks may have content that persists after the boundary. But ideally the degree of raggedness is not 'large' (comparable to the segment length). Both are possible in MP4: if you're authoring for segmented delivery then I would suggest segmenting cues also so that cues (and repetitions) are shorter than the shortest expected segment length. Otherwise, you have a significant ragged-edge issue. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 5 April 2013 17:32:27 UTC