x264 development

[Quark.Fusion]

I just thinking about some form of background encoding (managed by frontend) when PC isn't used. As you can't predict at which intervals encode can run, imho, it's better to finish previous task that abort. But if it bothering to code — your right not to do it. Anyway if checkpoint feature will be implemented it's just question of small patch to allow such choice.

[kemuri-_9]

If i really need to pause x264 for some reason, I just use Process Explorer (procexp)'s pause and resume feature.

since it does have the ability to suspend a process indefinitely like that.

[laserfan]

If i really need to pause x264 for some reason, I just use Process Explorer (procexp)'s pause and resume feature.

since it does have the ability to suspend a process indefinitely like that.
Wow, I did not know that about procexp--thanks for the tip!

[LoRd_MuldeR]

In fact you can't "pause" a process on Windows. What you can do (and what ProcExp does) is: Enumerate and suspend all threads of a process.
In order to resurrect that process, you enumerate and resume all the threads.

This seems to work, but there's no guarantee that it will work properly for you every time...

[kemuri-_9]

I use suspend+resume quite frequently and have had no problems as of yet.

[Dark Shikari]

In fact you can't "pause" a process on Windows.Isn't that just a SIGSTOP?

[LoRd_MuldeR]

Isn't that just a SIGSTOP?

I know that signals are used on POSIX systems, but AFAIK windows doesn't use any signals.
If at all, they are emulated for POSIX apps using the Win32 API. And the Win32 API doesn't have a function to pause a process.
Only functions to suspend and resume threads...

http://www.codeproject.com/KB/threads/pausep.aspx

[akupenguin]

If you just don't allocate any more cpu-time to any of the threads in a process, that's equivalent to a SIGSTOP. (Unlike all other POSIX signals except SIGKILL, you can't catch SIGSTOP, so the fact that it's implemented as a signal doesn't really matter.)
If, as suggested in the linked article, you can create deadlocks by pause/resuming individual threads, then the threaded app was buggy already, and you should deadlock it so that we can find and fix the bugs.

[ACrowley]

Im want to encode some Blurays to 1080 x264 for private purposes,

Ive nothing changed. Not my System, not my AVS, and its the same Source.
HDDVD 1080p VC1 to x264 1920x800 9.2Mbps

Ive done the same encode in April with a older x264 Build in megui

1st Pass 33,28fps
2nd PAss 5,56 fps

Now i use the latest techhouse Build x264_x86_r999_techouse
and megui 0.3.0.3004 ,with standard DXVA HD HQ Profile 9.2Mbps 1920x800

program --pass 2 --bitrate 9231 --stats ".stats" --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --filter -3:-3 --subme 7 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"

1st Pass 11,99 fps
2nd Pass 5.58 fps

So, you can see theres nothing changed in 2nd Pass. its the same Perfomance.
But the 1st Pass ? Only ~12fps in 1 pass and i have a CPU Load around 60%. 2nd Pas 100% Cpu Load.

So, what can be the Reason ? I know there a lot of complex new changes in 264 (psyRdo,Ada.Bframe etc etc). As i say its the same System. nothing changed

Why is the Perfomance so much lower in 1st Pass ?

[nurbs]

--b-adapt 2 slows down first pass considerably. Frametype decision(?) is done in first pass, but isn't threaded.

[J_Darnley]

--b-adapt 2 didn't exist in April and frame type decision is only run on the first pass.

[ACrowley]

Thx.. i found out that its adaptive b-adapt 2 what slows down the 1pass so heavy. The fps are again ~ 33 fps without b-adapt 2 in 1st pass

As i said, the 2nd Pass was as fast as with older builds q ~5.88fps

[burfadel]

It should be pointed out that the benefits of the new b-frame decision make that drop in speed worthwhile, if the drop in speed is acceptable for you!

[toyotabedzrock]

There you go :) The only applications where VM's would be heavily constrained by a CPU intensive activity is one where it's doing a lot of read/writes. Video encoding does read writes, but it's in huge chunks, not millions of tiny ones.. That's the kind of load that a VM can virtualize with little loss in speed.

You can created a second drive with the "Use Physical Disk" option in VMware. Then use the second drive for all x264 related files, it will cut down on the overhead. Also windows XP can be trimmed to run with just 20-30 processes, disabled networking etc... and you will have a very fast VM.

Also place the page file for the VM to the directly mapped disk and set it to a static size.

If you have enough memory then you can also use the "Disabling Memory Trimming" and "Fit all virtual machine memory into reserved host RAM" settings.

There will never be a pause command in x264, because SIGSTOP (or OS-specific equivalent) is the correct way to do that.
There will never be a priority command in x264, because `nice` is the correct way to do that (and if your OS doesn't have a nice-equivalent, too bad).
In order to accept a suspend-to-disk command, someone would have to convince me that there's some use case where neither hibernate nor pause is the correct solution. Furthermore, checkpointing at every frame would be way more trouble than it's worth. Checkpoint at keyframes, then only ratecontrol state needs to be saved.

Perhaps check-pointing after 4 or more keyframes. I'm not sure how x264 handles writes, but if it writes to often and the power goes out the checkpoint file could be corrupted.

[Sagekilla]

Indeed, but like I said there's no realistic situation I can imagine where something like video encoding would suffer from a big performance hit under a VM. x264 is generally compute bound, not IO bound, and IO bound apps tend to perform worse than compute bound apps in a VM environment.

Still, I wish we could one day somehow add in start/stop to x264. I might go dive into the code though and make a patch to learn a thing or two, so we'll see if that ever turns out being successful ;)

[MrCommunistGen]

I don't know if this is relevant here, but Skystrife's 1016 build (the default DL for MeGUI) crashes immediately for me when encoding starts, but the (vanilla?) build from x264.nl works fine.
My command line:
program --pass 2 --bitrate 950 --stats ".stats" --ref 7 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --weightb --direct auto --filter -1:-2 --subme 9 --trellis 2 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
I also tried a few changes but with no change in end result. I tried getting rid of P4x4 (my only change from previous settings) because after reading the changelog I was going to give it a try. The MeGUI log simply states that encoding starts, then finishes 4 seconds later.

-mcg

[XhmikosR]

Read here (http://forum.doom9.org/showthread.php?p=1208804#post1208804).:)

[Sagekilla]

Currently running a r1016 vs r999 test on an extremely difficult clip with loads of motion @ 60 fps. No frames are dupes, each one has genuine motion, including lots of small scale (perfect for testing sub 8x8) and large scale motion. None of the settings used were particularly "sane" because the source requires extremely slow settings to get small file sizes for minimal lossy encoding.

Results for r1016 @ 1264x688:

C:\Users\Mike\Desktop\Test Files\Metamorphosis>x264 --crf 14 --ref 9 --mixed-
refs --bframes 16 --b-adapt 2 --weightb --b-pyramid --subme 9 --me umh --partiti
ons all --8x8dct --trellis 2 --psy-rd 0.7:0.7 --aq-strength 0.7 --threads auto -
-progress --output "video_1016.264" --stats "stats_1016.log" "source.avs"
avis [info]: 1264x688 @ 60.00 fps (1200 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: slice I:5 Avg QP:13.88 size:245787 PSNR Mean Y:50.82 U:54.07
V:54.88 Avg:51.73 Global:51.57
x264 [info]: slice P:750 Avg QP:16.67 size: 70676 PSNR Mean Y:45.39 U:51.12
V:52.47 Avg:46.67 Global:46.57
x264 [info]: slice B:445 Avg QP:19.56 size: 22327 PSNR Mean Y:45.18 U:50.63
V:50.24 Avg:46.33 Global:46.20
x264 [info]: consecutive B-frames: 35.3% 35.3% 29.4% 0.0% 0.0% 0.0% 0.0% 0.
0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 49.1% 38.3% 12.6%
x264 [info]: mb P I16..4: 0.6% 0.0% 0.0% P16..4: 28.0% 4.4% 17.4% 5.0% 9
.6% skip:34.9%
x264 [info]: mb B I16..4: 0.2% 0.0% 0.0% B16..8: 10.2% 2.3% 5.2% direct:
10.6% skip:71.5% L0:32.7% L1:21.3% BI:46.0%
x264 [info]: 8x8 transform intra:19.8% inter:16.3%
x264 [info]: ref P L0 53.3% 5.1% 1.9% 1.9% 1.3% 2.7% 7.1% 8.2% 18.4%
x264 [info]: ref B L0 78.5% 5.4% 2.0% 2.3% 2.2% 1.1% 4.8% 3.7%
x264 [info]: ref B L1 98.2% 1.8%
x264 [info]: SSIM Mean Y:0.9945513
x264 [info]: PSNR Mean Y:45.333 U:50.953 V:51.650 Avg:46.565 Global:46.443 kb/s:
25668.65

Results for r999 @ 1264x688:
C:\Users\Mike\Desktop\Test Files\Metamorphosis>x264r999 --crf 14 --ref 9 --mi
xed-refs --bframes 16 --b-adapt 2 --weightb --b-pyramid --subme 9 --me umh --par
titions all --8x8dct --trellis 2 --psy-rd 0.7:0.7 --aq-strength 0.7 --threads au
to --progress --output "video_999.264" --stats "stats_1016.log" "source.avs"
avis [info]: 1264x688 @ 60.00 fps (1200 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:5 Avg QP:13.89 size:248864 PSNR Mean Y:50.79 U:54.24
V:54.89 Avg:51.72 Global:51.56
x264 [info]: slice P:750 Avg QP:16.67 size: 69913 PSNR Mean Y:45.20 U:50.85
V:52.05 Avg:46.47 Global:46.37
x264 [info]: slice B:445 Avg QP:19.56 size: 22458 PSNR Mean Y:45.14 U:50.39
V:49.94 Avg:46.26 Global:46.13
x264 [info]: consecutive B-frames: 35.3% 35.3% 29.4% 0.0% 0.0% 0.0% 0.0% 0.
0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 48.9% 38.3% 12.7%
x264 [info]: mb P I16..4: 0.6% 0.0% 0.0% P16..4: 28.3% 6.9% 20.8% 3.3% 5
.3% skip:34.9%
x264 [info]: mb B I16..4: 0.2% 0.0% 0.0% B16..8: 10.5% 2.3% 5.3% direct:
10.7% skip:71.0% L0:32.4% L1:21.4% BI:46.2%
x264 [info]: 8x8 transform intra:19.7% inter:20.0%
x264 [info]: ref P L0 53.2% 5.2% 1.9% 1.8% 1.3% 2.7% 7.1% 8.3% 18.4%
x264 [info]: ref B L0 78.2% 5.6% 2.1% 2.4% 2.2% 1.1% 4.8% 3.6%
x264 [info]: ref B L1 98.2% 1.8%
x264 [info]: SSIM Mean Y:0.9943849
x264 [info]: PSNR Mean Y:45.204 U:50.694 V:51.283 Avg:46.413 Global:46.294 kb/s:
25469.25

encoded 1200 frames, 0.84 fps, 25469.88 kb/s

I'm curious how it'll perform on a more sane source :)

[Adub]

What kind of encoding speed did you get with 1016?

[Adub]

No, that is with 999. I asked about 1016.

[Sagekilla]

Oops, I forgot to comment properly. The second one is with r999. It doesn't help any that I was doing some tasks with x264 running in the background, so I'll have to re-do the test to get a more accurate idea of the speed.

Edit: Crap, just noticed what went wrong. IIRC, 1016 was slightly (about .02 fps) slower than 999, but like I said I was doing lots of work while it was encoding so it's not a perfect image of how well x264 performed.

[Adub]

Okay, thanks for the test.

[Dark Shikari]

Oops, I forgot to comment properly. The second one is with r999. It doesn't help any that I was doing some tasks with x264 running in the background, so I'll have to re-do the test to get a more accurate idea of the speed.

Edit: Crap, just noticed what went wrong. IIRC, 1016 was slightly (about .02 fps) slower than 999, but like I said I was doing lots of work while it was encoding so it's not a perfect image of how well x264 performed.I would be surprised if it wasn't slower; the p4x4 improvements do cost speed.

[Sagekilla]

If I tested with a completely idle environment (Me not browsing the internets and unpacking some data in the background) then I expect the two to be -very- close to each other. Most of the settings I use are so ridiculously slow (esp --ref 9 and --bframes 16 --b-adapt 2) that it probably wouldn't make a huge difference anyway.

[kemuri-_9]

here was a quick test, i just did it on what i profile with, which is pretty crazy in motion and fairly complex
with my somewhat standard (mentally insane) SD material settings.

r999:

x264_r999_athlon --crf 18 --min-keyint 1 --keyint 500 --scenecut 50 --ref 16 --mixed-refs --deblock 0:0
--no-fast-pskip --b-adapt 2 --bframes 16 --b-bias 5 --b-pyramid --weightb --direct auto --subme 9 --direct-8x8 -1
--trellis 2 --analyse p8x8,p4x4,b8x8,i8x8,i4x4 --8x8dct --qpmin 0 --qpmax 51 --qpstep 50 --pbratio 1.4 --qcomp 0.65 --me
tesa --merange 24 --psy-rd 0.8:0.0 --thread-input --threads auto --progress --no-dct-decimate --aq-strength 0.8 --level
4.1 --log-file r999.x264.crf.log --output NUL x264_build1.y4m
yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: profile High, level 4.1
x264 [info]: slice I:19 Avg QP:13.67 size: 13837 PSNR Mean Y:62.56 U:64.49 V:62.77 Avg:62.77 Global:51.67
x264 [info]: slice P:424 Avg QP:20.54 size: 22735 PSNR Mean Y:45.24 U:48.23 V:45.90 Avg:45.62 Global:42.96
x264 [info]: slice B:537 Avg QP:24.58 size: 11225 PSNR Mean Y:41.57 U:45.50 V:42.14 Avg:42.05 Global:41.13
x264 [info]: consecutive B-frames: 12.2% 19.6% 61.5% 6.2% 0.5% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 48.5% 49.2% 2.3%
x264 [info]: mb P I16..4: 5.5% 32.7% 2.0% P16..4: 25.8% 14.7% 10.0% 0.6% 0.2% skip: 8.5%
x264 [info]: mb B I16..4: 1.0% 9.2% 0.4% B16..8: 47.3% 5.0% 4.2% direct:12.2% skip:20.6% L0:37.0% L1:40.0% BI:23.0%
x264 [info]: 8x8 transform intra:79.9% inter:84.1%
x264 [info]: direct mvs spatial:99.4% temporal:0.6%
x264 [info]: ref P L0 62.2% 14.5% 6.9% 3.3% 2.4% 2.1% 2.0% 1.2% 1.0% 0.8% 0.7% 0.6% 0.6% 0.6% 0.6% 0.4%
x264 [info]: ref B L0 72.5% 12.2% 4.0% 2.6% 1.9% 1.4% 1.1% 0.9% 0.7% 0.6% 0.5% 0.5% 0.4% 0.4% 0.3%
x264 [info]: ref B L1 86.9% 13.1%
x264 [info]: SSIM Mean Y:0.9874417
x264 [info]: PSNR Mean Y:43.566 U:47.051 V:44.166 Avg:43.996 Global:41.921 kb/s:3901.35
x264 [info]: encoded 980 frames, 2.23 fps, 3901.35 kb/s


r1016

x264_r1016_athlon --crf 18 --min-keyint 1 --keyint 500 --scenecut 50 --ref 16 --mixed-refs --deblock 0:0
--no-fast-pskip --b-adapt 2 --bframes 16 --b-bias 5 --b-pyramid --weightb --direct auto --subme 9 --direct-8x8 -1
--trellis 2 --analyse p8x8,p4x4,b8x8,i8x8,i4x4 --8x8dct --qpmin 0 --qpmax 51 --qpstep 50 --pbratio 1.4 --qcomp 0.65 --me
tesa --merange 24 --psy-rd 0.8:0.0 --thread-input --threads auto --progress --no-dct-decimate --aq-strength 0.8 --level
4.1 --log-file r1016.x264.crf.log --output NUL x264_build1.y4m
yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: profile High, level 4.1
x264 [info]: slice I:19 Avg QP:13.64 size: 13689 PSNR Mean Y:62.56 U:64.51 V:62.75 Avg:62.77 Global:51.67
x264 [info]: slice P:424 Avg QP:20.54 size: 22607 PSNR Mean Y:45.23 U:48.31 V:45.95 Avg:45.63 Global:42.96
x264 [info]: slice B:537 Avg QP:24.54 size: 11304 PSNR Mean Y:41.56 U:45.70 V:42.29 Avg:42.08 Global:41.16
x264 [info]: consecutive B-frames: 12.2% 19.6% 61.5% 6.2% 0.5% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 49.8% 47.8% 2.3%
x264 [info]: mb P I16..4: 5.6% 32.8% 2.0% P16..4: 26.1% 15.4% 8.1% 0.9% 0.6% skip: 8.5%
x264 [info]: mb B I16..4: 1.0% 9.2% 0.4% B16..8: 47.0% 5.1% 4.1% direct:12.1% skip:21.0% L0:37.2% L1:39.5% BI:23.3%
x264 [info]: 8x8 transform intra:79.8% inter:83.0%
x264 [info]: direct mvs spatial:98.7% temporal:1.3%
x264 [info]: ref P L0 62.2% 14.3% 6.9% 3.3% 2.4% 2.1% 2.0% 1.2% 1.0% 0.8% 0.8% 0.6% 0.7% 0.6% 0.6% 0.4%
x264 [info]: ref B L0 72.4% 12.2% 4.0% 2.7% 1.9% 1.4% 1.1% 0.9% 0.7% 0.6% 0.5% 0.5% 0.4% 0.4% 0.3%
x264 [info]: ref B L1 86.9% 13.1%
x264 [info]: SSIM Mean Y:0.9874128
x264 [info]: PSNR Mean Y:43.555 U:47.195 V:44.267 Avg:44.018 Global:41.943 kb/s:3897.71
x264 [info]: encoded 980 frames, 2.21 fps, 3897.71 kb/s


lower QPs @ lower bitrate -> win in my book

[Snowknight26]

--log-file
Custom build or is it just not mentioned in --longhelp?

[kemuri-_9]

custom build... w/ komisar's log file patch.
i do lots of batch encoding it and it comes in handy for writing the x264 output to a file, instead of getting lost to the shell/command prompt foreverz

[Dark Shikari]

custom build... w/ komisar's log file patch.
i do lots of batch encoding it and it comes in handy for writing the x264 output to a file, instead of getting lost to the shell/command prompt foreverzWhy, because you're incapable of doing 2> filename?

[kemuri-_9]

Why, because you're incapable of doing 2> filename?

well, w/ --progress, it totally bloats it all up.
since i do often like to frequently look at how the encode is progressing.

i used to do 2>&1 | tee *.log but again, the progress bloat came around.

[Snowknight26]

Why, because you're incapable of doing 2> filename?

It was bad enough before you switched from updating the output every .1%, but now every that its every 10 frames would make that file huge. Very handy patch.

[Dark Shikari]

It was bad enough before you switched from updating the output every .1%, but now every that its every 10 frames would make that file huge. Very handy patch. 2>&1 | grep -v "frames, " > filename

Same thing, no needless modification of x264.

[kemuri-_9]

there's no way possible with tee and/or grep to have what you want to write to file and have it display the progress to the screen for when you want to occasionally want to check up on it.

if you do
2>&1 | tee file
you get to see everything as normal, but then the file gets the progress bloat

if you do
2>&1 | grep -v " eta " | tee file
the file gets what you want (besides the I slice statistics, since they're removed with the last progress line), but you don't see jack.

the purpose of --progress and then the purpose of what you would use 2> for are counters to each other. they just don't work together well
with the log file patch you can get --progress without some drawback.

[Sagekilla]

Kemuri, which processor do you have? It might just me forgetting what it's like to encode SD material (HD + MVDegrain3 = slooow!) but I was a bit surprised it was so fast @ 2 fps.

[kemuri-_9]

it's listed in my specs tag in my signature, but it's a phenom 9850.
why i have -march=athlon builds, since it's faster on my phenom than -march=pentium2 (though i make both + fprofiled)

this was also from a y4m as indicated from the command line, which is practically raw yv12 data just wrapped in a header specifying its properties (why the 980 frames at 640x480 pixels file is 430 MB).
so any avisynth overhead is not included in this.

[crypto]

@Dark Shikari
I normally do fast HD encodes @ fps>25 and find the speed penalty of "--b-adapt 2" too high compared to the PQ gain. What do you think? Is it possible to dynamically switch to "--b-adapt 2" during fades and dissolves.

[LoRd_MuldeR]

@Dark Shikari
I normally do fast HD encodes @ fps>25 and find the speed penalty of "--b-adapt 2" too high compared to the PQ gain. What do you think? Is it possible to dynamically switch to "--b-adapt 2" during fades and dissolves.

Lower "--bframes" to a sane value, if you use "--b-adapt 2" ;)

Also I doubt that you can use "--b-adapt 2" only in places where it is better than "--b-adapt 1".
How do you want to decide, without actually running "--b-adapt 2" on the all frames?

[Shinigami-Sama]

Lower "--bframes" to a sane value, if you use "--b-adapt 2" ;)

Also I doubt that you can use "--b-adapt 2" only in places where it is better than "--b-adapt 1".
How do you want to decide, without actually running "--b-adapt 2" on the all frames?

zones?

also yes sane b-adapt 2 <= 5
even 5 is a bit much

[Sagekilla]

6 is about the upper limit I've seen used. I even tried an extremely predictable source (A 24 mp image that has a 1280x720 cropping rectangle scroll across it @ 1 pixel/s) and it never used more than even 6 B's. For most content I've never seen a source (except that artificial one) use 6 B's more than 1% of the time. For 5 B's, it was 2-4% at best. If you need speed, 4 should give you all the speed you need with very negligible decrease in quality/compression.

[LoRd_MuldeR]

Lower "--bframes" to a sane value, if you use "--b-adapt 2" ;)

Also I doubt that you can use "--b-adapt 2" only in places where it is better than "--b-adapt 1".
How do you want to decide, without actually running "--b-adapt 2" on the all frames?

zones?

That would mean the user has to decide manually for each frame whether it's a fade or not.
Having to tune the encoder for individual frames is not exactly what you want from a good encoder...

[kemuri-_9]

That would mean the user has to decide manually for each frame whether it's a fade or not.
Having to tune the encoder for individual frames is not exactly what you want from a good encoder...

if implemented it would be following the 'more rope to hang yourself with' principle,
which is what akupenguin has stated in the past as reasoning for x264's design iirc.
zones are manual tweaking of the encoder as it is, and can be applied to single frames as is.

[Sagekilla]

IIRC, zones let you fine tune a number of different parameters for that specific area, but I think it's only specific options that are exposed in some portion of the code. I remember asking Dark Shikari about this at one point and he said you could do stuff like using different settings beyond rate control for specific zones, except I never really figured out how to do this.

If anyone actually knows how you would specify something like different AQ settings or <arbitrary setting name here> I'd appreciate if anyone would tell me ;)

[check]

There's support to change some encoding settings on the fly, but it's not exposed via the CLI beyond the bitrate/qp option.

[Sagekilla]

Hm. Any chance that would ever be supported in the near future?

[Snowknight26]

[14:41:03] <Snowknight26> so what was it that you cant change in zones?
[14:41:12] <Dark_Shikari> psy-rd, which will be fixed in r10xx
[14:41:18] <Dark_Shikari> aq also
[14:41:46] <Dark_Shikari> aq can't be changed for some technical reasons: I could allow it but the timing would be very off (i.e. changing it at frame 50 might result in the change being delayed to 70)
[14:41:57] <Dark_Shikari> or I could try messing with zones to get that to wokr
[14:42:01] <Dark_Shikari> its possible, but would require effort

When I asked him if b-frames could be changed in zones, he replied 'why not', but its not clear whether he meant the number of b-frames or the adaptive b-frame decision method.

[kemuri-_9]

iirc, possible parameters that can be designated within zones would be in the x264_encoder_reconfig section, which currently has (looking at the code)

reference frames
bframe bias
scenecut threshold
use deblocking
deblocking alpha & beta
intra and inter luma partitions
direct mode
me method
me range
noise reduction
subpel refinement
trellis quantization
chroma me
dct decimate
fast pskip
mixed refs
psy rd
psy trellis
8x8 transform (if enabled to begin with)
bframe pyramid (if enabled to begin with)


so it would be to overhaul the zone parser to handle these, as it seems it can already handle being able to do it within the code base.
and this would be fairly nontrivial with trying to come up with a intuitive scheme that is able to be parsed within code... with all the possible options and combinations of how it could be, might be why it hasn't been done yet.

[Dark Shikari]

intra and inter luma partitionsfixed

[kemuri-_9]

ah thanks for pointing that out.

since people are speculating away on why these options can't be used within the zone option as is, what is the reason, if i may so ask?

[Dark Shikari]

ah thanks for pointing that out.

since people are speculating away on why these options can't be used within the zone option as is, what is the reason, if i may so ask?AQ is done in lookahead, so if I allowed AQ to be changed in zones, I would have to do one of the following:

1. Simply allow zones to be non-frame-accurate and potentially start/stop at locations up to dozens of frames off (for AQ, at least).
or
2. Restructure zones to also check the lookahead frames to see if any one of them is the start of an AQ zone.

I really don't want to do either. Also, Fallout 3 is awesome.

[kemuri-_9]

ha ha, i guess i wasn't specific enough:
i was referring as to why the current parameters within the x264_encoder_reconfig block are not able to be used with the current zone parser...

similarly, from what you just said, it does sound like AQ should not be reconfigurable to maintain zone determinism, i think people could live without having it reconfigurable.

ha ha fallout 3 eh, that does seem to be the current rave...

[Dark Shikari]

ha ha, i guess i wasn't specific enough:
i was referring as to why the current parameters within the x264_encoder_reconfig block are not able to be used with the current zone parser.They aren't? That would be news to me. Last I tried, it works fine.