[MPlayer-dev-eng] more NUT questions

[Ivan Kalvachev]

D Richard Felker III said:
> On Sat, Apr 17, 2004 at 04:34:07AM +0300, Ivan Kalvachev wrote:
>> Michael Niedermayer said:
 hmm. Now I see why we need frame_code! flags are not compressed
>> optimally ;)
>
> I tend to agree.

:)


>> > > > > 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.

I agree. I also though about it. It would be useful to use both
older timestamps and older durations (well, will try to find something
useful)


>> > > 11. There is no way to check is frame_type  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  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.

It is just an goal priority. I think that in a different thread
Michael showed that if frame_type0 is not used, the overhead doesn't
increase dramaticaly.
The point is that if we have the size of the packet we already know
the size of the frame. So there is no need for complicated storing
schemes.

I have gave and posible solution. Why don't you argue about it?

>> 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...

It is kind of hack, but it is nice one. If I have faild to explain.
We write 16k for index even if it is empty. We use an 16kb memory buffer.
Every time when we write packet we add it to the index.When the index is
full (including pointers size) we write the ready index at the empty
space. Then we write another blank 16k for the next index. And so on.

This will allow to have indexs in right position for streaming and to
made indexes while capturing.
And yes, it doubles the requared demuxer memory from 16k to 32k.
After all index is optional, we may not read it on Apple-II computers.

If you have better idea I would like to hear 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.

No. We need some system for validation of packet headers data.
We cannot afford one broken packet to break the chain.
Just like I gave example with frame_type0.

If we have broken part, we may read wrong forward pointer,
we may jump near the end of file and after that to jump out of the file.
The demuxer will find the error and will try to resync (look for startcode).
Unfortunatly we will think that only this packet is damaged and we
will sync a long after the problematic position.


>> 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!!

Well, ther are error correction codes available. I have seen
e.g. rar file to repair and fair big chunk of bytes (512),
using only 1% overhead (in 1mb file).
I'm not very skilled in this area but this is the only
way to learn:)

You cannot have error resistance without some kind of check codes.
Otherwise I would recomend to remove all crc in all data and to use
MPEG-TS (or some other format that have error resistance)
as container above nut.

Best Regards
   Ivan Kalvachev
  iive