[mythtv-users] Little OT: RealTime Parallel Multi-PC Transcoding

belcampo belcampo at zonnet.nl
Wed Jun 16 08:15:18 UTC 2010


Raymond Wagner wrote:
> On 6/15/2010 17:05, belcampo wrote:
>>> Do you actually need to have realtime h264, or do you just want to 
>>> speed up transcodes?  If the latter, is there any reason why you 
>>> cannot just run two transcodes in parallel?
>> If I want a speedup as you say I should run 2 transcodes in parallel, 
>> how would I do that, independantly, on the same source.
>> As mentioned in the 1st post multithreading is very inefficient. Also 
>> see http://saintdevelopment.com/codecs/bfs-vs-cfs.txt which I found 
>> here http://x264dev.multimedia.cx/
>> After 2 Cores the efficiency drops dramatically. Where my approach 
>> would /should be more efficient, at least I think and hope so.
> 
> I would have to see more information surrounding that test to draw any 
> conclusions from it.  Certainly on a quad core processor, running more 
> than four threads is going to provide negligable, if any, gains.
> 
> The Core2Quad running DDR2 memory is starved for bandwidth on a number 
> of applications.  A couple years back, we did testing with a Q6600, 
> using a turbomachinery solver that we knew was good for efficient 
> parallelization across hundreds of machines.  Two processes ran with 75% 
> speedup over one, while four processes only ran with 20% speedup over 
> two.  DDR3, and especially triple channel i7s should significantly 
> improve these numbers.
I think "the problems" are of another nature, but that's what I think. 
I'll do some testing to see if my gutfeeling tells me I'm wrong or right.
> 
> Video encoding using 'slices' is what is called 'ridiculously 
> parallel'.  Aside from some preprocessing of the raw video, the encoding 
> process is batch.  The encoding threads are completely independent, 
> working on their own data set, and there is no need for communication 
> between them.  Ignoring bottlenecks on shared resources like memory or 
> communication buses, the encoder should scale linearly with the number 
> of cores.
Have a look at 
http://alvarez.site.ac.upc.edu/research.html#Technical_Publications
from the University of Barcelona/Spain.
The parallelization 'problems' are more or less still there.
> 
>>> You would want the video cuts to be tens of seconds long to reduce 
>>> data and startup overhead.
>> Could you be more specific on this ?
> 
> Starting up processes is expensive.  The startup and teardown of 
> something complex like x264 is probably going to be a couple seconds.  
> If you're only going to be encoding chunks of a couple seconds long, 
> that is a huge amount of overhead.
I'll investigate to see if that's a 'real' problem.
Thank you for your input so far, really appreciate it.

Henk
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users



More information about the mythtv-users mailing list