[haiku-development] Re: MediaPlayer in latest build
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 15 Dec 2009 12:16:26 +0100
David McPaul <dlmcpaul@xxxxxxxxx> wrote:
[...]
> > A bad API that requires needless copies?
> I look at it more from a how much time do we have. I don't like the
> copies taking place but I am not sure it it causing an issue. I
> think
> all the readers would need changing.
Even if it would change all readers, it's not really a very complex
change. Anyway, since we haven't yet set any deadlines for R1, we
obviously have all the time in the world.
[...]
> >> Media files are too big to buffer in memory.
> > Huh? Media files in general are too big? I could cache hundreds of
> > mp3
> > files in RAM if that would make any sense.
> In general, the files I play are in the hundreds of Mb. 1080p video
> is Gb.
For those files the chunk cache indeed performs more or less the work
you outlined. However, for audio files, it makes sense to cache them in
advance.
If you do stuff on your system that is resource heavy, you could accept
a dropped video frame - however, a dropped audio frame is not
acceptable in any case.
> >> Your original commit message mentioned that the hickups still
> > > occur?
> > Yes, this has little to do with the hickups that occur all the
> > time.
> > It's more about those that would still happen in critical
> > situations
> > even if the system works otherwise fine.
> What was the effect of my changes. Did it make the hickups worse?
In theory, it could even crash because of your changes under low memory
conditions as you removed error checking, and it would also make hickups
much more probable. In practice, however, one cannot actually test for
this, as there are a lot more hickups that have to be solved first :-)
Bye,
Axel.
Other related posts:
