Why do many people hide their x264 encoder settings...?

[Lathe]

I find this more often now; WHY is it that people do 'something', I do not know what it is, but it seems deliberately to hide the encoder settings used with x264 when you go to read them with MediaInfo.

Now, in reading some older posts, it SEEMS that the developers most certainly did not want people to do that. It is so frustrating because when I see files where there are no encoder settings shown, then you don't learn anything from it. Most annoying.

Any explanations as to why people do this? Also, is there any way to 'read' the file with any CLI code or any way to render what x264 settings were used? There is a tantalizing thread on VideoHelp, where a fellow I think wrote out some code to do exactly this, but it was only for Linux and OsX. I didn't realize it until I kept trying to plug it into the CMD line and it didn't work :)

Thanks kindly for anyone who can explain why people do this and what means, if any there might be to extract it anyway.

Cheers!

[Dust Signs]

when I see files where there are no encoder settings shown, then you don't learn anything from it.
I think that is exactly the point. Some people think that their settings are so "special" that they don't want to share them with anyone else. I think that the x264 developers are right in not supporting this - mainly because most of these "hidden"/"special" settings are garbage.

Also, is there any way to 'read' the file with any CLI code or any way to render what x264 settings were used?
As far as I know, the settings are written as a custom SEI message into the bit stream (if your output is an Annex B bit stream). The message content is a list of settings, more or less in the same way the CLI parameters are specified, i.e., as strings. If the SEI is gone, it will be nearly impossible to find the parameters, but if, e.g., only the SEI type has been messed with to avoid detection, this is much easier to fix.

Best regards
Dust Signs

[Kurtnoise]

You said "many"people"...could you clarify this a litlle bit ? I'm wondering what is it the number of those people because this is a stupid thing to hide such settings.

[jpsdr]

Parameters used by x264 are storred in the h264 stream, probably using some tag. If you open your file with mediainfo, in the video stream describtion, you'll have a line showing the parameters used.

[Ghitulescu]

Why?

Maybe because each video is unique, both in content and in destination/use.

[Groucho2004]

You're assuming that someone deliberately patched an AVC stream created by x264 to hide the settings. If that is the case, why don't you ask that person? Where would one even find these streams?

[hello_hello]

How do you know the x264 encoder was used?

Maybe some muxing programs remove the supplemental enhancement information, or don't necessarily re-write it.
For example if you split an MKV video containing x264 encoded video with MKVMergeGUI, the first section will retain the SEI but the second section will not.

[detmek]

You're assuming that someone deliberately patched an AVC stream created by x264 to hide the settings. If that is the case, why don't you ask that person? Where would one even find these streams?
Actually, someone patched x264 itself not to write encoder settings. I found one of those builds a 2-3 years ago. And, as per rule 6 we can not talk about those streams.

[Lathe]

Wow, well I sure appreciate all the input and thoughts on this; thank you very much. I just was reading earlier posts where the developers were saying quite strongly that they did not approve of doing this. Thanks DustSigns for the detail. Thanks Kurtnoise, I agree with you. Thanks jpsdr, but that was why I was asking in the first place; MediaInfo does NOT show the encoder settings used. Thank you Ghit for the interesting abstract ambiguity :) Groucho, I KNOW you are either one of the developers or someone with a LOT of experience in this (I have read MANY of your posts) , so I wonder why you ask that specifically - perhaps I am just not experienced enough, but I would ASSUME that if the developers made the codec intentionally to show the parameters, and they DON'T show, then someone has I guess either inadvertently (doubtful) or deliberately removed them. Thank you Hello Hello (you are always most kind and helpful and are NEVER condescending, and I very much appreciate that!) That actually is quite interesting; I didn't know that an application, especially one as common as MKVMerge would remove the information in certain cases.

Sincerely though; I honestly was extremely curious about this and I DO appreciate the many interesting insights into this! I'm always TRYING at least to gain more insight into x264 and how it is used (or perhaps misused in this case...)

Cheers!

[Groucho2004]

Groucho, I KNOW you are either one of the developers or someone with a LOT of experience in this (I have read MANY of your posts) , so I wonder why you ask that specifically - perhaps I am just not experienced enough, but I would ASSUME that if the developers made the codec intentionally to show the parameters, and they DON'T show, then someone has I guess either inadvertently (doubtful) or deliberately removed them.
I guess I did not express myself clearly. There are several possibilities why the encoder settings are not showing in Mediainfo:
- Another encoder than x264 was used
- Someone used a patched version of x264 that does not write the parameters into the stream
- Someone removed that info after encoding
- ...

So, if you come across such a stream you should ask the person who created it why they removed the info. I sure don't know why one would do that.

Maybe it's done by some dumbass, self-proclaimed "scene" encoder gurus who think they have found the holy grail of settings and want to keep them a secret.

p.s. I'm not one of the x264 devs, not sure about LOTS (in capitals) of experience either...

[Lathe]

I guess I did not express myself clearly. There are several possibilities why the encoder settings are not showing in Mediainfo:
- Another encoder than x264 was used
- Someone used a patched version of x264 that does not write the parameters into the stream
- Someone removed that info after encoding
- ...

So, if you come across such a stream you should ask the person who created it why they removed the info. I sure don't know why one would do that.

Maybe it's done by some dumbass, self-proclaimed "scene" encoder gurus who think they have found the holy grail of settings and want to keep them a secret.

p.s. I'm not one of the x264 devs, not sure about LOTS (in capitals) of experience either...

Heh... well, I appreciate your taking the time to clarify that; and I certainly and fully agree with you that there should be no reason to do that deliberately (unless, of course, you are a self-proclaimed dumb@ss guru...) I would assume that the developers would not want people to 'patch' their work in order to do this.

Thank you all very much again!

[Sharc]

It seems the encoder settings info gets lost when the video file is muxed with tsMuxeR ....

[Groucho2004]

It seems the encoder settings info gets lost when the video file is muxed with tsMuxeR ....
Hm, not from what I'm seeing. Where did you read that?

[Sharc]

Hm, not from what I'm seeing. Where did you read that?
When I inspect the encoded video file (*.264) before muxing with MediaInfo it returns all the encoder settings. When I inspect the muxed *.m2ts the encoder settings are no longer shown.
The former (2D) version 1.10.6 of tsmuxer did not strip the encoder settings off.

[Groucho2004]

When I inspect the encoded video file (*.264) before muxing with MediaInfo it returns all the encoder settings. When I inspect the muxed *.m2ts the encoder settings are no longer shown.
The former (2D) version 1.10.6 of tsmuxer did not strip the encoder settings off.
I'm doing the same thing, the encoder settings are still there. The version of tsmuxer is 2.6.12.

Edit: I should mention that I'm using the command line tsmuxer. Maybe the gui strips the settings.

[Sharc]

I'm doing the same thing, the encoder settings are still there. The version of tsmuxer is 2.6.12.

Edit: I should mention that I'm using the command line tsmuxer. Maybe the gui strips the settings.
Strange. Command line tsmuxer 2.6.12 seems to strip the encoder settings as well here. I get all the video information from MediaInfo, but the encoder settings are lost.
Is there anything to tweak in the .meta of tsmuxer or MediaInfo which I might be missing?

[Groucho2004]

Strange. Command line tsmuxer 2.6.12 seems to strip the encoder settings as well here. I get all the video information from MediaInfo, but the encoder settings are lost.
Is there anything to tweak in the .meta of tsmuxer or MediaInfo which I might be missing?

Meta file content:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --auto-chapters=5 --vbr --vbv-len=500
V_MPEG4/ISO/AVC, "V:\Working\Avatar\Avatar.264", fps=23.976
A_AC3, "V:\Working\Avatar\source\Avatar.ac3", lang=eng

Command line:
tsmuxer <metafile> <bddir>

Mediainfo DLL version: 0.7.70.0

Lastly, looking at the file content from within FAR Manager you can see the settings are there:
http://s23.postimg.org/jyvjupqqz/Image1.png

[Motenai Yoda]

with taro's builds just set --opts 0 (maybe 1 too) didn't write x264 settings

the patch should be
From 61170cf8fdf1f15bee50d5d16e717f5b4b88672f Mon Sep 17 00:00:00 2001
From: Lucien <astrataro@gmail.com>
Date: Thu, 7 Mar 2013 18:44:29 +0000
Subject: [PATCH 08/42] Add a parameter to set level of writing options in User
Data Unregistered SEI

---
common/common.c | 34 +++++++++++++++++++++++++++++++++
encoder/set.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
x264.c | 7 +++++++
x264.h | 15 +++++++++++++++
4 files changed, 110 insertions(+), 5 deletions(-)

diff --git a/common/common.c b/common/common.c
index 9ba67af..d32f184 100644
--- a/common/common.c
+++ b/common/common.c
@@ -180,6 +180,10 @@ void x264_param_default( x264_param_t *param )
param->i_opencl_device = 0;
param->opencl_device_id = NULL;
param->psz_clbin_file = NULL;
+
+ param->i_opts_write = X264_OPTS_FULL;
+ for( int i = 0; i < X264_OPTS_MAX; i++ )
+ param->psz_opts[i] = NULL;
}

static int x264_param_apply_preset( x264_param_t *param, const char *preset )
@@ -1029,6 +1033,36 @@ int x264_param_parse( x264_param_t *p, const char *name, const char *value )
p->b_aud = atobool(value);
OPT("sps-id")
p->i_sps_id = atoi(value);
+ OPT("opts")
+ {
+#define OPTS_SET( psz_x, prefix, flag ) \
+ if( !strncasecmp( value, prefix, strlen(prefix) ) ) \
+ { \
+ if( p->i_opts_write & flag ) \
+ { \
+ free(psz_x); \
+ psz_x = NULL; \
+ } \
+ psz_x = strdup( value + strlen(prefix) ); \
+ p->i_opts_write |= flag; \
+ }
+ OPTS_SET( p->psz_opts[0], "preinfo:" , X264_OPTS_PREINFO )
+ else OPTS_SET( p->psz_opts[0], "0:" , X264_OPTS_PREINFO )
+ else OPTS_SET( p->psz_opts[1], "postinfo:", X264_OPTS_POSTINFO )
+ else OPTS_SET( p->psz_opts[1], "1:" , X264_OPTS_POSTINFO )
+ else OPTS_SET( p->psz_opts[2], "preopt:" , X264_OPTS_PREOPT )
+ else OPTS_SET( p->psz_opts[2], "2:" , X264_OPTS_PREOPT )
+ else OPTS_SET( p->psz_opts[3], "postopt:" , X264_OPTS_POSTOPT )
+ else OPTS_SET( p->psz_opts[3], "3:" , X264_OPTS_POSTOPT )
+ else
+ {
+ int flag = strlen(value) == 1 && isdigit(value[0]) ? atoi(value) : atobool(value);
+ b_error |= flag < X264_OPTS_NONE || flag > X264_OPTS_FULL;
+ p->i_opts_write &= ~X264_OPTS_FULL; // clear basic flag bit
+ p->i_opts_write |= flag; // write basic flag bit
+ }
+#undef OPTS_SET
+ }
OPT("global-header")
p->b_repeat_headers = !atobool(value);
OPT("repeat-headers")
diff --git a/encoder/set.c b/encoder/set.c
index 6b0881b..d71917e 100644
--- a/encoder/set.c
+++ b/encoder/set.c
@@ -569,26 +569,75 @@ int x264_sei_version_write( x264_t *h, bs_t *s )
};
char *opts = x264_param2string( &h->param, 0 );
char *payload;
- int length;
+ int offset = 16;
+ int length = 200;
+
+#define X264_FREE_OPTS \
+{ \
+ for( int i = 0; i < X264_OPTS_MAX; i++ ) \
+ { \
+ if( h->param.psz_opts[i] ) \
+ { \
+ free( h->param.psz_opts[i] ); \
+ h->param.psz_opts[i] = NULL; \
+ } \
+ } \
+}

if( !opts )
+ {
+ X264_FREE_OPTS
return -1;
- CHECKED_MALLOC( payload, 200 + strlen( opts ) );
+ }
+ if( h->param.i_opts_write & X264_OPTS_SETTING )
+ length += strlen( opts );
+ for( int i = 0; i < X264_OPTS_MAX; i++ )
+ {
+ if( h->param.psz_opts[i] )
+ length += strlen( h->param.psz_opts[i] );
+ }
+ CHECKED_MALLOC( payload, length );

memcpy( payload, uuid, 16 );
- sprintf( payload+16, "x264 - core %d%s - H.264/MPEG-4 AVC codec - "
- "Copy%s 2003-2014 - http://www.videolan.org/x264.html - options: %s",
- X264_BUILD, X264_VERSION, HAVE_GPL?"left":"right", opts );
+ if( !h->param.i_opts_write )
+ *(payload + offset) = '\0';
+ else
+ {
+ if( h->param.i_opts_write & X264_OPTS_PREINFO )
+ offset += sprintf( payload + offset,
+ ( h->param.i_opts_write & X264_OPTS_INFO ) ? "%s " : "%s",
+ h->param.psz_opts[0] );
+ if( h->param.i_opts_write & X264_OPTS_INFO )
+ offset += sprintf( payload + offset, "x264 - core %d%s - H.264/MPEG-4 AVC codec - "
+ "Copy%s 2003-2014 - http://www.videolan.org/x264.html",
+ X264_BUILD, X264_VERSION, HAVE_GPL?"left":"right" );
+ if( h->param.i_opts_write & X264_OPTS_POSTINFO )
+ offset += sprintf( payload + offset, " %s", h->param.psz_opts[1] );
+ if( h->param.i_opts_write & ( X264_OPTS_PREOPT | X264_OPTS_SETTING | X264_OPTS_POSTOPT ) )
+ {
+ offset += sprintf( payload + offset, " - options:" );
+ if( h->param.i_opts_write & X264_OPTS_PREOPT )
+ offset += sprintf( payload + offset, " %s", h->param.psz_opts[2] );
+ if( h->param.i_opts_write & X264_OPTS_SETTING )
+ offset += sprintf( payload + offset, " %s", opts );
+ if( h->param.i_opts_write & X264_OPTS_POSTOPT )
+ offset += sprintf( payload + offset, " %s", h->param.psz_opts[3] );
+ }
+ }
length = strlen(payload)+1;

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

+ X264_FREE_OPTS
x264_free( opts );
x264_free( payload );
return 0;
fail:
+ X264_FREE_OPTS
x264_free( opts );
return -1;
+
+#undef X264_FREE_OPTS
}

void x264_sei_buffering_period_write( x264_t *h, bs_t *s )
diff --git a/x264.c b/x264.c
index 2a72203..73bf88c 100644
--- a/x264.c
+++ b/x264.c
@@ -989,6 +989,11 @@ static void help( x264_param_t *defaults, int longhelp )
H2( " --timebase <int/int> Specify timebase numerator and denominator\n"
" <integer> Specify timebase numerator for input timecode file\n"
" or specify timebase denominator for other input\n" );
+ H2( " --opts <integer> Set level of writing options in SEI [%d]\n"
+ " - 0: no information will be written in SEI\n"
+ " - 1: write x264 information\n"
+ " - 2: write x264 options\n"
+ " - 3: write x264 information and options\n", defaults->i_opts_write );
H2( "Muxer specific:\n" );
H2( " [mp4/3gp/3g2/mov/flv]\n" );
H2( " --dts-compress Eliminate initial delay with container DTS hack\n" );
@@ -1196,6 +1201,8 @@ static struct option long_options[] =
{ "dump-yuv", required_argument, NULL, 0 },
{ "sps-id", required_argument, NULL, 0 },
{ "aud", no_argument, NULL, 0 },
+ { "opts", required_argument, NULL, 0 },
+ { "no-opts", no_argument, NULL, 0 },
{ "nr", required_argument, NULL, 0 },
{ "cqm", required_argument, NULL, 0 },
{ "cqmfile", required_argument, NULL, 0 },
diff --git a/x264.h b/x264.h
index b0f1b1a..e0cd183 100644
--- a/x264.h
+++ b/x264.h
@@ -252,6 +252,19 @@ static const char * const x264_nal_hrd_names[] = { "none", "vbr", "cbr", 0 };
#define X264_NAL_HRD_VBR 1
#define X264_NAL_HRD_CBR 2

+/* SEI level */
+#define X264_OPTS_NONE 0x0000
+#define X264_OPTS_INFO 0x0001
+#define X264_OPTS_SETTING 0x0002
+#define X264_OPTS_FULL 0x0003
+
+#define X264_OPTS_PREINFO 0x0010
+#define X264_OPTS_POSTINFO 0x0020
+#define X264_OPTS_PREOPT 0x0040
+#define X264_OPTS_POSTOPT 0x0080
+
+#define X264_OPTS_MAX 4
+
/* Zones: override ratecontrol or other options for specific sections of the video.
* See x264_encoder_reconfig() for which options can be changed.
* If zones overlap, whichever comes later in the list takes precedence. */
@@ -462,6 +475,8 @@ typedef struct x264_param_t
uint32_t i_fps_den;
uint32_t i_timebase_num; /* Timebase numerator */
uint32_t i_timebase_den; /* Timebase denominator */
+ int i_opts_write;
+ char *psz_opts[X264_OPTS_MAX];

int b_tff;

--
1.8.5.2.msysgit.0

[Selur]

Not sure what the fuss is about, I mean normally the 'magic' is not in the encoding, but in the processing before encoding and knowing the encoding settings only makes sense to me in case I want to create compatible content which I want to append to an existing video,.. -> What could be learned from looking at the encoding settings of others?

There is a tantalizing thread on VideoHelp, where a fellow I think wrote out some code to do exactly this, but it was only for Linux and OsX. I didn't realize it until I kept trying to plug it into the CMD line and it didn't work
care to post a link? (normally I analyze raw h.264 streams with h264_parse to get the general settings)

Cu Selur

Ps.: As a side note, x265s infos get lost when muxed to mkv and x265 even provides an option to not save these infos to the SEI. ;)

[Sharc]

......Lastly, looking at the file content from within FAR Manager you can see the settings are there:....
That's definitely different in my case. The strings are present in the .264 video file but missing in the muxed .m2ts. The only step in between is tsmuxer 2.6.12.
Not that I care too much, but once the question has been asked why "people" hide their settings ....

[Motenai Yoda]

That's definitely different in my case. The strings are present in the .264 video file but missing in the muxed .m2ts. The only step in between is tsmuxer 2.6.12.
Not that I care too much, but once the question has been asked why "people" hide their settings ....

probably because they use low quality/fast encoding settings and don't want others call their works "garbage", but usually those folks don't know how to properly set x264 nor how to remove the info.

[Lathe]

Annnnnnnd, this is the point where I have to drop some mushrooms in order even to BEGIN to understand what is going on... :)

Fascinating though. AH... Sounds like that FAR program is what I was asking about, maybe...?

For what it's worth from a guy who is standing (laying, more like) about 1000 stories below you fellows, I just did a reencode using BDRB and I noticed that in the WORKFILES if I use MediaInfo on the .264 video stream, THEN all the settings show. But... after BDRB rebuilds the BD structure, if I use MediaInfo on the resulting M2ts stream, they are gone! (That IS TSMuxer, basically, right?)

Oh, and Selur, you MIGHT remember my bothering you a while back about this same thing, about finding the encoding parameters in a raw stream using your nice program based upon h264_parse. But, either I couldn't read the results properly, or it didn't give me all the parameters.

Heh, well at least I can see that I am not the ONLY one who can get kind of curious about why some certain random thing happens in x264! Learning is indeed it's own reward...

probably because they use low quality/fast encoding settings and don't want others call their works "garbage", but usually those folks don't know how to properly set x264 nor how to remove the info.

And, of course, that is probably the bottom line here anyway...

Thanks guys!

[Groucho2004]

I just did a reencode using BDRB and I noticed that in the WORKFILES if I use MediaInfo on the .264 video stream, THEN all the settings show. But... after BDRB rebuilds the BD structure, if I use MediaInfo on the resulting M2ts stream, they are gone! (That IS TSMuxer, basically, right?)
How bizarre. I can't think of anything BD-Rebuilder does differently compared to the workflow I described above.

I agree with the comments made that it does not matter whether the settings are preserved or not but I'm curious about what's going on with tsmuxer.

[Groucho2004]

Sounds like that FAR program is what I was asking about, maybe...?
If you are looking for an orthodox file manager (http://en.wikipedia.org/wiki/File_manager#Orthodox_file_managers) - FAR (http://farmanager.com/index.php?l=en) is as good as it gets.

[Lathe]

If you are looking for an orthodox file manager (http://en.wikipedia.org/wiki/File_manager#Orthodox_file_managers) - FAR (http://farmanager.com/index.php?l=en) is as good as it gets.

It's most likely beyond me, but I'll check it out.

Thanks!

[Motenai Yoda]

How bizarre. I can't think of anything BD-Rebuilder does differently compared to the workflow I described above.

I agree with the comments made that it does not matter whether the settings are preserved or not but I'm curious about what's going on with tsmuxer.

tsmuxer seems to remove/rewrite sei if no setted with contSPS (Do not change SEI and VUI data).

[Groucho2004]

tsmuxer seems to remove/rewrite sei if no setted with contSPS (Do not change SEI and VUI data).
It's actually "insertSEI". And yes, that's the option which blanks the x264 encoding settings.

[Sharc]

It's actually "insertSEI". And yes, that's the option which blanks the x264 encoding settings.
Mystery solved. Thanks!

[Motenai Yoda]

It's actually "insertSEI". And yes, that's the option which blanks the x264 encoding settings.

with "forceSEI" too

[Sharc]

Now this brings me to the question as to when it is necessary to activate these SEI settings ....
Anyone can enlighten me? Thanks.

[foxyshadis]

Now this brings me to the question as to when it is necessary to activate these SEI settings ....
Anyone can enlighten me? Thanks.

When you need to completely replace all existing timing information in the file, for Bluray or hardware player compatibility. TSMuxer doesn't bother deciding what SEIs are meaningful, it just discards all existing.

[pcordes]

There's nothing special about FAR manager for this task, btw. I use

strings -n10 file.mkv | less


and then search for "x264". If it doesn't appear soon, I usually control-c and quit, since it's either near the front of the file or missing altogether. (It's unusual, but I *think* it sometimes happens, that the x264 settings string is still kicking around in the file, but not in the place where mediainfo knows to look.)

strings is the Unix shell command to read a binary file and print out any strings of consecutive ASCII characters. (min length = 10, since I used -n10). less is a pager like more (same as DOS, I think), but better.

As others have said, if the settings string is missing, you can determine some things about the h.264 bitstream from its headers, and some more from decoding it, I guess. Decoders don't usually keep stats to try to work out things like chroma_qp_offset, or which partition types ever got used, or whether weighted P or B prediction was actually ever used, but they could. It would be possible to add code to ffmpeg's h.264 decoder to track these things, and print them out at the end.

Things like subme, and badapt=1 vs. badapt=2, can't be determined, short of feeding things back in to x264 to see what decisions it makes with various settings. (and even then, you're not feeding it the same input as the original source.) Or maybe some heuristics could notice things about the h.264 stream that would indicate certain settings. But anyway, very slow, tons of work to implement, and won't be perfectly accurate.

[Lathe]

There's nothing special about FAR manager for this task, btw. I use

strings -n10 file.mkv | less


and then search for "x264". If it doesn't appear soon, I usually control-c and quit, since it's either near the front of the file or missing altogether. (It's unusual, but I *think* it sometimes happens, that the x264 settings string is still kicking around in the file, but not in the place where mediainfo knows to look.)

strings is the Unix shell command to read a binary file and print out any strings of consecutive ASCII characters. (min length = 10, since I used -n10). less is a pager like more (same as DOS, I think), but better.

As others have said, if the settings string is missing, you can determine some things about the h.264 bitstream from its headers, and some more from decoding it, I guess. Decoders don't usually keep stats to try to work out things like chroma_qp_offset, or which partition types ever got used, or whether weighted P or B prediction was actually ever used, but they could. It would be possible to add code to ffmpeg's h.264 decoder to track these things, and print them out at the end.

Things like subme, and badapt=1 vs. badapt=2, can't be determined, short of feeding things back in to x264 to see what decisions it makes with various settings. (and even then, you're not feeding it the same input as the original source.) Or maybe some heuristics could notice things about the h.264 stream that would indicate certain settings. But anyway, very slow, tons of work to implement, and won't be perfectly accurate.

Hmmm... Fascinating. Thanks kindly for the input!

[kuchikirukia]

probably because they use low quality/fast encoding settings and don't want others call their works "garbage", but usually those folks don't know how to properly set x264 nor how to remove the info.

More likely done so the work is judged on its own merits rather than on what people think its merits should be.

"Oh, you didn't use no-dct-decimate? Well, I can clearly see decimation everywhere and it makes it unwatchable!"
"12 reference frames rather than 16? I'm not downloading this bloated crap!"

There are trillions of possible combinations of settings and there isn't one that is optimal across every source, yet there are people who believe in their one magic setting, though we can't seem to agree to it. We live in a world where there are people who believe that any filtering "destroys the quality" (though I bet they don't watch raw interlaced content.) There are people who anchor their judgement of quality on file size (because, of course, a 10GB movie with 7GB in 24 bit FLAC and DTS-MA is obviously going to be better than a 6GB one with 1GB in 320kbps + 768kbps QAAC. "That extra 4GB really brings out the detail in the backgrounds!")

More information in how something is made just gives people more things to look for trying to find fault in the end result.

[benwaggoner]

More likely done so the work is judged on its own merits rather than on what people think its merits should be.

"Oh, you didn't use no-dct-decimate? Well, I can clearly see decimation everywhere and it makes it unwatchable!"
"12 reference frames rather than 16? I'm not downloading this bloated crap!"
The number of customers who would actually have an opinion on the settings that were used would be vanishingly small, let alone the subset of people who wouldn't watch video because it didn't look good in theory, despite how it looked in practice.

Plus, the big deltas in video quality come much more from source and preprocessing anyway. Content that looks bad generally would have looked bad with lossless encoding :).

I can't think of a time I've ever tried to obfuscate encoding settings, and I've been professionally encoding video for 20+ years now.