Joining 2 videos, reencoding one to match the other's video encode settings

[PlanetIndigo]

So I have a video with graphical artifacts/glitches in a couple of spots in the video. I have another source which doesn't have those glitches but I want to keep most of the first video except those odd glitches. (I don't want to use the 2nd source in its entirety)
What I was trying to do is to split the first video and splice in the two reencoded pieces of the 2nd video source into the first at the two spots with graphical glitches.

I want to avoid reencoding the first video at all cost to avoid losing quality.
So I went and reencoded the 2 little parts from the second video using the same codec as far as I know as the first video, I spliced them in using avidemux but while the resulting file plays, it has weird graphical oddities in the spliced in parts due to I believe not completely identical video encoding settings. Although I am not entirely sure about that, but that's my best guess at this point. (when watched separately, they play fine)

Could someone help me figure this out?

Is there a tool that can match perfectly the video encoding settings from one video to match the other?

I will upload a small clip of what I'm trying to match if it helps.

Mediainfo just lists the video codec as MPEG4-AVC. The file is in an mkv container and I was using avidemux.

[smrpix]

TMPGenc Smart Renderer will definitely work, VideoReDo will probably work. Anything else you are going to have to match the specs to a very, very high degree of precision.

[PlanetIndigo]

TMPGenc Smart Renderer will definitely work, VideoReDo will probably work. Anything else you are going to have to match the specs to a very, very high degree of precision.

Thanks for the advice. Those seem to be trialware though. Is there nothing I can do with freeware/lightweight tools like the ones I already have? Avidemux, Virtualdubmod, mkvmerge, ffmpeg, megui ?
You said it could be done if I match the specs to a very high degree of precision, I don't have an issue trying that but the main problem I'm having now is that I can't seem to identify the settings used in the encode of the first video. Mediainfo doesn't give me anything besides the "MPEG4-AVC". Is there a tool that could identify all the video encode settings of that video? (or at least the ones that are responsible in ensuring compatibility when merging the two videos)

[smrpix]

You've identified the issues very well. That's why I gave the reply I did. Mediainfo, for one, will identify many of a file's parameters -- but not enough. Trying to perfectly match a file you did not create yourself is a very, very difficult task.

If there were good, free smart renderers TMPGenc and VideoReDo would be much cheaper.

[hello_hello]

I don't use smart rendering programs so I can't comment there, but the chances of successfully matching settings and joining files are pretty low. If you try, you might have more success using --stitchable in the x264 command line. Without it, you can encode two videos with x264 using identical settings and often they still won't join successfully.

http://x264.janhum.alfahosting.org/fullhelp.txt
--stitchable
Don't optimize headers based on video content. Ensures ability to recombine a segmented encode.

In the case of x264 I think the header optimisation thing (I don't really understand it) was added at some stage and it broke the ability to append encodes so the stitchable option was added a bit later.

If you try to append video that's not the same, MKVMergeGUI will offer a warning about the codec private data not matching, which I think means the Sequence Parameter Set and Picture Parameter Set, but I don't really understand it.

[LMotlow]

Mediainfo just lists the video codec as MPEG4-AVC. The file is in an mkv container and I was using avidemux.

MediaInfo gives a lot more information than the codec that was used. It displays GOP info, bitrate, audio sampling, etc. Maybe you didn't notice that the "front view" is only a general and abbreviated view. Try the "Text" view for advanced info. The contents of the "Text" window can be copied and pasted into a forum post like any other text.

[poisondeathray]

What kind of "glitches" specifically? Could it be a simple decoder issue? Did you try other playback software and decoders ?

If you encode with x264 , set the --sps-id to some number, like 2. When you append, do it with an elementary AVC streams with dos (copy /b). When the sps-id value differs between fragments, this method can append AVC streams with different encoding settings (even different AVC encoders.) The input videos have to be cut on GOP boundaries

--stitchable with work if the fragments were encoded at the same time with the same encoder using the same settings - that's not the case here (--stitchable requires the same encoder, same core version, same settings).

[JVRaines]

I find that ffprobe.exe (from the FFmpeg suite) gives more complete information than MediaInfo. Redirect console output into a file for each segment and compare.

[PlanetIndigo]

Sorry, I was pretty busy the last few days but I've tried some more and I still can't successfully join the two videos...

MediaInfo gives a lot more information than the codec that was used. It displays GOP info, bitrate, audio sampling, etc. Maybe you didn't notice that the "front view" is only a general and abbreviated view. Try the "Text" view for advanced info. The contents of the "Text" window can be copied and pasted into a forum post like any other text.

Yeah, I know about those view options but my mediainfo version was ancient and didn't give any detailed info on the encoding parameters. I have since updated to a newer version and it does list a lot of settings. However, even after matching all the ones displayed, the two files still won't join correctly. At this point, the only difference I can see is the "writing library", the file I'm trying to append to has "x264 core 98 r1629 2e81ce1". I can't seem to find that x264 version on the net, but even going back to the closest x264 I could find (core 106 from avidemux), the two files would still not append right...

For info, here's the video info of the file I'm trying to match:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 26s
Nominal bit rate : 750 Kbps
Width : 864 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.075
Writing library : x264 core 98 r1629 2e81ce1
Encoding settings : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=750 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=1927 / vbv_bufsize=1927 / ip_ratio=1.40 / aq=1:0.50 / nal_hrd=none
Default : Yes
Forced : No

What kind of "glitches" specifically? Could it be a simple decoder issue? Did you try other playback software and decoders ?

If you encode with x264 , set the --sps-id to some number, like 2. When you append, do it with an elementary AVC streams with dos (copy /b). When the sps-id value differs between fragments, this method can append AVC streams with different encoding settings (even different AVC encoders.) The input videos have to be cut on GOP boundaries

--stitchable with work if the fragments were encoded at the same time with the same encoder using the same settings - that's not the case here (--stitchable requires the same encoder, same core version, same settings).

I'm sure those glitches are not a decoder issue. I've tried to play it in several players, even on my tablet, and the glitches always happen at the same spot.

I've uploaded a little sample of the file if anyone is curious:
File I'm trying to append the second file to (trying not to reencode this):
http://s000.tinyupload.com/index.php?file_id=08783873136354161174

2nd file I'm trying to append to it (I can reencode that, it's technically further in the video so the resulting vid doesn't make sense, but it's just for proof of concept, I removed the audio as well to reduce the variables, so for proof of concept I was trying to append this to the first video with audio removed as well):
http://s000.tinyupload.com/index.php?file_id=76084899387790454595

I must admit that I'm not quite sure where to start with the instructions you gave me, I don't know how to set the --sps-id or how to cut on GOP boundaries. Sorry...

I find that ffprobe.exe (from the FFmpeg suite) gives more complete information than MediaInfo. Redirect console output into a file for each segment and compare.

Does ffprobe give even more info than what I posted above? I've never used ffprobe before, do you know what kind of command line I would need to output video info from an input mkv file?

At this point, I'm thinking my best chance would be to find the same x264 encoder core, x264 core 98 r1629 2e81ce1, but I can't seem to find an old link to it on the net. If anyone has a link to that, please let me know.

If anyone has any other suggestion, or wants to "try their hand" at joining the files above and explain how they did it, it would also be greatly appreciated. Thanks again to everyone who has posted so far.

[smrpix]

You're not going to make this work.

I loaded both clips into TMPGenc Smart Renderer and it wanted to re-render everything.

To minimize variables I used ffmpeg to pass only the video stream, then loaded the video streams into TMPGenc Smart Renderer. It worked a bit better, but it appears the timecodes on those files and possibly the GOP lengths are out of whack. They may or may not be variable frame rate.

Not going to happen.

[poisondeathray]

Works ok with the method described above.

Your part 1 source file had artifacts/blocks around 1:05 to begin with - those are reproduced in the append because the part 1 isn't re-encoded, just "copied" . But the "seam" where the join is fine, that is where most appending strategies fail

The 2nd file needs to be re-encoded in your case, primarily because of the frame rate in the 2nd video, and aspect ratio --sar 240:241 in the part 1 (not 1:1)


To reiterate

1) demux the part 1 with mkvextract, or ffmpeg

2) re-encode the 2nd part, I used a different x264 version and the settings don't really matter, but I matched them anyway (you can change them it won't matter). The critical part is the aspect ratio, and frame rate which is 23.9760000 (ie. not 24000/1001) . You find this info with h264_parse a free commandline utility for analyzing h264 streams . I've attached the log below . You could use selur's mis2x264 to match the settings if you aren't that familiar with x264 (it reads mediainfo strings from x264 encodes), but again, not that important to match

x264 --bitrate 750 --profile high --level 3.1 --ref 8 --fps 23.976 --keyint 240 --min-keyint 24 --sps-id 2 --sar 240:241 --force-cfr --b-adapt 2 --bframes 6 --aq-strength 0.5 --vbv-maxrate 1927 --vbv-bufsize 1927 -o 3.h264 input.avs

Then dos copy the 1st to the 2nd as an elementary stream , then re-wrap into whatever container

copy /b "FT sample_track1_und.h264" + "3.h264" output4.h264

[poisondeathray]

You have to read up on "GOP" or group of pictures
http://en.wikipedia.org/wiki/Group_of_pictures

Basically, it's temporal compression, where not all frames are complete. Some frames rely on information from other frames, that's why the compression better . This means you cannot interrupt a GOP, or you get a garbled picture, artifacts because you are missing information. This is why you have to cut on "GOP boundaries". Only IDR frames are "complete" by themselves. If you had a intra only encode (only IDR frames), then you could cut anywhere without problems .

(I'm distinguishing between a "true" keyframe - an IDR frame - vs. a "fake" keyframe that is an I-frame (often abbreviated "i" lowercase frame) . These can occur when you use open-gop)




So if you had a source video with glitches, and you wanted to replace some sections - you could use that procedure above by splicing in segments, but the cuts in the source file have to be on GOP boundaries. Most freeware used to cut sections will cut on GOP boundaries anyways

Also, the inserted segment should begin with an IDR frame in coded order. You can sometimes get problems with appending if it begins with a b or p frame. Most of the time x264 will use and IDR frame to begin with, but you can force frametype placement by using a --qp file

[PlanetIndigo]

Alright, again, sorry for the delay in my answer, but I have been busy and also experimenting with this took some time.

It turns out that I was somehow familiar with the concept of GOP, but not under that name, I'm familiar with the concept of keyframes and how to only cut/edit on them.

Poisondeathray, thanks a lot for your help, your post helped me a lot. I've played around with this quite a bit and I've made several observations:

- as long as I first demux the video streams into .h264, even if I don't match the encoding settings precisely at all, as long as the resolution is the same, I can then append them to each other with several different methods (mkvmerge as well as a basic file merger I had which seems to do exactly the same as your dos command) and not have them glitch at the junction point. HOWEVER, rewinding or seeking in/out of the reencoded/inserted part will crash pretty much every player I tried.

- using your settings I was able to solve that issue, and after playing around with them it turns out that the key was not the fps or the aspect ratio but that almighty "--sps-id 2" command. Using that, you can pretty much mismatch a lot of the other encode settings and still have the resulting video be playable and seekable.

Which brings me to my question: is it possible to get them to be appended correctly and play correctly without that command? From what I understand (I could very well be mistaken though) that command seems to mark that part as having different encode settings and that's why it seems to be so lenient. I am however a little concerned about this causing compatibility issues in older players/devices or future players which I might want to use, so if at all possible, I'd like to keep working at it and try to avoid using that command if it can cause any sort of compatibility issue in the future.

I've been trying hard to find the exact x264 encoder build that was used to make the video, but I have so far come up empty handed. Does anyone know where I could get that build or could post it in the thread? (x264 - core 98 r1629 2e81ce1)

Here are 3 of the latest files I've been working with:
Part 1 (with the original file encode settings):
http://www.datafilehost.com/d/f72885c3

Part 2 (reencoded video with my encode settings matching almost completely part 1's except the core version and a couple encode settings that may not have been present on the core used to encode part 1, but were left at default values):
http://www.datafilehost.com/d/d689800b

Resulting file (which plays normally going forward but crashes if rewound back once you go past 6mn24 (the junction point), if part 2 is encoded with the extra command "--sps-id 2" rewinding becomes possible without crashes but I'm worried about compatibility issues or other issues caused by having 2 encode settings marked in the same file):
http://www.datafilehost.com/d/62b80a4b

[poisondeathray]

Which brings me to my question: is it possible to get them to be appended correctly and play correctly without that command?
From what I understand (I could very well be mistaken though) that command seems to mark that part as having different encode settings and that's why it seems to be so lenient. I am however a little concerned about this causing compatibility issues in older players/devices or future players which I might want to use, so if at all possible, I'd like to keep working at it and try to avoid using that command if it can cause any sort of compatibility issue in the future.

Probably not without that command. Or unless you used the same encoder, same settings, same encode and joined 2 sections that were split on keyframes. But even if you use the same version of the encoder, same settings , at the same session - even then sometimes it doesn't join without a glitch! You can find many old threads on this here and on other forums detailing this issue.

- using your settings I was able to solve that issue, and after playing around with them it turns out that the key was not the fps or the aspect ratio but that almighty "--sps-id 2" command. Using that, you can pretty much mismatch a lot of the other encode settings and still have the resulting video be playable and seekable.

Yes, that is what I said in my first post.

If you encode with x264 , set the --sps-id to some number, like 2. When you append, do it with an elementary AVC streams with dos (copy /b). When the sps-id value differs between fragments, this method can append AVC streams with different encoding settings (even different AVC encoders.) The input videos have to be cut on GOP boundaries

So this is the "best" way to do it if you are re-encoding - a binary join as described above. Compability will be high because most of the settings don't really matter. In fact, this is what youtube and some VOD platforms do on a larger scale, with distributed encoding - and they don't seem to have any problems. Or what if you didn't know what encoding settings were used? x264 prints a string, but what if another encoder than x264 was used? Or some people use a custom build to erase the SEI string. Some people even prefer to use this way over "smart rendering editors" , because when they re-encode , those few re-encoded frames are sometimes noticably lower in quality , whereas you can adjust x264 to produce high or similar quality frames

The other settings don't matter much (or at all), but my understanding is a changing --sar value midstream can cause problems in some players. It might be that the player you used ignored it or doesn't care. So you should still match some of the settings. Basically the settings that you can adjust freely are those you can adjust with --zones . Those shouldn't matter when they are different between sections. Notice --sar isn't there isn't in the list.

The other potential problem is fps. Elementary video technically shouldn't have an fps, but there are metadata fields that can contain this data. So if you encode part "B" and it has a different fps, theoretically that can cause problems with some players

This page is down ATM, but the google cache has it. Look at the --zones section
http://mewiki.project357.com/wiki/X264_Settings

zones

Default: Not Set

Tweak settings for specific sections of the video. You can modify most x264 options per-zone.

A single zone takes the form of <start frame>,<end frame>,<options>
Multiple zones are separated from each other with a '/'


Options:

These two options are special. You can only set one per zone, and if you set one, it must be the first option listed for the zone:

b=<float> applies a bitrate multiplier on the zone. Useful for extra tweaking of high- and low-action scenes.
q=<int> applies a constant quantizer on the zone. Useful for applying to a range of frames.

The other available options are as follows:

ref=<integer>
b-bias=<integer>
scenecut=<integer>
no-deblock
deblock=<integer>:<integer>
deadzone-intra=<integer>
deadzone-inter=<integer>
direct=<string>
merange=<integer>
nr=<integer>
subme=<integer>
trellis=<integer>
(no-)chroma-me
(no-)dct-decimate
(no-)fast-pskip
(no-)mixed-refs
psy-rd=<float>:<float>
me=<string>
no-8x8dct
b-pyramid=<string>
crf=<float>

Limitations:

The number of reference frames for a zone can never exceed what was specified with --ref
Scenecut can not be turned on and off; only varied if originally active (>0)
Merange can not exceed what was originally specified if --me esa/tesa
Subme can't be changed if the original commandline specified it as 0.
You can't set me to esa or tesa if --me was originally specified as dia, hex, or umh

Example: 0,1000,b=2/1001,2000,q=20,me=3,b-bias=-1000

And the other potential compatibility issue is any scenario with VBV compliance, like blu-ray , avchd, some devices etc... If you "patch" in a section that has a high bitrate for example, it might cause a buffer underrun. Of course those aren't issues on a computer for playback. So you should still try to match roughly the bitrates and use vbv settings for that new section if the intended target was device playback. This doesn't necessarily make it VBV compliant, but you have less chance of a violation. The only way to make it 100% VBV compliant on 1 attempt would be to re-encode the entire thing

[PlanetIndigo]

I see, thanks for the explanation. Well since I am a perfectionist, I will attempt my best to try and join them by matching the encode settings and x264 encoder and if even after matching those it fails to produce a seekable video, I will resort to the "--sps-id" command. BTW, was I correct in my assumption that this command stores all the encoding settings for that portion of the video as well? I'm not very familiar with headers, but does that info also appear in the header? I know that mediainfo makes no mention of the new x264 encoder version I used in the edited part when I open the resulting joined together final file with it.

For info, the part 1 I had uploaded a few days ago still had the artifacts I was talking about and that you pointed out, but later, I fixed that one by splicing a part of the credits from another non glitched episode (since the credits are identical) and I didn't have to reencode that one (since they had same encoder and encode settings), so at least for that edit it joined them fine, giving me a little bit of hope that if I can hunt down the same version of the x264 encoder I might be able to reproduce it.

I still haven't been able to find the standalone x264-core 98 r1629 2e81ce1, so I've been looking into old versions of meGUI that came packaged with it. While googling I found an old post on videohelp referencing the right version of meGUI, and my surprise was great when I saw that the poster referencing that version was you, poisondeathray, from almost 5 years ago!

https://forum.videohelp.com/threads/321864-MeGUI-encoding-error

In that topic you wrote:
"You're using an old build, there have been reports of crashes on some older builds, especially some combinations of x264.
0.3.4.15 is the newest of today . , x264 is at r1629 (when you check settings=> update you can check your x264 version)"

So apparently, I need to hunt down meGUI version 0.3.4.15. I haven't been able to find it yet though, those old versions seem to be a pain to get a hold of. You wouldn't happen to still have either that meGUI version or the x264 r1629 2e81ce1 by any chance? I may just make a new topic asking if someone has that old version of x264 laying around somewhere on their HDD...

[poisondeathray]

I see, thanks for the explanation. Well since I am a perfectionist, I will attempt my best to try and join them by matching the encode settings and x264 encoder and if even after matching those it fails to produce a seekable video, I will resort to the "--sps-id" command. BTW, was I correct in my assumption that this command stores all the encoding settings for that portion of the video as well? I'm not very familiar with headers, but does that info also appear in the header? I know that mediainfo makes no mention of the new x264 encoder version I used in the edited part when I open the resulting joined together final file with it.

--sps-id doesn't store the encoding settings; if you're referring to the metadata string that you see with mediainfo with x264 encoding settings - that does not affect playback in anyway . Those are user data strings SEI (or supplemental enhancement information) . They can be erased or changed without affecting anything. They are just metadata. If I edit it to say ref=10 , it doesn't suddenly change the video to use max 10 references. The actual video data is unaltered. Mediainfo will usually only show the data for the 1st section (so if you join 2 or more videos with different settings, only the 1st will be displayed)

However, things like VUI information (Video Usability Info) can affect actual playback depending on the player/decoder/renderer setup. --colormatrix, range flags etc... those all fall under VUI . These are identified by mediainfo, but in a different section (not the encoding settings string SEI) . These don't alter the actual bitstream (the actual video data isn't altered), but they can alter how things are played back in software

I still haven't been able to find the standalone x264-core 98 r1629 2e81ce1, so I've been looking into old versions of meGUI that came packaged with it. While googling I found an old post on videohelp referencing the right version of meGUI, and my surprise was great when I saw that the poster referencing that version was you, poisondeathray, from almost 5 years ago!

https://forum.videohelp.com/threads/321864-MeGUI-encoding-error

In that topic you wrote:
"You're using an old build, there have been reports of crashes on some older builds, especially some combinations of x264.
0.3.4.15 is the newest of today . , x264 is at r1629 (when you check settings=> update you can check your x264 version)"

So apparently, I need to hunt down meGUI version 0.3.4.15. I haven't been able to find it yet though, those old versions seem to be a pain to get a hold of. You wouldn't happen to still have either that meGUI version or the x264 r1629 2e81ce1 by any chance? I may just make a new topic asking if someone has that old version of x264 laying around somewhere on their HDD...

There are some old megui versions here, check a few around the same time (it's going to be around June 2010, because that's when the commit was made if you check the x264 change log

commit da1bc99cd4c74499aca99cbfbfc014154bb32440 [revision 1629]
Author: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
Date: Wed Jun 2 22:27:57 2010 +0900

Fix no-mbtree + aq-mode=0

https://www.videohelp.com/tools/MeGUI/old-versions#download

There are some older versions, to Dec 2010 on the megui server, but not June 2010 . The stable fork tends to update x264 later than the development server, so you might get lucky
http://megui.org/auto/

Baldrick (the site admin) used to host old x264 binary versions, but it doesn't look like he does anymore (If you click the hot link to any tool, on that main page there usually is an "old versions" link) . If you PM him , he might have them still in some hidden directory

[poisondeathray]

I found them on an old x264.nl mirror

x64
http://x264.nl/x264/?dir=./64bit/8bit_depth/revision1629
x86
http://x264.nl/x264/?dir=./32bit/8bit_depth/revision1629

[PlanetIndigo]

Awesome! You really are great help.

So for my own curiosity, how exactly is this "--sps-id" making it so the player knows how to properly read the appended sub section of the video? I thought that when appending video portions, it would make a header telling it how to read the first portion and apply it to the whole video, thus causing problems if later parts of the video didn't comply with the beginning (that's the VUI you are talking about, right?). How exactly is --sps-id fixing it by letting the player know how to properly play that appended section? Where is that info stored, in the header as well? Sorry, but I'm still trying to understand exactly what this command does.

I've just tried that r1629 core version of x264 and it doesn't seem to recognize the resize command which works fine in the more recent builds of x264 that I have. Is it really possible that x264 didn't support resize in 2010? I've tried:
--video-filter resize:864,480,1:1,method=lanczos
--vf resize:864,480
and a few other variations but no luck. It keeps saying "unrecognized option". The --help command doesn't seem to make a mention of it too so I'm quite baffled. I have difficulties believing that there would be no resize option and I'd hate to have to reencode it twice by using another encoder to resize the picture then encode it with that core and lose some more quality...

Edit: btw, I can't find a VUI portion in Mediainfo. Is this info supposed to be displayed in there? It's still somehow confusing to me: if the two video portions each independently retain the necessary info for a player to read them correctly when played individually (independently of the SEI info which can be deleted by the user), then how come there are no tools to read what those settings necessary for correct playback are? Matching all those settings would definitely ensure the two videos could be appended correctly, right?

[poisondeathray]

So for my own curiosity, how exactly is this "--sps-id" making it so the player knows how to properly read the appended sub section of the video? I thought that when appending video portions, it would make a header telling it how to read the first portion and apply it to the whole video, thus causing problems if later parts of the video didn't comply with the beginning (that's the VUI you are talking about, right?). How exactly is --sps-id fixing it by letting the player know how to properly play that appended section? Where is that info stored, in the header as well? Sorry, but I'm still trying to understand exactly what this command does.

All this command does is set the id of the sequence parameter set, and yes it's in the header. You can think of it like a "name" or "label." In the header, the SPS can be identified by a number (e.g. 0,1,2,3,..) . The default value used by every encoder (not just x264) is "zero". It doesn't tell the media player anything for playback, it only facilitates appending streams which have different settings. If you examine the appended stream, the SPS-id will take on the value of the first segment (so "zero" in most cases, will be the "new" SPS -id)

I've just tried that r1629 core version of x264 and it doesn't seem to recognize the resize command which works fine in the more recent builds of x264 that I have. Is it really possible that x264 didn't support resize in 2010? I've tried:
--video-filter resize:864,480,1:1,method=lanczos
--vf resize:864,480
and a few other variations but no luck. It keeps saying "unrecognized option". The --help command doesn't seem to make a mention of it too so I'm quite baffled. I have difficulties believing that there would be no resize option and I'd hate to have to reencode it twice by using another encoder to resize the picture then encode it with that core and lose some more quality...

x264 has to be built with the filtering patch to have resize filter. Those old x264.nl builds were "vanilla". They eventually got a decoder ffms2, but I don't think any of them got built with the filtering patch. Strictly speaking, x264 is supposed to be an encoder only. No decoder, no filtering (like crop, resize etc..) ,no audio. But some people have built modified builds which include various other things

Most people would use an avs script to do the resize. Even x264.nl builds had avs support. Avisynth is a frameserver

The other option would be to use a lossless intermediate. no quality loss, but takes more time, more temporary HDD space. Lossless intermediates are commonly used when you have heavy filtering to do with multipass encodes, not for what you are doing. Because slow filters are a bottleneck and you only want to have to endure them once

Edit: btw, I can't find a VUI portion in Mediainfo. Is this info supposed to be displayed in there? It's still somehow confusing to me: if the two video portions each independently retain the necessary info for a player to read them correctly when played individually (independently of the SEI info which can be deleted by the user), then how come there are no tools to read what those settings necessary for correct playback are? Matching all those settings would definitely ensure the two videos could be appended correctly, right?

"correct playback" is a function of a hundred different things, not just encoder, but decoder setup, splitter, renderer, software, host system, hardware, drivers, etc... You're just looking at 1 piece of the big picture right now

There are tools to parse various stream data . The only free one is h264parse, mentioned earlier. Professional tools include h264visa (called codec visa now), elecard streameye, a few others

Not all VUI options are displayed in mediainfo, and not all streams will have those options "flagged'. You have to explictly set some of them for mediainfo to show them . For example colormatrix you will often see mediainfo show this. If it's "undef" or undefined it might not show (not even a blank entry, but completely missing like your mediainfo above

eg. range flags and matrix coefficients in another video, read by mediainfo. They are missing in yours

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Limited

These don't always affect playback the exact way you want them to. It is ultimately determined by the playback setup and specific software. For example madvr accepts this type of data and adjusts playback accordingly . Adobe flash accepts range flags (full vs. limited) . Other software ignore matrix coefficients and do the RGB conversion for display based on resolution (HD gets 709, SD gets 601)

[poisondeathray]

A third option to using avisynth , or lossless intermediate, would be to use ffmpeg to manipulate/scale and pipe to x264 . (Or if you can find a ffmpeg binary with libx264 build using the same r1629)

eg (you need to add your specific the x264cli settings)

ffmpeg -i INPUT.ext -vf scale=864x480:flags=lanczos -an -f yuv4mpegpipe -pix_fmt yuv420p - | x264 - --demuxer y4m -o OUTPUT.h264