MKVToolNix v83.0 released

[markfilipak]

Originally Posted by videoh

Use copy /b in a cmd window. You don't need mkvmerge for this.

copy /b a.vob + b.vob + c.vob combined.vob

https://docs.microsoft.com/en-us/win...-commands/copy

The result has PTS errors and the ffmpeg transcode malfunctions.

[Mosu]

mkvmerge can only create Matroska files, not MPEG program streams (that's what VOBs are).

[videoh]

Originally Posted by markfilipak

The result has PTS errors and the ffmpeg transcode malfunctions.

Then you didn't do it right.

Maybe try knitting? Or miniature golf?

[markfilipak]

Originally Posted by Mosu

mkvmerge can only create Matroska files, not MPEG program streams (that's what VOBs are).

An MKV is fine. Actually, MKV is preferred. I'm sorry if I implied otherwise.

Do you have any guidance regarding the combing? I don't understand how combing can happen if mkvmerge is solely performing remuxing, but then, I don't understand a lot of things. ;-)

PS: I checked things and ...you know what? I did name the files '.VOB'. But you know what? I could have named them '.EXE'. It doesn't matter to MKV. It plays anything that it finds contains a video stream.

[markfilipak]

Originally Posted by videoh

Then you didn't do it right.

You don't understand. ffmpeg has a bug that mishandles gaps in PTSs and/or DTSs that aren't monotonic. 'copy /b' doesn't fix that, of course. mkvmerge (and HandBrake, too) do fix the problem somehow. Remuxing seems to work magic sometimes. Unfortunately, mkvmerge appears to create a different problem: Combing. The combing is what I seek to avoid. I would use HandBrake, but HandBrake insists on transcoding and I don't want transcoding.

I hope it's clear now.

Maybe try knitting? Or miniature golf?

What? Do you want me to play with myself?

[Mosu]

Originally Posted by markfilipak

Do you have any guidance regarding the combing? I don't understand how combing can happen if mkvmerge is solely performing remuxing, but then, I don't understand a lot of things. ;-)

I don't support MPEG program stream/MPEG elementary stream handling in mkvmerge anymore. That code was contributed by someone else who hasn't been around for more than a decade now, and I have no interest in fixing issues in that code.

As I've never dealt with telecined content I cannot give you any advice whatsoever.

Originally Posted by markfilipak

PS: I checked things and ...you know what? I did name the files '.VOB'. But you know what? I could have named them '.EXE'. It doesn't matter to MKV. It plays anything that it finds contains a video stream.

mkvmerge generally determines the file type by the content. There are certain cases where it uses the file's extensions in situations where content-based detection is ambiguous (e.g. not detecting an MPEG transport stream with H.264 inside as an H.264 elementary stream if the file's extension is ".ts" or ".m2ts").

[videoh]

Originally Posted by markfilipak

I hope it's clear now.

Nah. You asked how to just concatenate VOB files and I told you. You wrote:

It's important that OUT.VOB be simply concatenated

I never claimed it would fix any ffmpeg problems. Best bet for you is to post a sample source stream(s) and tell us how to duplicate your issue. Don't make all kinds of assumptions and then start blaming people if they don't necessarily accept them.

What? Do you want me to play with myself?

Divine energy will flow through you, if you allow it.

[markfilipak]

Originally Posted by videoh

I never claimed it would fix any ffmpeg problems.

There is no blame to assign, my friend. There is no blame at all.

What I have is VOBs that provoke time stamp mishandling by ffmpeg. I have found that remuxing via mkvmerge fixes those problems and that ffmpeg then transcodes the remuxed videos correctly. So, of course, I want to use mkvmerge as a preprocessor in scripts.

The fix should logically be limited to fixing the time stamps in elemental streams, but mkvmerge's output appears to be more than remuxed, it appears to be transcoded because the frames are no longer pristine, they're combed. I don't know what to make of that and I don't have the tools that would reveal what's actually happening in raw frames.

So, I come here to find out becasue you folks are informed. If I'm making assumptions, I appologize. It's because I'm somewhat ignorant. If you have any suggestions, I'd be very grateful.

Stay safe, stay healthy,
Mark.

[videoh]

Originally Posted by markfilipak

If you have any suggestions, I'd be very grateful.

As I said, best bet for you is to post a sample source stream(s) and tell us exactly how to duplicate your issue. We don't have magic wands or clairvoyance.

mkvmerge is not transcoding.

[sneaker_ger]

As you say mkvmerge is not re-encoding. If it was combed after using mkvmerge then if was also combed before. Probably your player activated de-interlacing/IVTC for the VOB file without you knowing thus appearing as if it was progressive. After remuxing to mkv your player isn't detecting this anymore.

[videoh]

Quite right, sneaker_ger. A small sample cut from the VOB would allow us to verify that. OP should cut a section that comes out combed in the MKV. Set range in DGIndex and then Save Project and Demux Video. Post a link to the resulting M2V file.

[AYColumbia]

Originally Posted by stax76

Post command line, output and media info.

https://mkvtoolnix.download/doc/mkvm...rge.exit_codes

Originally Posted by Mosu

mkvmerge should always exit with 2 in case of errors and 1 in case of warnings. As stax76 said, please post the command line used as well as the full output generated by mkvmerge.

Thanks I'll provide that info the next time it happens. I had not saved the prior info and I should have provided it. My bad.

[Mosu]

Hey everyone!

It's May. It's time. Time for another MKVToolNix release.

In v45 I accidentally introduced two bugs that users stumbled across almost immediately, and I nearly released a bug fix release only a few days after the v45 release, but ultimately decided against it. Therefore I suggest you upgrade to v46 now, especially if you're dealing with H.265/HEVC video in MP4 files.

Nothing's changed for package managers.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS since the previous release:

Version 46.0.0 "No Deeper Escape" 2020-05-01
New features and enhancements

• mkvmerge: when splitting, the placeholder "%c" can be used in the destination file name. It'll be replaced by the name of the first chapter in the file. Implements #2791.
• mkvmerge: when reading MPLS playlists mkvmerge will include a tag named "SOURCE_ID" in the track's statistics tags that conveys the fact that the source was a Blu-ray and what the track's ID was in the source container. When reading Matroska file existing "SOURCE_ID" tags will be kept. The format used is the same format MakeMKV uses. Implements #2774.
• mkvmerge: for audio-only files mkvmerge will now write a cue entry every 500ms instead of every 2s.
• MKVToolNix GUI: job actions: split up the option "execute when the job finishes successfully or with warnings" into two separate options: "…when finishes successfully" and "…when exits with warnings". Implements #2798.

Bug fixes

• mkvmerge: Matroska reader: when regenerating UIDs for chapters mkvmerge will now fix referencing tag chapter UID targets to have the same values. Fixes #2804.
• mkvmerge: MP4 reader: fixed a crash that could potentially happen while trying to identify H.265/HEVC tracks.
• mkvmerge: MP4 reader: when reading H.265/HEVC tracks without a frame offset table ("ctts" atom) present, mkvmerge did not parse the "hevcC" structure correctly in certain cases, causing no video frames to be output at all or the output not being playable. This fixes #2782, a bug introduced in v45.
• mkvmerge: MPLS handling/MPEG TS reader: timestamp restrictions as given in an MPLS file were only honored for the first play item, not for subsequent play items. For those play items the whole referenced file was always copied. Part of the fix of #2789.
• mkvmerge: MPLS handling/MPEG TS reader: under certain circumstances mkvmerge copied one frame too many before switching to the next play item. Part of the fix of #2789.
• mkvmerge: for audio-only files cues will only be created for I frames (important for e.g. TrueHD where decoding can only start on a sync frame). Fixes #2790.
• MKVToolNix GUI: fixed a crash that happened when closing the preferences after having closed at least one multiplexer tab. Fixes #2785.
• MKVToolNix GUI: macOS: changed the default of the "elide tab header labels" feature introduced in v45 from "no" to "yes" to mirror how versions before v45 behaved on macOS.

Have fun!

[MrVideo]

Originally Posted by markfilipak

Tbut mkvmerge's output appears to be more than remuxed, it appears to be transcoded because the frames are no longer pristine, they're combed.

I'm jumping in here a little late, so excuse me this has been discussed with you in previous posts. But, do you understand what a combed video frame is?

As noted, MKVmerge does not do any recoding/transcoding, it only copies source material.

A combed video frame is a result of two different fields in a 480i, 576i or 1080i video file. This can be because the video was shot with a 480i/576i/1080i video camera, or a 23.976 progressive video source was telecined to 29.97, where two video frames, out of five, can have combed video frames.

For a true video source, you have to live with the combing, or recode using a deinterlacing function, which combines the two fields into a single progressive frame. That ultimately results in a loss of time space. By this I mean if the two fields have rapid motion, that motion appears to move at a pace of 59.94 images a second. But, when you deinterlace, the time is now has a motion of 29.97 images a second, or time/space is now 1/2 of what it originally was. I personally prefer to keep the full motion intact. The process of deinterlacing can also reduce the vertical resolution.

If the 29.97 interlaced video is a result of the telecine process to convert 23.976 source material to 29.97, the IVTC (inverse telecine) process can restore the interlaced 29.97 video back to 23.976 progressive video, removing the combing effect.

If you already knew all this... then NEVERMIND!

[markfilipak]

Originally Posted by MrVideo

I'm jumping in here a little late, so excuse me this has been discussed with you in previous posts. But, do you understand what a combed video frame is?!

"progressive video source [that] was telecined"
A combed frame from telecine mixes 2 half-pictures that are separated in time by 1/24 second, and as you cited, a 23-telecine has 2 of them in every 5 frames (40%), and they are back-to-back: the 3rd & 4th frames.

"shot with a 480i/576i/1080i video camera"
Each combed frame in that case results in fields separated in time by 1/60 second -- less than half the combing -- but every frame is combed (100%).

Both are awful.

As for my project, the only thing I can figure is that I must have somhow grabbed a hard telecined video to use for testing. That seems a year ago, though it was just yesterday or the day before, and I've since used many test videos and discarded some. I've progressed past that. I'm still using mkvmerge and in fact am using it for 2 of the 4 processing steps, but I'm using it in a slightly different way. In other words, I got no problems with mkvmerge. Not any more.

[MrVideo]

Originally Posted by markfilipak

""shot with a 480i/576i/1080i video camera"
Each combed frame in that case results in fields separated in time by 1/60 second -- less than half the combing -- but every frame is combed (100%).

Yes and no. If the two fields have an imperceptible time difference, it will appear as though the frame was a progressive frame. There will be no combing effect visible.

Just think, before digital TV came along, no one really complained about interlaced video, no matter the source. We've become spoiled.

[darksen]

Is there any way to make MKVToolNix use a separate path to create the files and then move the finished files to the destination? I mean, a temp working folder?
This to prevent fragmentation as much as possible as it is impossible for MKVToolNix to pre-allocate the space beforehand.

Also, what does --engage-cow do?

Originally Posted by Mosu

MKVToolNix GUI: job actions: split up the option "execute when the job finishes successfully or with warnings" into two separate options: "…when finishes successfully" and "…when exits with warnings". Implements #2798.

Thank you! I was going to request this.

[Mosu]

Originally Posted by darksen

Is there any way to make MKVToolNix use a separate path to create the files and then move the finished files to the destination? I mean, a temp working folder?

Nope. No plans for it either.

Originally Posted by darksen

Also, what does --engage-cow do?

It's "--engage cow", and just give it a try and you'll see.

[Selur]

Seeing that with exhale there's a xHE-AAC encoder out there I was wondering if there are plans to support xHE-AAC in mkvtoolnix?

[Mosu]

There are no plans so far. I don't know what work (if any) would be required.