[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
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.
>
> 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