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

[Michael Niedermayer]

Hi

On Wed, Jan 04, 2006 at 06:15:33AM +0200, Oded Shimon wrote:
> On Tue, Jan 03, 2006 at 09:34:32PM +0100, Michael Niedermayer wrote:
> > On Tue, Jan 03, 2006 at 09:32:06PM +0200, Oded Shimon wrote:
> > > 3. re-arrange main header
> > 
> > NO, this has not been disscussed, it maybe a good idea but until i hear
> > your arguments i wont agree
> 
> With my frame code suggestion, you can make an invalid code with specifying 
> just flags and headers, you can specify a safety net code by specifyingjust 
> flags and headers, and I rearranged them what imo are those which have to 

invalid codes will be very rare so this is a bad argument


> be manually specified the most often (mul is on top, then sflag, then pts 
> and then stream. Now that I think of it, maybe pts after stream.)

the optimal order strongly depends upon the code used to generate the table
the current one is optimized for the lavf code, and yours is for your code
...


> 
> I can only guess that the reason you made it that way before was to allow 
> "continued" codes which depended on the values of the last entry. You never 
> really sepcified that this is defined behavior, and the only case it is 
> useful is for frame code 'N' you want to put in the middle of a bigger 
> frame code chunk, but to specify 'N' you need to atleast go upto tmp_mul, 
> destroying the values you had "cached" from before.

no, the single 'N' value has nothing to do with it the idea is simply to cache
the "most significant values" when enumerating stuff


[...]
> > > 6. fix small bug in info_packets (no get_s())
> > 
> > YES
> > 
> > 
> > > 7. per stream back_ptr and pts in syncpoints
> > 
> > NO, i agree with a single back_ptr and would abstain if you suggest per stream
> > but iam against pts per stream
> 
> Well, what is it about it that bothers you? The overhead? I've already 
> prooved that in high bitrate files, the overhead is irrelavent, and in low 
> bitrate files, the frame headers are most of the overhead anyway. (If you 
> do not agree with my tests please offer a better testing scenario)

i suggest to make per stream pts and back_ptrs optional

[...]
-- 
Michael