PDA

View Full Version : "Official" High Profile Settings for x264?


wswartzendruber
29th April 2008, 02:20
I've been racking my brains out trying to figure out what the official high profile options are for x264. If I can get someone to post a command line, I can patch those settings into MEncoder. I'm looking for the highest level of the highest profile.

Also, is it important to set a profile level if I'm putting these in a Matroska container? I'm asking because MEncoder (AFAIK) doesn't support setting the profile level.

Dark Shikari
29th April 2008, 02:31
"Official"? There are no "official" settings. You could use, for example, the 2008 HDTV Scene settings, of course; but those are in no way "official" (though they are endorsed by the developers...).

High Profile is signaled in the stream itself, not in the container.

Blue_MiSfit
29th April 2008, 05:09
Yeah, don't worry so much about "official" high profile settings. Worry about what your decoder can handle, and how much time you're willing to spend encoding :)

~MiSfit

nm
29th April 2008, 07:31
Also, is it important to set a profile level if I'm putting these in a Matroska container? I'm asking because MEncoder (AFAIK) doesn't support setting the profile level.
If you mean Level, use the level_idc parameter in x264encopts. Then x264 will write the level to the elementary stream and it will get muxed to the target container along with rest of the data.

audyovydeo
29th April 2008, 07:32
I've been racking my brains out trying to figure out what the official high profile options are for x264. If I can get someone to post a command line, I can patch those settings into MEncoder. I'm looking for the highest level of the highest profile.


I understand your question : when I started playing with x264 one of my first concerns was to make my encodes compliant to high profile.

As a starting point I took sharhtooth's megui settings for high profile, but I wanted to understand each option. It wasn't the case last year, but this page has been enriched since then and pretty much says it all :

http://en.wikipedia.org/wiki/X264


Another important thread to read is the one about DXVA compliance.

Here are my settings for Baseline, Main and High profiles. Open to criticism of course :

set base=-r 1 --me hex -m 5 -t 0 -A i4x4,p4x4,p8x8 --direct auto --no-fast-pskip --no-cabac

set main=-r 1 -b 16 --me hex -m 5 -t 0 -A p8x8,p4x4,b8x8,i4x4 --direct auto --b-pyramid -w --bime --no-fast-pskip --no-cabac

set high=-r 1 -b 16 --me hex -m 5 -t 1 -A all -8 --direct auto --b-pyramid -w --bime --no-dct-decimate --no-fast-pskip

for the High setting, I can vary --ref upto 4, and --me umh, according to the video source & my compression needs

all this for level 3.1 material (DV/PAL mainly).

hope this helps.
cheers
audyovydeo


PS - INPUT NEEDED :

I've read everything & its contrary about --no-dct-decimate :

- don't use with trellis (various sources)
- no good reason not to use it (dark shikari's guide)

Anyone got a definitive answer ?

Dark Shikari
29th April 2008, 07:35
Main allows CABAC. Also note that the "profiles" have nothing to do with bitrate or resolution; that's the levels.

All x264 output is High Profile compliant except for lossless mode, which requires High 4:4:4 profile.

nm
29th April 2008, 07:53
As a starting point I took sharhtooth's megui settings for high profile, but I wanted to understand each option. It wasn't the case last year, but this page has been enriched since then and pretty much says it all :

http://en.wikipedia.org/wiki/X264
MPlayer/MEncoder manual page is also quite complete (AQ setting descriptions are still missing though) and it offers more insight to some parameters. Search for x264encopts in http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html

wswartzendruber
29th April 2008, 15:18
Okay, thanks for the input so far. Here are my proposed settings:

frameref=3
bframes=16
me=umh
subq=7
trellis=1
partitions=all
8x8dct
direct_pred=auto
b_pyramid
weight_b
bime
nodct_decimate
nofast_pskip
level_idc=3.1
threads=2
crf=20
Now, why am I using level 3.1 instead of level 3.0? After reading Wikipedia, it said (for H.264) that level 3.0 was good for 720x480@30. I'm ripping to 720x480 at a little under 24 FPS (film). I would like to assume that I could use 3.0 for 30 FPS at the same resolution.

Other than that, what I'm understanding here is that if product X claims to support high profile, these settings should work. I don't really give two craps about QuickTime or Apple TV.

EDIT: These will likely be going in an MP4 container.

Dark Shikari
29th April 2008, 17:29
Level also makes certain bitrate restrictions which you should probably abide by ;)

wswartzendruber
29th April 2008, 20:12
Whoa, hang on. I thought Dark Shikari said that all of x264 (except for lossless) is compliant with high profile. If that's so, then why can't audyovydeo take his framerefs past 4? As far as I know, x264 allows for 16.

Also, when Dark Shikari says x264 is compliant with high profile, is that High, High 10, or High 4:2:2?

And I still don't get why I'm supposed to use level 3.1 instead of 3.0. My bitrate isn't exceeding 12.5 Mbps.

audyovydeo
29th April 2008, 20:21
Whoa, hang on. I thought Dark Shikari said that all of x264 (except for lossless) is compliant with high profile. If that's so, then why can't audyovydeo take his framerefs past 4? As far as I know, x264 allows for 16.

Also, when Dark Shikari says x264 is compliant with high profile, is that High, High 10, or High 4:2:2?

And I still don't get why I'm supposed to use level 3.1 instead of 3.0. My bitrate isn't exceeding 12.5 Mbps.

Your legitimate questions are addressed in the DXVA compliance thread I mentioned previously. I would do a disservice to resume it here. Read it from top to bottom.

http://forum.doom9.org/showthread.php?t=132924


But the main reason I don't use more that 4 ref frames is the diminishing compression return vs the encoding speed.

cheers
audyovydeo

Dark Shikari
29th April 2008, 20:23
Whoa, hang on. I thought Dark Shikari said that all of x264 (except for lossless) is compliant with high profile. If that's so, then why can't audyovydeo take his framerefs past 4?Because he's encoding for a specific level too, not just a specific profile.

desta
29th April 2008, 20:49
http://en.wikipedia.org/wiki/H.264#Levels

wswartzendruber
29th April 2008, 23:44
Is x264-20080406 SVN721 or newer? That's the latest version in the Gentoo tree.

And is, by any chance, nofast_pskip going to break anything? I'm using the recommended options on page 1 of the thread that audyovydeo posted, but would like to add that. AFAIK, that setting just determines how quickly the compressor rations out the bits.

Dark Shikari
30th April 2008, 00:08
Is x264-20080406 SVN721 or newer? That's the latest version in the Gentoo tree.That's quite an old version... but its a relatively new compile of an old version! I suspect that the package maintainer hasn't noticed that we switched to git ages ago...

Ugh, Gentoo. (www.funroll-loops.info)

And is, by any chance, nofast_pskip going to break anything? I'm using the recommended options on page 1 of the thread that audyovydeo posted, but would like to add that. AFAIK, that setting just determines how quickly the compressor rations out the bits.

Yes, no-fast-pskip will almost never decrease quality; it will usually increase it.

wswartzendruber
30th April 2008, 00:50
That's quite an old version... but its a relatively new compile of an old version! I suspect that the package maintainer hasn't noticed that we switched to git ages ago...

Ugh, Gentoo. (www.funroll-loops.info)



Yes, no-fast-pskip will almost never decrease quality; it will usually increase it.
Sorry, but I didn't quite get your response. I'm mainly trying to avoid the b_pyramid problem with DXVA.

And dude, Gentoo pwnz3r3s j00!!!!!! Ricers FTW!!!!! :cool:

J/K I use modest compiler flags.

Dark Shikari
30th April 2008, 00:52
Sorry, but I didn't quite get your response. I'm mainly trying to avoid the b_pyramid problem with standalone players.What do you mean, "get my response"? I suggest you update your version to a later one, since yours is >100 revisions old.

desta
30th April 2008, 01:24
I think he just means he didn't understand.

wswartzendruber
30th April 2008, 01:27
What do you mean, "get my response"? I suggest you update your version to a later one, since yours is >100 revisions old.

I was asking if my revision had the b_pyramids issue with DXVA resolved. Whoever maintains x264 over at Gentoo doesn't update the repository more than once every few months. I might end up having to roll my own ebuild to get the latest one.

Dark Shikari
30th April 2008, 01:31
I was asking if my revision had the b_pyramids issue with DXVA resolved. Whoever maintains x264 over at Gentoo doesn't update the repository more than once every few months. I might end up having to roll my own ebuild to get the latest one.Or you can just git clone, configure, make, make install like everyone else does ;)

And yes, the b-pyramid issue was resolved long ago.

Shinigami-Sama
1st May 2008, 07:04
Or you can just git clone, configure, make, make install like everyone else does ;)

And yes, the b-pyramid issue was resolved long ago.

if he does his own ebuild he could build it smart enough to always get the latest sauce and compile it all for him

the power of gentoo ;)

wswartzendruber
2nd May 2008, 16:27
Well seeing as how my current version is not even a month old, I think I'm just going to stick with that one for now. And when the ebuild maintainer, is his good judgment, decides to update it, I will merge it. I don't see the need to constantly upgrade something. No matter what, it's always going to be outdated. I would rather use a stable snapshot that gets updated every now and then.

Dark Shikari
2nd May 2008, 16:33
Well seeing as how my current version is not even a month old, I think I'm just going to stick with that one for now. And when the ebuild maintainer, is his good judgment, decides to update it, I will merge it. I don't see the need to constantly upgrade something. No matter what, it's always going to be outdated. I would rather use a stable snapshot that gets updated every now and then.
That's not one month old; its nearly 4 or 5 months old. Revision 721 was in mid-January.

PROTIP: Age is not defined by when something is compiled, but by when it was originally released. If I compile gcc 2.9.5 today, that doesn't make it brand new.

cogman
2nd May 2008, 17:37
Humm, an uber-high quality setting you say. Well there isn't anything official but give this a try and see if that is a "High" enough profile for you.

--crf 16 --ref 16 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,0 --subme 7 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --merange 32 --threads auto --thread-input --progress --output "output" "input" --me tesa

However, be prepared for day long encodes and file sizes that are larger then normal.

wswartzendruber
2nd May 2008, 18:05
I seem to recall saying:

Is x264-20080406 SVN721 or newer? That's the latest version in the Gentoo tree.

Dark Shikari
2nd May 2008, 18:09
I seem to recall saying:I thought by that you meant that "x264-20080406" was SVN721.

Inventive Software
2nd May 2008, 19:15
Don't trust whatever's in the Gentoo tree, since for most Linux distros, the software isn't entirely up to date. Checkout whatever's in the GIT trunk and compile that. If you're savvy, you can make an auto-compile script for it.

wswartzendruber
2nd May 2008, 19:33
Don't trust whatever's in the Gentoo tree, since for most Linux distros, the software isn't entirely up to date. Checkout whatever's in the GIT trunk and compile that. If you're savvy, you can make an auto-compile script for it.
And Gentoo has taught me that the latest snapshot is not always the most stable. Regressions are a natural part of software development, and the Gentoo developers try to ensure that when it comes to continuously developed projects, the most stable snapshots are posted in the repository.

Dark Shikari
2nd May 2008, 19:42
And Gentoo has taught me that the latest snapshot is not always the most stable. Regressions are a natural part of software development, and the Gentoo developers try to ensure that when it comes to continuously developed projects, the most stable snapshots are posted in the repository.Of course, that logic doesn't always work with projects that don't have stable branches. As a result, such as in x264 and ffmpeg, bugfixes aren't backported, so the absolute latest revision might indeed be the "most stable". Of course, you still have to be careful since there have been a couple revisions that caused problems on certain CPUs (which were, fortunately, fixed a few days later).

Lokean
5th May 2008, 02:24
I thought by that you meant that "x264-20080406" was SVN721.
No, Gentoo's 20080406 version is the official daily snapshot from 2008-04-06.

If you want the "live" git source, you need to use the ebuild in berkano overlay.