appropriate video for make fprofiled

[morph166955]

I've been using a clip of video for my local fprofiled builds which is 1800 frames from the dvd of "die another day" that I have croped to 848x352 and exported as a raw yuv file. While I have seen a marginal speed increase, I've been wondering however what benefit that clip has as opposed to any other clip. I've consolidated all of my questions down to what I think are a few key ones below:

1) What would the differences be if I fed make with a 1080p clip or a 720p clip?

2) What differences would there be if I fed both my current clip and one in HD (I believe you can do that)?

3) At what point does the number of frames in that clip have deminishing returns (not looking for a best here, but there has to be a plateau somewhere)?

4) What kind of action/still sequences are optimal for generating the fastest binary? For example here, my clip starts off with a conversation and then about half way in goes into a high speed action sequence. Is that a good thing or should I have one or the other?

Thanks!

[Dark Shikari]

I would think the settings you use (subme, etc) for make fprofiled would matter a lot more than the video itself.

[morph166955]

wow that was fast...

make fprofiled uses its own settings internally which I believe are static to everyone (minus the name of the clip). Since I'm actually mid build right now heres what its doing on my side as I type:


./x264 --crf 30 -b1 -m1 -r1 --me dia --no-cabac ../raw_bond_1800fr_848x352.yuv --progress -o /dev/null ;
./x264 --crf 18 -b2 -m3 -r3 --me hex -8 --cqm jvt --direct spatial ../raw_bond_1800fr_848x352.yuv --progress -o /dev/null ;
./x264 --crf 24 -b3 -m7 -r5 --me umh -8 -w -t1 -A all --b-pyramid --b-rdo --mixed-refs --direct auto ../raw_bond_1800fr_848x352.yuv --progress -o /dev/null ;

NOTE: ../raw_bond_1800fr_848x352.yuv is the clip I mentioned earlier.


On that note, I have one more question to add to my list.

5) Is there any way (I assume yes via a change to the makefile) and would it be beneficial/harmful to enable threading on the fprofiled runs? Since I am running lots of threads in my encodes it would make sense to me that the fprofiled passes also use threads since theoretically there could be a difference speed-wize when having all that extra cpu power (I have 8 cores and I generally use 7 of them for x264, leaving one for mencoder to do its decoding and my ram-buffer program to do its job, depending on the source I may run all 8).

[akupenguin]

fprofile itself is not threadsafe, so you can't multithread any program while profiling it. You can't run multiple encodes in parallel either, since they each update the same logfiles.
Threading wouldn't affect the final exe if it worked, it would just affect the time it takes to compile. fprofile affects unrolling, inlining, branch ordering, and code alignment, by providing data about how often each bit of code is used. x264 runs the same computations with or without threading, so the only difference is that the thread synchronization function itself won't benefit from fprofile.

[morph166955]

makes sense. any difference then in the video thats sent to it in terms of speed differences of the binaries?

[morph166955]

So I've been doing some tests and I've noticed that my fprofiled builds are in almost every run slower then the non fprofiled builds. So I guess this brings me back to the point of my original post...what kind of video would optimize x264 to give me maximum performance?