[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