Video differs depending on container

[dt5]

I hope that this is the right place to ask this question.

I am a little bit confused. I have a raw h264-file.
I used tsmuxer GUI to create a m2ts.
I used tsmuxer GUI to create a ts.
I used mkvmerge GUI to create a mkv.

When I exctract now the video track from the ts, m2ts (using tsmuxer) and mkv (using mkvextract) file and compare with the source file then they all 4 differ.

What is the reason for it?
I thought that only the container is different.

When i use the 264-file which was extracted from the m2ts and create a new m2ts with tsmuxer then the 2 m2ts are different. This is fine - the container may differ. But when i extract the video file from that new conatiner then i get the same 264-file which was used to create that container. This is what I would expect with all containers.

When I use the 264-file which was extracted from the mkv and create a new mkv and extract the video track again - then both 264-files are different :-(

So I conclude that mmg and tsmuxer are changing the video-track slightly. Why?!

And is there a way to get the 'original' file back or at least let tsmuxer and mmg 'create' the same video-track.

[kieranrk]

This is because of the way headers are stored in the file. The slice data should match.

[Selur]

it's kind of normal that muxing into a container and out of it you might loose some meta data,..
-> if anything aside from meta data changes it's probably not indented, so it might be helpful if you could elaborate on 'compare with the source file then they all 4 differ', if you just compare the checksum the differences are probably due to the addition or removal of meta data

[dt5]

I did the file compare with the Total Commander.
Any better tool to compare in this case the files?

The file sizes differ up to 3 MB (the file is about 3.5 GB). It is less than 0.1% - but 3 MB metadata?

Is it possible to remove the metadata?
I would always have a better feeling when I can get the original file back. (at least for this one time testing)

And I am not losing data - the original file is the smallest.


And I also don't understand why a muxer has to touch the metadata of the videostream. Shouldn't the metadata not be added into the container?

[kabelbrand]

Have you tried disabling "picture timing info" and/or "insert SPS/PPS" options in TSMuxer? These options are useful but might explain larger output files and a modified bitstream.

[dt5]

I tried with and without before - it made 2.3 MB difference in my case. I thought that the options unchecked would give me the original file. But i was mistaken.

I don't know whether it is worth to waste time with this question - I don't know anymore why I started to test at all - but now I am pretty curious.

A question to the meta-data: Are they all in the header at the beginning of the file? So 2 files with different metadata should be the same after a specific offset x and y for each file?

[sneaker_ger]

When I use the 264-file which was extracted from the mkv and create a new mkv and extract the video track again - then both 264-files are different :-(

I think mkvtoolnix re-adds the headers on top of the existing ones on each muxing->demuxing cycle, so they end up being there twice after the first cycle, three times after two cycles, four times after three cycles, etc. The author does not have time or interest to fix this.

I don't know much about ts/m2ts, but I think they differ in how often the headers are repeated. For broadcasts (where viewers can zap in at any time) the headers have to be repeated for every frame or at least GOP, unlike for mkv where one time storage at the front is sufficient. That's what kieranrk seems to have implied.

[dt5]

I was trying to use ultracompare to compare the files - but it hang each time since the files were too big :-(
I will try later with a much smaller file.

@sneaker:
Your explaination sounds logical. But this means that in generally I should avoid remuxing a mkv-file for small changes and add instead the original raw-file again.

To the extended size of the m2ts-video-stream - I would have thought that the additional data were stored in the container.

Still fighting with myself whether I should store my videos as m2ts or mkv. Samsung just dropped the mkv streaming support. And who knows when other companies will follow that trend. :-(

A little bit offtopic - is there a tool which can convert mkv to m2ts and supports PGS?! tsmuxer is dropping them when i try to import the mkv.
Or is the only way atm to use eac to demux the mkv and mux them again with tsmuxer?

[sneaker_ger]

Samsung just dropped the mkv streaming support.

A bit off-topic, but do you have a link with further information on that?

A little bit offtopic - is there a tool which can convert mkv to m2ts and supports PGS?! tsmuxer is dropping them when i try to import the mkv.
Or is the only way atm to use eac to demux the mkv and mux them again with tsmuxer?

Does ffmpeg work? Unfortunately, tsmuxer development stopped before pgs in mkv became common. You should be able to save some time if you only demux the pgs and add the mkv and the demuxed pgs into tsmuxer instead of demuxing all streams.

To the extended size of the m2ts-video-stream - I would have thought that the additional data were stored in the container.

I guess that as with mkvtoolnix you can't know for sure from demuxing how the data is actually stored in the container. A demuxer might add container data to the elementary stream during the demuxing process.

[dt5]

A bit off-topic, but do you have a link with further information on that?

An E-Mail from the support (I asked all bigger companies who sell BluRay-player whether they sell a device which supports m2ts/mkv with pgs):

vielen Dank für Ihre Anfrage.

Der Samsung Blu-Ray player BD-F7500 unterstützt *.m2ts Dateien. Bitte beachten Sie dabei, dass auch die Untercodecs der jeweiligen Datei (Video Codec, Audio Codec, etc.) vom Player unterstützt werden müssen. Anderenfalls ist eine Wiedergabe nicht möglich.

Ebenso kann es beim Streamen solcher Dateien zu Fehler kommen, *.mkv Dateien werden beispielsweise beim Streamen nicht mehr unterstützt.

[Guest]

@dt5

Please translate that to English per forum rule 13. Thank you.

[dt5]

Here is the translation:

Thank you for your inquiry.
The Blu-Ray player Samsung BD-F7500 supports M2ts files. Please note that the sub-codecs of the file (video codec, audio codec, etc.) must be supported by the player. Otherwise it is not possible to playback.
Similarly, it may lead to an error when streaming such files. Mkv-files, for example, are no longer supported when streaming.

Edit:
I was reading it now again and again.
It is possible that I misunderstood what the support wanted to say.
The support could have meant that the streaming is no longer supported in the case that one of the codecs is not supported. It was not written clear enough.