RE: [xine-devel] spudec-thread priority

[Guenter B. <bar...@st...>]

Hi James,

On Wed, 11 Jul 2001, James Courtier-Dutton wrote:

> One thing to check first is find out what exactly the problem is.
> How can we prove your theory about the thread switch based on low usage?

hum, well, I _know_ that linux threads are processes in reality and are
scheduled according to their use of cpu cycles. And I can clearly see the
playback get a bit jerky whenever packets arrive for the spu decoder.

> According to your email on pthreads, we cannot set scheduling type or
> priority unless we are superuser.
> Running xine as superuser is unacceptable.

exactly. but we can outsmart the scheduler a bit if we simply decode spu
in the same thread we decode video - this is a low-priority thread as it
consumes most cpu time.

> After some thought on the matter, why don't we discuss the following.
>
> 3 Threads: -
> 1) demux,decode for video(mpeg2,spu,nav) and decode for audio.

the demuxer and input plugin need to run in a seperate thread because
input devices tend to block when there's not data ready for reading.

audio blocks as soon as the audio buffer is full and these audio buffers
can be quite small so we definitely want to have this running in a
seperate thread, too.

> 2) video_out_loop.

agreed.

> 3) audio_out_loop.

I've thought about this quite often and didn't come to a conclusion. I'd
be nice to have an audio_out_loop taking care of audio synchronization
just like video_out_loop does for video, but I'm not sure how to do it.
Audio card have their own timer and it depends heavily on the audio
device/driver (oss, alsa, esd, arts...) how syncing must be done. So, I
guess it's not easy to design an elegant API here and it's questionable if
it's worth the effort.

> For hardware based decoders/video_out, the hardware specific plugin should
> run it's own thread if needed.

es we agreed elsewhere this can be done in den video_decode_loop thread.

Generally we should keep the number of threads as small as possible as
with every new thread the danger of races and/or deadlock increses as well
as the overhead needed for their syncing.

> demux and decode should filter the PES packets as early as possible.
> E.G. Filter on selected audio channel at the earliest point.

we did that in the past but this leads to bad response times in xine
that's why we do it as late as possible (possible without additional
memcpys) now.

> Config option to switch off nav. nav is things like buttons. (I am about to
> add it. :-) )

?!?

> Most of the MPEG2 specs I have seen talk about rate scheduling at the demux
> stage.

looks like I need to have a look at the specs again, what is this good
for?

> The fifo's could probably be much smaller.
> Maybe, only enough for 1 second of audio_out and 1 second of video_out.

what if you want to play back a stream generated by a bad demuxer that
didn't manage to interleave packages right?

And, btw, what exactly is 1 second of audio/video in _bytes_?
I think this depends heavily on the stream format, some avis have data
rates that vary heavily throughout the stream.

> The input->demux fifo could be the real big buffer.

well, any input plugin is free to implement a big buffer at this stage,
the input plugin api is designed for this - this could make raw devices
much faster btw.

Cheers,

   Guenter


--
time is a funny concept