[MPlayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.69,1.70

Ivan Kalvachev ivan at cacad.com
Wed Mar 9 18:57:03 CET 2005

On Wed, 9 Mar 2005 17:22:08 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> On Wednesday 09 March 2005 16:23, Ivan Kalvachev wrote:
> > On Sat,  5 Mar 2005 00:12:44 +0100 (CET)
> >
> > syncmail at mplayerhq.hu (Michael Niedermayer CVS) wrote:
> > > CVS change done by Michael Niedermayer CVS
> > >
> > > Update of /cvsroot/mplayer/main/DOCS/tech
> > > In directory mail:/var2/tmp/cvs-serv5211
> > >
> > > Modified Files:
> > >  mpcf.txt
> > > Log Message:
> > > returning to the old index at the end system, alternatives are too
> > > complex with questionable advantages
> >
> > Mostly agree.
> >
> > But I have one big objection. For online playing it is good the index to
> > be in the begging of the file so no additional seeking should be done.
> > (seeking over ftp and http is very slow, mplayer de facto closes the
> > stream and opens new one and server can detect this as intentional
> > attempt to overload it)
> >
> > Of course as dalias had pointed, with current indexing it is very hard
> > to relocate because the pointers inside index will also change.
> >
> > Well I request an simple change - pointers to be done relative.
> > In short it will show the offset in bytes between keyframes.
> RTFmpcf.txt
> index_timestamp
>         value of the timetamp of a keyframe relative to the last keyframe
>         stored in this index

I was talking about index_position. But if you change "last" with "previous" 
in both index_time<S>tamp and index_position, then it indeed seems
implemented this way.

On Wed, 9 Mar 2005 12:08:32 -0500
D Richard Felker III <dalias at aerifal.cx> wrote:
> Index should definitely not be specified as being at the beginning of
> the file! This destroys the ability to do linear writes, and playing a
> video over streaming ftp or http is stupid anyway. These protocols are
> not designed for streaming video. Instead use something where
> requesting the index and seeking can be made reasonably fast. Or
> better yet a protocol where you just tell the server the timestamp you
> want to seek to, and it uses the index to start streaming the right
> data to you!

Well, It is stupid but it is the easiest way. And It is something 
I don't have control on. So I must live with it.

I don't see why to don't allow having index in beginning. Yes it does
mean that I will have to reprocess (copy) the file once it have been
created or leave some space on purpose, with hope index will fit on it.
(20k is reasonable waste)

I do think that it should be possible to be done it if linear reading is

Unnecessarily limiting standard won't bring anything good.

Wish You Best
    Ivan Kalvachev

More information about the MPlayer-cvslog mailing list