[vdr] Re: VDR developer version 1.1.6

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

On Monday 05 August 2002 22:41, Klaus Schmidinger wrote:
> Andreas Schultz wrote:
> > On Monday 05 August 2002 19:51, Klaus Schmidinger wrote:
> >
> > [...]
> >
> > > So basicly what you want is to process only part of the buffer that's
> > > presented by PlayVideo(). That's already possible: simply process as
> > > much of the block as you want, and then return the number of bytes
> > > processed. I'm really sorry, but maybe I'm too blind to see the
> > > "hide and seek" tricks involved with this...
> >
> > Assume, the player gives me a complete frame to play, but i can only push
> > half of it to device. Who guarantees me that the next time PlayVideo()
> > gets called, it sees the second half of the same frame? Sure, the player
> > developer will implement it that way, all i want know is to define the
> > interface in a way that makes it clear already in the API what is going
> > on and what is required.
>
> What sense would it make if the player offered you data _other_ than the
> second half of what it offered you before?! I believe it is an absolute
> fair assumption that you will see a consistent data stream no matter how
> much you accept with each call to PlayVideo(). If the player decides to
> continue playing somewhere else, it would have to call Clear() first,
> anyway.

ok, ok. It looks like I can't convince you that the current API is evil 
(*grin*), so lets agree on disagreeing.

I can only say that although the above argument is logical and the API will 
work for me, I would _never_ design an API arround it (when I had a different 
way of doing it). I guess I just like to break down functionality into small 
easy, to understand fragments.
The loop arround PlayVideo() currently has to be replicated inside of every 
player class. Putting the loop into the device class would create a central, 
uniform way to solve the problem once and for all.
Now this is the way i would do it, but there are apparently lots of good 
reasons not to do it that way.

I've heard you will be at the meeting in Munich, maybe we can find a 
whiteboard to discuss those things then.

Andreas
-- 
Andreas Schultz <aschultz@cs.uni-magdeburg.de>
Student of computer science

"In accordance with plans for Linux OS world domination
      infiltration of governments is vital (:-))."