x264 development

[ajp_anton]

Why does it feel like the development of the actual encoder has kind of stopped...
Are there still improvements planned?

[Dark Shikari]

Currently there's about 25-30 MBAFF patches queued up waiting for final review. Patience is a virtue!

[simonhorlick]

Other things to look out for are hopefully Trellis ME (summer of code) and energy preserving quant. Both of which look like they'll be really good for compression.

[LoRd_MuldeR]

Other things to look out for are hopefully Trellis ME (summer of code) and energy preserving quant. Both of which look like they'll be really good for compression.

I can't see those on the list of projects palnned for SoC 2011 :confused:
http://wiki.videolan.org/SoC_x264_2011

[Mr VacBob]

Trellis ME is "Non-local RD optimization". Energy-preserving quant is a side project by saintdev (psy-trellis already behaves sort of like this).

[jpsdr]

It seems that bluray-compat put weigthp to 1 ? If i add a command line to put weightp to 2, will it work ?
I don't understand this choice. I thought weigthp 2 was bluray compliant according the specs, and problem was only because of some broken chipset ?
In the same good way, bluray-compat seems to put pict-struct only on interlaced content, and not on progressive content, wich seems to be strictly compliant to the spec, even if some people suggest to always put pict-struct, because some authoring software required it.
So, why chose to strictly follow the spec in one case, and not in the other ?
(Unless i am mistaken and understood things wrongly).

[skampy]

Has anyone ever had problems with the --zones function when the beginning frame is set to when the screen is blank (black)? Say at the very beginning of a video/movie (frame 0), or a few frames after a fade-to-black?

The problem is that, when that beginning frame of the set zone is reached, there is a 'gray' screen displayed for about a second or two, then the video resumes normally. The gray screen doesn't flash, it's simply static gray screen displayed in lieu of what is meant to be, in this case, a black screen.

This has happened with two seperate encodes with two different video sources, with x264 revisions of r1913 and r1924 respectively. Both gray screens occurred when the zone started during a black screen (intro/credits). The zones in this case were nothing special; the only setting used was a bitrate multiplier. I've used zones successfully many times without any problems, but now that I think about it, the start frame for the zone didn't happen to start on a black screen.

I am using the x264 CLI with the lastest x264 revision. The 1st and 2nd passes used exactly the same settings (I am aware that unless --slow-firstpass is specified, the 2nd pass settings aren't used for the 1st pass), and that includes the zone settings. The decoder I use is ffdshow w/ mpc-hc.

Any ideas? Is this a bug, or have I done something wrong?

PS- I don't think posting my x264 cl is relevant in this case, as I cannot fathom how any setting could cause such a weird bug.

[shon3i]

It seems that bluray-compat put weigthp to 1 ? If i add a command line to put weightp to 2, will it work ?
I don't understand this choice. I thought weigthp 2 was bluray compliant according the specs, and problem was only because of some broken chipset ?
In the same good way, bluray-compat seems to put pict-struct only on interlaced content, and not on progressive content, wich seems to be strictly compliant to the spec, even if some people suggest to always put pict-struct, because some authoring software required it.
So, why chose to strictly follow the spec in one case, and not in the other ?
(Unless i am mistaken and understood things wrongly).
It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

pic-struct is not mandatory for progressive content in specs, only for (fake)interlaced and pulldown. But verifiers complain about (probably due bad interpretation of specs)

D_S already update x264 to use pic-struct on (fake)interlaced and pulldown in case bluray compat, we now just wait for next revision.

[Sharc]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

Good to know. That's different then compared to the earlier strategy when later settings in the command line overwrote the preceeding ones.

[Dark Shikari]

weightp 2 gives relatively little compression benefit over 1 (since the modification I made). If you really want to force it, modifying the code is trivial.

[Sharc]

weightp 2 gives relatively little compression benefit over 1 (since the modification I made). If you really want to force it, modifying the code is trivial.
Little compression benefit yes, but I had in mind that the main benefit of weightp 2 was an improvement for fading scenes.

[Dark Shikari]

Little compression benefit yes, but I had in mind that the main benefit of weightp 2 was an improvement for fading scenes.weightp 1 does that now.

[Sharc]

weightp 1 does that now.
Excellent, thanks.

[Sharc]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

Will it also overwrite the --slices parameter?
I am asking because the --slices are still included here (http://sites.google.com/site/x264bluray/home/720p-encoding)

[shon3i]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr

[Sharc]

Thank you. All clear now.

[Dark Shikari]

It doesn't force anything that isn't global to all Blu-ray profiles.

[Sharc]

It doesn't force anything that isn't global to all Blu-ray profiles.
I see. And because it is executed after user parameters it does a clean up of non-compliant user settings :cool:

[jpsdr]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.


So, does it mean that finaly weightp 2 was not bluray compliant strictly speaking of bluray spec, leaving aside all problem concerning crapy broken chipset ?? :confused:

[sneaker_ger]

So, does it mean that finaly weightp 2 was not bluray compliant strictly speaking of bluray spec, leaving aside all problem concerning crapy broken chipset ?? :confused:

No. There's even a comment in the source that this is only to care for broken player, not for Blu-Ray compliance.

[sneaker_ger]

ref=4 for 1080

I don't think this is true, it limits to 6 regardless of resolution.

[mp3dom]

No. There's even a comment in the source that this is only to care for broken player, not for Blu-Ray compliance.

It's indeed true that all the other 'proencoders' out there that made use of weightp doesn't create any problems even on 'crappy chipset' like old mediatek. I think that if x264 is intended to be used not only for custom user who wants BD compatibility for their player but also for professional who wants to create 'commercial' bd compatible with the vast majority of the players out there, this is the right decision (force weightp 1 with bluray-compat). We have already see that BD specs are not so 100% clear and some manufacturer can misinterpret. For mass-replication the highest compatibility comes before highest quality... it's no secret.

[laserfan]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr
So with --bluray-compat I can remove aud and nalhrd from my command line?

It might have been nice if this was in the fullhelp, vs. having to pick-thru these threads (or interpret program code)...

[sneaker_ger]

So with --bluray-compat I can remove aud and nalhrd from my command line?

Yes.

It might have been nice if this was in the fullhelp, vs. having to pick-thru these threads (or interpret program code)...

I agree. There's a lot of things not covered in fullhelp.

[jpsdr]

It's indeed true that all the other 'proencoders' out there that made use of weightp doesn't create any problems even on 'crappy chipset' like old mediatek. I think that if x264 is intended to be used not only for custom user who wants BD compatibility for their player but also for professional who wants to create 'commercial' bd compatible with the vast majority of the players out there, this is the right decision (force weightp 1 with bluray-compat). We have already see that BD specs are not so 100% clear and some manufacturer can misinterpret. For mass-replication the highest compatibility comes before highest quality... it's no secret.

It's a little dictatorship in that specific case... :mad:
Now i'm screwed, and can't set it anymore to 2 despite the fact it's compliant to the bluray spec !!!!
Even if quality improvement is little, i still would like to kept it... It's one thing to put out of spec value in spec, but here it's different...
Big big disapointment...

[mp3dom]

It's a little dictatorship in that specific case... :mad:
Now i'm screwed, and can't set it anymore to 2 despite the fact it's compliant to the bluray spec !!!!

You can still edit & compile a build that doesn't force a weightp<2 with bluray-compat

[shon3i]

I don't think this is true, it limits to 6 regardless of resolution.
You must use level 4 or 4.1 and level limit will down to 4 so it's true, on 720 will down from 9 to 6 because bluray limit. Only 576p25@L3.0 need to set to 5 because that is max.

[sneaker_ger]

You must use level 4 or 4.1 and level limit will down to 4 so it's true, on 720 will down from 9 to 6 because bluray limit. Only 576p25@L3.0 need to set to 5 because that is max.

Yes, but we were talking about the --bluray-compat option.

[jpsdr]

You can still edit & compile a build that doesn't force a weightp<2 with bluray-compat

Easy to say...

[Selur]

okay, trying to wrap my head around it, so I can modify Hybrid accordingly (tomorrow), I try to sum it up:

--bluray-compat
enforces:
- 3 or less bframes
- bpyramid=strict (when bframes are used and bypramid is enabled, or does it always enforce bpyramid even when --b-pyramid none was set?)
- 4/6 max key frames depending on resolution
- weightp=1 (since this is forced, weightp 2 can't be used)
- aud=1
- nalhrd=vbr

Cu Selur

[laserfan]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr

So with --bluray-compat I can remove aud and nalhrd from my command line?

Yes. I agree. There's a lot of things not covered in fullhelp.
Thanks for answering. I wondered if --b-pyramid none still worked (for Sony DVDAP) using --bluray-compat and it does.

As a point of interest, I noticed that aud does not appear in the header info/MediaInfo. Maybe it never has, I dunno.

[laserfan]

--bpyramid=strict (when bframes are used and bypramid is enabled, or does it always enforce b_pyramid even when --b-pyramid none was set?)I just tried --b-pyramid none and it worked/is not overridden, get b_pyramid=0

[mp3dom]

Easy to say...
I think you just need to comment line 610 in encoder.c

h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE );

[nurbs]

- 4/6 max key frames depending on resolution

The limit is 6 regardless of resolution.
h->param.i_frame_reference = X264_MIN( h->param.i_frame_reference, 6 );
Since you need to set the level anyway it can be lower depending on input resolution, i.e. 4 for 1080p.

[sneaker_ger]

weightp is also only limited to 1, not forced.
Better see for yourself:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=encoder/encoder.c;h=b0fc7b907ea55e93ab2903a06e48ba02d71db4bb;hp=fd2c877373a72497e7ee0fe1462b48f547cbbc18;hb=f9e7f531048df7219a44203031c8f79bae6170d0;hpb=f422ec93254ed3f9883acac0bb3f67e3b4ea960c

[shon3i]

Yes, but we were talking about the --bluray-compat option.
You can't use use bluray compat without setting proper level, it's pointless, so de facto it's based on resolution, except 576@25 L3.0 where maximum references is 5.

Other settings like bframes, bpyramid, weightp are maxed to bd specs, and can be lowered or switched off.

[jpsdr]

I think you just need to comment line 610 in encoder.c

h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE );


I was thinking more on the following part :
Install ALL the tools/program/etc... needed to compile your own version, follow all the updates, the patches, etc...
And when i see all the troubles people have when you're noob on making your own x264 version.
No thanks !!!!!!! I don't have time for this, and don't want to spend on it.
I use the Jeeb's versions, wich are perfect for me because having the fade compensate patch.
I personnaly realy deeply regret this decision, of not allowing a still bluray compliant option, but i'll survive...

[mp3dom]

If the problem is only fades, I think that the fade-compensate already do its job quite nicely (it's also a method to improve fades without using weightp2).
Regarding fades, there are example out there that demonstrate that it's possible to have a very good result with the (equivalent) weightp=1 (sometimes even better results than x264's weightp2)
Regarding weightp2 probably it comes in a gray zone with free interpretation. If it's clear that weightp2 is in specs, all the players would have supported it and all pro-encoders would use it. Instead, some decoder chipset doesn't support it and pro-encoders doesn't use it.

[kieranrk]

Regarding weightp2 probably it comes in a gray zone with free interpretation. If it's clear that weightp2 is in specs, all the players would have supported it and all pro-encoders would use it. Instead, some decoder chipset doesn't support it and pro-encoders doesn't use it.

What you're saying doesn't even make any sense.

[mp3dom]

Is there a reason why some decoder chipset (players) have problems handling duplicates while (as far as I know) the same players doesn't exhibit the problem with other commercial titles (that still uses weighted prediction for P frames but supposedly doesn't use dupes?). Probably in the BD specs there isn't a clearly statements about this, because in the other case all players would have decoded the stream with dupes correctly (from the beginning or via a firmware upgrade)

[kieranrk]

Is there a reason why some decoder chipset (players) have problems handling duplicates while (as far as I know) the same players doesn't exhibit the problem with other commercial titles (that still uses weighted prediction for P frames but supposedly doesn't use dupes?). Probably in the BD specs there isn't a clearly statements about this, because in the other case all players would have decoded the stream with dupes correctly (from the beginning or via a firmware upgrade)

Well they can't just mention every single H.264 feature in the Blu-Ray spec. There's only a dozen or so pages about H.264.

[sneaker_ger]

The problem wasn't only in Blu-Ray players, but also software non-Blu-Ray specific players. And both hardware and software manufactors have acknowledged their mistake and have fixed the problem in newer products (and some of them fixed it with firmware updates for older products). It's just that no encoder made use of it until it was implemented in x264, so manufactors didn't have any such stream for their product testing and were thus unaware of the problem.

[sneaker_ger]

You can't use use bluray compat without setting proper level

Of course I can. 1080p24:
x264 --bluray-compat --vbv-maxrate 24000 --vbv-bufsize 24000 --keyint 24 --sar 1:1 -o out.264 input.file

100% Blu-Ray compliant.

But that wasn't even my point - it's that we were talking about the bluray-compat option which limits ref frames to a maximum of 6. period. We shouldn't mix things up to prevent confusion. Selur already was. But maybe I'm just splitting hairs...

[rallymax]

so... let me get this right...

Some of you are complaining about a command line switch (--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself). A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

These are the same people that are using x264 for FREE, and don't contribute to the coding effort.

If you MUST have a patch that differs from the mainline development of x264 then do the 5 or so steps to get MSYS, GIT the repos, SVN things like ffmpeg, do "configure ...;make install" for ffmpeg then "configure ...;make install" for x264. If that's too much why don't you go and whine to that PATCH feature developer to get them to change --bluray-compat to your interpretation.

How about showing some appreciation for the volunteer effort that the x264 Dev's give EVERY DAY FOR FREE.

To devs - you rock. I'm excited and appreciative every day of your gift to the community.:thanks:

[sneaker_ger]

(--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself).

You can't, some of the options are only available through --blueray-compat

A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

The x264 devs also regard it as spec compliant. It's only to care for older, buggy players.

If you MUST have a patch that differs from the mainline development of x264 why don't you go and whine to that branch developer to get them to change --bluray-compat to your interpretation.

That developer is active here, so whining here is an option. Patching is also trivial (delete a single line), but setting up a compiling environment is not and doing regular compiles is a lot of work.

To devs - you rock. I'm excited and appreciative every day of your gift to the community.:thanks:

This.

[Selur]

summing the feedback my last post got up:

--bluray-compat

enables a bunch of 'Blu-ray hacks':
- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames cannot reference frames outside their minigop
- Open-GOP keyframe interval hack
renders '--open-gop' parameters obsolete:
- now: --bluray-compat + --open-gop <> old version: --open-gop bluray
- now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD
enforces:
- aud=1
- nalhrd=vbr
(-> these are not needed in the command line when using '--bluray-compat')
restricts:
- bframes to: 3 or less
- bpyramid to: strict or none
- max references to: 6 or less
- weightp to: 1 or 0

[Dark Shikari]

It doesn't enforce nalhrd=vbr, it restricts nalhrd >= vbr.

[iSeries]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?

[Dark Shikari]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?It's not.

[Sharc]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?
I use this site (http://sites.google.com/site/x264bluray/home) as a reference. It appears to be well maintained and corresponds with the latest version from http://x264.nl.

... and the information given here (http://forum.doom9.org/showthread.php?t=154533) in the first post (sticky).