[MPlayer-dev-eng] NUT questions

[Ivan Kalvachev]

Hi,

After seeing the mail about nut, I decided to take a look
of it. So here are some of my questions:

1. There are some ideas that are not obvious, and not telling them in the
specs make it very hard to read.

What is not obvious (; the main things)

- frame_code. It looks like it is some re-usage schema, but I wonder if it
is possible to make more than maximum allowed 256 possible codes. (it is
definitely possible to have about 64k different sizes sequentially) I also
wonder how the program knows them before starting encoding.

- How timestamp is coded (mul,lsb look too limited/small),
initial_timestamp_predictor is not explained. WTH is "next last"?
The maximum timestamp change is not clear.
(well, there is mode where full timestamp could be transmited)

- How the size of packet is coded. initial_data_size_predictor is not
explained.
There is no way to give packetsize without using compression of
frame_code. It is very strange to have 2 sizes (prev/next) in explicit
form, and such complicated schema for packet size compression (for frames
with packet_header)

- What's the maximum packet size. ( I guess it is around 65536)

2. won't it be better checksum to be moved before reserved_bytes?
I like keeping all known fields in one piece
I guess it is better they to be right after packet_header (or part of it,
if this doesn't conflict readability).

3. In stream_header fixed_fps is useless, 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

4. That worries me much are the recording issues. The drift of audio
sampling frequency. Audio packets have timestamps so possible
workaround maybe audio to use system time for them, and not the time
calculated from the frequencies. Rich said that audio should be
resampleed to correct sampling frequency, but nor FFMpeg nor MPlayer have
such precise resampler (check af_resample if you don't believe me).


5. Is there some protection against start code appearing in the data
stream? MPEG always use VLC codes and bitstream syntax that guarantee
that. If I made encoder that dumps only startcodes as data, will this
affect parsing damaged nut file? Or in the worst case if we have nut in
nut, we may find wrong packet with right checksum.

6. After latest change, it is not clear when main, audio/video stream, and
frames are positioned in the stream. Only header order is given. ;)

7. The stream_id explanation is not very clear. Need rewording.

8. Hmm, something even more fishy. We have frame_type2_startcode if we
have frame_type=2. But frame_type=2 is indicated by
(flags[frame_code]&1)==1. Yeh, frame_code is written after the startcode!

9. It is very strange that spec talk about decoder/encode. I guess you
mean muxer/demuxer?

Best Regards
   Ivan Kalvachev
  iive

p.s.
And don't RTFS me.