[NUT-devel] FINALIZE NUT SPEC!!

[Oded Shimon]

Move thread to nut-devel... Sorry, I should have mentioned in the first 
mail that all replies should go to nut-devel if possible.

On Mon, Feb 27, 2006 at 01:34:52PM -0500, Rich Felker wrote:
> On Mon, Feb 27, 2006 at 03:43:52PM +0200, Oded Shimon wrote:
> > Also I want to improove speed, everytime I seeked back the damaged region 
> > when reaching it again it linear searched the entire ~200mb of damage 
> > again...
> 
> This might be desirable in the case of an incremental download, but in
> general it's probably good to cache known bad regions.

Which actually also brings the issue of seeking in a "growing" file. In the 
first seek you do, libnut does a discovery seek of finding the last 
syncpoint in the file, and marks it known. The only way it can invalidated 
is by playing past it (libnut automatically realizes this simply by adding 
a syncpoint to the syncpoint cache past the last syncpoint...). I should 
make some kind of signal in the API to indicate file has grown...

> > I object to index splitting because it is unnecessary complexity for very 
> > very rare occassion - partial damage in a 80kb chunk in a seekable stream.
> > Now you can copy the index anywhere, it's even more unnecessary...
> 
> I tend to agree. If one sector of the index is broken it's likely that
> many are. And if the index is unusable, it's not the end of the world.
> Just seek without index or rebuild the index.

In theory it does sound bad to loose such a nice feature over a "single 
byte" when you can salvage some of it by splitting, but in practice I don't 
ever see such a situation happenning. Seekable streams (streams which have 
an index at all) are probably permanent storage. Damage in permanent 
storage is practically always in HUGE chunks, not in a single byte...

> > The big problem I have with just info packets is that there's no way to 
> > really load them because they can be in any arbitrary location. Like we 
> > restricted the index being only after main headers and not any arbitrary 
> > location so demuxers can find it, same with info packets...
> 
> Global (chapter_id==0) info would still be required to be with
> headers, and users would have to put any other chapter info they
> wanted to be globally available with the headers too. Storing it other
> places would just be for streaming purposes.
> 
> However, for many streaming applications, you need the full power of a
> stream to represent realtime data reasonably. So even if we allow info
> packets at places other than with headers, I still want info streams.

If we're having info streams, then no "arbitrary info packets" please... 
They are an annoying complexity. (I have an api function, get_packet(), 
which when called either always gives a single frame, or throws an error. 
If it sees main headers, it skips over the entire header stuff, and 
recurses... With arbitrary info packets, this will have to turn nasty as a 
call could either give a frame, or an info packet...)

One nice advntage I see to dumping info streams is that, in reality, info 
streams don't really have "stream-like" behavior... (They make back_ptr big 
etc.)

- ods15