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.
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? 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 >
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 >> > >
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? >Chain segments with the same identifier would be treated as part of the same content, so would be concatenated in the same seek bar. The duration of the seek bar would be the sum of those chain segments (contiguously having the same chain id). A change of identifier would be a change of content and would be treated as for a playlist (eg. a menu accessible adjacent to the seek-bar). More concretely: I'm proposing skeleton message header fields: Chain-ID Chain-Title Chain-ID is a unique identifier, such as "peach-054". Chain-Title is a human-readable string, such as "Big Buck Bunny (Trailer)". A sequence of chain segments all having Chain-ID "peach-054" would be played in sequence, and a conventional seek bar should make this sequence appear to be an entire content item. If the Chain-ID then changes (to, say "orange-315") then the seek bar is reset for that content item. The item "Big Buck Bunny (Trailer)" may still be accessible via a playlist menu, and selecting that would revert the seek-bar for playback of that item. The Chain-Title values are not authoritative, so two chains having the same ID but different Title would still be treated as part of the same item. A player may choose freely which of these titles to display in a playlist (eg. use the first of the sequence). Conrad.> 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 >> > >