Code is not 64-bit clean about tsmuxer HOT 13 CLOSED

With my first run through tsMuxerGUI I get the same output as @xavery

62342b056d37e44fae4e48161d6208bf  bbb-2mins-gcc-linux.m2ts

I've saved the meta file as well, I'll see if I can get the output of a Windows build for comparison.

For reference the meta file is:

MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr  --vbv-len=500
V_MPEG-2, "/mnt/shared/tsmuxer-bbb-test/bbb-2mins.mkv", track=1, lang=und
A_AC3, "/mnt/shared/tsmuxer-bbb-test/bbb-2mins.mkv", track=2, lang=und

from tsmuxer.

Hi there. PERHAPS this post on Doom9's forum has the solution (or workaround) to the problem,
I think it's worth a try:

https://forum.doom9.org/showthread.php?p=1882862#post1882862

from tsmuxer.

My understanding is the 64-bit code won't compile without "-fpermissive" - but perhaps this is actually masking the issues you are describing. I'll try to document the errors that appear if you compile without "-fpermissive" to see if they correspond to the issues you describe.

The issue must be in utf8Converter.cpp - is the build you are using Windows or Linux? Also if you could include some instructions to reproduce the issue with some open source video like https://peach.blender.org/ or http://www.valkaama.com/index.php?page=sources that would really help with the process.

from tsmuxer.

@justdan96 — yeah, the file bitStream.cpp should be rewritten for good. According to what I have found on the web, that kind of conversion [under "normal" circumstances] is not tolerated by the 64-bit compiler(s) because of the "loss of precision" thing. But I myself am not qualified for the task.

from tsmuxer.

I don't have any issues compiling the code on a 64-bit machine, even without -fpermissive, but the resulting binary does not work correctly. I am using Linux, specifically Ubuntu 18.04. I'll post an example of the corrupt output for Big Buck Bunny tomorrow.

from tsmuxer.

I've uploaded a file (the first two minutes of Big Buck Bunny) that will trigger the audio bug when processed with a 64-bit build of tsMuxeR. I have also included in the archive the corrupted output of the 64-bit tsMuxer, as well as the correct output of a 32-bit build. I used the m2ts muxing option to create these files, but the bug occurs in the other modes as well, such as Blu-ray ISO. This is Blu-ray quality HD video, so each file is slightly over 500 MB in size once unpacked from the archive.

bbb-2mins.mkv - The original file
bbb-2mins-broken.m2ts - Output of 64-bit tsMuxer with audio glitches
bbb-2mins-correct.m2ts - Correct output of 32-bit tsMuxer

https://drive.google.com/file/d/1Dhb9lkvT7B9cUzsYU0gypAJsgvPrHCBq/view?usp=sharing

from tsmuxer.

Sorry can you also share the exact command line parameters you used to produce those files? I want to make sure my own tests are exactly the same as yours.

from tsmuxer.

I used the GUI. The mode I used was M2TS Muxing. I didn't change any options from the defaults.

from tsmuxer.

I tried reproducing this issue with 64-bit builds made by GCC 9.2.0 and Clang 9.0.0, in both debug and release modes, and none of the builds were capable of producing a TS file with audio glitches like the one you attached. Similarly like you, I used the GUI to start the muxing process and did not change any defaults : the only thing I did was clicking "add" with the source MKV file, selecting "M2TS muxing" and then "Start muxing".
Playing back the TS files made by these builds in VLC doesn't produce any audio artefacts, while playing back "bbb-2mins-broken.m2ts" does.
However, none of the TS files produced by my builds are exactly the same as "bbb-2mins-correct.m2ts", as verified by calculating an MD5 sum. This is of course an issue by itself, since the output shouldn't vary according to the build mode or the compiler, but I guess that's tolerable as long as the playback's fine.
I ran vbindiff on "bbb-2mins-correct.m2ts" and my TS produced by Clang in release mode, and the differences are peculiar to say the least : they boil down to few bits being set differently. For example, my TS has 9B in place where "correct" has 9A, 48 and 47, B3 and B2, and so on. I haven't identified the part of the frame/header where this occurs, though, since that would require significantly more time.

Final note : all my builds produce the same bit-exact output.

62342b056d37e44fae4e48161d6208bf  bbb_clangDbg.m2ts
62342b056d37e44fae4e48161d6208bf  bbb_clangRls.m2ts
62342b056d37e44fae4e48161d6208bf  bbb_gccDbg.m2ts
62342b056d37e44fae4e48161d6208bf  bbb_gccRls.m2ts

I guess we'd need to know the exact compiler version and/or flags which were used to produce "bbb-2mins-broken.m2ts" in order to investigate further.

from tsmuxer.

Interesting results. I will dig out my Linux VM with Qt installed and will produce a new tsMuxerGUI. Then I'll produce tsMuxer in a Linux container with Clang and GCC. I will trace the output from the GUI and try to produce my own results and compare against the existing hashes.

This might be the first step to a testing suite.

from tsmuxer.

I've created another Windows build of tsMuxer, from this branch: #17

The MD5 sum is still exactly the same:

62342b056d37e44fae4e48161d6208bf  bbb-2mins-from-mxe-meta.m2ts

@blenheimears can you please try creating a build from the branch specified in the pull request and see if you get MD5 sums matching mine and @xavery ?

from tsmuxer.

I'll keep testing the MD5 sums with new builds but so far I haven't been able to reproduce this.

I will also think about how to create a small testing suite to make these problems easier to catch.

from tsmuxer.

Seeing as I can't reproduce the issue I will be closing this issue

from tsmuxer.