Video stutters after trimming

[Freodon]

I converted the trimmed sample video to mp4 using MkvtoMp4. Now instead of lagging at the beginning, it shows me what can be seen in the first attachment (very small picture in the upper left corner) and then after a second or so, it shows me what you see in the second attachment - but at this point taking a snapshot produces a full-size non-glitched frame screenshot.
I'll try re-encoding and see if it helps.

[ndjamena]

Try passing your files through TSMuxer, as far as I can tell it seems to have fixed the problem, but I only have the one file to work with.

This is what it added to the header:

Nal length 21 start code 4 bytes 
 ref 0 type 6 SEI
   payload_type: 0 buffering_period
   payload_size: 13
    0x86 0x85 0xec 0x0 0x0 0x0 0x6 0x85
    0xec 0x0 0x0 0x0 0x40
    seq_parameter_set_id: 0
    initial_cpb_removal_delay[0]: 855000
    initial_cpb_removal_delay_offset[0]: 0
    initial_cpb_removal_delay[0]: 855000
    initial_cpb_removal_delay_offset[0]: 0
Nal length 14 start code 4 bytes 
 ref 0 type 6 SEI
   payload_type: 1 pic_timing
   payload_size: 6 0x0 0x0 0x0 0x0 0x0 0x2
    cpb_removal_delay: 0
    dpb_output_delay: 2

[Freodon]

Can you tell me where should I put this header info?

[ndjamena]

TSMuxer is a program like MKVMerge, except it transfers the video/audio into a .ts file rather than an MKV. I remuxed your video with it, and when it was done I could remux that ts stream back into an mkv, then use AVIDemux to remux that mkv into an avi, then use MKVMerge to remux that avi back into an mkv and the resulting file came out perfectly, which I couldn't do with your original file. According to h264_parse, the difference between the two streams is what I posted above, as far as I can tell, the entries increase the buffer (or maximum bitrate) and set something about the timing of the frames.

H264 bitstream changed: insert nal unit delimiters
H264 bitstream changed: insert pict timing and buffering period SEI units

It may just be co-incidence, but it's worth a try. Remux the original files to ts then back to MKV, then try cutting them again, see if your problem is fixed.

[ndjamena]

I just tried MKVCutter on it, the thing's screwed. I guess you have no choice but to re-encode.

[Freodon]

Okay, so what software do you recommend to re-encode with as little quality loss as possible?

[ndjamena]

They all use X264 so they're all pretty much the same. The quality will be whatever you choose it to be. I was thinking you could maybe do a two-pass to match the bitrate you already have, just to gloss over the fact that you had to re-encode the thing at all. But really, making sure the decoder decodes the thing properly in the first place is what's important. I'm not entirely sure what's wrong with the thing, assuming there is something wrong with it, and there might be glitches in the playback that you simply hadn't noticed.

I'm still trying to make sure it is actually the video at fault

Attempt to create a cut version using the working files MKVCutter left behind with FFMPEG instead of MKVMerge:

[h264 @ 0000000006e5e020] reference count 3 overflow
[h264 @ 0000000006e5e020] reference count overflow
[h264 @ 0000000006e5e020] decode_slice_header error
[h264 @ 0000000006e5e020] mmco: unref short failure
[h264 @ 0000000006e5e020] number of reference frames (1+4) exceeds max (4; probably corrupt input), discarding one

Trying to mux the h264 stream from "original.mkv" using FFMPEG after extracting it with MKVExtract:

[matroska @ 00000000050bb020] Can't write packet with unknown timestampav_interleaved_write_frame(): Invalid argument

Attempting to remux "Original.mkv" into an MP4 using FFMPEG

[h264 @ 0000000004a8e4e0] Delayed frames seen. Reenabling low delay requires a codec flush.

I guess Handbrake would do, but really it's whatever you prefer.

[Freodon]

I re-encoded using Handbrake. Output file's size was considerably lower than the original, but the difference in quality is extremely negligible (see attachments - first pic is old, second is new). After that, I trimmed it with MkvCutter and finally - there are no problems with the playback. Thanks for the help!

[ndjamena]

Animation tend to compress well. I THINK I can see a difference in that little bit of green poking up over the fence under the ponies chin, but since JPG uses compression too it may have exaggerated the problem. I can definitely see a difference in the file size though, it looks as though the new version is easier to compress. You can generally do a hell of a lot of damage to cell animation without it being noticeable during playback, most of the time it just looks like an alternate form of artistic style.

[Freodon]

Weird. On non-enlarged picture that green thing difference is visible, but not on the actual size image.

[ndjamena]

Huh? Where's the actual size one if not there? If I expand those pictures by clicking on one, start up the windows magnifier and switch between the two the difference is even more profound.

[Freodon]

Unfortunately, for some videos index gets slightly broken at random parts after re-encoding with Handbrake (seeking always returns the same time for a ~5 second fragment, but it should be at least 2 seconds accurate). Is it really so hard to simply cut out a small part from a video? I also stumbled upon .edl files which could be an alternate non-intrusive solution, but their compatibility seems limited. Can they be merged into an .mkv container?

[ndjamena]

The seeking problem would be caused by whatever you're using to decode the video only seeking to key frames. By default x264 uses a maximum keyint of 240, which is about 10 seconds apart. If you want 2 seconds you could try adding -keyint 48 to Handbrakes x264 command line field.

It's not hard to cut a section from a video, it's hard dealing with corrupted streams. There's a difference.

???

An MKV has an index and a chapter system, I'm not sure why you'd need an edl or what problem you're trying to solve in mentioning them.

[Freodon]

Right, these are just keyframes far away from each other.

[Freodon]

Small trivia: SolveigMM Video Splitter managed to cut out the logo without creating a stutter, and output file size is the same as original. So it seems MkvCutter is a bit unperfected.

[Selur]

So it seems MkvCutter is a bit unperfected.

No surprise there unlike other tools, MkvCutter doesn't have tons of routines to handle imperfect sources,.. (I know why I labeld it APLHA)

[ndjamena]

FFMPEG couldn't handle the "original.mkv" you posted. If you want to continue experimenting you could try remuxing your new files into an MP4 with it to see what happens. Who knows, maybe Solveig managed to emplace a fix.

[Freodon]

The seeking problem would be caused by whatever you're using to decode the video only seeking to key frames. By default x264 uses a maximum keyint of 240, which is about 10 seconds apart. If you want 2 seconds you could try adding -keyint 48 to Handbrakes x264 command line field.
Can you tell me where exactly is that command field? I tried adding it to "extra options" in video tab but it didn't work.

An MKV has an index and a chapter system, I'm not sure why you'd need an edl or what problem you're trying to solve in mentioning them.
Yeah, but can it be used to automatically skip part of a video as if it was never there in the first place? (AFAIK this is what .edl files are able to do)

...

[ndjamena]

Handbrake has changed a hell of a lot since I used to use it, they used to have an advanced tab where you could modify a lot of the x264 options using sliders, drop down boxes and text boxes. I think they removed them because people seemed to think there were magical settings that would make their encodes exponentially better. I'm not really sure how Handbrake works now days. Is this what you added to the extras?

keyint=24

MKVs have ordered chapters that can jump around the file anyway you like, it will even repeat sections if you tell it to. It can also select exactly which tracks to play while inside a chapter, you can also add multiple sets of chapters if one set isn't enough for you. IT'S NOT FINISHED YET, so there's more to come.

Other than that, you can actually add any kind of edl file you like to an MKV as an attachment. I've been thinking of adding all the AVS scripts I use in processing an encode as attachments, just so I can have some reference as to what worked, what didn't and where I've been.

[Freodon]

Alright, what I did was:
1. Re-encode the .mkv video with Handbrake with keyint=24 option so that seeking is more accurate.
2. Trim it with MkvCutter.
3. Convert it to .mp4 using MkvtoMp4 which somehow removed the stutters that were sometimes created after trimming with MkvCutter and also made the file format more universal.

I am yet to find a problem in any of the processed videos, so it all seems to have worked.

@down

Which My Little Pony is that? "Friendship is Magic"?

Yup. Unfortunately they decided to have a cold opening before the theme song instead of having the theme before anything else...

[ndjamena]

You might consider keeping backups of the original files. It's still not clear what went wrong and it's possible, if unlikely, there's bugs in MKVMerge/FFMPEG.

I think if there's problems in the stream data MKVMerge will only realise as it tries to cut it, otherwise it just blindly copies the frame order from the original file.

Here's somewhat of an explanation:

https://trac.bunkus.org/ticket/918

As far as I'm aware, FFMPEG and MKVMerge have a different code base, so it's doubtful, but not impossible, that they contain the same or similar bugs. I think AVIDemux uses FFMPEG code. Solveig either has doesn't have that bug, has better error handling routines or simply copied the order from the original MKV without checking.

Either way, your video is poison and your new files are the best remedy for now...

Which My Little Pony is that? "Friendship is Magic"?

[Freodon]

In at least one file, I found a slight stutter just before the trimmed fragment. If only Handbrake could encode specific fragments (from frame to frame) so that I don't have to use MkvCutter separately, maybe using so much software on one file makes it more and more broken...

I'll try encoding cold opening and main part separately and later appending with mkvmerge.

[Freodon]

Now I see that if I select the time near the trimmed fragment, it freezes for longer than normally, shows vertical yellow bars for a split second and then loads the selected fragment. In the other video with the slight stutter near just before the cut fragment, going frame-by-frame gives strange results - it repeats some frames out of order, it shows strange artifacts in the upper part of the screen (it looks like small black squares with fuzzy colorful pixels inside), and going frame-by-frame in this area gives slightly different frames each time.

[ndjamena]

Handbrake CAN start and end an encode from any position in the file, there's a drop-down box that displays the word "chapters" up top, click it and you'll see "seconds" and "frame" options.

If you re-encoded the file with handbrake and it's still showing problems then it's not being caused by the video, since handbrake would have created a brand new video (unless the problems are hardcoded into the pixels and appear identical during playback on all devices). What about the audio? Did you pass that through or did you re-encode that too?

[Freodon]

Unfortunately, Handbrake won't do the job for me, see here: https://forum.handbrake.fr/viewtopic.php?f=11&t=31186&p=143569#p143569
My reply to them was a bit rude, I know, but this whole problem is starting to drive me nuts.
If it worked correctly, I could just re-encode up to the unwanted fragment, then from the unwanted fragment to the end, and then append the second file to the first one with mkvmerge.

[ndjamena]

Add chapters with mmg?

[Freodon]

It shows me this error when I try to add chapters.
Am I supposed to write a text file containing chapter data and add it to the container? If so, why does the chapter editor allow making new chapters in a file with no chapters?

[ndjamena]

[Chapter Editor | Save] OR [Chapter Editor | Save to Matroska File]

NOT [START MUXING]!!!

[Freodon]

Okay, maybe try this: if anyone manages to re-encode the following sample with no freezing, seeking nor graphical errors, you've done the impossible.

[smrpix]

Like this?