Video stutters after trimming

[Freodon]

I have an .mkv file that contains a [h264 high L4.0, yuv420p, 1920x1080] video track and a [AAC 48000 Hz] stereo sound track. I trimmed it at the very beginning, removing a logo. I used MKVCutter. But when I launch the video, frames stutter at the beginning, and then speed up to make up for the delay (while audio is fine). It lasts only a second or so, later everything is fine. It doesn't happen anywhere else in the video, even around another trimmed parts. I have other .mkv videos that contain the same tracks, and the same logo at the beginning to trim, and the issue doesn't happen there. Is it a frame numbering issue or maybe faulty encoding (I re-encoded parts around the deleted segment because there was no key frame nearby)? How can I fix this?

[Selur]

wild guess: input is vfr
other than that I would need a sample and a cut list which creates the broken output to get to the bottom of it.

[Freodon]

The file is 800 MB, I would upload it but it's just too big.

[Selur]

What does mkvcutters log say?

[Freodon]

I attached a log.

[Selur]

Log doesn't show any problem.
-> try:
a. if updating mkvmerge, mkvinfo, mkvextract helps (they all are part of mkvtoolnix); simply replace the files in the MkvCutter folder with the new ones.
b. if updating LSMASHSource helps; download latest L-SMASH-Works from here and replace the LSMASHSource.dll with the on in the one in the AviSynth folder.

If that doesn't help, try the following:

• open the file with mmg (part of mkvtoolnix)
• drag&drop your file in it
• set 'Global->Splitting->Split mode' to 'split after size' and enter 10M as size
• hit 'Start muxing' and abort after the first few files were created.

Now take the first file and try if you can reproduce the problem (it should contain the start where your problematic cut happened), if you can upload the file and your cutlist here so that I can try to reproduce the problem.

Cu Selur

[Freodon]

After replacement, MKVCutter is unable to load LSMASHSource.dll
I tried both x64 and x86 versions, and with updated and unupdated mkvtoolnix but it never loaded.
And after just updating mkvtoolnix (with unreplaced LSMASHSource.dll) is says "Resetting since mkv split did not create any split files" and no trimmed video was created.

[Selur]

Strange, works fine here -> uploaded an updated package to my google drive.

[Freodon]

I just noticed that if I play this trimmed video in VLC, the video stops after a second and audio keeps going. In MPC-HC however it just stutters for 1 second and then continues normally, so MPC seems to have some built-in frame feeze recovery function. But I've seen people fix this issue somehow after reporting to them that .mkv I downloaded stutters just like that (not necessarily at the beginning of the video).

[Freodon]

I know this thread is old but I still haven't resolved the issue.
I've been cutting out the intro theme (which is between ~1min and 1,5 min of a 20 minute video) and end credits (which are obviously at the very end) with MKV Cutter in these episodes and everything seemed fine, but in the 6th episode I did this, the few last seconds (just before deleted credits) stutter no matter what video player I use, while audio is fine. So it seems to be a rare but existent and really annoying issue and I really don't know why it is like that. I would upload the video but it's 800 MB big...

[Selur]

Problem is without having the source and a cut list there really is no chance to tell where the problem is,..

[Freodon]

I found this on mkv cutter site:
It only properly supports progressive, constant frame rate H.264 content
Could it be because frames I want to cut happen to be of different rate than the neighboring ones? How can I check that?

[Selur]

extracting the timecodes with mkvextract (there are a few GUIs for it out there) and look at the time codes.

[MaverickTse]

I know this thread is old but I still haven't resolved the issue.

Try to get a copy of AviUtl and perform the same cutting.
Use [ to set the start of a section, ] to set the end of section, then Right Click->Delete selected area.
Repeat the above process until all junks are cut.

To encode back to mkv:
File> Export with Plugin>Adv. x265Ex GUI>Video Compression> Select an x264 Profile near the top of the dialog.

The AviUtl Extra Pack hosting here also use L-Smash Works for reading MKV.

I suspected that there may be problems in the source file or some corrupted sectors on your HDD...

[Freodon]

I know this thread is old, but I still didn't manage to solve the issue.
I uploaded 2 .mkv files - "original" is the snippet of the whole video, and "trimmed" is the original one with Madman logo cut out with MkvCutter. Even in the original one you can see that video lags in the middle - an issue that wasn't present in the whole video. But in the trimmed video, issue is the same as with cutting the whole video - it freezes for a moment, and then continues on normally. Why does MkvCutter do that to this video?

[Selur]

Don't see any lagging here. Trimmed and original both play fine here. (using MPC-HC and 'DXVA2 (native)' hardware decoding activated)

[Freodon]

Don't see any lagging here. Trimmed and original both play fine here. (using MPC-HC and 'DXVA2 (native)' hardware decoding activated)

I also use MPC-HC, but where do I enable hardware decoding? Is it here:

or somewhere else?

[Selur]

under:
"Options->Internal Filters->Internal LAV Filters settings->Video decoder->Video Settings->Hardware Acceleration->Hardware Decoder to use"

[hello_hello]

I haven't read much of the thread but the samples don't play properly for me. Using MPC-HC each time.....

ffdshow, CPU decoding.
Original sample smooth.
Trimmed sample displays a few frames at the beginning, pauses, the audio continues, and then a few more frames display at the end (the video seems to skip a whole section in the middle).

ffdshow DXVA decoding.
Original sample isn't smooth. Motion "jitters" across the screen. Maybe there's something wrong with it to begin with. Only the very last part (half a second) has smooth motion.
Trimmed sample is exactly the same as when playing the original.

LAV decoding, no hardware acceleration.
Original and trimmed sample both play with "jittery" motion. Once again, only at the very end is the motion smooth.

LAV decoding, Nvidia CUVID.
Original sample is mostly smooth, but there's sometimes a little "glitch" near the end. It seems to be where the motion changes from jittery to smooth when no hardware acceleration is used, but it plays smoothly before and after a little glitch in the motion when CUVID decoding is used.
Trimmed sample is mostly smooth but there's a slight pause/glitch during the fade-in and another at the same place near the end.

I don't know, but it seems like maybe there's been an edit/smart cut applied originally (maybe to add the logo?) and a second smart cut to remove it is causing more problems.

[Selur]

What MKV Cutter does is straight forward:

• analyse source:
  - to guess compatible x264 settings (using mediainfo&h264_parse)
  - to get the key frame positions (using mkvinfo)
• split the source:
  - audio is directly split/cut in one go using mkvmerge
  - video is split on GOP borders to get parts that are kept and parts of partial kept GOPs
• reencode the partially kept GOPs using Avisynth (FFVideoSource/LibLavSource + trim) and x264
• merge the video parts and the audio

No magic involved. New stuttering&co should only appear if one or multiple of the following cases occur:

• source if vfr or interlaced (nothing to do in this case)
• source can't be decoded properly by FFmpegSource/LibAvSource (if this is the case updating the filters might help)
• the encoding settings weren't chosen well (not sure how to choose better settings)
• mkvmerge added some flags which are not compatible with the demuxer used during playback (remuxing with mkvmerge and disabling problematic settings might help)

Cu Selur

[MaverickTse]

I don't see any stutter for both files also.
May be it is a machine issue: either CPU too lame, a fragmented filesystem or slow HDD.

[Freodon]

Don't see any lagging here. Trimmed and original both play fine here. (using MPC-HC and 'DXVA2 (native)' hardware decoding activated)

My decoding is also set to DXVA2 but it doesn't play good for me.

I don't see any stutter for both files also.
May be it is a machine issue: either CPU too lame, a fragmented filesystem or slow HDD.

I've got a quad-core 3.40 GHz CPU and a nice 1TB hard drive so it's definitely not weak hardware's fault. The problem persisted even after copying the video to SSD drive. It also happens in VLC - identical issues at the same parts.

Can people for whom it plays good provide their MPC-HC settings?

[Selur]

might not be just the mpc-hc settings, I'm also using madvr as renderer which might also play into this,...
(btw. there should be plenty of mpc-hc setup guides out there)

[Freodon]

I checked it on another computer - same issues.
The video lags even after delaying the tracks with mkvmerge which doesn't include any encoding/decoding (right?). This is strange.

might not be just the mpc-hc settings, I'm also using madvr as renderer which might also play into this,...
(btw. there should be plenty of mpc-hc setup guides out there)

I tried these settings. Quality of the video is now worse (it looks like upscaled 480p despite being 1080p) and the issues persist.

[Selur]

Yes, changing a delay doesn't do any reencoding, but what it does is change the container, which points to:
"mkvmerge added some flags which are not compatible with the demuxer used during playback (remuxing with mkvmerge and disabling problematic settings might help)"
-> may be https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers helps

[hello_hello]

I tried indexing the video with ffms2. I still think there's something odd happening because if I navigated back and forth a bit (MeGUI's preview) things would get all silly and lots of frames would display as nothing but grey. If I opened the ffms2/Avisynth script with MPC-HC though, it'd play perfect smoothly from start to finish. Better than if MPC-HC opened the video directly. Go figure......

Okay.... so it appears it's also a renderer dependant problem. MPC-HC + MadVR + either CPU or GPU decoding and it plays fine. The Haali renderer displays it with jittery motion whether CPU or GPU decoding is used. Same with EVR.
VMR9 + LAV + CPU decoding = jittery motion.
VMR9 + LAV + CUVID decoding = smooth motion with a little glitch towards the end.
That's just playing the "original" sample, not the "trimmed" sample.

[ndjamena]

The Trimmed version pretty much destroys AVIDemux, but if I run it through my Chapter batch and mux it into a TS file the ts file plays back perfectly. If I then remux the ts back to MKV using MKVMerge the problems reappear. I'll try remuxing it to mkv with FFMPEG.

-Edit- The FFMPEG version works fine. MKVInfo next.

[Selur]

iirc MKV Cutter came with mkvmerge v6.7.0, may be replacing mkvmerge&co with newer versions helps.

[ndjamena]

It doesn't. In the little time I've had to look at the two files, the main difference I can see is that MKVMerge has begun the file with a single video frame, then adds 170ms worth of audio, then enough video frames to make up the difference before beginning with a mass of audio frames again and it just seems to keep doing that, whereas the FFMPEG (LibAV) version seems to order the video and audio frames based solely on their timecodes.

-Edit- You're not using bframes in your encoding settings, the codecs may not be expecting the frames to be out of order in any way.

[Selur]

Decoders should be able to differ between coding and display order.
Mkv Cutter will use b-frames if the source is detected to have them. (either determined by mediainfo or h264_parse)