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

[Ivan Kalvachev]

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
needed..

Unnecessarily limiting standard won't bring anything good.


Wish You Best
    Ivan Kalvachev
  iive