From: Julian S. <ju...@ju...> - 2007-05-23 00:31:11
|
Am Mittwoch 23 Mai 2007 02:10 schrieb Petri Hintukainen: > On Wed, 2007-05-16 at 23:03 +0200, Julian Scheel wrote: > > Actually I thought quite a bit further and now think about this approach: > > Create a thread in plugin-init for the tvtime-post-plugin. In that thread > > we will have a loop which waits to get notified from deinterlace_draw > > that a new frame came in. All the arguments passed to deinterlace_draw > > will be stored in a struct which is then accessed by the thread. The > > thread will lock that struct until the frame is drawn. > > deinterlace_draw though will return immediately after storing the struct, > > so that the decoder could start decoding the next frame. > > Now the decoder could always decode the upcoming frame while the current > > frame is being post-processed in a seperate thread. > > This is the best solution I could think of for the moment, as the effort > > needed for assuring thread-safety is not very big and a whole block is > > parallelized. > > > > Looking forward to any comments. > > Proof of concept: > http://phivdr.dyndns.org/xine-lib/threads/ > > Simple video post plugin that executes draw method of next post plugin > in separate thread. Not well tested, but seems to work. > Decoding and deinterlacing 1080i in separate threads results very even > CPU usage between two cores and keeps on-demand CPU frequency low :) Looks good. I actually added a thread to the tvtime-plugin. That works well, too. Will post a patch tomorrow. Actually your approach is more generic though. BTW: What happened to the upscaling thing you told me about? -Julian |