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

belcampo belcampo at zonnet.nl
Tue Jun 15 21:05:59 UTC 2010

Raymond Wagner wrote:
> On 6/15/2010 12:22, belcampo wrote:
>> In PAL-land, where I live, we've got 25fps and a GOP-size of 12frames.
>> None of my DualCore CPU's can transcode, with ffmpeg, in realtime to 
>> desired h264 quality. But I do have 2 more DualCores sitting there 
>> doing nothing.
> What exactly is the purpose of this?
For the most an intellectual challenge.
> 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 
After 2 Cores the efficiency drops dramatically. Where my approach would 
/should be more efficient, at least I think and hope so.
> H264 includes the concept of video slices.  When you do a multi-threaded 
> encode, you physically slice the video domain into multiple blocks, 
> which are encoded independently.  You would have to make some serious 
> changes to the x264 encoder to support running this in parallel on 
> multiple machines, but it could be done.  (looks like someone already 
> did it)
> http://www.hacks.arizona.edu/2009/03/x264-mpi-rough-demo-code/
Thanks for the link.
> Your method of splitting apart each GOP, encoding separately, and 
> stitching together afterwards would work, but would be horribly 
> inefficient.  
I've discovered that my assumption of key-frames every 12 frames is ONLY 
true for MPEG-2 streams, so I do see the problem with H264 sources now.
> H264 should be using much larger spacing between 
> keyframes, and it should be of dynamic length, dependent on changes in 
> the video, rather than arbitrarily placed every 12 frames.  The only way 
> to do that would be to have a first pass be running just ahead of the 
> normal encode, to identify good locations for cuts. 
I have found a solution in the ability of tsMuxeR's split function which 
is able to cut at keyframes when a split-time of 2 seconds is chosen.
> 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 ?
> _______________________________________________
> 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