Re-encoding ordered chapters, shows last 1-2 seconds

[zetsu_shoren]

Whenever I re-encode, the output would show the last 1-2 seconds of the previous chapter in fast forward after passing through the chapter point.

What may be the cause of this problem?

[Asmodian]

The chapter is not on a GOP boundary or I frame.

[zetsu_shoren]

How do I find this GOP boundary/I-frame? Is it something I can do with mkvmerge GUI? I found myself here: http://forum.doom9.org/archive/index.php/t-160027.html, but I'm not sure what this "Xin1Generator" exactly is. Is that what I should use?

[Asmodian]

No, I would use a qpfile (http://mewiki.project357.com/wiki/X264_Settings#qpfile) to assign I frames where you want the chapters.

[zetsu_shoren]

What is this "qpfile"? Is it a how do you call it, an option, in x264? Like --crf <number>? Do I have to do the encoding process using --qp all over again? Or is it something I can do to/use on finished files?

[vivan]

You can't do anything about already encoded files.

--qpfile is an encoder option. Basically you're telling encoder that you want frame X to be an I-frame, which will allow you to seek precisely to this frame.
It's not related to --qp in any way, you should use --crf or --bitrate as ratecontrol method.

[zetsu_shoren]

So a sample would be:

--qpfile 34923 I 20 --crf 18 -o <out> <in>

Is that right?

What exactly is the number after "I" for? What should I put it at? Rather, how do I know what to put it at?
For crf, I know for sure that I want to put it at a value that would make the output file have a small enough size with decent quality. For the number after "I" on the other hand - what is being controlled?

If all else fails, how do I adjust the timecodes of the chapters such that it would work normally (transition smoothly, if not perfectly smooth, from one chapter to another)? I tried moving the start of the timecode for the chapter after the linked file's chapter by up to 2 seconds, yet the last few seconds of the chapter before linked file's chapter still persists to show when I'm already far from that part.

I should add that when I take the linked file/s out of the same folder as the main file and play the main file, it transitions smoothly.

[pcordes]

Whenever I re-encode, the output would show the last 1-2 seconds of the previous chapter in fast forward after passing through the chapter point.

What may be the cause of this problem?

Post your command line and full output. My guess is that you're encoding from an MPEG source with weird timestamps, like directly from a .VOB instead of using something that knows about DVD titles.

It seems likely that the output you're seeing is exactly the input that's being fed to x264, so the problem isn't with x264, but with something earlier in the processing chain.

Are you trying to encode STARTING at the beginning of a chapter? Or do you see this at the beginning of every chapter, even if you encode the whole title?

The other replies you got are from people trying to help you make output files that have a seek-point (keyframe) at every chapter boundary, for the benefit of players that can't seek to the previous keyframe and decode (without display) up to the chapter boundary. If that's what your problem was, it wasn't really clear from your first post. (you said "passing through", as in playing through without seeks, not "seeking to", so hopefully that isn't what you meant.)

[kuchikirukia]

Try joining by appending in mkvmerge and then splitting out the chapters again. My guess would be it splits on keyframes.

[zetsu_shoren]

C:\Users\<user>\x264.exe --preset veryslow --crf 18 -o C:\Users\<user>\Desktop\out.mkv.mkv C:\Users\<user>\Desktop\in.mkv

I just mux out the video track.

What I do is I encode the video and audio separately. After I encode both, I mux them all together (encoded video track and audio track) + the subtitles, chapters, and tags if there are (from the original file).

For things that make use of ordered chapters/segment linking, I do the same for the files needed. I just copy the original SUID when muxing the files that are segment linked so I don't have to change the SUID in the chapter of the main file. The problem is, when I use 'pg up' or 'pg dn' to seek/go to the chapter points instantly, they show the segmented files fine. But when you play it normally, like go a few seconds before the chapter point of the end of the segmented file, it would play the last 1-2 seconds of the part before the start of the segmented file in fast motion.

http://i.imgbox.com/qMNhBGXs.png

When the seek thing (I'm not sure what you call it, the thing that moves while the video is playing, the thing above the play button) passes through the chapter point with the yellow circle, it shows the last 1-2 seconds of what's in the yellow square in fast motion. It doesn't show the START of the segmented file, it shows what's before that chapter point. It doesn't show in normal speed. It's like it rushes because the audio of the part after it is already playing, as if to catch up to it. It looks almost as if it lagged and it has to catch up.

Try joining by appending in mkvmerge and then splitting out the chapters again. My guess would be it splits on keyframes.
The whole point of this ordered chapter thing is to make the file sizes smaller. And if I append them, they'd appear at the start and/or the end, not in between the video.

[kuchikirukia]

The whole point of this ordered chapter thing is to make the file sizes smaller. And if I append them, they'd appear at the start and/or the end, not in between the video.

Split by chapter. Append. Split by chapter. Reassemble your ordered chapters.

Don't know if it will work, but when you're having a problem with the way something was assembled it sometimes fixes it to take it apart and reassemble.

[pcordes]

What player are you using? I guess maybe mpv (http://mpv.io/), since you mentioned pgup/down to skip by chapter.

Have you tried others? Different players might behave differently when they see what they think are jumps in pts (presentation timestamps) in the input.

Do you still see the problem with mpv --no-audio? If it's A/V sync when playing through a new file that's the causing a problem, taking audio out of the picture changes how it does timing for video frames.

mkv segments are not a widely-used feature; you might be doing it right but running into bugs. Or doing it in a way that should be valid, but is different from how the player author tested their code. (I haven't used them myself, which is why I can't say anything about how well any specific player supports them.)

[zetsu_shoren]

Split by chapter. Append. Split by chapter. Reassemble your ordered chapters.

Don't know if it will work, but when you're having a problem with the way something was assembled it sometimes fixes it to take it apart and reassemble.
I don't quite get your instructions. Split as in under Global and use split after duration on the timecodes of the chapter points? But the parts are separate. What's there to split?

What player are you using? I guess maybe mpv (http://mpv.io/), since you mentioned pgup/down to skip by chapter.

Have you tried others? Different players might behave differently when they see what they think are jumps in pts (presentation timestamps) in the input.

Do you still see the problem with mpv --no-audio? If it's A/V sync when playing through a new file that's the causing a problem, taking audio out of the picture changes how it does timing for video frames.
I use mpc-hc. Page up and page down are the default keys for seeking straight to chapter points.

I installed VLC and tried it, and it still does the "show-the-last-1-to-2-seconds-of-the-main-video-before-the-start-of-the-segmented-video-in-fast-motion." But this time, instead of 1-2 seconds, it shows in normal speed, but it's greatly reduced to less than 1 second. This time, it just looks like a random frame appears for less than a quarter of a second (sometimes, it doesn't even show at all, depending on how far I click from the chapter point), and the continuation of the main video plays right after (though it's not a random frame. It's definitely a frame from the last second before the segmented file starts).

But it doesn't change the fact that when I replace the video track of my complete output file (with audio, subs and all) with the original video track, the problem of the video lagging behind is still there, as if the problem really is with the I-frames or GOP or whatever that is.

I'd want to show you via webm, but doing so may be a violation of any rule this site has. If not, then I would gladly show it to let you all know what I mean.

[ndjamena]

-cut-

If you want to find out where all the seek point are use MKVInfoGUI (or MKVInfo -v) and look at the cues.

I asked Mosu for the ability to extract the cues using MKVExtract but he said "no" (or at least a longer, more vague equivalent).

-Edit- (Sorry, MakeMKV skips indexing consecutive I-Frames, MKVMerge doesn't. And MakeMKV rounds timecodes differently too.)

[kuchikirukia]

I don't quite get your instructions. Split as in under Global and use split after duration on the timecodes of the chapter points? But the parts are separate. What's there to split?


Then.
Append.
Them.

[ndjamena]

Add the fie to MMG, select "split before chapters" and then type "all" into the "chapter numbers" field.

[zetsu_shoren]

So I did this:
1. add main file to MMG (the one with ordered chapters)
2. go to Global
3. under Splitting, choose "split before chapters" and typed "all" in the "Chapter numbers"
4. muxed, and got 3 output files
5. added file (1) to MMG
6. appended files (2) and (3) in order
7. muxed, and got 1 output file
8. opened the file to check if it works, but instead, saw this:
http://goput.it/5mz6.png

The first circled part is the second segmented file.

As I've posted in an earlier post:
http://i.imgbox.com/qMNhBGXs.png
is what it's supposed to look like, wherein the second segmented file is after the main file, not right after the first.

So what's going on this time? Did I do the right thing?

I placed the output file in a separate folder to see it play without the 2 segmented files and discovered that even without the second segmented file (the one just before the end), it still has the same behaviour of showing the last 1 second in fast forward.

[ndjamena]

Trying splitting again, and this time check the "link files" option.

If that doesn't work, you may have added the files to MMG in the wrong order.

If that doesn't work, there may be a bug in MKVMerge I'll have to check out.

[zetsu_shoren]

Trying splitting again, and this time check the "link files" option.
I clicked on 'link files' this time and did the same process.
The output file is almost double the length of the main file.
http://goput.it/oexs.png
1 = main file
2 = segmented file 1
3 = segmented file 2 (god knows why it was placed here)
4 = continuation of main file, but it doesn't start where it ends at 1
5 = empty part
The two yellow squares are the parts of the segmented files that are empty (god knows why this happened). Basically, they end around just before the squares.
The yellow circle is where the main file ends, and god knows why everything past that point is empty (and why the chapter point is in the empty part).
I'm guessing 4 doesn't start off where 1 ended because of those empty parts in 2 and 3, for whatever reason they were empty.

If that doesn't work, you may have added the files to MMG in the wrong order.
Files? Wait, how many files should I put in MMG?
Just the main file, right? Or do I have to include the 2 segmented files? (In which case, wouldn't make sense)

[ndjamena]

OK then.

[ndjamena]

You'd think getting chapters in the right place would be the easiest thing in the world.

So far I've discovered AVIDemux adds a decoding delay to all it's time-codes, which isn't so bad for MPEG2 but when you're dealing with AVC it can become a nightmare. FFVideoSource can get the frame rate wrong occasionally, plus when a stream starts with orphaned b-frames it will skip them and set zero at the first I-frame then add however many frames it skipped as black frames at the end. SolveigMM displays time-codes in frames rather than milliseconds, it doesn't display frame type and only skips to key frames, which I assume excludes seekable non-IDR I frames. MakeMKV, MKVMerge and Eac3to, the only three programs I've actually checked, each seem to have their own ideas on which frames should be added to the cues and are therefore seekable, thankfully I remux all my files with MKVMerge so at least that's predictable. I know a lot of people don't.

My WDTV will only skip to seek points, I figured that out the hard way and now I'm trying to make sure the files that are intended to be played on it have the chapters in the right place.

The other files meant for re-encoding are even more difficult, I need to put the chapters on exactly the right frame so that when it comes time to encode them my batch scripts can extract the chapters and build a QP file from them to pass to x264 to make sure it puts IDR-frames there. I have no idea how many of the files I've processed so far wound up with chapters in the right spots, I'll have to go back and check when I finally figure out how to get all this working.