x264 cli bugreports

[Dark Shikari]

Ding ding ding, we have a winner!

I'm going to guess its related to how frame_init_lowres interacts with ratecontrol in threaded mode.

If this is true, then the following changes will both solve the problem:

1. Disable frame_init_lowres asm (but don't disable anything else).

2. Add x264_emms() after the call to frame_init_lowres asm.

My build environment doesn't support threads, so I'll have to find someone to make you a few builds to test.

[Underground78]

Originally Posted by Dark Shikari

My build environment doesn't support threads, so I'll have to find someone to make you a few builds to test.

I can do a build with threads support if you give me a patch to apply on GIT source code ...

[Dark Shikari]

Originally Posted by Underground78

I can do a build with threads support if you give me a patch to apply on GIT source code ...

For idea 2 above, find the following code in encoder/encoder.c:

        if( h->frames.b_have_lowres )
            x264_frame_init_lowres( h, fenc );

Add, after it (on the next line) x264_emms();

For idea 1 above, find the following code in common/x86/mc-c.c:

pf->frame_init_lowres_core = x264_frame_init_lowres_core_mmxext;

pf->frame_init_lowres_core = x264_frame_init_lowres_core_cache32_mmxext;

pf->frame_init_lowres_core = x264_frame_init_lowres_core_cache32_mmxext;

Comment these out or remove them.

Test with no modifications, with just idea 1, and with just idea 2, and see if any of them resolve the issue.

[J_Darnley]

Here you go. 7-zip archive contains two builds with threads of the two ideas.
http://users.telenet.be/darnley/x264-lowres-ideas.7z

Dark_Shikari, you posted two identical lines. Is that correct? It does appear twice in mc-c.c for cacheline 32 and 64.

[Dark Shikari]

Originally Posted by J_Darnley

Here you go. 7-zip archive contains two builds with threads of the two ideas.
http://users.telenet.be/darnley/x264-lowres-ideas.7z

Dark_Shikari, you posted two identical lines. Is that correct? It does appear twice in mc-c.c for cacheline 32 and 64.

Yes, that was correct.

It needs to be three builds, so that a comparison can be made with a normal build to see if that one is broken too.

[J_Darnley]

Ah, ok. I'll re-upload the archive. But I can say that for a first pass target of 500 the two ideas now give 515 instead of ~20000.
[EDIT] Three build archive uploaded.

[Underground78]

Sorry J_Darnley I've already made my test builds when you've posted but I was answering a phone call ...

Test builds gcc 3.4.5 fprofiled : Test builds ...

Default build :

E:\film>x264-default.exe --pass 1 --bitrate 500 --stats "default.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
        --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "default.mkv" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12    Avg QP:12.66  size: 74475:00:00
x264 [info]: slice P:542   Avg QP:12.75  size: 60999
x264 [info]: slice B:447   Avg QP:14.26  size: 26072
x264 [info]: mb I  I16..4: 15.1%  0.0% 84.9%
x264 [info]: mb P  I16..4: 27.6%  0.0%  0.0%  P16..4: 65.7%  0.0%  0.0%  0.0%  0.0%    skip: 6.6%
x264 [info]: mb B  I16..4:  3.8%  0.0%  0.0%  B16..8: 43.2%  0.0%  0.0%  direct:28.8%  skip:24.2%
x264 [info]: final ratefactor: -1.#J
x264 [info]: direct mvs  spatial:99.3%  temporal:0.7%
x264 [info]: kb/s:9112.7

encoded 1001 frames, 58.29 fps, 9112.89 kb/s

Idea 1 :

E:\film>x264-idea-1.exe --pass 1 --bitrate 500 --stats "idea-1.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
        --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "idea-1.mkv" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12    Avg QP:30.99  size: 11820:00:00
x264 [info]: slice P:542   Avg QP:33.31  size:  4208
x264 [info]: slice B:447   Avg QP:35.87  size:   861
x264 [info]: mb I  I16..4: 47.3%  0.0% 52.7%
x264 [info]: mb P  I16..4: 23.5%  0.0%  0.0%  P16..4: 36.7%  0.0%  0.0%  0.0%  0.0%    skip:39.8%
x264 [info]: mb B  I16..4:  1.2%  0.0%  0.0%  B16..8: 15.5%  0.0%  0.0%  direct: 2.9%  skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs  spatial:94.9%  temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 87.76 fps, 561.11 kb/s

Idea 2 :

E:\film>x264-idea-2.exe --pass 1 --bitrate 500 --stats "idea-2.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
        --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "idea-2.mkv" "
1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12    Avg QP:30.99  size: 11820:00:00
x264 [info]: slice P:542   Avg QP:33.31  size:  4208
x264 [info]: slice B:447   Avg QP:35.87  size:   861
x264 [info]: mb I  I16..4: 47.3%  0.0% 52.7%
x264 [info]: mb P  I16..4: 23.5%  0.0%  0.0%  P16..4: 36.7%  0.0%  0.0%  0.0%  0
.0%    skip:39.8%
x264 [info]: mb B  I16..4:  1.2%  0.0%  0.0%  B16..8: 15.5%  0.0%  0.0%  direct:
 2.9%  skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs  spatial:94.9%  temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 90.10 fps, 561.11 kb/s

Both ideas 1 and 2 seem to work to fix the bug ...

[Dark Shikari]

Hopefully resolved.

[Underground78]

It works :

E:\film>x264-fixed --pass 1 --bitrate 500 --stats "fixed.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
        --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "fixed.mkv" "1x01-p1.avs"

avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12    Avg QP:30.99  size: 11820:00:00
x264 [info]: slice P:542   Avg QP:33.31  size:  4208
x264 [info]: slice B:447   Avg QP:35.87  size:   861
x264 [info]: mb I  I16..4: 47.3%  0.0% 52.7%
x264 [info]: mb P  I16..4: 23.5%  0.0%  0.0%  P16..4: 36.7%  0.0%  0.0%  0.0%  0.0%    skip:39.8%
x264 [info]: mb B  I16..4:  1.2%  0.0%  0.0%  B16..8: 15.5%  0.0%  0.0%  direct: 2.9%  skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs  spatial:94.9%  temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 91.65 fps, 561.11 kb/s

Thank you very much !

[garbii]

I had to reverted to a x264 version from 2008 04 08 ... The one I was using right now was from 2008:12:30. The difference is ubntu jaunty vs ubuntu intrepid :P


Anyway new x264 has a worse CRF mode... although crf 22 gave me the old crf 20 quality, the size is actually larger ...
The settings for both encodes are the same with a difference that with the new one I removed bime and brdo from command line and instead use subme 7. (which is due to x264 api changes)

Old crf=20
minami-ke 08 size 42 MB
gundam 00 s2 20 size 80 MB

new crf=22
minami-ke 08 size 56 MB
gundam 00 s2 20 size 84 MB

Munto 05
old = 54 mb
new=70 mb

Now the difference on the same files shows that new crf mode is less efficient then the old one... So I consider this a bug since new version provides the same quality but with a lot larger files .

[Sharktooth]

that's not a bug but an intended behaviour.
talking about compression efficiency and CRF doesnt have much sense.
fact is, at the same filesize, the new x264 version gives better quality. hence, use the newer version and rise the CRF until you get your desirer filesize (and as i said, at the same filesize, you'll get a better quality).

[garbii]

Originally Posted by Sharktooth

that's not a bug but an intended behaviour.
talking about compression efficiency and CRF doesnt have much sense.
fact is, at the same filesize, the new x264 version gives better quality. hence, use the newer version and rise the CRF until you get your desirer filesize (and as i said, at the same filesize, you'll get a better quality).

I played with different numbers of CRF and the problem here is the differences in size. As you can see with new x264 the GUndam episode is quite close in size to what the old one was... The quality is also good. However less action packed shows like Munto and Minami are a lot larger then the old ones while having the same quality. THis is what I consider a bug because I found my desired quality (crf=22), but it doesn't seem to work as the old one did for non action shows.

[nm]

Originally Posted by garbii

Old crf=20
minami-ke 08 size 42 MB
gundam 00 s2 20 size 80 MB

new crf=22
minami-ke 08 size 56 MB
gundam 00 s2 20 size 84 MB

Munto 05
old = 54 mb
new=70 mb

Now the difference on the same files shows that new crf mode is less efficient then the old one... So I consider this a bug since new version provides the same quality but with a lot larger files .

It would be better to do a 2-pass encode to the same size and then compare quality visually.

Looks like your source is anime. The 2008-04 version of x264 didn't have psy-RD, which may not be a good idea for animation. Now psy-RD is enabled by default, so try disabling it with --psy-rd 0.0:0.0 (or psy-rd=0.0,0.0 if you use MEncoder).

[Sharktooth]

Originally Posted by garbii

I played with different numbers of CRF and the problem here is the differences in size. As you can see with new x264 the GUndam episode is quite close in size to what the old one was... The quality is also good. However less action packed shows like Munto and Minami are a lot larger then the old ones while having the same quality. THis is what I consider a bug because I found my desired quality (crf=22), but it doesn't seem to work as the old one did for non action shows.

again, this is not a bug but an intended behaviour.
as nm said, try disabling psy options since your encode is anime.

[garbii]

I enabled psy-rd=0.0,0.0 and gave new build a try I still have the same problem though... Let me rephrase. CRF should be a stable quality factor so once I choose the crf value I like it should always give me the same quality on files, or similiar at least. This is not the case with new crf, where I should consider the source and then choose the crf and if I have to do that I might as well use good old 2pass bitrate.

Extreme example of non action source vs a very demanding fast paced source:

Old crf=20
gundam 00 s2 ep 23 140 MB
mianami-ke okaeri 10 43 MB
both encodes have similiar quality. Both files are a 20 minutes shows.

New crf=24
gundam 00 s2 ep 23 81 MB
mianami-ke okaeri 10 45 MB
While the non action minami has good quality the 80 mb gundam encode just sucks in terms of quality.


New crf=22
gundam 00 s2 ep 23 100 MB
mianami-ke okaeri 10 53 MB
Quality wise minami seems the same as crf=24, it size is larger though ... Gundam is better then the previous encode but still not as good as the 140 MB encode which is just natural

I find it that new crf behavour makes this mode uselles for me. This example should really show that the previous version was better at keeping the same quality and not over enlarging filesize where not needed . With the old mode I could just set it to one value and not worry because all my encodes ended with similiar quality, with the new mode I would have to use 21 or maybe 20 for gundam and 24 for minami ... Now for me that's not what constant quality mode should be all about.

[Dark Shikari]

Originally Posted by garbii

I enabled psy-rd=0.0,0.0 and give new build a try I still have the same problem though... Let me rephrase. CRF should be a stable quality factor so once I choose the crf value I like it should always give me the same quality on files, or similiar at least. This is not the case with new crf, where I should consider the source and then choose the crf and if I have to do that I might as well use good old 2pass bitrate.

Extreme example of non action source vs a very demanding fast paced source:

Old crf=20
gundam 00 s2 ep 23 140 MB
mianami-ke okaeri 10 43 MB
both encodes have similiar quality.

New crf=24
gundam 00 s2 ep 23 81 MB
mianami-ke okaeri 10 45 MB
While the non action minami has good quality the 80 mb gundam encode just sucks in terms of quality.


New crf=22
gundam 00 s2 ep 23 100 MB
mianami-ke okaeri 10 53 MB
Quality wise minami seems the same as crf=24, it size is larger though ... Gundam is better then the previous encode but still not as good as the 140 MB encode which is just natural

I find it that new crf behavour makes this mode uselles for me. This example should really show that the previous version was better at keeping the same quality and not over enlarging filesize where not needed . With the old mode I could just set it to one value and not worry because all my encodes ended with similiar quality, with the new mode I would have to use 22 or maybe 20 for gundam and 24 for minami ... Now for me that's not what quality mode should be all about.

I had exactly the same problem with the old CRF--which was fixed with my modifications. My Touhou clips could reach CRF ~30-35 without noticeable degradation while BlackPearl looked crap at above ~24. So, to paraphrase you, "the old CRF is useless to me."

Unless you can come up with a magical algorithm for judging the human visual system, there is no guarantee that any CRF algorithm will give equivalent quality across all sources--in fact, it's almost guaranteed it will not.

Anyways, the proper approach here is not to blame CRF but to adjust qcomp until you are satisfied with the mapping between CRF and quality level.

Also, though you probably don't realize this, there have actually been three CRFs.

1. Original CRF (similar to current CRF)

2. CRF after AQ (qcomp completely disabled)

3. New CRF (most similar to original CRF)

Let me put this in a nice large font size here:
During 2), CRF was effectively broken. The "new" CRF merely restored the original behavior.

If you don't like this behavior, what you really want is qcomp=1, i.e. disabled.

[audyovydeo]

Originally Posted by Dark Shikari

Also, though you probably don't realize this, there have actually been three CRFs.

1. Original CRF (similar to current CRF)

2. CRF after AQ (qcomp completely disabled)

3. New CRF (most similar to original CRF)

mmmh, interesting. I assume that :

1 = <r968
2 = r968
3 = >r????


cheers
audyovydeo

[nm]

Originally Posted by audyovydeo

mmmh, interesting. I assume that :

1 = <r968
2 = r968
3 = >r????

I'd guess something like this:

1: rev < r804 (variance-based psy adaptive quantization)
2: r804 <= rev < r968
3: rev >= r968 (move adaptive quantization to before ratecontrol, eliminate qcomp bias)

[garbii]

Originally Posted by Dark Shikari

If you don't like this behavior, what you really want is qcomp=1, i.e. disabled.

Thanks that helped However just so you know it still not the same as the old "broken" crf. While it gives the same filesizes (and better quality) it's only up to some point . For example the eariler mentioned gundam ep with crf=22 and qcomp=1 ended up as a 102 MB file while with old value it was 140 mb ...

The quality of the mentioned ep is still quite good (not as good as the 140 mb one obviously) and I'm aiming to end up with small files anyway so I'm happy

Thank you for your help, and I still don't like how the normal non "broken" crf behaves ... oh well ...

[daimroc]

I get the error malloc size with de x264 r1201 (32 bits).

I have the following command line:

x264 --crf 16 --keyint 240 --min-keyint 24 --scenecut 40 --bframes 16 --b-adapt 2 --ref 4 --deblock 0:0 --qpmin 5 --qpmax 24 --aq-mode 1 --aq-strength 0.25 --mbtree --partitions all --direct auto --weightb --me tesa --merange 32 --mvrange -1 --mvrange-thread -1 --subme 9 --psy-rd 1.0:0.0 --mixed-refs --8x8dct --trellis 2 --no-fast-pskip --no-dct-decimate --nr 0 --threads auto --thread-input --output "video.mkv" "video.avs"



My avs is:

DirectShowSuorce("video.,m2ts")
Crop(Crop(0,132,-0,-132)

The source is a 1080p video, which I do a crop.

If I do a resize to 640x368 for example I don't have any problem.

I have a Core 2 Duo E6750 with 2GB of RAM, winth windows vista x64.




Thanks.
Daimroc.