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

[Michael Niedermayer]

Hi

On Sat, Jan 07, 2006 at 11:24:37AM +0200, Oded Shimon wrote:
> On Wed, Jan 04, 2006 at 11:52:03AM +0100, Michael Niedermayer wrote:
> > 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:
> > > > > 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
> 
> You never really answered the question, does the overhead really bother you 
> that much Michael? I want to make NUT done already. Rich wants keyframe 
> exact seeking (and I agree), we all want demuxer and muxer simplicity, and 
> the only solution for this is per stream pts and ptr in every syncpoint.

i dont think pts per stream are needed for this, what exactly was the problem
anyway if we just have a rule like
output a syncpoint immedeatly if a back_ptr changes by more then t
doesnt that ensure that we never have to search more then t?


> 
> The overhead is 50 to 70kb for every additional stream for a 700mb file, it 
> really is not that bad. :/

hmm, then lets add a 50-70kb jpeg captured from whatever video input device is
available ;)

its not only the overhead but also what you gain or loose

[...]

-- 
Michael