codec private data issue - ffmpeg CRF15 and CRF18 in MKV files

[jack616]

Just an info post for anyone else who may encounter this:

I've re-encoded 4 WVC1/DTS files to MP4/AC3 using Winff
Then tried to put all into an MKV wrapper with mkvmerge GUI and had the
codec private data error (42 and 42)

This seems to have been caused because I had one of the files re-encoded with ffmpeg CRF18
and the other at CRF15.

I'm not sure why this makes MKV squeal but I thought it worth mentioning somewhere in case
anyone else has a problem and can't spot the issue.

[sneaker]

Yes, you cannot arbitrarily change x264 settings and then append into a single mkv track without breaking stuff. If you only change crf you can make compatible encodes by using x264's "--stitchable" option. (Not sure if it's available in ffmpeg)

[poisondeathray]

Or another better approach would be to append them first and encode in 1 go. Or append in the lossless domain before the 1 encoding (e.g with an avs script)

[hello_hello]

https://mailman.videolan.org/pipermail/x264-devel/2013-July/010167.html
Add "--stitchable" option for segmented encoding
Stops x264 from attempting to optimize global stream headers, ensuring that different segments of a video will have identical headers when used with identical encoding settings.

Different CRF values don't seem to come under "identical encoding settings" in that respect. I've appended different CRF value encodes many times. If you use stitchable, they'll append, while without it, it's quite hit and miss, even if the CRF values are the same. I know there's other ways to do it, but often when you want to encode different sections of video using different CRF values, encoding them individually and appending the encodes is easiest.

I tend to use stitchable in the command line most of the time even if I don't initially intend to do any appending. There's nothing more annoying than having to abort an encode that's been running for hours for some unexpected reason, or having it aborted for you by the power going out, and having to start from scratch again because even if you resume encoding from where it left off, there's probably not much chance it'll append.
And sometimes you just want to re-do a small section using a lower CRF value because it didn't encode well, without having to re-encode the whole lot again. Hardcoding subtitles and noticing one mispelled word.... that's another time having used --stitchable" comes in handy.

I had a bit of a play with WinFF and adding the following to the command line seems to work.
-x264opts stitchable