tsMuxer Open Source

[d3rd3vil]

Ah shit then we got a problem

[Balling]

Originally Posted by Sakura-chan

This is not really a bug, more of a question. I'm fairly new to tsmuxer.

Why do m2ts files remuxed with tsmuxer to the same format end up being smaller? For example, I grab a 5,820,604,416 bytes m2ts from a BD, containing an h264 and lpcm track (nothing complex). I remux it as is with tsmuxer to m2ts, nothing changed. I end up with a 5,806,061,568 bytes file. That's 14,542,848 bytes less than the original (13.87 MB).

Upon demuxing the tracks from both they are identical (compared checksums). So no issues, but why? I understand mkv having less overhead so the resulting remuxes will be smaller, but I expected staying in the same format would result in the same file sizes.

It is a bug. The ITU-T H.222 spec is not fully followed, it is hard to. See: https://github.com/justdan96/tsMuxer/issues/108

Basically, the amount of null packets should be so much more. And that will increase the overhead and thus the size.

[varekai]

@justdan96
Thanks for your continued work on updating an indispensable tool! Much appreciated!

[yannick92]

Hello everyone, did you have a good holiday?

Back to my encodings after having abandoned them in the spring, I discovered an unusual error message (never seen before...), when I wanted to re-encode an AC3 track with EAC3TO, previously demuxed with TSMuxer, let me explain:

As usual, I want to reduce an E-AC3 (DD+) audio track to AC3 + demux it.
No problems with TSMuxer, no processing errors...

Then I re-encode it with EAC3TO for various reasons...
But during the processing log, I have an unusual "Warning": "The last (E-)AC3 frame is incomplete and thus gets skipped" ??...

With Last Uptade >>> git-27f1d54



On the other hand, NO "Warning" after having previously Demuxed my track with TSMuxer 2.6.12:



On the other hand, I don't know if there is a correlation, but after demuxing in my different tests, I don't get the same file size (pre re-encoding), either:
With "Warning" my file is: 360 370 KB
But WITHOUT "Warning" it is: 360,369 KB??

Conclusion, what do you think? Is this a Bug? or regular?

For lack of time, I could not test with less recent realese of TsMuxer, but I remember not having had this problem with the updates of the beginning of the year, see the spring...

Thank you in advance for your answers !

Sincerely

Yannick

EDIT: Seen update and fix, in my case everything is ok now!
Thanks for the work jcdr..

[Balling]

Why The last (E-)AC3 frame is incomplete and thus gets skipped

Is printed for a bigger file??

"E-AC3 (DD+) audio track to AC3"

That is only possible on blu-ray.



Yeah, checking this up it appears that the very last frame is Eac3 and it is not removed, otherwise it is all good and only AC3 frames are extracted. Edit: NOW FIXED.

[Kuler087]

Why does tsmuxer add a negative delay instead of removing frames like mkvtoolnix?

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : MLP FBA AC-3 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 1 h 49 min
Bit rate mode : Variable
Bit rate : 64.0 kb/s
Maximum bit rate : 6 840 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossless
Delay relative to video : -3 s 337 ms
Stream size : 50.2 MiB (0%)
Language : English
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE

[Selur]

(reason is probably, since it's simpler)
Does it add or simply keep the delay?

[Balling]

Originally Posted by Kuler087

Why does tsmuxer add a negative delay instead of removing frames like mkvtoolnix?

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : MLP FBA AC-3 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 1 h 49 min
Bit rate mode : Variable
Bit rate : 64.0 kb/s
Maximum bit rate : 6 840 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossless
Delay relative to video : -3 s 337 ms
Stream size : 50.2 MiB (0%)
Language : English
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE

Because you are not allowed to remove frames (except for seamless branching). Removing frames from THD and AC3 will make it lossy in first case and different in the second case. And also AC3 you are not allowed to remove priming samples. Same for DTS HD and MA, in DTS HD the reference decoder will not decode it EVEN. Also, same happens with EAC3, it has delay 256 samples, usually more.

[Balling]

Originally Posted by Balling

It is a bug. The ITU-T H.222 spec is not fully followed, it is hard to. See: https://github.com/justdan96/tsMuxer/issues/108

Basically, the amount of null packets should be so much more. And that will increase the overhead and thus the size.

Actually, I am interested. How hard would it be to fix? AFAIK, no one has open source code for that.