[MPlayer-dev-eng] Lots of stuff for NUT

[Oded Shimon]

On Wed, Jan 04, 2006 at 10:52:21PM -0500, Rich Felker wrote:
> On Thu, Jan 05, 2006 at 01:58:29AM +0100, Michael Niedermayer wrote:
> > > > 99% of the cases and a near point in the remaining that seems fine
> > > > why should the user have to accept 2x overhead for something she doesnt
> > > > need?
> > > 
> > > It's not 2x, and as Oded has shown the overhead is trivial. For low
> > > bitrates where overhead matters it's several orders of magnitude
> > > smaller than the frame headers, and for high bitrate it's something
> > > like 25% IIRC.
> > 
> > the case with 10 streams IIRC had 2x addtional overhead but i
> > might be wrong, still 25% is alot too
> 
> The 25% increase is for high bitrate files, and it's like 100k for 700
> megs. For modem-bitrate the increase is nearly immeasurable since
> there will be very few syncpoints per unit time. Please look at the
> numbers, but unless I'm quite mistaken they're so small that even the
> lamest windows warez kids won't try to make broken files to reduce
> it..

pure numbers:

620mb low bitrate audio and video file:
Stream 0:
   frames: 481813
   TOT: packet size: 323845480 packet overhead: 990207 (0.31%)
   AVG: packet size: 672.14 packet overhead: 2.06
Stream 1:
   frames: 615440
   TOT: packet size: 299283040 packet overhead: 615549 (0.21%)
   AVG: packet size: 486.29 packet overhead: 1.00
just single pts:             Syncpoints: 19315 size: 229235
single back_ptr and pts:     Syncpoints: 19315 size: 276897
per stream back ptr and pts: Syncpoints: 19316 size: 315915  (0 subtitle streams)
per stream back ptr and pts: Syncpoints: 19413 size: 407794  (2 subtitle streams)
per stream back ptr and pts: Syncpoints: 19445 size: 599933  (10 subtitle streams)


700mb high bitrate:
Stream 0:
   frames: 88261
   TOT: packet size: 672631304 packet overhead: 199733 (0.03%)
   AVG: packet size: 7620.93 packet overhead: 2.26
Stream 1:
   frames: 147102
   TOT: packet size: 53467272 packet overhead: 148523 (0.28%)
   AVG: packet size: 363.47 packet overhead: 1.01
just single pts:             Syncpoints: 27674 size: 315730
single back_ptr and pts:     Syncpoints: 27678 size: 391804
per stream back ptr and pts: Syncpoints: 27462 size: 462052  (0 subtitle streams)
per stream back ptr and pts: Syncpoints: 27475 size: 649130  (2 subtitle streams)
per stream back ptr and pts: Syncpoints: 27520 size: 1080662 (10 subtitle streams)


All subtitles streams are fake streams giving 1 5 byte keyframe every 100 
video frames with the same pts as the last video frame. (more accurately, 
when "(video->last_pts%100) == subtitle_stream_n")



my opinion:

with 2 subtitles streams, in the high bitrate file, you have 997386 bytes 
overhead not including index. The spec says:
~0.2% overhead, for normal bitrates
That's 1.5mb for this file, so I'd say we're still doing better than even 
our goals say. (Index will certainely not be 500kb..)

Wtih pathological 10 subtitle streams, I suspect the index will be 400kb 
(I still need to check this, I'll work on that later today), grand total 
2mb overhead for this file. Given it's 10 subtitle streams after all, IMO 
it's not that bad. (without any funky subtitles, mkv gave 1.5mb overhead 
for this file when using lacing, and 2.25mb without)

For the low bitrate file, the packet headers outwheigh the syncpoints... 

Optionality is weird, and it's better if we don't allow it at all.
Windows lusers seem not to care about overhead that bad, they are still 
using AVI after all, so I highly doubt they'll make a util for "reducing" 
NUT overhead, especially if we even abuse the syncpoints to detect 
stream corruption (like out of order dts).


P.S. The 10 subtitle test actually increased the packet overhead for the 
audio and video frames. The only possible cause for this is the last_pts 
being reset by the syncpoint, and being an innefficient last_pts for it. 
Maybe we should rethink what last_pts should be reset to for each stream. 
(Currently it is the "global_key_pts" in the begginning of the syncpoint) 
In the 700mb video above, it turned to:
AVG: packet size: 7622.67 packet overhead: 3.02
AVG: packet size: 363.48 packet overhead: 1.73

As an experiment, I just tried using "key_pts" of each stream to be used as 
the last_pts of that stream:
AVG: packet size: 7622.67 packet overhead: 2.93
AVG: packet size: 363.48 packet overhead: 1.00

The video is still higher than it originally was (2.26), but not by as 
much, and the audio is even a little bit smaller. However I think I still 
preffer using global_key_pts, cause it has to be the highest pts keyframe, 
which makes it the most current one... I should just use a better frame 
code table.

- ods15