[MPlayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.75,1.76

[Oded Shimon]

On Sat, Sep 17, 2005 at 09:27:41PM +0200, Michael Niedermayer CVS wrote:
> CVS change done by Michael Niedermayer CVS
> 
> Update of /cvsroot/mplayer/main/DOCS/tech
> In directory mail:/var2/tmp/cvs-serv1787
> 
> Modified Files:
> 	mpcf.txt 
> Log Message:
> add back_ptr
> add info_frames
> require sync_point after headers
> require info packets to be between headers and frames (or you could say they are headers now)
> add userdata stream type

We should probably also refine max_distance like I said - distance between 
startcodes.

Oh, and what does the checksum of an info frame cover? probably same as it 
does in an info packet, the data itself, but this should be mentioned. (is 
there a checksum at all for info frames?..)

It should be dictated that all info frames should be marked as keyframes, 
and all of them must appear in the index (except repeated frames?.. see 
my question below). basically, max_index_distance should be zero/ignored 
for these streams.

[...]

> +		Info frames
> +a info frame can be repeated, but must then be exactly identical
> +Note, such repeated frames can be detected by their pts difference of 0
> +Info frames can be used to describe the file or some part of it (chapters)

Why and more importantly how can info frames be repeated?...

Since an info frame has a pts, and applies to a local area, it only makes 
sense to put it in that local area. so if you repeat it at all, you're 
gonna repeat it at exactly the same place, this is completely redundant.

unless you mean i can do this:

I0 .... I1 .... I2 .... I0I1I2

which would be totally insane in implementation as i'd have to store the 
pts's of all info frames (or just ignore them alltogether?.. what am i 
supposed to do at all with such chunks?)

Actually, I think I see a scenario where what i just said does make sense - 
chapters. put all the info frames together in the begginning/end/whatever, 
mark so in the index, and spread them in the places where they correctly 
should be, so the player can now read all chapter info easily (instead of 
seeking all over the place).

is this sane? am i way off in understanding what you meant?

hey, more so, if it is done like this, then the info frames which can be 
sanely read without much seeking should be marked as keyframes and 
mentioned in the index, and the "spread out" info frames should be marked 
as non keyframes and not in the index. this way, the demuxer will only read 
all the info frames mentioned in the index.

hmm, damnit, i see I have completely changed my opinion halfway writing 
this mail. i hate it when that happens, and it happens often. :(

BTW, in case noone noticed, there's no 'chapter' type in the info table :)
I propose
"ChapterId", "v"
"ChapterName", "UTF-8"

- ods15