[MPlayer-dev-eng] more NUT questions

[D Richard Felker III]

On Sat, Apr 17, 2004 at 04:34:07AM +0300, Ivan Kalvachev wrote:
> Michael Niedermayer said:
> > Hi
> >
> > > On Wednesday 14 April 2004 21:31, Ivan Kalvachev wrote:
> > >
> > > THAT"S THE POINT. We have 256 frame_codes (hmm less than 256),
> > > so we can code 256 lsb combinations.
> > > But frame_code is used also for flags(128 possible)
> > no, there just 24 legal combinations of the flags
> > packet_type(P)        msb_size(D)     pts(TTT)        keyframe(K)
> > 0             X               XXX             X               20 cases
> > 1             X               101             X               4 cases
> >
> hmm. Now I see why we need frame_code! flags are not compressed
> optimally ;)

I tend to agree.

> > > 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 think about it, many combinations simply dont exist, non-keyframes in
> > audio streams? full timestamps will be rare, keyframes in video streams are
> > rare too, ...
> If nut is used for capture it will be used with ffv1,huffyuv,ljpeg codecs
> that use only keyframes.

Overhead is irrelevant for these codecs, since their compressed frames
are absolutely huge. What's 20 bytes of header when each frame is 200k
or more?

> I'm not aware if there are any audio codecs
> that use compensation, but it should be possible.

You mean audio codecs with predicted frames? I think some do exist...

> > > > > maybe average (or median) would
> > > > > have more sane (it may even be in timestamp units) e.g.
> > > > > time_base=1001/24000, average_frame_time=1; => fps=23,976
> > >
> > > What's wrong with this?
> > u didnt explain for what it would be usefull
> In timestamp prediction.

It's not useful because you can't know it. It's much better to store a
flag that means "same delta as previous", etc. And remember several
levels of previous deltas.

> > > 11. There is no way to check is frame_type 0 broken. If there is small
> > > broken part in frame_type_0 beginning we will get wrong frame_code.
> > > We will read some values. We will seek to some position.
> > > And so on, until we jump out of stream, calculate negative or
> > > forbidden value.
> > yes, its always the case, u parse format foobar until u see a illegal value
> I though that error resistance was one of the main goals. We need something
> to catch possible error (read - spend few more bytes).
> One naked byte sitting in the middle of nowhere. This is the weakest spot
> in the chain. After one broken frame_type0, we will lose all frames of
> type 0 after it, even if they are not broken.

IMO error recovery at the expense of significant size is not a good
tradeoff. You shouldn't have corrupt files lying around... But perhaps
there's a way to meet both goals.

> Just an rough idea.
> Make index_packet fixed size. (16k). Write as many entries as possible.
> index_packet must have additional (fixed size) pointers to previous/forward
> index_packet. sequence_start packet may point directly to the 1'st index.

Forward pointer (to next index packet) is impossible because it's not
known when the index packet is written. Anyway I find this whole
design an ugly hack. There has to be a correct way to do it...


> > > Solution 4.
> > > GOP. All frame headers at one place. Kinda of #2.
> > > Even better, it could be some kind of destributed index.
> > > small indexes all over connected with forward/backward pointers.
> > > Hmm sound familiar, maybe I have seen it before?
> I think that this is the right solution:
> Headers of frame_type0 frames should be packet together with the last
> packed_header-ed packet. This way they would be protected by the crc
> of the same packet. Anyway if the packet is broken usually demux of
> next frame_type0 it won't be possible.

WTF?!?! There is no CRC!!! CRC is totally useless.

> And yes, there MUST have crc. We may not calculate crc for the whole
> packet, but only for the header(s). This may allow smaller crc (1, 2 bytes).

What good does this do? Knowing that the data is corrupt is totally
useless unless you can repair it. All CRC does is waste space. CRC is
absolutely not acceptable!!

Rich