[MPlayer-dev-eng] more NUT questions

[Ivan Kalvachev]

Michael Niedermayer said:
> 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, ...
The probelm with lossy codec is subjective quality.
I think that for high quality encoder tries quite a many
possible combinations, until it find the optimal(quality/speed/size).

This is not lossy codec. It is file format.
And while encoders are complicated, this file format is
suposed to be simple.

Anyway I think that We have reached the point of pointing
issues. And the discution is about to be turned into flames.
Next time I will propose few changes.
(removing flags and diffrent prediction methods).

I just want to find any possible issue. That's why I give
imaginable situation, that should be troublesome for the
demuxer.


> > 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
Well, it was just an idea.
I was thinking that this would simplify the (de)muxer as it will have to work
with single constant (in size) buffer.
BTW why is then frame_type0 size limitation? I mean why excacly that size?

> [...]
> 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)
Well you have done it the way I would.
That so why do you need stuffing then?
And no I have not looked in the source. It is nearly imposible to find
mistakes in the specifications if you know how it should work. I mean that
if something have dual meaning (like packet/frame  size), but
you know how it should be, you miss to find the second (wrong) meaning.

> [...]
That this mean that you accept the rest?
;)

>> 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
Well, we could at least dream of it. Who knows the future.
If you had the money (as donation) would you patent it?

Or would you patent some of the stuff you have wrote/invent by yourself?

I personaly believe that GPL software should not be in defendent position,
about patents. GPL should make it's own portfolio.
Just look how an Gnome program become patented by Microsoft. And the patent
documentation contain gnome and kde logos on the pictures!

Best Regards
   Ivan Kalvachev
  iive