[MPlayer-dev-eng] NUT questions

[Michael Niedermayer]

Hi

On Tuesday 13 April 2004 01:01, Ivan Kalvachev wrote:
> 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. 
no

> (it is 
> definitely possible to have about 64k different sizes sequentially)
huh? sizes of what?

> I also 
> wonder how the program knows them before starting encoding.
i have the feeling that u missunderstand the way the frame sizes are stored, 
they can either be identical to the 2 last recent used, or the least 
significant bits are encoded in the frame_code and the most significant bits 
in a vlc afterwards

>
> - How timestamp is coded (mul,lsb look too limited/small),
use larger font :)

> initial_timestamp_predictor is not explained. 
spec fixed
---
the last timestamp differences are reset to the 
initial_timestamp_predictor values from the stream header if a
packet of type not 0 in encountered
---

> WTH is "next last"? 
spec fixed
---
next_last is the second last unique data_size, for example:
previous data_size: 123,500,312,500,500    last=500, next_last=312
---

> The maximum timestamp change is not clear.
please elaborate, i dont understand ur question

> (well, there is mode where full timestamp could be transmited)
yes

>
> - How the size of packet is coded. initial_data_size_predictor is not
> explained.
spec fixed
---
last and next_last are reset to the initial_data_size_predictor values
stored in the stream header if an frame with type > 0 is encountered
---

> 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)
no limit, no seriously, if u have enough memory u could have 2^1000 size 
packets :)

>
> 2. won't it be better checksum to be moved before reserved_bytes?
no

> 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).
NO, this may require seeking back to update them, and this may be a problem 
for some muxers, the packet size is already there, but its much easier to 
predict the packet size instead of a checksum

>
> 3. In stream_header fixed_fps is useless, 
its usefull for transcoding to container formats which only support fixed fps, 
and its usefull for error detection

> 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? 
no, u will find one approximately every 4 exa byte in a random 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?
probably, but designing a format which makes it impossible to break it 
intentionally is not really our goal i think

> Or in the worst case if we have nut in 
> nut, we may find wrong packet with right checksum.
puting a container format into another like ogg in avi is a ugly hack, putting 
the same container format into itself is so idiotic that it hasnt been done 
yet (AFAIK at least)
but that problem isnt specific to NUT, just try it with another format ...

>
> 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. ;)
yes, iam not exactly sure if some strict ordering should be enforced, it could 
be very difficult for some muxers to support, just think of realtime capture, 
we dont want to waste time with buffering there

>
> 7. The stream_id explanation is not very clear. Need rewording.
yes, if there are no objections, ill drop the stream_class ordering stuff

>
> 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!
i dont see the problem here, if theres a frame_type2 start code its a type 2 
frame if theres no such startcode, its not a type 2 frame

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

>
> Best Regards
>    Ivan Kalvachev
>   iive
>
> p.s.
> And don't RTFS me.
:(

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