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

D Richard Felker III dalias at aerifal.cx
Thu Mar 10 00:51:24 CET 2005


On Thu, Mar 10, 2005 at 01:30:37AM +0200, Ivan Kalvachev wrote:
> On Thu, 10 Mar 2005 00:37:33 +0200
> Oded Shimon <ods15 at ods15.dyndns.org> wrote:
> 
> > On Wednesday 09 March 2005 21:38, Michael Niedermayer wrote:
> > > > I do think that it should be possible to be done it if linear reading is
> > > > needed..
> > >
> > > what do u want to use a index for if u are limited to sequential/linear
> > > reads? seeking would be impossible per definition
> > 
> > I know very little about all this indexing stuff/NUT/etc. Just want to throw 
> > in my 2 cents from a user prospective - A common scenario for me is 
> > downloading an AVI file linearly from a server, obviously the stream is 
> > seekable, but because the index is at the end, I can't seek in the file 
> > unless I do -idx or wait until the whole file is completed...
> > 
> > Personally, I see this as the only fault of AVI, and I understand the 
> > implementation problems with this, but I'm just saying if anything is 
> > possible to make NUT be able to support this, it would be great. (Does it 
> > already?)
> 
> AVI index could be on any place. It could be in the beginning or at the end
> in the middle or anywhere else.
> Well nut is going to be more limited in than avi.
> I can only hope that we will never will need to make such extensions,
> to handle super big files.

This is stupid trolling, nothing more, and unlikely to make anyone
listen to your points. It's been known from the first day mpcf.txt was
started that nut will never need any extension whatsoever to support
different size data. All fields are vlc.

With that said, only allowing index at the end does not make nut "more
limited than avi". It just means you're not allowed to do stupid
useless hacks. AVI implicitly allows all sorts of hacks which make it
difficult to write a demuxer that will handle any "valid" file, simply
because almost any nonsensical file is valid.

Look, the ftp/http streaming/seeking crap mplayer does is just that,
CRAP. It's abusive and should not have even been included to begin
with. These protocols are not made for random access, and creating
files especially to "work around" that is just an ugly hack. Use a
protocol that's suitable for the situation. Don't misdesign your file
formats to work around bad protocols.

Rich




More information about the MPlayer-cvslog mailing list