From 80d2afefc9d582c6768d4d78a89064be570bcd13 Mon Sep 17 00:00:00 2001 From: Michael Roitzsch Date: Sat, 8 May 2004 15:05:36 +0000 Subject: document _x_spu_decoder_sleep CVS patchset: 6500 CVS date: 2004/05/08 15:05:36 --- doc/hackersguide/stream.sgml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'doc') diff --git a/doc/hackersguide/stream.sgml b/doc/hackersguide/stream.sgml index cbbe53d04..3ea987340 100644 --- a/doc/hackersguide/stream.sgml +++ b/doc/hackersguide/stream.sgml @@ -610,6 +610,19 @@ which for audio and video is done by the engine, has to be done manually for SPU:    vpts = metronom->got_spu_packet(metronom, buf->pts); + + Another difference is that while both audio and video decoders are automatically + blocked in their get_buffer()/get_frame() + methods when the output cannot take any more data, this does not work for SPU, + because it could take minutes before the next free slot becomes available and we must not + block the decoder thread for that long since it might be shared with a video decoder. + But when a SPU decoder does not share the thread and we let it run without any + blocking, it will overflow the available overlay slots very soon. Since SPU + decoders should not have to know, whether they share the thread or not, a helper + function _x_spu_decoder_sleep() is provided, which, when told + the timestamp of the next overlay, will wait long enough to not overflow the + overlay slots, but short enough to not hinder a video decoder in the same thread. + There are also two functions in the SPU decoder API, which have not been discussed above: -- cgit v1.2.3