x264 development

[Sharktooth]

it's an average it doesnt mean ALL I-Frames have "higher" QP than the corresponding P-Frames. you arent considering there could be consecutive I-Frames too due to flashes or very high motion, I-frame only GOPs, etc... and btw, as i said, that choice was already discussed and still, i dont think it's bad for certain targets. the only adjustment needed it's probably the qcomp parameter since the presets were made well before some critical x264 changes (AQ, psy-rd, etc...). so id say to set qcomp to default and if there is still some visible i-frame pumping effect.

[akupenguin]

btw, as i said, that choice was already discussed and still, i dont think it's bad for certain targets.
Discuss it again, for me. What is it about certain targets that could make their optimal QP offsets different?

[Sharktooth]

to make it short, on some big TVs some users reported a visible difference between b/p frames and i frames with default i/p p/b ratio.
those TVs were maybe not properly calibrated too, or just fancy TV "features" were producing some strange behaviours, but the solution was easy since i assumed x264 was far more efficient than any other h.264 encoder, so i ended up reducing the quant. ratio between frametypes in "default" blu-ray and ps3/xbox360 presets (megui) and everything went good.

[hajj_3]

builds since v1148 dont seem to have the correct version number tag for mediainfo to display, they all say: "x264 core 67 r1148M 400740b" instead of v1173 etc. Hope you guys can fix this in the next version.

[LoRd_MuldeR]

builds since v1148 dont seem to have the correct version number tag for media info to display, they all say: "x264 core 67 r1148M 400740b" instead of v1173 etc. Hope you guys can fix this in the next version.

That most likely isn't a problem of x264. The x264 configure script detects the revision number via GIT. And that part didn't change!

Whoever made the build you are referring to didn't do it properly. The "M" also indicates unofficial patches ;)


Encoded with my own build of r1173, information was detected with Avinaptic:

[ About H.264 encoding ]

User data: x264
User data: core 67 r1173M f6d3166
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2009
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=8
User data: deblock=1:0:0
User data: analyse=0x3:0x133
[...]

[hajj_3]

ahh, i'm using the 1 megui had on it's update list (jeeb's patch).

[JEEB]

Hmm... I always use the information from 'x264 --version' to get the stuff to my relnotes.txt files and so far it has worked well - I can see the version number just fine. So I'd guess the problem is somewhere else...

Just in case, try running 'x264 --version' from command line on this (http://jeeb.fiveforty.jp/x264/1173/x264.exe) build. Of course you should also try the official builds from x264.nl that are compiled without any patches, but I think that my build shouldn't have problems with version numbers...

Also made a test encode with my 1173 build and got the following string in the raw H.264 stream as always - "x264 - core 67 r1173M f6d3166 - H.264/MPEG-4 AVC codec - Copyleft 2003-2009..."

[hajj_3]

can you try opening it with latest mediainfo please to see what version that says.

i emailed the author before posting earlier, he said his app just reads the version from the .mkv file, he doesnt manually detect which version was used so he said the problem was with x264.exe.

[nm]

can you try opening it with latest mediainfo please to see what version that says.
JEEB said that he made a test encode and checked the raw stream, which contains the same version string that MediaInfo would print out.

so he said the problem was with x264.exe.
and more specifically your/MeGUI's x264.exe, which apparently still is r1148.

[LoRd_MuldeR]

I tried to make a fprofiled build of x264 r1178, but it seems the fprofile commands are not compatible with the new arguments :eek:

So I tried to fix the problem like that:
http://pastie.org/537203

Unfortunately I get a new problem now, one that I did not see before:

common/macroblock.c:1417: error: corrupted profile info: profile data is not flow-consistent
common/macroblock.c:1417: error: corrupted profile info: number of executions for edge 3-4 thought to be 53856

Any ideas? :confused:

-- [EDIT] --

D'oh! I found the cause of the problem: fprofile doesn't like threads, but threads are on by default now :D

The proper path should look like this:
http://pastie.org/537224

BTW: I wonder whether presets should be used in the fprofile commands now?

[kemuri-_9]

the fprofile codepaths need a major overhaul...
first of all it doesn't cover b-adapt 0 or b-adapt 2, and now there's the whole incompatibility issue with the new defaults.

not to mention that something broke with the latest patch slew, since x264 exits on a majority of the fprofile codepaths once they're corrected.
seeing at how it exits with a -1 return value with no output, i would say it's from the preset/profile/tune patch

which i've also confirmed by reverting that specific commit.

[LoRd_MuldeR]

not to mention that something broke with the latest patch slew, since x264 exits on a majority of the fprofile codepaths.
seeing at how it exits with a -1 return value with no output, i would say it's from the preset/profile/tune patch

The fprofile commands simply use deprecated CLI arguments that no longer exists in r1178. This will cause x264 to exit.

My patch should fix that. I removes all invalid arguments. The meaning should stay the same, as these options are enabled by default now ;)

But we need to explicitly set "--threads 1" for fprofiled now. That's what I added in the second patch...

[komisar]

LoRd_MuldeR, for gcc 4.4.X add "-fprofile-correction" to CFLAGS for multithread compilation...

...and for "most of the important codepaths" in profiling process this patch (http://komisar.gin.by/x.patch/x265_profile_fix.1178.diff) make identical options for last version

[kemuri-_9]

The fprofile commands simply use deprecated CLI arguments that no longer exists in r1178. This will cause x264 to exit.

My patch should fix that. I removes all invalid arguments. The meaning should stay the same, as these options are enabled by default now ;)

But we need to explicitly set "--threads 1" for fprofiled now. That's what I added in the second patch...

no, i fixed the code paths to use --psnr --ssim for paths 1+ while removing --no-ssim and --no-psnr from 0
and removed --progress replacing it with --threads 1 within the double foreach.
paths 1,2,3,4,5 all exit with -1 with no other output after the above changes.

[LoRd_MuldeR]

paths 1,2,3,4,5 all exit with -1 with no other output after the above changes.

There is no "-8" and no "-w" any longer. These must be removed too. After that it works for me...

[J_Darnley]

For anyone else, try: http://pastebin.com/d2a2c226e It should revert all the tests back to the old settings.

[LoRd_MuldeR]

For anyone else, try: http://pastebin.com/d2a2c226e

Why do you put "--threads 1" to each single line?

Putting it once at the location where you removed the "--progress" is sufficient and avoids redundant code.

[J_Darnley]

Yeah. Fixed that and a couple of remaining default settings. http://pastebin.com/d2a8165aa

[Dark Shikari]

Forgot to update the fprofile settings. Fixed.

[LoRd_MuldeR]

Forgot to update the fprofile settings. Fixed.

You are still using "-w", but I thought that one was removed too :confused:

So I think the correct fix would be to remove "-w" and add "--no-weightb" to all lines that didn't have "-w" before...

[Dark Shikari]

You are still using "-w", but I thought that one was removed too :confused:

So I think the correct fix would be to remove "-w" and add "--no-weightb" to all lines that didn't have "-w" before...The profiles don't have to be exactly the same as before, they just have to exercise all the code paths in as short a commandline as is reasonably possible.

[LoRd_MuldeR]

The profiles don't have to be exactly the same as before, they just have to exercise all the code paths in as short a commandline as is reasonably possible.

That doesn't explain why you explicitly set an option that is enabled by default anyway (and actually doesn't exist as a parameter any more).

So if you don't want to set "--no-weightb", you can at least remove the "-w" parameters, right?

[Dark Shikari]

that doesn't explain why you explicitly set an option that is enabled by default anyway (and actually doesn't exists as a parameter any more).

So if you don't want to set "--no-weightb", you can at least remove the "-w" parameters, right?Ｌｏｏｋ　ａｇａｉｎ　；）

[LoRd_MuldeR]

Ｌｏｏｋ　ａｇａｉｎ　；）

Aaaaand it's gone :D

[Varies]

in last build "x264 modified rev. 1181 (jeeb's)" i can't set threads to 1 :( after encode it's always 6

[kemuri-_9]

in last build "x264 modified rev. 1181 (jeeb's)" i can't set threads to 1 :( after encode it's always 6

adding --threads 1 to the command line is working as it is supposed to.
you're doing something wrong if it isn't

[microchip8]

@wuemura

this thread is ONLY for x264 development discussions, NOT for normal user help!

Please post a new thread about your problems

[Kurtnoise]

@DS: a simple question for you...:D

MaxDPB = (pixel width)*(pixel height)*1.5*min(16, ref #)

does it look correct ?

[LoRd_MuldeR]

I think fprofile is borked in x264 r1189:

OPT5 = --frames 50 --crf 24 -b3 -m10 -r3 --me tesa -t1

It sets SubeME=10, but not Trellis=2. So actually SubME=9 will be used...

[Dark Shikari]

I think fprofile is borked in x264 r1189:

OPT5 = --frames 50 --crf 24 -b3 -m10 -r3 --me tesa -t1

It sets SubeME=10, but not Trellis=2. So actually SubME=9 will be used...Correct. Fixed locally.

[LoRd_MuldeR]

Correct. Fixed locally.

:thanks:

[juGGaKNot]

What is the max subme atm ? 10/11 ? if one would enter a higher value what would happen ?

ask because it does not crash with subme 11/12/666.

or it throws an error message for "invalid" parameters.

Thats why i asked.

[J_Darnley]

10 is the current maximum, and nothing crashes because the library clips the value to between 0 and 10 in x264_validate_parameters

[LoRd_MuldeR]

What is the max subme atm ? 10/11 ? if one would enter a higher value what would happen ?

If you don't want to look at the sources, x264 does have "--(long)help" option you can use. Maybe you look there, before you ask the obvious ;)

-m, --subme <integer> Subpixel motion estimation and mode decision [7]
- 0: fullpel only (not recommended)
- 1: SAD mode decision, one qpel iteration
- 2: SATD mode decision
- 3-5: Progressively more qpel
- 6: RD mode decision for I/P-frames
- 7: RD mode decision for all frames
- 8: RD refinement for I/P-frames
- 9: RD refinement for all frames
- 10: QP-RD - requires trellis=2, aq-mode>0

ask because it does not crash with subme 11/12/666.

Sure it doesn't crash. x264 either clips "wrong" parameter values to the valid range or it throws an error message for "invalid" parameters.

[Chengbin]

Just curious, what does 10L mean?

[Dark Shikari]

first result on google for "10l cola" (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2002-May/007585.html)

[J_Darnley]

The last time that was asked: http://forum.doom9.org/showthread.php?p=1218259&highlight=10L#post1218259
[EDIT] Snap.

[DarkZell666]

The last time that was asked: http://forum.doom9.org/showthread.php?p=1218259&highlight=10L#post1218259
[EDIT] Snap.
first result on google for "10l cola" (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2002-May/007585.html)

And me who thought it simply meant "lol", to indicate self-derision ... nice one ;)

[IgorC]

Is it possible that x264 has surpassed general expecatation for H.264 standard as "twice better than MPEG-2".
I encode a few videos at different by last x264 with new tree MB algo at half of bitrate and it was visually still better than Xvid. (bitrates around 500-1000 kbit/s for DVD resolution).

I know that at high bitrates Xvid can obtain better results but there is also a bitrate saturation effect. And last revision x264 has outstanding quality at much lower bitrates.
IMHO it makes sense to say in case of x264 that is "twice better than MPEG-4 ASP".

My hat is off badly. I've never seen before such brilliant development.

[popper]

i thought the "general expecatation for H.264 standard as "twice better than MPEG-2" was infact 2.5 times better compression for a given quality against mpeg2 (realtime DVB Transport Streams), given the charts given out by the tear one Pro Hardware Encoder AVC vendors (i pointed to way back, but cant find the direct URL again with a quick search), but perhaps you didnt mean it in that sense ?

[Gabriel_Bouvigne]

Is it possible that x264 has surpassed general expecatation for H.264 standard as "twice better than MPEG-2".
I encode a few videos at different by last x264 with new tree MB algo ...
MBTree rate control is totally independant on the fact that the encoder is an h.264 encoder. A similar algorithm could be implemented in an mpeg-2 or mpeg4-asp encoder. Thus I'd say that such an algorithm is irrelevant to the " twice better" claim.

[IgorC]

I wasn't clear.

I tried new treeMB algo and saw that I could go to lower bitrates and still got good quality. Then I decided to compare it to Xvid.
I know that it can be implemented to MPEG-2 and ASP as it's actually happened with VAQ(-like) in HCENC and Xvid implementations. It's not like native H.264 tools: CABAC, reference frames, inloop filter etc...

Now when I rethought my statements I see that I forgot that it isn't correct to compare particular implementations (x264) with format (ASP). It's more correct to compare formats or implementations separately. Xvid vs x264 or H.264 vs ASP.
IIRC H.264 should have ~1.5x quality of ASP. While at reasonable low/middle bitrates x264 has ~2x quality/reduction of bitrate comparing to Xvid.

Main reason of this is that x264 is intensively developing while last important quality (not speed, bugfixes etc...) improvements for Xvid were made during the end of 2004 (except of VAQ in 2008).

[Ku2_BiO_X]

is the new x264 r1203 support vista ultimate x64?

x264 --pass 1 --preset slower --tune animation --bitrate 1000 --output NUL test.avs
i get an error: "could not open test.avs"

the avs script:
"DirectShowSource("test.mkv").converttoyv12"

and when i use test.mkv directly, it only encode ~300 frames but the mkv has more than 300 frames.

another problem: unsupported input format (xvid) when i try to encode avi file.

i use the old revision of x264 (core 65) before and it's working fine.
tq

[nm]

is the new x264 r1203 support vista ultimate x64?

x264 --pass 1 --preset slower --tune animation --bitrate 1000 --output NUL test.avs
i get an error: "could not open test.avs"
Do you have a 32-bit x264 build? Otherwise it can't use AviSynth directly, unless you happen to have squid_80's 64-bit AviSynth build (http://members.optusnet.com.au/squid_80/).

and when i use test.mkv directly, it only encode ~300 frames but the mkv has more than 300 frames.

another problem: unsupported input format (xvid) when i try to encode avi file.
Besides AviSynth, x264 only supports uncompressed YUV 4:2:0 video in AVI, yuv4mpeg or raw files.

[Ku2_BiO_X]

thank you very much nm.
i try the 32-bit version and it works well in my 64bit system. tq

[hajj_3]

when will the x264 in megui update be updated? it is v1183 at the moment, 1210 is the latest version on x264.nl

[kemuri-_9]

when will the x264 in megui update be updated? it is v1183 at the moment, 1210 is the latest version on x264.nl

the x264 devs don't control meGUI, ask the meGUI people instead.

[LoRd_MuldeR]

when will the x264 in megui update be updated? it is v1183 at the moment, 1210 is the latest version on x264.nl

This was answered already in the sticky:
http://forum.doom9.org/showpost.php?p=1311316&postcount=13

Also: Why not replace x264.exe yourself? More than enough people post new builds whenever a new x264 revision becomes available.
You don't need to wait for the x264 developers to upload the new build to the update server for you...

[Astrophizz]

This was answered already in the sticky:
http://forum.doom9.org/showpost.php?p=1311316&postcount=13

Also: Why not replace x264.exe yourself? More than enough people post new builds whenever a new x264 revision becomes available.
You don't need to wait for the x264 developers to upload the new build to the update server for you...

Unless the build changes the cli. To hajj_3: Read some of the Megui threads and you'll see that Kurtnoise has some updates and you can swap over to his server to get a new x264 and core megui version (among other things).

[LoRd_MuldeR]

Unless the build changes the cli. To hajj_3: Read some of the Megui threads and you'll see that Kurtnoise has some updates and you can swap over to his server to get a new x264 and core megui version (among other things).

You can still pass custom CLI parameters that are not supported natively by MeGUI yet ;)