Re: [PATCH][RFC] Run deinterlacer and decoder in separate threads

On 15/05/12 13:13, Petri Hintukainen wrote:
> Hello,
>
> Attached patch runs deinterlacer (tvtime plugin) and video decoder in
> separate threads.
>
> It could be further improved by splitting deinterlacing to multiple
> threads, for example:
>   - pipelining: color space conversion, pulldown detection,
> deinterlacing, chroma filter, ...
>   - processing frames in slices
>
> Usage:
> xine --post tvtime:threads=1
>
> Not deeply tested ...
>
>
> - Petri
>

A long time ago, we did some testing, and adding more threads to xine 
actually made things worse.
The Linux kernel scheduling has improved considerably since then, with 
things like NOHZ etc., so it might be worth looking at the problem again.
Back then, the problems were caused by trying to put the 
overlay/subtitle decoding in a different thread. In the end, we had to 
have the video frame decoder and subtitle decoding in the same thread, 
otherwise all the thread priorities when wrong and video motion was a mess.

Also note, that de-interlacing is easy, what is difficult is frame rate 
conversion.
I.e. converting the frame rate from 25fps (PAL) to maybe 70fps (laptop 
screen).
That being said, some de-interlacing algorithms are CPU intensive, so 
getting another CPU in a dual/quad core CPU to do it, could help 
considerably.

Kind Regards

James



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/