Why does muxing a video stream into a MKV file change that stream?

[4L7zHhiyQO3Thui6]

Dear all,

I'm new to video conversion and am trying to learn a little bit about it. I just did a basic test the outcome of which made me scratch my head:

I have an .m2ts file which contains one video stream and multiple audio and subtitle streams. As a first test, I have demuxed all streams, first using tsMuxeR, then eac3to. All audio and video streams which these both tools extracted were identical (compared via "fc /b").

Then I loaded the same source file into mkvtoolnix GUI, let it produce an .mkv file from it, and used gMKVExtractGUI to extract all streams from that .mkv file. To my surprise, I noticed that the video stream was different to the video streams I had obtained in the first test described above. I was slightly shorter - not only did the contents differ, but also the length.

I decided to investigate the subject further and again let mkvtoolnix GUI produce (mux) another .mkv file, this time using the single streams I had obtained from tsMuxeR in my first test as input. Then I demuxed that new file, again using gMKVExtractGUI. The outcome was the same: The video stream which was extracted from the new .mkv file was different from the original one.

In other words, mkvtoolnix seems to alter video streams (at least) when muxing them into an .mkv file. What do we lose by that alteration, and how can we prevent that?

Thank you very much in advance!

[DB83]

See this:


https://forum.videohelp.com/threads/398541-MKVToolNix-v49-0-0-video-stream-size-is-sma...A5%EF%BC%A4%5D

[LigH.de]

One reason I vaguely remember: Video streams for specific purposes (for broadcast or for reading from slower media into decoders with a limited decoding buffer) need to stay above a minimal bitrate.

In case of DVB, multiplexing several programmes in a bouquet would cause issues if the bitrates of the contained programmes vary too much. Therefore they often get stuffed with fillers.

In case of Blu-ray and DVD, a too low bitrate would cause a "buffer overflow" by the drive reading more than one GOP into the decoding buffer from the optical disc spinning with a constant speed; and seeking back is time consuming.

All that doesn't matter when reading files from a fast harddisk with quick seeking. Thus, content can be stored without any waste in an MKV container.

[pYPsfVARqM3nH7hD]

@DB83

Thank you very much for the link! It perfectly answers the question, and I wonder why I didn't find it. I originally wanted to use MKV as long-term file format, but obviously mkvmerge is throwing away too much stuff, so I'll stick with M2TS. What a pity that it can't handle chapters ...

@LigH.de

Thank you very much for answer, which basically confirms what the page behind the line @DB83 gave says (or the other way around ).

[DB83]

For future reference:


After you start a topic, check your post and there will be Similar Threads below the post. That is how I was able to assist


BTW try makemkv as an alternative to mkvmerge

[jagabo]

obviously mkvmerge is throwing away too much stuff

It's only throwing away stuff that's useless in an MKV file. Stuff that doesn't contribute to the audio or video quality, only to the file size.

[pYPsfVARqM3nH7hD]

Thank you very much for your tips again!

Now I've tried makemkv as an alternative to mkvmerge and let it produce an MKV file, then extracted all streams from this MKV file. Interestingly, this time the video stream was larger than the original one. MakeMKV also shows the wrong runtime (but only one second too low given a total runtime of over an hour).

I guess I'll give up on MKV and just stick with M2TS. Neither do I like data removed from the original video stream, nor do I like data added to it. This pertains to seemingly unnecessary data as well. I'd like to be able to go forth and back between the various container formats without problems. Given that, it would be bad if I had data which a container format needs removed from the stream solely because I earlier had that stream put into another container format which considered that data not necessary.

As for the chapters, I'll simply keep them as an accompanying file in text format along with the M2TS and wait for tools which can make a truly lossless MKV from that.

[DB83]

It may be useful if we were analyse these streams before and after remux.


The tool required is mediainfo. In 'text mode' we require a report of the original streams demuxed from the m2ts file. A report from the mkv's as created and reports from the streams demuxed.


Also useful would be a short extract, if possible, of the original demuxed video (from the m2ts)


But methinks you over-react. If the new runtime is only a second difference over one hour that could be a false report or a rounding.

[jagabo]

I doubt MediaInfo will show enough detail. An ffprobe report probably will. Transport streams may include things like leading partial GOP or trailing B-frames that cannot be rendered because their reference frames are missing. Some programs will report those as part of the video, and some won't. For example, with a leading partial GOP players might show a blank screen at the start and only play the audio until the first I-frame. Or they may seek ahead to the first I frame and start playing there.

[DB83]

Fairy nuff.


Still think the OP is over-reacting and he wants subs so mkv is the way to go.

[pYPsfVARqM3nH7hD]

@DB83 Thanks again for all your help.

I'd like to clarify that mentioning the "wrong" runtime was just meant as an additional note and not as an actual problem. I had looked into various files, demuxed and original ones, using various media information tools, and already had noticed that they are showing different runtime, the difference usually being only a few seconds. Actually, I rather found it funny instead of problematic that the stream size had increased, but the runtime had decreased.

The reason why I have given up on MKV is that different MKV tools make different changes to the original streams when multiplexing them into the MKV file. This behavior seems somehow random and undefined to me, and I don't want such alteration, especially after having read the explanations you have linked in one of the previous posts. As I understand these explanations, the streams in the MKV may have data removed which would be necessary should I ever decide to convert the MKV back to M2TS, or should I ever decide to edit (re-author) the files with certain software tools.

The main advantage of MKV IMHO is that it can handle chapters, while M2TS can't. Since I'd like to preserve the chapters, but don't want to use MKV, I had to think about it for a while. Then I noticed two things: While M2TS indeed can't store chapter data, Blu-Ray discs or course can; the chapter data is stored in the playlist files there. Secondly, tsMuxeR can not only mux and demux, but can also produce Blu-Ray ISO files; it turned out that there were correct playlist files with chapter information in those ISOs. Great!

Now I believe I have a satisfying solution for my needs:

1) Using tsMuxeR, demux all streams of interest from the original BD folder (after having loaded the correct playlist file from that folder in tsMuxeR).

2) Using eac3to, do the same. eac3to will create the same number of streams as tsMuxeR, plus a text file with chapter information.

3) First test: Compare each stream which tsMuxeR has extracted to the corresponding stream eac3to has extracted, of course in binary mode. If there is any difference, identify and correct the problem before proceeding (didn't happen yet).

4) Using tsMuxeR, again load the correct playlist file, select the streams of interest, and this time let it create a BD ISO file.

5) Mount this ISO file, e.g. to drive letter G:

6) Using tsMuxeR, load the appropriate playlist file from drive G:, and let it demux all streams. Using eac3to, do the same.

7) Second test: Compare each stream tsMuxeR has produced in step 6) to the corresponding stream eac3to has produced in step 6). They should be identical. If there is any difference, identify and correct the problem (didn't happen yet).

8) Third test: Compare each stream tsMuxeR has produced in step 6) to the corresponding stream tsMuxeR has produced in step 1). Likewise, compare the chapter information file eac3to has produced in step 6) to that one eac3to has produced in step 2). All streams and the chapter information file should be identical. If there is any difference, identify and correct the problem (didn't happen yet).

That way, you can be sure that the streams in the ISO are identical to the streams on the original BD. The whole process sounds like a lot of effort, but in fact, it is a matter of minutes given a fast PC. For me, it's really worth it. The result is one file (the ISO) which can be played by most software players, which contains all streams of interest in unaltered form, and which contains the chapter information in a form which is also recognized by most players.

I haven't understood yet what you mean by "he wants subs so mkv is the way to go". I have the subs as part of the M2TS file(s) in the ISO, I know that they are identical to the original (because they are just streams which have undergone the tests described above), and most players allow to activate or inactivate them and show them just as you would expect. Notably, I have conducted thorough tests with VLC, which behaved completely correctly. Hence, it seems we can have the subs even without MKV

Thanks again!

[DB83]

My bad.


Your reference was to chapters. Not subs.


Still think, to coin a phrase, you are using a sledge-hammer to crack a nut. But at the end of the day it is your time not mine.


Even so, if you care to read the forum, most people will simply use makemkv to create a playable container format from the original source without additional demuxing etc. If they had noticed a critical timing difference between the original disk and the mkv I would have expected some concern. I do not recall ever reading so.

[4L7zHhiyQO3Thui6]

Thank you very much again!

Yes, I am kind of paranoid regarding this. However, I am doing this not because I am concerned that something could miss when I just watch that MKV file. Of course, during my tests I have verified that the MKV file contained everything (subtitles, streams etc.) and that there were no other problems (synchronization etc.). As expected, watching this MKV worked like a charm. I definitely could watch the the MKV exactly like I could watch it from the original BD.

You are also completely right that people would post in forums a lot if they had problems with watching MKV files; the format is quite prevalent.

However, I actually have another concern: Should I ever need to convert this MKV file to another format (I guess that this is not completely unrealistic, given how fast formats and player capabilities change), or even re-author it, I would be in a bad position if the streams in the MKV file would not contain the full data the original streams did contain. The fear that I can't convert the MKV back to another (future) format without problems (because the streams in the MKV already have lost data) is the only reason for taking the effort.

For example, the link you gave in a previous post states that professionals avoid MKV during production because the streams in it lack some information which is needed by professional software. Neither am I a professional, nor do I possess such software, nor do I plan to do so. But these statements show that the data which has been stripped from the streams in the MKV may be important as soon as we want more than just watch the MKV.

[DB83]

I know I, nor I guess anyone else, will convince you. But consider this. (The 'proof' will be in the reports that were requested)


M2TS and MKV are NOT formats. They are the containers for the actual video and audio streams - the beans in the actual tin. In the case of blu-ray, the actual video stream could be mpeg-2, AVC or VC-1. All container formats require some overhead for them to function.


That initial 'demux' could even create another container format simply known as TS or 'Transport Stream' which has it's own overhead.


All overheads vary which will result in varying file sizes. But the underlying video is still the same.


So your argument about a future ACTUAL format is suspect since the theoretical conversion will still 'eat the beans' and 'not the tin'

[4L7zHhiyQO3Thui6]

I highly appreciate your expertise and your help, but in this case, I can't agree (probably I haven't made my concern clear enough). The underlying video is not the same. This is my only concern!

I know that MKV and M2TS are actually not video / audio formats, but container formats. Actually, this exactly is the cause of my problem! When I have a raw video stream (e.g. h264), and I embed it in a container like MKV, I expect that I exactly get that stream back when I extract it again from the container.

I perfectly understand that different container formats have different file sizes even with identical streams in them, and I don't care about that. But the crucial point is that embedding a stream into an MKV container (that is, mux that stream into an MKV file) obviously changes that stream itself. That problem does not seem to exist with M2TS containers.

And to be precise, I am quite sure that this is not a problem of the MKV container format itself. It is a problem of the tools which we use to create the MKV containers. The tests I have done, partly according to your proposition, have clearly shown it: While MakeMKV increased the size of the video stream in the MKV (that is, the stream was greater in size than its original after I had extracted it from the MKV again), mkvtoolnix / mkvmerge decreased the size of the very same video stream.

In summary, I know the difference between a container (format) and a stream (format). My concern is not about the whole container having a different size than the "original". My concern is that the streams themselves which are embedded in the MKV have data removed or added by the tools which usually are used to create the MKV.

IMHO, each toolchain which processes a certain container format must make sure the following (doesn't need to be the default, but must be possible): If we have some streams, notably a h264 video stream, and we mux these streams into a container, notably MKV, and we then demux the container again and extract all streams, each of the extracted streams must be bitwise identical to the corresponding original stream. This is not the case with MKV or the MKV toolchains, respectively.

Once again, I know that I can't expect an M2TS file with some streams to have the same size as an MKV, TS or whatever container file with the same streams, because different container formats will of course need different file sizes, even if they contain the same streams. But I definitely expect that muxing a stream into a container does not alter the data of that stream itself in any way. But this is exactly what the usual MKV toolchains do.

I can very well imagine that mkvmerge and its friends provide command line parameters which make them disable "optimizations" and prevent them from removing or adding data to the streams. However, I haven't seen respective options in the GUIs yet, and unfortunately, I can't study the command line parameter documentation for each tool right now.

Until I can do this and until I am able to understand those documentations, I'll stick with the solution outlined in my previous post, being relaxed and knowing that I can create an MKV or whatever other container from the ISO whenever I feel like it, because I have the original raw stream in unaltered form in that ISO.

To be honest, I would prefer MKV over M2TS, but as long as creating MKV means removing data from the h264 stream in it, it is not an option for me personally. As soon as I figure out (or somebody tells me) how to mux an MKV without altering the underlying streams themselves in any way, I'll start converting the ISOs to MKV.