Distinguish x264 encoded H.264 video from other encoders

[titlis]

I have Elecard StreamEye Studio,
any recommendation?

Like looking at the spatial quantizer distribution

[LoRd_MuldeR]

Much easier: Use a Hex-Viwer and look for the string "x264". In a x264-encoded stream, you will find that string, along with the version number and all options, in x264's custom SEI message ;)

(Unless, of course, the stream was created with a modified x264 that doesn't insert the message -or- the message had been filtered out deliberately)

[titlis]

I've been using that method via MediaInfo
but I heard that Vimeo and Youtube use modified x264
and It doesn't appeared to have SEI message

And I found interesting post from Dark Shikari

http://forum.doom9.org/showthread.php?p=1144725#post1144725

Maybe I can do something similar for x264 too?

[LoRd_MuldeR]

I am not an expert in stochastic, but maybe something like a K-S Test (http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test) could be used to compare the quantizer values of a "sample" x264-encode with those from the "unknown" encode. If the test concludes that both come from the same probability distribution, it's likely to be an x264 encode. Otherwise it probably is not...

[MasterNobody]

There are ways to distinguish x264 encoded videos without custom SEI (but I wouldn't disclose such details even though probably I don't know all of them). But if you upload short samples I can try to say was it encoded with x264 or not.

[titlis]

http://www.mediafire.com/?g8gaa71kgy1hzmc

Here is the short sample clip from the Blu-ray disc I have.

demux and cut using DGAVCindex but the second frame of the first GOP decoded in wrong way.
(Maybe the Open-GOP issue I guess, could FFmpeg or Mplayer&Mencoder can directly cut stream by Keyframe withoout having a Open-GOP issue? If it could, it would be a great pleasure to know )


All that I know about distinguish x264-encoded stream is looking at the spatial quantizer distribution and find whether spatial adaptive quantization is used or not.'
but I think all the grain in the movie make this kinda approach pointless, or maybe there can be another encoder with spatial adaptive quantziation feature. ( It won't be x264-only feature right? )

[MasterNobody]

http://www.mediafire.com/?g8gaa71kgy1hzmc

Here is the short sample clip from the Blu-ray disc I have.
This is not x264 for sure. And it was probably rather dumb encoder (configured not for quality).

[Dark Shikari]

I have dozens of methods I could use to determine if an encoded stream was encoded by x264, in addition to the obvious. Like MasterNobody, I won't disclose them all.

[sneaker_ger]

What's with all the secretiveness?

[titlis]

This is not x264 for sure. And it was probably rather dumb encoder (configured not for quality).

What a sad.... I wish it was x264

I have dozens of methods I could use to determine if an encoded stream was encoded by x264, in addition to the obvious. Like MasterNobody, I won't disclose them all.

Then where can I learn about those methods? Do I have to understand the sourcecode? Sad I'm not a programmer :(

[Dark Shikari]

What's with all the secretiveness?It's rather nice to have some methods kept sufficiently secret that someone looking to steal x264 and pass it off as their own work can't obfuscate it away.

[Nevilne]

For x264, cryptic messages are stored in blocks in dark gradients and fades! :)

[titlis]

It's rather nice to have some methods kept sufficiently secret that someone looking to steal x264 and pass it off as their own work can't obfuscate it away.
But x264 is Open Source anyway. Do we have to worry about stealing some algorithm which is completely public?
I mean we can't prohibit people from stealing x264 since it's open source, isn't it?


For x264, cryptic messages are stored in blocks in dark gradients and fades! :)
Is it true?

[Dark Shikari]

But x264 is Open Source anyway. Do we have to worry about stealing some algorithm which is completely public?
I mean we can't prohibit people from stealing x264 since it's open source, isn't it?x264 is open source under the GPL, which is a rather stringent license that makes strict rules about what you can and cannot do when distributing it. Among other things, you cannot use as part of a proprietary application (you can buy a commercial license for this purpose, but that license still requires you to contribute back any changes you make to x264).

Additionally, even in the cases where this doesn't apply (e.g. a web-based encoding service), it's good to be able to embarrass plagiarists. For example, "Raystream", a recent (and horrifically done) scam company advertised their "amazing proprietary encoding technology", which was of course just x264 on default settings with no modifications.

[sneaker_ger]

It's rather nice to have some methods kept sufficiently secret that someone looking to steal x264 and pass it off as their own work can't obfuscate it away.

I see.

@MasterNobody
What's your excuse?

But x264 is Open Source anyway. Do we have to worry about stealing some algorithm which is completely public?
I mean we can't prohibit people from stealing x264 since it's open source, isn't it?

They still have to adhere to the license, so some people might try to copy and publish it illegally.

[titlis]

I see that...

But it's too sad that methods are kept secret.
I just think it would be nice to know even a little part of it.
( somewhat relatively less important )

[MasterNobody]

@MasterNobody
What's your excuse?
Same as Dark Shikari because I am also one of x264 contributors and I agree on this with main developers.

[Dark Shikari]

They're pretty basic.

Do the headers match up with something x264 could create?

Does the adaptive quantization field look like x264's?

Does it use any features x264 doesn't support?

Does it use x264's particularly absurd brand of reference frame duplication?

And so forth.

[sneaker_ger]

Same as Dark Shikari because I am also one of x264 contributors and I agree on this with main developers.

I see, wasn't aware of that.