[x264-devel] Re: Slices

[Tom Jacobs]

this code I used to get these results was champ yen's code 
http://www.ccns.ncku.edu.tw/~champ/x264-champ-18x.tar.gz
this uses pthread as its multi processor system so to speak. I don't know 
anything about pthread (apart from it compiles on my Linux box). the work im 
doing is porting this so it compile on my custom multi-processor 
instruction-set simulator (ISS). to get a little technical it compiles it 
for a MIPS architecture and simulates a varying shared memory pram type 
system (so my supervisor tells me). basically I can get an instruction count 
for each of the processors and I can base my 'improvements' on that. abit 
hand wavy and not quite what the end user of x264 is looking for but in 
theory to shows the ability of SoC video encoders exploiting the abundance 
parallelism in the codec.

think ive rambled to much there so will stop.

im not sure how to make a patch, it would only be from champ's code anyway 
since mine has architectural commands like barrier in it. saying that it 
would be good if the multisliced and current cvs could to joined since the 
new rate control would be good for multislice. I think the code is based on 
183r btw

thanks

Tom
----- Original Message ----- 
From: "Loren Merritt" <lorenm at u.washington.edu>
To: <x264-devel at videolan.org>
Sent: Tuesday, May 24, 2005 10:25 AM
Subject: [x264-devel] Re: Slices


> On Tue, 24 May 2005, Tuukka Toivonen wrote:
>> On Mon, 23 May 2005, Tom Jacobs wrote:
>>
>>> having said this what do people think? is it aceptable (assuming im 
>>> getting good benifits from using my multi-prossor system)?
>>
>> Yes. I think it is acceptable. I'm quite sure that this works relatively 
>> better than the ffmpeg MPEG-4 SMP encoding; I'm quite surprised that it's 
>> this way. The quality loss is less than 1% at high bit rates; with just 
>> two slices it's practically the same as no-slices version.
>
> Agreed. Send a patch, and I'll see about applying it between working on 
> UMHex and 8x8 transform.
>
>> With ffmpeg, there was a significant quality loss with just two threads, 
>> and worse, the speed improvement wasn't that much (far from 2x).
>
> I don't know either. The only difference in strategy I see is that ffmpeg 
> first runs fullpel ME on the whole frame, waits for all threads to finish, 
> then runs subpel + encode.
>
> --Loren Merritt
>
> -- 
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
> 

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