[openbeos] Re: mov reader
- From: "François Revol" <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 16 Jun 2005 18:45:26 +0200 CEST
> Some applications use it to directly call BMediaTrack::ReadFrames
> from here,
> which is not a good idea, because the data may need to be read from
> disk first,
> and doing this when the data needs to be available in a few ms is
> just wrong.
> A disk read with control thread realtime priority isn't good either,
> because it may
> affect system performance.
I never noticed that but the R5 MediaPlayer does audio decode in that
thread...
While not as dangerous as doing disk reads, it's not a good idea either
to do any real computing at real time priority, because the more
complex the code is, the more bugprone it is, the more busylooping-
prone it is.
And I know there are some issues with ffdecoder with for example mp3.
I already got CD Manager for example to lock everything up because it
was doing bad things with the mp3 decoder at realtime priority (pets
Marcus)...
>
> If that doesn't help, try to put a
> set_thread_priority(find_thread(0), 5)
> into BSoundPlayer's before it calles the buffer callback functionm,
> or into BMediaTrack::ReadFrames. But only for debugging, not into
> SVN.
>
As said, the buffer callback should only just try to read something
from a ring buffer of already decoded data from a non-realtime thread,
or output silence if not data is available after a small timeout.
At least that's what nplay does:
http://clapcrest.free.fr/revol/beos/shot_nplay_audio_decode_thread.png
:P
But this doesn't have to do with mov at all.
François.
Other related posts:
