2009/6/20 Silvia Pfeiffer <silvia at silvia-pfeiffer.de>:> I agree, this has been a huge problem - and in fact is a problem with > html5 <video> more generally than ogg. > > How do you think that a chain identifier in skeleton will make it > possible to have e.g. a single seek bar over a stream? Would it be n > timelines or one?I was thinking that it would be useful to identify sections that are logically part of the same content. eg. if you edit out some part of file A, and end up with the chain A1, A3. Then after that you play file B, and after that you play some data derived from file C. You might end up with a chain sequence like A1, A3, B, C1, C2, C5. Perhaps it would make sense to give a seek bar for (A1, A3), then reset it for B, and reset it for (C1, C2, C5). Does that make sense? (Use cases would be useful here...) K.> > Cheers, > Silvia. > > On Sat, Jun 20, 2009 at 10:52 AM, Conrad Parker<conrad at metadecks.org> wrote: >> Hi, >> >> An issue that's been cropping up recently is chaining support. We >> discussed this a bit at FOMS 2008, and there are some open issues. >> There was talk of making some skeleton-like metadata that spans chain >> boundaries (or perhaps putting into skeleton a "chain identifier"). >> Other things that need to be specced out: >> >> ?* edits vs. playlists: how to distinguish between chains that have >> come about by removing part of an existing file, vs. a sequence of >> completely separate files >> ?* how to present a seek bar to the user for each kind of chain, ie. >> one timeline for the entire sequence? >> >> Perhaps all we need is a field in skeleton (could be a text >> message-header field) for "sequence identifier", which identifies >> chain sections which are part of the same edit. >> >> Chain sections which are just a concatenation of files to play (eg. >> output from icecast) would be distinguished by not having the same >> sequence id, either by explicitly having different sequence ids or by >> not having a sequence id at all (the current case). >> >> Conrad. >> _______________________________________________ >> ogg-dev mailing list >> ogg-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/ogg-dev >> > >
On Sun, Jun 21, 2009 at 01:27:25AM +0900, Conrad Parker wrote:> 2009/6/20 Silvia Pfeiffer <silvia at silvia-pfeiffer.de>: > > I agree, this has been a huge problem - and in fact is a problem with > > html5 <video> more generally than ogg. > > > > How do you think that a chain identifier in skeleton will make it > > possible to have e.g. a single seek bar over a stream? Would it be n > > timelines or one? > > I was thinking that it would be useful to identify sections that are > logically part of the same content. > > eg. if you edit out some part of file A, and end up with the chain A1, > A3. Then after that you play file B, and after that you play some data > derived from file C. > > You might end up with a chain sequence like A1, A3, B, C1, C2, C5. > > Perhaps it would make sense to give a seek bar for (A1, A3), then > reset it for B, and reset it for (C1, C2, C5). > > Does that make sense? > > (Use cases would be useful here...)Is what you have in mind somehow like chapters of a DVD, IOW points in time you yan jump to? That's something I'm looking for. Currently, I'm using OGM containers to store movies with chapters. That's an usecase where I play a movie from disk, but I think it could also be useful for streaming video. Let's say you've got a 50min video of a conference talk. It'd be a nice feature if it had named chapters like 01-introduction, 02-topic1, 03-topic2, ..., 09-conclusion. I watch the introduction, skip forward to chapter 3 because I'm interested in topic2, and then skip to the conclusion. Thanks, Hans> > K.
2009/6/21 Hans J. Koch <hjk at linutronix.de>:> On Sun, Jun 21, 2009 at 01:27:25AM +0900, Conrad Parker wrote: >> 2009/6/20 Silvia Pfeiffer <silvia at silvia-pfeiffer.de>: >> > I agree, this has been a huge problem - and in fact is a problem with >> > html5 <video> more generally than ogg. >> > >> > How do you think that a chain identifier in skeleton will make it >> > possible to have e.g. a single seek bar over a stream? Would it be n >> > timelines or one? >> >> I was thinking that it would be useful to identify sections that are >> logically part of the same content. >> >> eg. if you edit out some part of file A, and end up with the chain A1, >> A3. Then after that you play file B, and after that you play some data >> derived from file C. >> >> You might end up with a chain sequence like A1, A3, B, C1, C2, C5. >> >> Perhaps it would make sense to give a seek bar for (A1, A3), then >> reset it for B, and reset it for (C1, C2, C5). >> >> Does that make sense? >> >> (Use cases would be useful here...) > > Is what you have in mind somehow like chapters of a DVD, IOW points in time > you yan jump to? That's something I'm looking for. Currently, I'm using OGM > containers to store movies with chapters. That's an usecase where I play a > movie from disk, but I think it could also be useful for streaming video. > > Let's say you've got a 50min video of a conference talk. It'd be a nice > feature if it had named chapters like 01-introduction, 02-topic1, 03-topic2, > ..., 09-conclusion. I watch the introduction, skip forward to chapter 3 > because I'm interested in topic2, and then skip to the conclusion.You are essentially talking about a table of contents (TOC), and the two approaches are: 1) include an explicit list of chapters [offset,title] in the file header 2) include markers in the stream at the start of each chapter The advantage of an explicit TOC is that it is quick to parse and then jump to arbitrary points. The disadvantage is that it is only useful to apply to finished files (ie. impossible to apply to live streams). The advantage of in-stream markers is that they can be added during streaming of live content, ie. before production of the entire file is finished. The disadvantage is that the whole on-disk file needs to be scanned to find them (ie. inefficient to apply to disk files). The design of Ogg has generally leaned towards streamability, ie. not including too much information in the up-front headers. The inefficiency of the in-stream approach can be overcome by caching: an application can scan the file once and store the TOC in a separate file. * For a desktop media player this is straightforward: cache the chapter offsets, and offer a navigation menu. * For a web application: access to the chapters can be made available through the URL for the video stream, using the ?id= or #id= syntax (currently in draft in the W3C Media Fragments WG). Of course it is useful, especially for desktop apps, to use a common TOC format. The same TOC file can be shared between multiple versions of the same video content, varying by codecs and encoding quality levels. Any suggestions for a TOC file format, preferably documented? Chaining is essentially a version of in-stream markers. However it is really a hard cut in the stream, essentially a separate file. I think we could handle markers with something more lightweight, like a dedicated CMML track with id attributes. Conrad.