Critical AVC settings to add flawlessly to a previous encoding?

[aLu]

In XviD, if I want to add to an existing video that I encoded a year ago, it's usually no problem. However, x264 has a lot more options, and I'm not sure which of them are important for playback and which for encoding/quality purposes only. Maybe you can give me some hints? They're not all neatly on the same tab, unfortunately.

As far as I know, crucially important are:
- custom matrix (must be the same)
- analyse= (!) (setting must be the same)
- deblocking (I suppose -?)

What else?

Of course the codec's output options must be generally similar. With more recent video, I found it unnecessary to go to great lengths (by trial and error), but in some cases I had to downgrade x264 for very old encodings. I reproduced x264's commandline arguments faithfully from Avinaptic info like this:

[ About H.264 encoding ]

User data: x264
User data: core 47 svn-518
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:0:0
User data: analyse=0x3:0x133
User data: me=hex
User data: subme=7
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=2
User data: 8x8dct=1
User data: cqm=2

User data: chroma_qp_offset=0
User data: slices=2
User data: nr=0
User data: decimate=1

User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=1
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=2pass
User data: bitrate=4432
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30


SPS id: 0
Profile: High@L5.1
Num ref frames: 8

Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Custom intra4X4 luma:
6 9 13 19
9 14 20 27
13 20 28 35
19 27 35 42
Custom intra4X4 chromau:
6 10 15 20
10 16 21 27
15 21 28 33
20 27 33 42
Custom inter4X4 luma:
8 11 15 20
11 16 21 27
15 21 28 35
20 27 35 42
Custom inter4X4 chromau:
8 11 16 21
11 17 22 27
16 22 28 35
21 27 35 42
Custom intra8X8 luma:
6 7 8 10 12 14 16 18
7 9 11 13 15 16 18 20
8 11 14 16 17 19 21 22
10 13 16 18 20 22 24 26
12 15 17 20 23 25 28 30
14 16 19 22 25 29 34 38
16 18 21 24 28 34 46 52
18 20 22 26 30 38 52 72
Custom inter8X8 luma:
8 9 10 12 14 16 19 21
9 11 13 15 17 19 21 23
10 13 16 18 20 22 23 25
12 15 18 21 23 24 26 32
14 17 20 23 25 27 33 40
16 19 22 24 27 34 41 52
19 21 23 26 33 41 53 64
21 23 25 32 40 52 64 80

... translates into this:

x264.exe --pass 1 --bitrate 4432 --stats "X:\x264_2pass.log" --level 5.1 --b-pyramid --trellis 2 --chroma-qp-offset 0 --ref 5 --analyse all --subme 7 --b-rdo --mixed-refs --8x8dct 1 --bframes 3 --b-pyramid 1 --b-bias 0 --direct spatial --weightb --bime --thread-input --cqmfile "X:\eqm_avc_hr.cfg" --output "X:\output.mkv" "X:\input.avs"
... for that particular version of x264 (revision 518 / 2006-05-06).

This was cobbled together from MeGui code and trial & error on the commandline, I don't really know what I'm doing here.

I'd like to have a better idea what is important or not, it would be great time-saver. Quality or bitrate is not an issue when encoding only a few frames.

[sneaker_ger]

Here's (http://mewiki.project357.com/wiki/X264_Settings) an explanation of all the settings. The x264 build you've used so far is extremely outdated which results in your command line not working at all. Get a newer version from http://x264.nl .
The most important thing for playback is IMHO to keep your video restricted to a specific level (http://en.wikipedia.org/wiki/H.264#Levels). Most hardware decoders (like DXVA used for Graphic Card accelerated decoding) are limited to level 4.1. If you're going for Blu-Ray there are a few more restrictions. If you don't want to encode for Blu-Ray you pretty much only have to take into account the following options for playback compatibility:
--ref
--vbv-maxrate and --vbv-bufsize
--level

If you're not aiming for a specific file size I recommend you to only use single pass (quality set by --crf) and save yourself a lot of time.

/edit:argh. Ignore what I said. I pretty much missed the point that you were going to append your encode to an old encode

[sneaker_ger]

Since I don't have access to that old revision and I'm not a "pro" myself I can't guarantee it to work, but you could try adding "--threads 2" (and maybe "--sps-id"?) and then cat the streams using MKVMergeGUI (for Matroska) or mp4box (for mp4). Or are you not simply appending but adding something in the middle?

[aLu]

You can get the x264 build-518 installer here (http://x264.nl/x264/?dir=./revision518), and Avinaptic (the analyzer tool) here (http://forum.doom9.org/showthread.php?t=123076).

My exact commandline looked like this:
x264.exe --pass 2 --bitrate 4432 --stats "X:\x264_2pass.log" --level 5.1 --ref 8 --b-pyramid --trellis 2 --chroma-qp-offset 0 --thread-input --cqmfile "X:\eqm_avc_hr.cfg" --output "X:\output.mkv" "X:\input.avs" --ref 5 --analyse all --subme 7 --b-rdo --mixed-refs --8x8dct 1 --bframes 3 --b-pyramid 1 --b-bias 0 --direct spatial --weightb --bime
As you can see, I defined "--ref" twice, and it looks a bit messier.

I'm not going for Blu-ray compatibility, my objective is purely PC playback with the usual decoders & players (ffdShow/libavcodec/ffmpeg).

If you don't want to encode for Blu-Ray you pretty much only have to take into account the following options for playback compatibility:
--ref
--vbv-maxrate and --vbv-bufsize
--level
matrix and --analyse, as I know from experience, are essential too - matrix only if a custom matrix is used, of course). It's the old encoding that sets the compatibility standards here.

I started out by using the commandline suggested by MeGui (that is why it looks messed up) and adding the options I needed, until appending the old video to the new (or vice versa) with mkvmerge no longer produced blocking artifacts (when part of the image is not decoded properly). Virtually the LAST option I changed - or figured out how to change - was the "--analyse" setting. I was about to give up, but suddenly there were no "smeared" and fractured blocks anymore, the image looked clean and crisp. It took me 11 trial runs to get to that result.

Thanks for your suggestions, sneaker_ger, but I already got it working prior to posting - i.e., I got exactly what I wanted, after trial & error, by matching ALL encoding settings of the old encoding with my new encoding commandline. With one exception:
User data: slices=2
which always was
User data: slices=1
in my encoding. But apparently it only has to do with how many threads are used during encoding and is a performance option. I'm not sure if it can be changed at all.

Ah, XviD is so much easier! ;) The only thing to worry about is a custom matrix, leaving the other settings on default is usually enough.

I'll go though the x264 wiki (http://mewiki.project357.com/wiki/X264_Settings#Analysis) (and have done so before sporadically), but it's not always clear
- which settings affect the way a decoder decodes the video
- which settings purely affect quality, filesize or speed.

I'm beginning to believe that the easiest way is actually what I have done before: matching Avinaptic info 1:1 to commandline options. That way you can technically never go wrong.

[RunningSkittle]

Use x264 preset and tuning system!
http://mewiki.project357.com/wiki/X264_Settings

[Astrophizz]

He has to use a (very) old revision to be able to append the video to the older one he had encoded. So he can't use presets or tuning - or a lot of other new things :/

[LoRd_MuldeR]

He has to use a (very) old revision to be able to append the video to the older one he had encoded. So he can't use presets or tuning - or a lot of other new things :/

You can append any valid H.264 stream to any valid H.264 stream and the result will be a valid H.264 stream again ;)

The question is more whether the decoder/player will handle it flawlessly. But this cannot be answered generally, because it is implementation-dependent.

But as long as you don't change the resolution or switch to an unsupported Profile/Level, there's a good chance it will work...

[RunningSkittle]

Point still stands, go read what "--tune fastdecode" does!

[nm]

Thanks for your suggestions, sneaker_ger, but I already got it working prior to posting - i.e., I got exactly what I wanted, after trial & error, by matching ALL encoding settings of the old encoding with my new encoding commandline. With one exception:
User data: slices=2
which always was
User data: slices=1
in my encoding. But apparently it only has to do with how many threads are used during encoding and is a performance option.
Not exactly; slices also affect the output video stream and decoding. Long ago, x264 had a slice-based threading model where video frames were cut to slices and encoded in separate threads. However, that model was superceded by more efficient frame-based threading and support for multiple slices was dropped completely for a while. It was brought back few months ago (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=4d553edf178bf0ae01547731a48e1fb08c5cc1f4), and more recently, slice-based threading was re-implemented for low-latency encoding (http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=e8b73a9a4db4dd703528a1eee247b84ac335e395).

I'm not sure if it can be changed at all.

With current x264 versions, use parameter --slices