From: Petri H. <phi...@us...> - 2012-05-15 12:14:04
Attachments:
tvtime_thread.diff
|
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 |
From: Roland S. <rsc...@hi...> - 2012-05-15 22:55:29
|
Didn't do any testing but I like the idea. I think though if the decoder already does threaded decoding this (like h.264 though I'm sometimes still seeing some trouble with that) won't really do much right? I am not convinced that using threads for csc, pulldown, deinterlacing, chroma filter is really the right way going forward. What makes these operations slow is the memory traversal so handling them all at once would make things way faster (in case of csc and deinterlacing it would also increase the chroma quality a lot for combined deinterlace/csc at least for deinterlacers doing bob/weave based on content, which means you'd most likely would want to throw out the not terribly useful chroma filter anyway for such setups so not much would be left for additional threads...). Can't say much about pulldown, as currently it is totally useless in a 50Hz world (not once in your lifetime will you see 3:2 pulldown which is the only thing it can handle), I guess though it might not really be worth using a separate thread since it should be pretty lightweight as it should only need to look at a fraction of all pixels (even for more elaborate pulldown detection). Roland Am 15.05.2012 14:13, schrieb Petri Hintukainen: > 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 > > > > ------------------------------------------------------------------------------ > 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/ > > > > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: James <Ja...@su...> - 2012-05-26 15:18:48
|
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 |