Disabling x264 user data?

[chaynik]

Is it possible to disable the user data x264 writes to the streams it produces? Such data can be viewed with tools like avinaptic, and contains everything from the revision of x264 used to encode the file to all the settings used. Thanks in advance!

[Dark Shikari]

In theory, yes. But I'm not going to tell you how to do it, because we don't want you to.

[Dust Signs]

we don't want you to.
May I ask why? With some basic knowledge about the syntax of H.264 bitstreams it's fairly easy to remove the corresponding NAL/SEI message. Or are you talking about something else here? Nevertheless, I don't know any tool capable of doing this special task. You'll have to write one on your own or (simpler) modify the x264 source code accordingly and use the compiled binary of that.

Dust Signs

[roozhou]

Try my x264 build here
http://forum.doom9.org/showthread.php?t=141441

Add --no-versioninfo to the cmdline parameter and no user data will be written to the bitstream.

I also made a small tool to patch existing x264.exe. Just drag and drop x264.exe to this program and user data will no longer be written(not completely removed, still ~25bytes overhead).

Enjoy!(souce code included)

[Dark Shikari]

May I ask why? With some basic knowledge about the syntax of H.264 bitstreams it's fairly easy to remove the corresponding NAL/SEI message. Or are you talking about something else here? Nevertheless, I don't know any tool capable of doing this special task. You'll have to write one on your own or (simpler) modify the x264 source code accordingly and use the compiled binary of that.Because we want to force people to go out of their way if they want to try to pass off x264 bitstreams as their own (or, equally, hide the settings they used to encode).

Sure, you can do it, the option just shouldn't be available to someone who isn't willing to spend the time and effort to understand the standard or the source code.

Also, it makes debugging much more annoying when people are hiding their settings they used to encode....I politely request that you stop posting this patch.

[ChronoCross]

More than likely this has to do with wanting to remove your encoding settings to make you look more 1337 in whatever pirate community your in so that your rival pirate group won't steal your 1337 settings. There is no technical reason that you would need to remove this information from the file.

[roozhou]

More than likely this has to do with wanting to remove your encoding settings to make you look more 1337 in whatever pirate community your in so that your rival pirate group won't steal your 1337 settings. There is no technical reason that you would need to remove this information from the file.

There is one: smaller size.

One of my friend wrote a tool to encode still images to H264 I frames using x264. The 400~500 bytes user data is written to every encoded image and causes a BIG overhead because most of them are around 15k in size.

[ChronoCross]

There is one: smaller size.

One of my friend wrote a tool to encode still images to H264 I frames using x264. The 400~500 bytes user data is written to every encoded image and causes a BIG overhead because most of them are around 15k in size.

your friend might want to use a tool designed for still images rather than something that is designed for video. Your probably not getting any benefit from using h264 on a single still image.

[Dark Shikari]

your friend might want to use a tool designed for still images rather than something that is designed for video. Your probably not getting any benefit from using h264 on a single still image.... well, except for the fact that my testing shows that x264 vastly outperforms JPEG and JPEG2K...

[Mr VacBob]

H264 is a great static image compressor. JPEG is practically MPEG-1, after all, and it's missing a lot of things that could improve its quality (prediction, AQ, any kind of postprocessing).

[Inspector.Gadget]

Yeah, I've seen this sort of discussion before on other forums and it's always some kid that wants to pretend to his internet warez buddies that he's the master of video compression when he's using --ref 1 and --deblock -20:-20. Lame.

[Adub]

Yeah, I've seen this sort of discussion before on other forums and it's always some kid that wants to pretend to his internet warez buddies that he's the master of video compression when he's using --ref 1 and --deblock -20:-20. Lame.
Seconded. There is no logical reason to put forth such a request.

[neuron2]

Actually there can be a reason. I ran into a case where the user data pushed a needed SEI into the next transport packet and complicated my design. I'm not saying it can't be worked around, just that it's too strong to say there is no possible logical reason to want that.

[Dark Shikari]

Actually there can be a reason. I ran into a case where the user data pushed a needed SEI into the next transport packet and complicated my design. I'm not saying it can't be worked around, just that it's too strong to say there is no possible logical reason to want that.Why not put the needed SEI before the user data?

[neuron2]

LOL. You wrote the encoder, not me!

All I do is mux the output of x264 into transport. Some SEIs that it would be convenient to have in the first packet get pushed out by the user data.

It's not a big deal and I have already designed around it. I mentioned it only to refute Adub's dogmatic assertion.

[Dark Shikari]

LOL. You wrote the encoder, not me!AFAIK x264 doesn't output any SEIs other than userdata, so I don't know what other SEIs you're talking about.

[neuron2]

Sorry, yes, I misspoke. I meant to refer to the slice header of the first picture.

[Comatose]

Some fansubbers do it to troll... well, they don't remove it, they change it.

[Audionut]

Is there anyway to find what settings were used if the user data wasn't written or was deleted?

[neuron2]

Not by an average human. An AVC expert may be able to deduce many things by analyzing the stream but probably not full knowledge of the settings.

[expresspotato]

I also was looking to disable this... Its kinda weird I can open the video in say vi and just /(search) for say deblock and up comes all the encoder settings I've used. Some people feel proud of how good quality they've managed to get with x264 and don't want to share it with the world.

[kieranrk]

Some people feel proud of how good quality they've managed to get with x264 and don't want to share it with the world.

We also don't want to share how to turn the user data off.

[expresspotato]

We also don't want to share how to turn the user data off.

Thank you for libx264 anyways!

[Daiz]

Some people feel proud of how good quality they've managed to get with x264 and don't want to share it with the world.

If you know some magical settings that magically improves quality (protip: you most likely don't), you should be able to tell them to the developers and everyone else so that the overall quality of the x264 project can be improved. You're just hurting x264 by trying to hide the data.

[LoRd_MuldeR]

Some people feel proud of how good quality they've managed to get with x264 and don't want to share it with the world.

If you achieve good quality with x264, then this is 99.999999999999% thanks to the excellent work of the x264 team!

And 0.000000000001% because you "managed" to not completely screw up the settings :rolleyes:

So you use the software that has been kindly provided to you for free, but you aren't even willing to share your settings with the community?

What kind of egoistic behavior is that ???

[expresspotato]

Oh come come now, I contribute as best I can.

For all we know youtube could be using libx264 and no one's the wiser.

[kieranrk]

For all we know youtube could be using libx264 and no one's the wiser.

They do.

[LoRd_MuldeR]

Oh come come now, I contribute as best I can.

The fact that you asked how to disable "user data" (something even a freshman student can do in 1 minute) shows that your C coding skills are zero.

So how are you going to contribute anything to a project like x264 ???

For all we know youtube could be using libx264 and no one's the wiser.

Youtube does use x264. That's not a secret at all.

[expresspotato]

The fact that you asked how to disable "user data" (something even a freshman student can do in 1 minute) shows that your C coding skills are zero.

So how are you going to contribute anything to a project like x264 ???

Youtube does use x264. That's not a secret at all.

1. I didn't actually go snooping to find it. Just commenting on the original thread and that this was an afterthought for me as well.

2. Well you learn something every day now don't you! Wonder what settings they're using ;)

[JEEB]

2. Well you learn something every day now don't you! Wonder what settings they're using ;)
Rather fast ones. Their ffmpeg IIRC was rather old, too (although IIRC they certainly updated from the times they were using 2005 codebase). It still warns about edit lists when stuff in the mp4 container with them gets uploaded (Flash itself should support these features of the mp4 container nicely AFAIK).

In other words, nothing worth mimicking.

[rack04]

2. Well you learn something every day now don't you! Wonder what settings they're using ;)

With the one I had on hand:

cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=5 / brdo=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0
/ 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=2 / b_pyramid=0 / b_adapt=1
/ b_bias=0 / direct=1 / wpredb=1 / bime=0 / keyint=60 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=2000 / ratetol=1.0
/ rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=38 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

[asarian]

Actually, I like hearing you can retrieve the info. :) I have many older encodes whose precise encoder settings I forgot. It's like a built-in useful mini-log.

[expresspotato]

With the one I had on hand:

cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=5 / brdo=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0
/ 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=2 / b_pyramid=0 / b_adapt=1
/ b_bias=0 / direct=1 / wpredb=1 / bime=0 / keyint=60 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=2000 / ratetol=1.0
/ rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=38 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

One word: Yikes.