VideoHelp Forum
+ Reply to Thread
Results 1 to 13 of 13
Thread

Threaded View

  1. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    hi
    although it seems similar to my previous question, it's a different problem.
    what's the best (fastest, most frame accurate, etc.) way to cut an mkv file? Avidemux doesn't operate with an mkv file as well as an mpeg file. i don't want any encoding. just cut mkv files.
    another question is that what's the best tool for this purpose? converting mpeg2 to mkv (x264 encoder), frame accurately with capability of batch processing?
    thx
    Last edited by hamidi2; 3rd Apr 2012 at 14:35.
    Quote Quote  
  2. You can't have frame accurate cuts without reencoding the cut GOPs.
    Quote Quote  
  3. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    i don't know what GOP is, but i'm certain that if i were in place of a video editor software creator, i would never let this happen!
    Quote Quote  
  4. Because of the way video is compressed, only keyframes are "independant" frames. Other frames rely on each other or on keyframes for information when they're encoded. Therefore you can only cut video on keyframes without re-encoding. Depending on the type of video and encoder settings keyframes can be many seconds apart. It's not the video editor's fault.

    When encoding, one way around this rather than encoding an entire video and then trying to cut it later, is to edit the original video first, or to only encode the sections of it you wish to keep. MeGUI has an AVS Cutter under the Tools menu. Basically you setup a normal encode, MeGUI creates the script for encoding, then you use the script cutter to specify the sections you wish to re-encode. For instance you could specify frames 12 to 3146, then frames 3546 to 7634.... that sort of thing. So effectively the cuts are being applied during encoding. The AVS script cutter has a preview window so you can specify the cuts frame accurately.

    Alternatively, a smart video cutter will let you cut anywhere, but it'll re-encode the sections around the cut if it's not done on a keyframe. I've never used it, but I think VideoRedo will do "smart" cutting.
    Quote Quote  
  5. Member
    Join Date: Oct 2004
    Location: Freedonia
    Search Comp PM
    VideoReDo can indeed be used to cut MKV files. That is I can personally verify that it works with MPEG-2 and H.264 video but I honestly have not tried VC-1. hello_hello is correct that it tries not to re-encode and does so only if it must.
    Quote Quote  
  6. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    rehi
    thank u for replying.
    indeed this problem has happened during encoding. let me describe it better.
    i'm encoding from MPEG to MKV. the video encoder which is in this case Avidemux knows the start and end frames i've specified. if the start frame is not a keyframe, a keyframe may be generated relying on the last keyframe of the input video and the frames after it until the start frame i've specified. the last keyframe of the original (input) video must not be used in such a case. so, the starting frame of the output video may be exactly the start frame i've specified in the original video. in this case, my problem is the end frame. if the problem is keyframe as u say, it seems that Avidemux has lengthen the video to the next keyframe while it may not happen! no need to include additional frames existing beyond the frame i've specified to be the end frame in the original video.
    a note is that this problem doesn't occur when i encode into avi even with the same encoder (x264)! how is it explainable?
    i've examined MeGUI. it has not so good UI, produces lots of temporary files and is not so user-friendly. but since u advised it, i will examine it again.
    i've never examined VideoReDo for editing. i just use its Quick Stream Fix capability. now that u say, i will examine it too.
    thx
    Quote Quote  
  7. You have a group of frames. One of them is a keyframe while the rest are B and P frames. These frames rely on each other, or on the keyframe for information when they're decoded. However they don't always rely on preceeding frames, they can use information from future frames (looking at them in the order they're played). Therefore you mightn't be able to cut the video at a specific frame if it needs information from a future frame when it's decoded. The future frame(s) also need to be included when cutting. Hence the need to cut on a keyframe at the beginning and up to a keyframe at the end. At least that's the way I understand it.

    Originally Posted by hamidi2 View Post
    a note is that this problem doesn't occur when i encode into avi even with the same encoder (x264)! how is it explainable?
    I don't know, I've never encoded x264 video using an AVI container. I could guess that as the AVI container isn't as flexible as more modern containers, the encoding software is limiting the use of B and P frames, but as I said, that's just a guess...
    It could also be that AVIDemux isn't identifying keyframes accurately when an AVI container is used. It was never designed to contain h264 video. Does AVIDemux actually edit AVIs containing h264 video properly? I've hardly used AviDemux myself but frame accurate h264 editing doesn't seem to be something which is easily achieved and maybe when using an AVI container it's even harder. More guessing....

    Originally Posted by hamidi2 View Post
    i've examined MeGUI. it has not so good UI, produces lots of temporary files and is not so user-friendly. but since u advised it, i will examine it again.
    All encoders create temporary files. Mostly they create the same temporary files, only some just make an effort to hide them from you (putting them in the Windows temp folder, for example). I usually just let MeGUI create the temporary files in the same location as the source video as once the encoding is done I delete the whole lot anyway, but it's not hard to create a new temporary folder manually and tell MeGUI to put all it's temporary files there.

    MeGUI is definitely not the most user friendly encoder but as a result it's probably the most versatile. In my opinion any extra learning curve is worth it. And of course it includes a script cutter, so once you set up your encode and MeGUI has created an avs script for encoding (one of those temporary files) you can open the avs script with the script cutter and preview the video while you specify the exact frames you're wanting to encode.... so then there's no need to edit later. You also need to apply the same cuts when encoding the audio to keep it in sync, but MeGUI lets you create a "cuts file" (another of those pesky temp files ) which you can use when encoding the audio so both the audio and video should be cut in the same places when encoding.
    Quote Quote  
  8. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    rehi
    thank you for these great information. i'm happy that u know so much about encoders
    1. first, i wonder how frames may depend on their next frames! then,

    Does AVIDemux actually edit AVIs containing h264 video properly?
    no! it just manipulates mpeg files properly. after encoding manipulating the results even if the Avidemux itself has made them is not so easy and even sometimes impossible.
    i've not switched to MeGUI yet, but i decided to examine VideoReDo. after using a phase of its QuichStream Fix capability on a bunch of video files, i've to cut them. again with VideoReDo i make the files which needed to just cropped and de-interlaced (Avidemux filters).
    2. can i combine these two phases since both are done with the same tool?
    if VideoReDo cut frames accurately, it seems that i may still avoid switching to a new unknown UI. newbies have right to scare and scape what they're not familiar with!
    Quote Quote  
  9. Originally Posted by hamidi2 View Post
    first, i wonder how frames may depend on their next frames!
    Much of the bitrate savings in high compression codecs comes from encoding only the changes from frame to frame. A GOP (group of frames) will start with a I frame, a keyframe. Much like a JPEG picture it contain all the information to reconstruct the entire frame. For several frames after that the compressed data only includes information about parts of the picture that change from frame to frame. In essence they say "keep the picture from the last frame, but make these changes." So, for example, in a "talking head" shot with a static background, the first frame contains the head and the background. But all the subsequent frames of the GOP only contain information about the talking head. If you remove the first frame there will be no way of reconstructing the static background.

    That is why editors that don't reencode can only cut on keyframes. Smart non-reencoding editors allow frame accurate cuts and will reencode only cut GOPs. Simple reencoding editors allow frame accurate cuts but will reencode the entire video.

    In MPEG 2 video the distance between keyframes is typically about 15 frames. In xvid encoding it can often be 300 frames, in x264 250 frames (those are the default max GOP size in those codecs).
    Quote Quote  
  10. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    thank u very much
    i will try to get the best solution for what i want to do based on your advice.
    Quote Quote  
  11. Member
    Join Date: Apr 2008
    Location: Iran, Islamic Republic of
    Search Comp PM
    oh thanx for such a good explanation. now i see why corrupted mpeg4 files still move the corrupted object when the original object in that place is absent. very good idea, but how is it possible? it gets very complicated.
    so, i think the best method is not to define 300 or 250. scene changes be detected instead and I-frames be kept exactly at the beginning of a scene. right? do encoders have such an option and can they detect scene changes and decide what to choose as I-frames with this method?
    in this method of compression, movies like what featuring Jackie Chan must consume more space than what in CNN. right?
    how are the differential info saved?
    i still don't figure out why frames may depend on their "next" ones. it's reasonable to depend on previous ones, but not next ones!
    and you believe that VideoReDo and MeGUI are of type smart non-reencoding editors and Avidemux is not?
    how can i justify that Avidemux cuts accurately when encodes from mpeg2 to xvid, but doesn't when encodes to mkv? both are encoding, not just a cut.
    Quote Quote  
  12. Originally Posted by hamidi2 View Post
    so, i think the best method is not to define 300 or 250. scene changes be detected instead and I-frames be kept exactly at the beginning of a scene. right? do encoders have such an option and can they detect scene changes and decide what to choose as I-frames with this method?
    Yes, most encoders have the ability to add keyframes at scene changes. The "max" setting is for when the scene doesn't change for a long time.

    Originally Posted by hamidi2 View Post
    in this method of compression, movies like what featuring Jackie Chan must consume more space than what in CNN. right?
    Yes, but CNN may not be a good example because they usually have stuff moving in the background.

    Originally Posted by hamidi2 View Post
    how are the differential info saved?
    That's way too big a subject.

    Originally Posted by hamidi2 View Post
    i still don't figure out why frames may depend on their "next" ones. it's reasonable to depend on previous ones, but not next ones!
    The frames are not encoded/decoded in the same order they are presented. In presentation order (the order you see them when you watch a video) they may appear as IBBP, I=keyframe, P=predicted frame (forward only) B=bidirectional predicted frame (forward or backward), they are encoded, stored, and decoded as IPBB. Then the decoder re-orders the frames before output. The P frame only contains changes from the I frame. The B frames may reference either the I or P frames, or both. B frames are also encoded with lower quality. The idea being that you won't notice lower quality for a few frames because an I or P frame will come along soon and clean the picture up again. In theory, B frames can also require less bitrate because they can reference more than one frame. But in my experience that rarely makes much difference.

    Originally Posted by hamidi2 View Post
    and you believe that VideoReDo and MeGUI are of type smart non-reencoding editors and Avidemux is not?
    I know VideoReDo is a smart non-reencoding editor. I don't know what ability the others have in that regard.
    Quote Quote  
  13. MeGUI is not a "smart cutter". It's an encoder and can't really be used to cut existing video.
    My suggestion re MeGUI was to go about it a different way as you said you were trying to edit video after you'd converted it from the original mpeg source. Rather than encode an entire video using the x264 encoder and then try to edit the encoded video later, it'd probably be a lot easier only to encode only the sections of video you want to keep in the first place.

    Once MeGUI has created a script for encoding the entire video you can open the script with the script cutter (it'll open a preview window just like an editor would). Using the preview window you can specify the exact frames you wish to encode, skipping the sections you don't want to keep. As you're re-encoding the video you can do it on a frame accurate basis regardless of the source. Once you've set up your cuts you can just let MeGUI encode the video and it doesn't matter where the keyframes land because you're not needing to edit the video after it's encoded anymore, it's effectively being editing while you're encoding.
    Quote Quote  



Similar Threads