On Fri, Feb 24, 2006 at 02:31:15PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
New patch. One kink left to sort out is info frames. My suggestion for it is to use negative chapter id's..
Can I commit this patch?
ok
committed, with one additional clause: +Info SHOULD be stored in global packets instead of info streams/frames if +possible, and the amount of data is not large.
Taken from Michael's phrasing a while ago...
Now, my idea for info frames - exactly the same as info packets. The pts for info frames is completely meaningless, it's only there to be able to comply to MN rule, so there can be repeated info frames, that describe the same "chapter", and you can see that they are the same info frame because they have the same chapter id, which means they must be binary identical.
I'm against it, unless you're proposing that we remove info streams entirely.. This completely nullifies the stream-quality of info streams. There's no guarantee that you'll have the frame by the time it becomes relevant, or that it won't appear way before it's relevant, etc.
Rather, I would _like_ to do like this: info frames have no chapter_start or chapter_len because these values are implicit in their frame pts and the next frame pts (possibly EOR). However, this
iam against this, info frames and info packets should be identical so we can remux info stream stuff into info packets if we want to or the other way around without looking at the contents furthermore if we start playing in the middle of a chapter we will need some repeated info frames to figure out what we see
If you're against this adamantly then we might as well remove info streams entirely, since your objections ruin the whole stream property of info streams that I wanted them for. The problem is this: if you have a reason to use info streams instead of info packets at the header, it's because chapter length is NOT known at the time the first info frame for the 'chapter' is written. Consider something like a like news show where the info is produced by someone at the studio at the same time it's being transmitted. A simpler more realistic example would be a live net radio show with DJ segments (unknown length) and songs (known length). I have a proposal that works, IMO. It requires some alterrations to convert info frames to info packets, but ONLY in the header (chapter start/length), not any of the contents (key/value pairs). It works like: 1. All info frames with the same chapter id must be binary identical. 2. The first info frame with a given chapter id determines the start time of the chapter from its pts. 3. An info frame with different chapter id (or EOR) marks the end time of the previous chapter. Info frames with same chapter id are just repetition and have no other meaning. This scheme allows full stream-type semantics for info frames, so that they work as intended. Oded had an alternate proposal of just storing 0 as the chapter length if it's unknown. I objected to this because it's lossy, i.e. these chapters, like all chapters, _do_ have a length; it's just not known until further along in the stream. Surely it could be stored in other ways (like key/value pairs), but this precludes easy remuxing chapter information from a live stream into chapter information for a permenant file, since you'd have to parse special keys. One objection you may have to my scheme is that it precludes overlapping chapter spans. I thought this was a problem too and didn't like it at first, but then Oded pointed out that you can use more than one info stream if you need to (the above points 2-3 should be interpreted only within a single given stream). Comments? Rich