[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

[Michael Niedermayer]

Hi

On Thu, Mar 02, 2006 at 12:31:16PM -0500, Rich Felker wrote:
> On Thu, Mar 02, 2006 at 04:29:50PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Thu, Mar 02, 2006 at 01:25:38PM +0200, Oded Shimon wrote:
> > [...]
> > > > > >      EOR frames MUST be zero-length and must be set keyframe.
> > > > > >      All streams SHOULD end with EOR, where the pts of the EOR indicates the
> > > > > >      end presentation time of the final frame.
> > > > > >      An EOR set stream is unset by the first content frames.
> > > > > >      EOR can only be unset in streams with zero decode_delay .
> > > > > > +    has_checksum must be set if the frame is larger then 2*max_distance or its
> > > > > 
> > > > > I still feel this should be a seperate variable, the only reason you gave 
> > > > > so far against it is that poor demuxers won't be able to decide... And IMO 
> > > > > that's a very poor argument...
> > > > 
> > > > every additional field adds complexity, what do we gain here with that field?
> > > > personally i would fix max_distance and not store it at all, as i fear people
> > > > will set it to random values
> > > 
> > > ?
> > > if (frame_size > 2*nut->max_distance)
> > > 
> > > if (frame_size > sc->max_size)
> > > 
> > > I fail to see the added complexity...
> > > 
> > > As for what do we gain - more freedom to the muxer, and the ability of 
> > > limiting for ex. audio to a very small size and not increasing overhead, 
> > > and limiting video to slightly higher to avoid additional overhead...
> > 
> > agree but only if we store all these max_size/distance stuff in u(16) so
> > they cannot be arbitrary large
> 
> NO! They really need to be arbitrarily large! If you have a file where
> each frame is at least 5 megs, max_distance is useless unless it's
> well over 5 megs!

are you drunk? if all frames are 5megs then max_distance==5mb will give
you exactly the same file as any smaller max_distance, now if max_distance is
set to 10mb you reduce the overhead by 1 syncpoint every 10mb, if its set
to infinite you gain 2 syncpoints per 10mb and loose the ability to seek

1 syncpoint needs approximatly 8(startcode)+1(forw_ptr)+3(back_ptr)+4(pts)
+4(crc) = 20byte

are you seriously insisting on allowing the user to set max_distance higher
then 5mb?! thats a maximum gain of 40byte per 10mb or 0.0003815%

now i hope that the average windows kid will be smarter then rich and not
come to the same conclusion that larger average frames somehow need larger
max_distance, or otherwise we can forget the error recovering capabilities of
nut in practice

sorry but i wont continue these disscussions, expect me to fork if this
continues, proposals should be judged on their effects (like overhead,
complexity, error robustness, amount of memory or computations or delay
, ...) but not on philosophical ones, nonexisting codecs, nonexisting demuxer
architectures, nonexisiting kernels and so on

my proposed header compression, which has negligible complexity would reduce
the overhead by ~1% and was rejected based on nonexistant kernel and demuxer
architectures
so either 0.0003815% is significnat that my header compression will go into
the spec or arbirary sized max_distance leaves it, choose, but stop to change
the rules for each thing depening upon if you like it or not

[...]

-- 
Michael