Recoding .MKV into h264 from Mpeg2 - Chapter marks are not in output files

#1
Have mpeg2 .MKV files that have chapter marks (made using MakeMKV)

Using VideoReDo to recode into h264 versions (still .MKV) that are smaller, but the output files don't have the chapter marks.

I"m sure it is something simple but I can't figure it out.

Thanks for any help.
 

jmc

Active member
#2
Have mpeg2 .MKV files that have chapter marks (made using MakeMKV)

Using VideoReDo to recode into h264 versions (still .MKV) that are smaller, but the output files don't have the chapter marks.

I"m sure it is something simple but I can't figure it out.

Thanks for any help.
There is a setting for VRD to create a "chapter file". Put that file in the MKV with Mkvmerge.
Tools>Options>Chapter marks>Automatically create a Chapter File.

You may need to checkbox "At Scene Markers" also.
 
#3
There is a setting for VRD to create a "chapter file". Put that file in the MKV with Mkvmerge.
Tools>Options>Chapter marks>Automatically create a Chapter File.

You may need to checkbox "At Scene Markers" also.
Thanks - I think I can do what you are saying already, using MKVtoolNix by manually importing the chapter info from the original, then writing it to the h264 version that VRD made (that didn't come out with the chapters intact).

I was hoping that VRD could include the chapter marks automatically in its output files (since the chapters are already marked, and recognized by VRD, in the input files).

So I'm not sure if there is a setting in VRD to transfer any existing chapter marks to the output file, which would save the hassle of going back and doing them all manually as you've outlined (or my procedure, which looks to be about the same).

Thanks!
 

jmc

Active member
#4
Thanks - I think I can do what you are saying already, using MKVtoolNix by manually importing the chapter info from the original, then writing it to the h264 version that VRD made (that didn't come out with the chapters intact).

I was hoping that VRD could include the chapter marks automatically in its output files (since the chapters are already marked, and recognized by VRD, in the input files).

So I'm not sure if there is a setting in VRD to transfer any existing chapter marks to the output file, which would save the hassle of going back and doing them all manually as you've outlined (or my procedure, which looks to be about the same).

Thanks!
I can't duplicate your source files but I did create a MKV.MPG file from a dvd and it showed the chapter marks.
Then I created from that a H264.MKV and it also had chapter marks.
And MKVmerge shows a "Chapters" entry in the listings.

So coming from a dvd to a mkv file VRD works with keeping the chapter marks.

What settings do you have set in the VRD "Chapter Marks" listings.
 
#5
I can't duplicate your source files but I did create a MKV.MPG file from a dvd and it showed the chapter marks.
Then I created from that a H264.MKV and it also had chapter marks.
And MKVmerge shows a "Chapters" entry in the listings.

So coming from a dvd to a mkv file VRD works with keeping the chapter marks.

What settings do you have set in the VRD "Chapter Marks" listings.
Well it seems that creating a SINGLE h264 version of the .MKV in question does in fact keep the chapter marks (as you've nicely also verified - thanks!)

It appears however that when using the "Batch Processor" , with multiple files (even selecting the same custom profile for output as I used on the single file test), the chapter marks do not transfer into the output file.

I looked all through the output profile settings, but couldn't find anything that would seem to change anything WRT chapters in the output files.

Seems that the "Chapter" options in VRD preferences do not apply to batch operations?
 

jmc

Active member
#6
Well it seems that creating a SINGLE h264 version of the .MKV in question does in fact keep the chapter marks (as you've nicely also verified - thanks!)

Seems that the "Chapter" options in VRD preferences do not apply to batch operations?
Yeah, tested and seems "chapter" info is not in the Profile file(exported).
Only seems to function in the main VRD interface output.

Like, you can batch extract the audio but you can not batch
replace the same audio back into the files.

I do hope things like this are fixed in V6 (which should be "soon").
Tho I don't know how "important" batch issues are to users as a whole. major/minor?

For me encoding MPG to x264, Batch will process most and fail on a few.
Recycle the failed few and they usually are recoded with no problem.
The main VRD interface does not have that failure rate at all.

The annoying thing for me is that W7/64 stops VRD with the
error message. W10 displays the error but Batch keeps going.
 
Last edited:

Dan203

Senior Developer
Staff member
#7
Yeah, tested and seems "chapter" info is not in the Profile file(exported).
Only seems to function in the main VRD interface output.

Like, you can batch extract the audio but you can not batch
replace the same audio back into the files.

I do hope things like this are fixed in V6 (which should be "soon").
Tho I don't know how "important" batch issues are to users as a whole. major/minor?

For me encoding MPG to x264, Batch will process most and fail on a few.
Recycle the failed few and they usually are recoded with no problem.
The main VRD interface does not have that failure rate at all.

The annoying thing for me is that W7/64 stops VRD with the
error message. W10 displays the error but Batch keeps going.
Batch is basically a UI wrapper around the COM interface. You could do everything that batch does using a script, or even a 3rd party app like VAP. On occasion when we launch multiple instances of the COM interface successively, which batch does, one of them will crash. That's what's displaying the Windows error, not the batch UI itself, and why batch continues on when this happens. Debugging batch and the COM interface is very difficult as each instance of COM that is launched by batch is launched outside the debugger and has to be attached to manually. Usually just the short amount of time needed to do that is enough to prevent the crash, so issues like this are almost impossible to reproduce in a way that we can diagnose the error. Like you said simply running the file a second time usually works, so it's not even file specific. It's just a weird timing issue and we don't seem to have any reliable way to diagnose or fix it.
 

jmc

Active member
#8
so issues like this are almost impossible to reproduce in a way that we can diagnose the error. Like you said simply running the file a second time usually works, so it's not even file specific. It's just a weird timing issue and we don't seem to have any reliable way to diagnose or fix it.
Good to know, it will bug me less now.

Thanks,
jmc
 
Top