View Full Version : A program to cut MKV files
sirt
5th January 2013, 13:02
Hi,
I'm not sure if it is the right place to post this but here is my question : do you know a program that would allow me to cut MKV files (encoded with x264 and whatever the audio is) without reencoding ? I've given a try to several softwares such as MKV Cutter, FreeVideoDub but with no sucess. I can't cut my own encoded files ! Of course, I can do this trough AVIsynth with FFVideoSource or DirectShowSource but I'm looking after a program that won't force me to demux audio or anyhting like this.
parsifal
5th January 2013, 13:09
Hello sirt. Have a look at the following two:
1. Avidemux (easier, provides a visual preview)
2. mkvmerge GUI, contained in the mkvtoolnix utilities suite (more robust, proper handling of multiple embedded streams, no visual preview so you can only cut using timecodes)
Happy New Year!
sirt
5th January 2013, 15:06
Hi,
Thanks for your answer. Actually, I am already using MKVmerge but I never managed to cut anything properly with it. Again, all I do is purely educative because I want to cut my own encodes. I know AVIdemux but I have never used it, then, according to you you can bump an MKV stream into it, cut it how you need and finally save the output without reencoding ?
I also tried Yamb but it never cut anything well or I got errors.
As I said before, I can cut it how I intend to via AVIsynth but my problem is the sound, is there a way to "cut" both at the same time ? When using FFVideoSource or DirectShowSource audio is not taken in account, as if it had been demuxed, or am I wrong ? Can I "keep" it ?
EDIT
Then I gave a try to AVIdemux and as expected you can cut the video in the way you want but when using "copy" mode for both audio and video with MKV container, and exporting the output, I have no idea if it is reencoded or not. The writting lirary Lav is used so I don't know what happens.
LoRd_MuldeR
5th January 2013, 22:00
The "Copy" option in Avidemux is identical to the "Direct Stream Copy" in VirtualDub. It means the stream is copied 1:1 and thus no re-encoding will be done.
BTW: The "writing library" probably refers to the (MKV) muxer in this context, which would be libavformat in your case...
Another tool for MKV editing, though I have not used that one myself yet:
http://forum.doom9.org/showthread.php?t=163985
sirt
5th January 2013, 22:49
The "Copy" option in Avidemux is identical to the "Direct Stream Copy" in VirtualDub. It means the stream is copied 1:1 and thus no re-encoding will be done.
BTW: The "writing library" probably refers to the (MKV) muxer in this context, which would be libavformat in your case...
Another tool for MKV editing, though I have not used that one myself yet:
http://forum.doom9.org/showthread.php?t=163985
Thanks for your answer.
The SolveigMM program you redirected me to is - unfortunately - not free so I won't test it albeit a "demo" is available.
Regarding AVIdemux, I would rather not use libavformat but MKVmerge instead ! You will reply : use MKVmergeGUI instead, but the problem is...it is not easy to cut videos with it in so far as it doesn't allow to preview the video...
LoRd_MuldeR
5th January 2013, 23:35
MKVmerge is a command-line tool. Avidemux is a fully-fledged graphical video editor. These are two completely separate programs. You can use the one or the other.
Unless you have any reason to believe that Avidemux (using libavformat) produces invalid MKV files, why do you want to use MKVmerge instead?
sirt
5th January 2013, 23:47
The reason is that it rewrites the file when muxing and it notably deletes the parameters used to encode ! It's not like it is fundamental of course but I like keeping in mind what I used in such and such encode. I guess I should simply check the video via AVIdemux, pick up the timeshifts values and eventually report them back to MKVmerge..and cut the video trough its interface.
LoRd_MuldeR
5th January 2013, 23:56
Yes, if you edit a video file, e.g. by cutting out a segment, the file unavoidably has to be re-written. What else do you expect?
Also what do you mean with it "deletes the parameters used to encode" ???
sirt
6th January 2013, 00:13
I mean the x264 settings used to encode are deleted ; if I check it on MediaInfo, the original x264 parameters used are not shown for an unknown reason. I guess the writing muxer used is the cause of this.
LoRd_MuldeR
6th January 2013, 00:23
The one and only reason why MediaInfo (and similar tools) can show the x264 encoding settings is because x264 writes its version and its settings into the H.264 stream as plain text, embedded into a custom SEI message.
This information is intended for debugging purposes and it's absolutely nothing that would be recognized (or even be relevant) for the H.264 decoder.
The H.264 standard explicitly allows "custom" SEI messages - and it also says that such messages should be ignored by the decoder, if the type is not recognized. That's probably exactly what Avidemux (or libavformat) does.
So it means it does not "delete" the x264 debugging information (or anything of that sort). It just doesn't explicitly recognized that (non-standard) information and thus doesn't again write it into the output file...
sirt
6th January 2013, 00:57
I did not express myself clearly. I know the parameters are not deleted under no circumstances. Indeed, what I precisely want is the SEI message not to be deleted ! But I guess it is not possible trough AVIdemux.
nhakobian
6th January 2013, 03:25
I think a little more detail needs to be given as to why the x264 SEI message isn't being kept in the new copy.
As was said above, x264 stores its encoding settings into a custom SEI message in the output file. This message isn't stored as a custom element in the MKV file, but its a data structure in the underlying H.264 bitstream.
x264 writes this SEI message at the beginning of the output bitstream. So, if you are removing a section of the video at the beginning of the file, you are removing that SEI message too.
As a test, you might want to see if the SEI message remains if you remove the end of the video instead of the beginning. If it disappears, it means that AVIdemux is specifically stripping the SEI message from the bitstream, which I would think should be considered a bug in the program.
You might want to see if you can send a message to one of the AVIdemux developers and see if they can add a feature to copy the x264 custom SEI into the new stream if the section of video in which it is contained is removed. I'm not familiar with the H.264 bitstream format, so I do not how difficult this might be, but I think its a reasonable feature request to make. I'm sure you are not the only person who would like to have this information retained.
LoRd_MuldeR
6th January 2013, 03:33
Because the H.264 standard leaves the semantics of a "custom" (user data) SEI message completely undefined, it may be undesired (or even dangerous) to move arbitrary "custom" SEI messages to a different place.
Sure, one could implement a feature that explicitly scans the input stream for the x264 custom SEI message and, if found, ensures this message will be present in output stream too. But this really would be specific to x264-encoded streams!
Also one could very well argue that standards exist to keep the bit-stream format independent from specific encoder/decoder implementations and therefore encoder-specific "hacks" are to be avoided...
nhakobian
6th January 2013, 05:13
Those are all good points I hadn't thought of.
Modifying the bitstream could potentially cause issues if VBV is used, but I think it could be argued that cutting the bitstream can cause VBV issues too.
It just doesnt seem like there isn't a good and clean method of solving this.
hello_hello
6th January 2013, 11:13
VBV settings effect the way the video is encoded. Cutting the stream wouldn't effect that so it wouldn't cause VBV issues, I don't think.
Any program such as MKVMergeGUI which simply "cuts" can only do so on keyframes, so if you specify a cut point using MKVMergeGUI which isn't on a keyframe (which you likely will) it'll look for the first keyframe after the specified cut point and cut there. Consequently it's hard to cut accurately using any program and often it'll be seconds out. Some programs can do "smart cutting" where they re-encode the area around the cut point where necessary and then copy the rest, but someone else will have to recommend a program for smart cutting as I can't off the top of my head.
To simply split a file using MKVMergeGUI you might need to specify the max. number of files as 2 under splitting options. That way it'll split at the specified point only (keyframes aside) and not split the MKV into multiple pieces.
MKVMergeGUI seems to leave the encoder settings intact for the first segment when splitting but it doesn't re-write them for the rest.
Chevy787
7th January 2013, 01:13
To make things a bit easier, although it'll still cut on the closest keyframe, you could use vfr.py (http://forum.doom9.org/showthread.php?t=154535) to specify an .avs that specifies what should be cut rather than use timecodes.
SealTooGreat
11th October 2020, 22:14
I did not express myself clearly. I know the parameters are not deleted under no circumstances. Indeed, what I precisely want is the SEI message not to be deleted ! But I guess it is not possible trough AVIdemux.
Unfortunately, if you are cutting a section of the video at the beginning of the file, SEI message will be lost. It also frustrates me. But you can keep x264 encoding settings as a tags in MKV file.
1. Create .xml file (There's "example-tags-2.xml" in "examples" folder). And change only red fields with x264 encoding settings that correspond to your file.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
<Tags>
<Tag>
<Targets>
<TrackUID>1</TrackUID>
</Targets>
<Simple>
<Name>Writing library</Name>
<String>x264 core 157 r2945 72db437</String>
</Simple>
<Simple>
<Name>Encoding settings</Name>
<String>cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=2500 / vbv_bufsize=5000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:0.60</String>
</Simple>
</Tag>
</Tags>
Keep in mind you have to save the original x264 encoding settings (from MediaInfo) before you cut your file and paste it in this .xml file.
2. Open MKVToolNix.
3. Drag'n'Drop the file that you've cut.
3. In the field "Tracks, chapters and tags" select the video stream.
4. On the right in the "Properties->General options->Tags" browse to the .xml file that you have created.
5. Press "Start multiplexing".
Now, MediaInfo will register x264 encoding settings.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.