h264 stream validation

[samepaul]

I encoded some clip with x264
x264 --crf 17.5 --preset slower --profile high --level 50 --non-deterministic -o "%PREFIX%-video.mkv" "%SRC%"
Since I always use FFDSHOW for decoding I didn't encounter any problem with the compressed video.
Accidentally happened to use CoreAVC in some DirectShow application instead of FFDSHOW and suddenly I see garbled video :(
Checked with Cyberlink PDVD7 decoder - same result. Adobe2 decoder can't decode it at all.

VLC shows video OK, but no wonder since both VLC and FFDSHOW are based on LIBAVCODEC. So I'm afraid it could be the case when bugs in one project family (libavcodec/x264) successfully compensate each other :)
How can I make sure that my movie is ok? I read once in x264 dev blog that Dark Shikari used some kind of reference stream validator.

upd: x264 core:79 r1353 380a201
CyberLink H.264/AVC Decoder (PDVD7.x) file version 2.0.0.1709
CoreAVC 1.9.5 build 6721

[nurbs]

CoreAVC 1.9.5 doesn't play x264 encodes with --weightp 2 correctly. It's a decoder bug. If the Cyberlink decoder shows the same artifacts it could be a similar bug. Don't know about Adobe, but some decoders (mostly hardware) refuse to play anything that's labeled with a level higher than 4.1. Another possibility is that the software decoders were programmed with the maximum DPB limit of level 4.1 for whatever reason and depending on your video resolution the 8 refs of --preset slower could be too much for that.

By the way, why --non-deterministic? There is no benefit from that option and why would you want an additional random element in your encodes.

[samepaul]

but some decoders (mostly hardware) refuse to play anything that's labeled with a level higher than 4.1.
Thanks for hint, I'll check it out.

By the way, why --non-deterministic? There is no benefit from that option and why would you want an additional random element in your encodes.
It's written, this option improves performance on SMP systems. So I wouldn't say "no benefit".

[nurbs]

It's written, this option improves performance on SMP systems. So I wouldn't say "no benefit".
I still suspect there is a reason why not even --preset ultrafast uses that option.
Have you ever tried measuring the speed difference?

[samepaul]

Ok, some heads up.
Changing profile level didn't solve the situation, but --weightp 1 did.
Also I was wrong about Cyberlink. Once I disabled DXVA there everything worked like a charm even with original files. I guess I'm somewhat convinced about CoreAVC bugs.
So thank you a lot for the tips.
I'm still a bit curious about stream validation though :)

[samepaul]

Have you ever tried measuring the speed difference?
I did not undertake thorough testing, I did quick run. Showed better CPU load balance. Speed improvement wasn't drastic, about 1-2%, but still there.
Why ultrafast does not include it? Have no idea.
I actually believe in non-determinism. Did you hear about things that non-deterministic CPU can do? It can crack up TLS in a moment :)

[kemuri-_9]

I still suspect there is a reason why not even --preset ultrafast uses that option.
Have you ever tried measuring the speed difference?

I remember pengvado/akupenguin stating something along the lines of

'a program should be deterministic by default when capable of being so'

(I can't remember where he said this or else i would've used a link/quote)
that's why non-determinism is not enabled by default.

[G_M_C]

I remember pengvado/akupenguin stating something along the lines of

'a program should be deterministic by default when capable of being so'

(I can't remember where he said this or else i would've used a link/quote)
that's why non-determinism is not enabled by default.

Probably one of the famous Pengvado-quotes listed somewhere :p

[nm]

Here: http://forum.doom9.org/showthread.php?p=1330402#post1330402

[sneaker_ger]

Which revision of x264 are you using? There was a bug in the first revisions after weightp was committed which could result in non-compliant streams breaking (some?) DXVA decoders.

[nurbs]

That bug was fixed in version 1342 and he's using 1353. I think I had that one and it showed up in libavcodec.

[sneaker_ger]

Sorry, read the posts twice searching for the revision number and still missed it. :o
But if there's a decoding error the x264 developers (http://x264dev.multimedia.cx/?p=212) might be interested to take a look.