[MPlayer-dev-eng] more NUT questions

[Michael Niedermayer]

Hi

On Saturday 17 April 2004 03:34, Ivan Kalvachev wrote:
[...]
>
> > > I cannot understand how we syntheses these codes before start encoding
> > > (they cannot be written at the end just like the index) and how we are
> > > sure that they will be enough.
> >
> > basic logic, if we can encode every possible frame, then they are
>
> enough, and
>
> > we just need to use 4 frame_codes of the 255 to ensure this, the
> > remaining 251 can be used to store the most likely packets, how does the
> > muxer know which are likely? its the problem of the muxer, but its really
> > not
>
> difficult,
> If I write muxer, it is my problem. If I don't know anything about the
> nature of the data that is coming, I cannot make right prepositions.
> If I cannot make right prepositions I won't make optimal stream.
> If I cannot make optimal stream from first try, I don't need this
> compression scheme!
just because u cant find the _optimal_ solution doesnt mean the system is bad, 
look at _any_ lossy codec, u will never be able to find the optimal solution, 
there are too many dependencies, idct rounding, dependence of the previous 
frames, subjective quality, ...

[...]
> > > Don't forget that the size/pointers/ are vlb, so we may not be able to
>
> fix
>
> > > them even with seeking (at least I don't know system function for
> > > inserting bytes):
> > > Hmm, now I see why you define stuffing vlb code (0x80).
> >
> > yes, exactly thats why 0x80 is there :)
>
> I don't like it at all. How about setting limit of _header_ to 16k?
i dont see any advantage in such a limit, a demuxer shouldnt have a problem 
with larger headers and a muxer can always chose to write small headers if it 
doesnt support larger ones, btw, its (near) inpossible to create >16k headers 
if we ignore global codec headers, about the 0x80 stuffing i see no reason to 
disallow it, it gives muxers more flexibility, a muxer doesnt have to use it

[...]
> > > But by "guessing" I think that you mean to examine all parameters
> > > before writing. Well you can easily compute and crc with it:P
> >
> > no, its not easy, its quite complicated, for size we would just need a
> > size= get_length(a) + get_length(b) + ...;
> > i leave the code for generating the checksum to u ;)
>
> The complexity of get_length() is very close put_v() complexity.
> If we use buffer it would simplify all calculations.
u dont seem to have looked at our implementaton, libavformat internally uses a 
buffer for muxing and it calculates the checksum before flushing the buffer 
or if the muxer explicitly asks, that way the muxer only needs 2 lines of 
code to calculate the checksum, and thats independant upon the size of the 
block upon which the checksum is calculated (it doesnt have to fit in the 
buffer)

[...]

>
> Also it may be fun to patent nut once it is finished. This will give us
> full control of suspending clones under different licenses.
> The only problem is money. (GPL will be ok, if we give free permission
> for all GPL-ers )
do u have any clue how much patenting costs? and actually sueing and winning a 
lawsuit cost MUCH more

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en