[MPlayer-dev-eng] Flaming NUT

[D Richard Felker III]

On Fri, May 07, 2004 at 03:53:43AM +0300, Ivan Kalvachev wrote:
> Michael Niedermayer said:
> > ivan, maybe u want to mux your nut files with only 2 valid frame-codes and vlc
> > code everything afterwards, that way theres is a _lot_ of checking done (99%
> > of the frame_code bytes are invalid, 99% of the stream_id vlc too, ...)
> 
> Why should i replace 1/2^32 with 2/256?

Were you going to put a checksum on every single frame in the old
system? (This would include every 'laced'/subpacket frame in audio
packets, which was not in the spec.) If not, then Michael's suggestion
gives you more protection, not less, IMO.

> What is the overhead if this scenario is used?

If you don't store any pts/size info in the framecode, then you just
need the number of bytes to vlc code stream id, lsb timestamp and data
size, plus 1 byte (for the "dummy" framecode). Stream id and lsb
timestamp will each be one byte for sure, unless you're doing
something incredibly stupid. Data size will be 1-2 bytes most of the
time, and likely 3 bytes for video keyframes. So You have 4-6 total
bytes overhead per frame...

> Would you make some test with real movie. Will it be better than avi?

...which is less than Matroska (without lacing, possibly even with
lacing) and MUCH LESS than avi. You have to work REALLY HARD to make a
container with worse overhead than avi (or even comparable overhead).

> MPEG-TS uses one byte startcode. But as it have fixed size
> packets it is quite easy to check is this packet header or
> random byte. Inserting mpeg-ts into mpeg-ts would not be so
> big disaster as sync codes of the internal stream would be
> in increasing offset position and won't follow the pattern.
> 
> The killer stream of mpeg-ts is stream full of sync codes. But
> it won't be very usable "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"...

Recall that one type of error resilience is resilience against byte
insertion or deletion. Sounds like MPEG-TS would fall apart under this
sort of damage. :)

> > yes, iam scared, the idea of having to deal with ogg2 scares me, ffmpeg still
> > has some problems with ogg1, which wont disapear until someone adds code to
> > extract the timestamps from vorbis packets, but thats not easy, i already
> > looked at libvorbis ...
> Well that is what I say "small design error".

Would you elaborate on the small design error? Is it just the missing
PTS for individual packets? IMO ogg has a lot more design errors...

> If you want to make your future life easier I recommend you contact
> them and say how it should be improved.
> I hope they won't take your recommendations for flames;)

Actually it's not a bad idea...

> I'm sure that NUT would be better than most containers out there.
> But it won't be THE BEST.
> I want it to be THE BEST.

I don't think we agree on what "the best" is. Your idea of best
precludes low-latency muxing and as far as I can tell doesn't offer
any concrete benefits. If you'd like to help us with ideas to improve
error recovery, that's cool, but please understand that the changes we
made were made for a reason.

I believe it's probably possible to increase error resilience a good
bit more with minimal or no sacrifice. But I am not willing to
sacrifice the zero-latency property, or to increase overhead for users
who don't care about extra error resilience at this layer.

Rich