Hi, I currently have a MKV file where I want to use the video stream only and place it into another MKV. The video is out of sync for everything else however. The simple solutions are to either delay the video (easy) or cut everything else (annoying).
The issue I'm having is that the delay is simply delaying the video from playing beyond the first frame (which is not blank) for X ms. I would sooner prefer to see a blank clip or black frame than this. Now you could say that inserting a blank clip for X ms at the start would work but I am struggling to match the x264 settings to that of the original clip for that process to work.
If anyone knows of any other not-so-time-consuming options that would be great. I'd like to avoid re-encoding but if there is a fast way to do (20 minutes or so) I'd be up for it.
+ Reply to Thread
Results 1 to 22 of 22
Thread: MKVMerge Delay with Blackness
selur has a program that will match settings according to the mediainfo report - mis2x264 . You might have to find matching x264 core versions, and it still doesn't guarentee it working.
Does the other video have audio? If so you need accompanying blank audio as well, the same specs, same # channels, sampling rate etc...
Sorry I don't quite understand your description . You want to insert video "i" into video "b" ? What position ? video "b" has audio ? but video "i" doesn't ?
Is it appended to the beginning ? or insterted somewhere in the middle ?
i is "video i" , "---" is the no audio. b is "video b", a is the audio for "video b"
iii bbbb --- aaaa
Well actually you solved it already with your first comment =D
I wanted to create a delay at the start without having the first frame stalled (as it's not black) by the delay that mkvmerge provides. So I wanted to have a BlankClip which I could not match the settings for. I had used mis2x264 with no luck but when you mentioned finding and using the correct x264 core, well everything worked.
Thanks for the help! Now I need to write a massive batch script to automate this process XD
ok just to clarify for other folks who might not understand: the core version will be listed in the mediainfo report. It's changed whenever the x264 API is changed. It's not the same thing as revision number , in this example is r2431 . The core here is 142
Writing library : x264 core 142 r2431 ac76440
Although the video now plays their appears to be quite a number of issues with the color. There are random tints of color that will cover part of if not all of the screen during playback. By tints I mean that it appears as though you are looking at some part of the screen through a green/blue/red lens. This only occurs when I append these clips together (the BlankClip and the video clip from the MKV). Not sure if there's a solution to this.
To re-describe what I'm trying to do it is to take a video clip of a MKV file and delay it by a few seconds to match the audio/chapters/subtitles that start a few seconds later than the video clip. The audio and others do not come from the MKV file. I was hoping to have the delayed part of the video clip be black frames instead of the first frame of the video clip being frozen for the duration of the delay as it is not black.
Correct me if I'm wrong: Right now , the video duration is shorter than the audio; and video starts early
Instead of delaying the Video,
You want to append a blank video segment
The only 100% sure fire way is to re-encode (do the joining in lossless domain e.g. avs script)
If the videos had been encoded with --stitchable , along with the same core & settings, then they should append without issues as well
Last edited by poisondeathray; 8th Jul 2014 at 14:51.
I don't really mind re-encoding it all again; the script is simple to make. My concern is how do I maintain the same quality (bitrate, etc.) in the x264 encoder? Is it really as simple as using the same settings as before?
I haven't actually tried to re-encode a video after it's been encoded, only encoded episodes from DVD and bluray sources where I purposely lose some quality in favor of size.
You will always lose some quality when encoding with lossy settings. You could use lossless (CRF 0 ), but filesize will increase dramatically.
Just use some settings that are "good enough" for your eyes. Typically people use around CRF 16-22 , the lower the value the les quality loss, the larger the filesize
Yeah, I'm very familiar with CRF. I'm a bit high-end for that usually sticking to CRF 13-16 from source materials. But that description helps. More or less you're saying that:
Source -> Lossy Encoding -> Lossy Encoding
will result in further quality loss from stage 2 to 3 regardless of the settings I use albeit might not be that noticeable. If that's the case I think I'll stick with my delay, one lossy encode is enough lol.
I would have liked to have stitched them together but the video was not encoded with a revision of x264 that supports --stitchable which i hear is 2342 or greater. I guess that's why I see that tint effect despite the fact that I used the same settings and core for the BlankClip as those of the video.
Another thing you could try is assigning a different sps-id to the blank segment and joining the elementary streams (e.g dos copy)
Even if the encoding settings are different, supposedly that allows you to append them
The issue I'm having is that the delay is simply delaying the video from playing beyond the first frame (which is not blank) for X ms.
- extract time codes for the video stream using mkvextract
- adjust time code of the first frame (and all following; should be easily doable using excel or similar), in example by adding +10 (ms) on each value
- add the new time codes for the video stream using mkvmerge/mmg
That appears to be the same as creating the delay in mkvmerge which is kind of what I don't want. You're right, it is showing the first frame a bit longer. That's also what I'm not looking to have XD
Last edited by Elegant; 9th Jul 2014 at 13:08.
sorry, I misread the thread.users currently on my ignore list: deadrats, Stears555
Going back to an earlier comment, you had mentioned something about --sps-id 2. I think that tsMuxeR seems to take care of that although I have to create a m2ts file (which I can convert to mkv). I can't change the SEI and VUI data though as it fails to mux. It does not appear to be re-encoded at all and I don't seem to have that "tinting" issue. Bitrate suffers a tiny hit (1-20kbps) but I'm assuming that's due to BlankClip being added.
Any thoughts on tsMuxeR? I'm wondering this can be considered a solution that does not diminish the quality of the source material, I'm just not very familiar with how well received this tool is for this kind of use.
Last edited by Elegant; 10th Jul 2014 at 00:30.
No, just use --sps-id 2 on the small part you're encoding and appending. Output an elementary stream (e.g. input1.264). Join the elementary video stream with dos copy to the main video (e.g. input2.264)
copy /b input1.264 + input2.264 output.264
Join the audio separately by normal methods, then mux video & audio together with mkvmerge
I tried some quick tests on some files with different encoding settings (on purpose) , that didn't even join properly with mkvmerge, and it seemed to work. I only did a few tests, but frankly I'm surprised. I might have lucked out on the choice of samples, but no glitches so far at the join site or anywhere else...weird
Any thoughts on tsMuxeR? I'm wondering this can be considered a solution that does not diminish the quality.
The file overhead for transport stream is about 5-7% larger than MKV container . If it's only slightly larger in filesize than the 2 mkv's added together, then something went wrong (or maybe your files weren't very big, calculations weren't accurate). So if it truly worked you should be able to remux with mkvmerge to MKV container without issues. Or perhaps you've discovered a bug with that specific mkvmerge build ?
Last edited by poisondeathray; 10th Jul 2014 at 00:33.
Okay so I recreated the BlankClip with x264 using --sps-id 2 and using your dos command. This is a pretty good approach looking at it now, playback is correct. What I find cool is MediaInfo will properly recognize both streams and will inform me what settings both streams were encoded with despite being merged now.
These are some results from different methods:
mkv with just video stream unaltered: 610,442,994 bytes; 3384 kbps
m2ts with BlankClip appended: 647,792,640 bytes; 3588 kbps (6% increase in file size and an increase in bitrate)
mkv conversion of the m2ts: 607,263,065 bytes; 3364 kbps
mkv created using sps-id 2 and dos copy: 607,263,091 bytes; 3364 kbps
I'm not really sure if there is much of difference between tsMuxeR and the sps-id method except that the former will return the encode settings of the unaltered video and not that of both the BlankClip and the video stream in MediaInfo. Both seem to check out and play back just fine, that "tint" from the mkvmerge method is gone. In addition, the x264 core used in both cases does not seem to affect the end result, I'll have to test it later with different encode settings and see if this holds true.
Perhaps there is a bug with append in mkvmerge?
Last edited by Elegant; 10th Jul 2014 at 01:50.
When you refer to "cutting everything else" being annoying, are you referring to the work it would require being annoying or do you actually want to avoid removing a bit from the beginning of the audio etc?
I ask just in case you're not aware that instead of applying a positive video delay you can apply it as a negative audio delay (and everything else delay). Mostly a negative audio delay is fine because it just cuts off a bit of silence, but maybe it needs to cut more than that. Even so, I'd tend to extract the audio, cut it myself, apply a little fade in, then remux it.... rather than mess with the video.
What's the delay required?
Not knowing, I thought Selur might be onto a good idea. The frame duration for film is about 41.6ms. If you added an extra 5 ms to each of the first 24 frames (the 1st second of video) that'd give you an extra 120ms. Would slowing down the video a tiny bit for the first second or so be noticeable? ie Would you notice if the first second was only 21.5fps... that sort of thing?
If not, the easiest way to do it might be to apply the required delay for the video, extract the timecodes, then manually move the first second's worth of frames back by an appropriate amount so the first frame is at 0 again...... or something like that.
I don't suppose you'll find yourself really lucky and be able to extract a tiny bit of black from the existing video? The chances aren't great, but sometimes there's a bit of black before the end credits, or right at the end, or after a fade out etc. If you're lucky you might be able to make a copy of the video, cut out a small section of black and tack it onto the front of the original..... stranger things have happened.
The length in this case is 24 frames (1 second) but I have another series I'm doing where it varies from episode to episode where the delay can anywhere from 7-40 frames off. Mind you I can do a delay in the later cases as the first frame is already black. The main reason why I can't offset everything else back is that I haven't discovered a way to properly offset chapters.
@poisondeathray Your method of using dos copy is perfect! The use of --sps-id 2 isn't required using dos copy method either. After a fair bit of testing, I've discovered that the core and the encoding settings appear to make no impact on the playblack of the file. tsMuxeR appears to do a similar process as well. The "tinting" issue that was present from mkvmerge is also gone. This really makes me wonder why mkvmerge has such an issue appending the streams, could it be a bug?
Using different --sps-id would give you more flexibility, as different settings, different AVC encoder encoded files could be joined
No, the point is that if you set a new SPS-ID, the new sequence can use whatever settings it wants, because it uses a different SPS than the original stream.
Dark Shikari is one of the main x264 developers
"Tinting" issue might be related to that specific mkvmerge build (e.g. maybe try another older version)