PDA

View Full Version : Why does x264 not embed the complete settings in the file?


jq963152
24th March 2013, 15:36
Hello,

quote from another thread:


The reason why MediaInfo can show "Encoding settings" for files encoded by x264 is because the x264 encoder writes its settings into the file, e.g. for debugging purposes.


Question:

Why does x264 not embed the complete settings in the file?

Some options seem to be missing (at least in MediaInfo).

And why do the embedded settings always look like the API way and never like the CLI way (ref=4 instead of --ref 4 for example)?

Maybe the settings could additionaly be embedded the CLI way when the CLI was used?

Guest
24th March 2013, 16:19
What settings do you think are missing?

LoRd_MuldeR
24th March 2013, 16:45
Some options seem to be missing (at least in MediaInfo).

x264 just writes a string into the file, as a custom SEI message. MediaInfo (and all similar tools) will just show you that string. That's it.

(You can even "see" that information with your favorite Hex editor, if you want to)

And why do the embedded settings always look like the API way and never like the CLI way (ref=4 instead of --ref 4 for example)?

Maybe the settings could additionaly be embedded the CLI way when the CLI was used?

Probably because the info is written by the x264 encoder library (libx264), not by the CLI front-end. The libx264 knows nothing about CLI parameters ;)

There even are a lot of GUI apps built on top of libx264 that don't use CLI parameters at all. And even CLI apps that make use of libx264 may very well use their own different CLI syntax (e.g. FFmpeg).

However all applications that use x264 unavoidably use the libx264 API, so it makes the most sense to document the options exposed by the x264 API, I think.

Another reason: The information that x264 writes into the file is mainly intended for debugging purposes, i.e. for developers. It's not intended to allow users to "copy" settings from existing files...

jq963152
24th March 2013, 17:15
What settings do you think are missing?

Well, just an example:

--pbratio does not not seem to be displayed (which is being used/altered by --tune grain for example).

Again, just an example.

There even are a lot of GUI apps built on top of libx264 that don't use CLI parameters at all.

Yes, i know, like HandBrake for example.

Probably because the info is written by the x264 encoder library (libx264), not by the CLI front-end. The libx264 knows nothing about CLI parameters

However all applications that use x264 unavoidably use the libx264 API, so it makes the most sense to document the options exposed by the x264 API, I think.

Hmm, okay.

But then it still could at least write every option in the file and not just a few.

Another reason: The information that x264 writes into the file is mainly intended for debugging purposes, i.e. for developers. It's not intended to allow users to "copy" settings from existing files...

See above.

MasterNobody
24th March 2013, 17:24
Well, just an example:

--pbratio does not not seem to be displayed (which is being used/altered by --tune grain for example).

Because you most probably used it together with mbtree enabled and in this case its value doesn't matter (it is ignored). libx264 writes only options that can influence encoding stream, i.e. there is no need to write options that don't change output.

Selur
24th March 2013, 17:27
Another reason: The information that x264 writes into the file is mainly intended for debugging purposes, i.e. for developers. It's not intended to allow users to "copy" settings from existing files...
if debugging is the main purpose, wouldn't it be logical to also include an option to not write these settings? (I mean I normally seems to be a common consensus, that debug output should not be enabled as default,.. ;))

btw. is there a tool available which can read a 264 file and output the matrices used? (the encoding settings only indicate that a custom matrices were used, but not how the looked, so even for debugging purposes there are not all options)

It's not intended to allow users to "copy" settings from existing files...
That I do all the time if I need to cut one of my encodes frame accurate,.. :D

jq963152
24th March 2013, 17:36
Because you most probably used it together with mbtree enabled

Yes, --preset veryslow with --tune grain, so yes, mbtree enabled.

and in this case its value doesn't matter (it is ignored). libx264 writes only options that can influence encoding stream, i.e. there is no need to write options that don't change output.

IMHO it should always show every option, even if it was not altered and/or left at default value and even if "it doesn't matter"/is ignored...

It would also be nice if it would show things like --preset veryslow or --tune grain and so on when the CLI was used (and only when the CLI was used). Maybe in a separate line called "Encoding settings (CLI)" or something like that.

paradoxical
24th March 2013, 19:20
IMHO it should always show every option, even if it was not altered and/or left at default value and even if "it doesn't matter"/is ignored...

That seems silly. If the setting is changed or ignored writing out the value, especially if its incorrect, is bad idea since that is just misleading. Not writing it out is much better than writing out incorrect information.

It would also be nice if it would show things like --preset veryslow or --tune grain and so on when the CLI was used (and only when the CLI was used). Maybe in a separate line called "Encoding settings (CLI)" or something like that.

Did you miss the part where libx264 doesn't know the CLI parameters? It only knows it's own API values. The preset and tunes are just part of the CLI frontend to autoset API values.

detmek
24th March 2013, 19:33
Not to mention that x264 has so many options that writing it all would be almost unreadable. I can bearlly find needed info even now when I read MediaInfo log.

jq963152
24th March 2013, 19:40
That seems silly. If the setting is changed or ignored writing out the value, especially if its incorrect, is bad idea since that is just misleading. Not writing it out is much better than writing out incorrect information.

Well, --preset verslow and --tune grain means (among other things) --trellis 2 and --deadzone-inter 6 --deadzone-intra 6, correct?

And the following page:

http://mewiki.project357.com/wiki/X264_Settings#deadzone-inter.2Fintra

says:

Deadzone is incompatible with Trellis.


Now, according to your (and "MasterNobody"'s) logic, x264 should not write the Deadzone option(s) into the file (because of being ignored), correct?

But it does, see:



Encoding settings: ... / trellis=2 /... / deadzone=6,6 / ...


Why?

Did you miss the part where libx264 doesn't know the CLI parameters? It only knows it's own API values. The preset and tunes are just part of the CLI frontend to autoset API values.

No, i didn't miss that. That's why i wrote it would be nice.

Because, maybe it could be changed?

jq963152
24th March 2013, 19:45
PS:

Sorry, at the time of doing post #10 i hadn't yet clicked the link to the Doom9 forum post from "akupenguin" (http://forum.doom9.org/showthread.php?p=1031142#post1031142) where it is explained that Trellis and Deadzone are "incompatible" but still can be used together it seems.

paradoxical
24th March 2013, 19:52
No, i didn't miss that. That's why i wrote it would be nice.

Because, maybe it could be changed?

It could be but that would be a really poor change. That change would then heavily couple libx264 to the CLI fronted to be able to do what you want. The point of libx264 is that it isn't coupled to any one frontend so that it is easy for anyone to create their own. Hence why it only writes out what it knows which is its own API values. For libx264 to write out the CLI values for any particular CLI frontend, you would not only have to write the CLI frontend but then have to modify libx264 as well. Which means anyone creating their own CLI frontend has to fork the libx264 to write the settings out for their specific frontend. That's poor design.

mandarinka
24th March 2013, 20:16
btw. is there a tool available which can read a 264 file and output the matrices used? (the encoding settings only indicate that a custom matrices were used, but not how the looked, so even for debugging purposes there are not all options)

Avinaptic displays the used matrices. Dunno if it allows easy exporting of them into a usable format (but you know... usually the matrix is "Prestige", hehe - if we are talking about non-professionaly encoded video).

Selur
24th March 2013, 20:18
btw. I wrote a small tool a while ago to convert the 'encoding settings' shown through MediaInfo into normal command line elements, those interested can get it here (http://forum.selur.de/topic237-mis2x264-mediainfo-encoding-settings-to-x264-cli.html), if you find a bug and report it, I'll fix it. :)

Didée
25th March 2013, 18:09
Well, --preset verslow and --tune grain means (among other things) --trellis 2 and --deadzone-inter 6 --deadzone-intra 6, correct?
Correct.

And the following page: http://mewiki.project357.com/wiki/X264_Settings#deadzone-inter.2Fintra

says:
Deadzone is incompatible with Trellis.
That's not correct. At least, the wording is a bit unlucky.

Trellis is not "incompatible" with deadzone. Simply put, Trellis is another kind of "deadzone" settings. (Quick picture: deadzone = static threshold, Trellis = smart/adaptive).

Trellis and Deadzone can not be used at the same time. (Two different methods for the same thing.)
However even when Trellis is used, it is not used always. When Trellis=1, then Trellis is used only on the final MB coding. During the previous ME steps, Trellis is not used - hence, there the core will use deadzone.
And even when Trellis=2 (use Trellis on "all" ME steps), then still it is not used during the subsampled lookahead. There, again, the deadzone settings apply.

Summed up: Deadzone is always used in some way or another. Even when Trellis is used.

jq963152
18th April 2013, 21:46
Hello,

i just tried encoding with --vbv-init 1.0 but MediaInfo does not show it. Why not?

And does that mean that --vbv-init 1.0 was ignored?

paradoxical
18th April 2013, 22:05
Because that setting isn't written out. It can't show something that's not there. No, that does not mean it was ignored.

jq963152
13th May 2013, 17:38
Quote from the other thread:

Although it would be possible to modify x264 to never write that information into the file, you cannot expect that anybody here will give advices on how to achieve this. You're not the first one :rolleyes:


Why do YouTube videos not show x264 "Encoding settings" in MediaInfo :confused:?

Groucho2004
13th May 2013, 17:44
Why do YouTube videos not show x264 "Encoding settings" in MediaInfo :confused:?
Maybe because they compile their own patched version of x264? Just guessing.

paradoxical
13th May 2013, 17:50
Why do YouTube videos not show x264 "Encoding settings" in MediaInfo :confused:?

Because they either patched x264 to not write it out or they have that info stripped out when muxed into the mp4 that gets streamed.

jq963152
13th May 2013, 17:59
or they have that info stripped out when muxed into the mp4 that gets streamed.

Hmmm, demuxing it doesn't bring back the information...

MediaInfo doesn't even show "Writing library: x264 core XXX rXXXX", which usually is shown for x264 streams in MediaInfo.

Groucho2004
13th May 2013, 18:18
Hmmm, demuxing it doesn't bring back the information...
:confused: Why would it?

MediaInfo doesn't even show "Writing library: x264 core XXX rXXXX", which usually is shown for x264 streams in MediaInfo.
This is part of the string that is written to the elementary stream.
Here is the code for that if you're interested:
int x264_sei_version_write( x264_t *h, bs_t *s )
{
// random ID number generated according to ISO-11578
static const uint8_t uuid[16] =
{
0xdc, 0x45, 0xe9, 0xbd, 0xe6, 0xd9, 0x48, 0xb7,
0x96, 0x2c, 0xd8, 0x20, 0xd9, 0x23, 0xee, 0xef
};
char *opts = x264_param2string( &h->param, 0 );
char *payload;
int length;

if( !opts )
return -1;
CHECKED_MALLOC( payload, 200 + strlen( opts ) );

memcpy( payload, uuid, 16 );
sprintf( payload+16, "x264 - core %d%s - H.264/MPEG-4 AVC codec - "
"Copy%s 2003-2013 - http://www.videolan.org/x264.html - options: %s",
X264_BUILD, X264_VERSION, HAVE_GPL?"left":"right", opts );
length = strlen(payload)+1;

x264_sei_write( s, (uint8_t *)payload, length, SEI_USER_DATA_UNREGISTERED );

x264_free( opts );
x264_free( payload );
return 0;
fail:
x264_free( opts );
return -1;
}

paradoxical
13th May 2013, 18:49
Hmmm, demuxing it doesn't bring back the information...

Well, yes, the info is gone from the stream. There is nothing to bring back.