[x264-devel] Re: parallising the encoder

Michael S. Kazmier mkazmier at empowersat.com
Wed Apr 6 22:44:30 CEST 2005



> The approach of dividing the whole video in half temporally would work
> for even hundreds of threads, and they don't have to all be on the same
> computer.

So would you do an integer divide based on the number of threads you are
running to determine how many times and where to split the input?

> No need for extra keyframes if you have a little overlap or run a
> scenecut detector in advance. 

I think this would be a great approach, that is, to run the scenecut
detector in advance.

> Also, I originally thought it hurt
> ratecontrol, but you can do overflow compensation just like normal as
> long as the encoders can communicate at least once every few frames.

I am not following what you mean here.  But I assume you are referring to
each encoder thread reporting back its current bitrate to the master thread.

> The only problem is that it needs significant application support. I don't
> forsee it in ffmpeg, only x264cli and elder.
> 

My understanding of x264 is that the software is aimed at a being an
efficient, open source H.264 encoder for use in other applications.  While
ffmpeg or other apps may not have an immediate multi-threaded need or
desire, I believe there are others that would exploit this functionality if
it existed.  For those of us working toward realtime and/or HD encodes, this
exercise is necessary.

So let me propose we take both parallelization ideas and combine them.  From
a master thread perspective, you handle scenecut detection and temporal
division.  You then pass the specific blocks to the encoder thread(s).  Each
encoder control thread can either spawn a single encoding thread (for single
processors) or run multiple encoder threads with a single line of the frame
passed to each thread on n<=2 basis to ensure proper macroblocks exist for
motion estimation.

To me, that solves a number of problems and allows for the greatest future
flexibility and scalability.  Although I don't necessarily understand how
your temporal divisions will scale to hundreds of processors.

--Mike


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list