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.

[yannick92]

Good morning
I have a problem with splitting MKV into M2TS with TSMuxer (last nightly):
No error during muxing, I get my 2 parts (split in 4 GB because DD in Fat 32), in playback with VLC, split 1 ok but split 2 no image, just the sound...?
Same on PS3, Split 2 "data not compatible" so no reading at all...
Is this a bug?
THANKS

[Hellboy.]

Originally Posted by yannick92

Good morning
I have a problem with splitting MKV into M2TS with TSMuxer (last nightly):
No error during muxing, I get my 2 parts (split in 4 GB because DD in Fat 32), in playback with VLC, split 1 ok but split 2 no image, just the sound...?
Same on PS3, Split 2 "data not compatible" so no reading at all...
Is this a bug?
THANKS

Is better if you report the bugs you find here:
https://github.com/justdan96/tsMuxer/issues

[yannick92]

Originally Posted by Hellboy.

Is better if you report the bugs you find here:
https://github.com/justdan96/tsMuxer/issues

Ok thx, I didn't dare...

[jcdr428]

Hi all, I am working on the buffers management of tsMuxer.

These are the Rx leak rates from the transport buffers given by the BD-ROM Part3 V2.5 specs:

Stream:.................................10^6 bits/s
MPEG-2 Main/Main........................18
Sec. AVC Level 3.2........................9.6
LPCM 48/96 kHz...........................20
LPCM 192 kHz..............................30
DD..............................................2
DTS............................................5
DRA............................................5
All others....................................48

Can anybody advise / PM me what are the leak rates in the V3 (UHD) specs ?

[Emulgator]

Hi jcdr428, many thanks for your continued work !

BD-ROM V3.0 HEVC constraints (2015 06) and
BD-ROM V3.0 UHD Format Spec (2015 07 24) and
BD-ROM V3.2 UHD Format Spec (2018 01 22) agree.

"3.11 HEVC video stream Decoder Model
In case an input to TB (Transport buffer) is a HEVC video stream,
the BDAV-STD decodes the input in the same way as T-STD defined in ISO/IEC 13818-1.
For transferring the HEVC video stream data from MB (Multiplexing buffer) to EB (Elementary stream buffer),
ISO/IEC13818-1 defines two methods: the leak method and HRD.

(BDAV-STD Video Decoder Model)
It is restricted that the BDAV-STD shall use the leak method for transferring the HEVC video stream from MB to EB.
(The BDAV-STD shall not use the HRD for the transfer of data from MB to EB.)"
-----------
"3.11.1 BDAV-STD model parameter limits
Table 3-7:
Rx1 Leak rate from TB1 for HEVC video stream: 1.1*100*10^6 bits/s = 110Mbit/s
Rbx1 Leak rate from MB1 for HEVC video stream: 1.0*100*10^6 bits/s = 100Mbit/s
MB1 Multiplexing buffer for HEVC stream 73.333 bytes
EB1 Elementary stream buffer for HEVC stream 12.500.000 bytes
DPB1 Decoded picture buffer for HEVC stream 93.312.000 bytes"
----------
Good practice UHD HEVC stream encoding for 112nm pitch BD-100: VBR peak max 109, better 108Mbps.
MPEG-2TS Peak rate for 112nm pitch BD-100: 127,9Mbps
A Scenarist UHD setting screenshot showed a max. Data Transfer rate of 122,546Mbps for a 112nm pitch Triple-layer BD-100.

P.P.S Hm.
Rx1 is max. leak rate from Transport buffer TB1 into the 73kB Mux buffer MB1 (<=110Mbs)
After container overhead is stripped off (here 110/100 -> up to +10% overhead can be accommodated)
Rbx1 is max leak rate from Mux buffer MB1 into the 12,5MB EB1 (Elementary buffer). (<=100Mbps
which would imply that any HEVC CBR ES can only touch Rbx1 from underside, keeping a safety distance (99Mbps ?)
and for HEVC VBR ES the mean value of bufferlengths worth can only touch Rbx1 from underside.
(Peaks up to 109,5Mbps minus muxer overhead, Valleys to match buffersize within bufferlength).
Don't know If I am correct here, but I thought I throw this in.

[jcdr428]

Thanks @Emulgator. HEVC Rx leak rate 110 x 10^6 bits/s: this is for Main10/High Tier/Level 5.1 Primary Video.

So there are no other HEVC profiles/levels or secondary video allowed in player profile 6 (UHD), is that correct ?

What happens with 64 or 81.7 Mbps discs: are they supposed to receive AVC video only ?

[Emulgator]

What happens with 64 or 81.7 Mbps discs: are they supposed to receive AVC video only ?

I guess no. You just keep bitrate down and still choose the codec (following producer's taste or really following source resolution and content ;-)

Going from the Blu-ray ecosystem "We have certain SoCs, softwares and plants available,
so let's keep needed restrictions we already have researched and extend only where necessary"
there is such thing as FHD on Ultra-HD Blu-ray, allowing longer movies, series, whatever.
If all points to FHD, then 8bpc-> AVC vs. 10bpc-> HEVC

The producer would have the choice between (FHD project ? AVC or HEVC) OR (UHD project ? HEVC only)
and the encoding person in consequence following duration/complexity vouch for BD-66 or BD-100,
then have to take care and control encoder properly before attempting to mux.
(BD-ROM 66? BD-ROM 100? which pitch ? how many layers are there and which layer are we in ?
In HEVC case on selecting Disc type Scenarist would only assign and approve the lesser bitrates.

So there are no other HEVC profiles/levels or secondary video allowed in player profile 6 (UHD), is that correct ?

HEVC Profiles should be more than one allowed. Secondary video: I am not sure, will look into it.

P.S. A quick search in the HEVC video constraints paper did not find the word "secondary".
Allow secondary AVC video to be muxed in on a AVC Ultra-HD Blu-ray ?
If ressources, time and interest allow: Why not. Can be warned about later if some Oppos play and some Pannys not.

FHD Ultra-HD Blu-ray ROM:

AVC 1920x1080 is allowed in 8bpc only (no 10bit).
I would expect the following:
AVC restrictions should stand still as before, Level 4.1, VBV model, But: No more 3D MVC coding allowed.
AVC Level 4.1 Main would accommodate 1920x1080x30/1280x720x68,3fps@50Mbps

HEVC 1920x1080 is allowed in 10bpc only (no 8bit)
HDR/SDR, Buffer leak model.
There is your other HEVC Profile: HEVC Level 4.1 Main10 High would accommodate 1920x1080x64fps@50Mbps.
But I see no reason to enforce/expect such signaling on muxer-side for FHD,
since Level 5.1 Main10 High can be used all the same with less than maxed-out, so FHD bitrates.

UHD Ultra-HD Blu-ray ROM:
Mandatory HEVC 3840x2160 10bpc, Buffer leak model.
The Profile: Level 5.1 Main10 High can place 160Mbps to accommodate 3840x2160x64fps

(No AVC allowed nor possible, AVC Level 5.2 Main(8) would place 240Mbps to accommodate 3840x2160x66,8fps
and Hi10P, well out of the equation...)

From the muxer perspective I would gather that the model and leak rates shall not differ if HEVC UHD or FHD is to be muxed.
As bitrate should also not affect the muxer strategy, IMHO.
After all, it is the same hardware demuxing/decoding is running on for all legally possible stream parameters.

For completeness sake:
HEVC max number of slice segments: 34
HEVC Max number of pictures in DPB: 6 for 3840x2160 and 1920x1080
HEVC GOP duration: 1s for 3840x2160 and 1920x1080
HEVC STD delay: 1s for video stream, 60s for still picture.

Optional: For better searchability HEVC stream may contain a temporal sublayer consisting of TSA pictures...

[jcdr428]

So let's say I want to compress a UHD Blu-ray to FHD HEVC to fit on a 50 GB BD-R: what HEVC leak rate and overall TS_recording_rate should I use (i.e. what min. Arrival TimeStamp interval between two 0x1011 packets) ?

Currently tsMuxer does not care about leak rates, it just calculates one ATS interval between two successive video DTS by dividing the frame duration between those two DTS by the number of packets in this duration, whatever the number of tracks or size of frames. Therefore there is a huge variation in ATS interval for e.g. I-frame vs B-frame.

[cubicibo]

The leak rate is the peak bitrate of the input VBR stream, capped at the maximum rate allowed for a given elementary stream type.

[Emulgator]

Good thread, cubicibo, from the beginning !
jcdr428 was at it 2020, together with drmpeg's other post
https://github.com/justdan96/tsMuxer/issues/108

From my quick glances other (disc) muxers seem to need to parse VBR elementaries before actually muxing.
No way to go for streaming of course, but there are different bitstream restriction sets in force which help on-the-fly muxing.

[jcdr428]

The leak rate is not really the peak rate, but rather the average reading rate for one frame from the transport buffer to the multiplexing buffer. The multiplexing buffer mustn't overflow above maximum permitted size, nor underflow (i.e. become null before end of reading of the frame). This is why the blu-rays generally have a 900ms "dwell" between the arrival time stamp and the DTS, to allow for burst bitrates than can be well above maximum permitted (cf. Super Mario Bros UHD which goes to >130 Mbps for a leak rate of 109*10^6).

Edit: and this is why there are various leak rates for H.264:
1.2*40*10^6 for level 4.1,
1.2*24*10^6 for level 4,
1.2*24*10^6 for level 3.2,
1.2*16.8*10^6 for level 3.1,
1.2*12*10^6 for level 3

It should be the same for H.265, unfortunately the WhitePaper does not give the various leak rates for the various levels that can be used.
E.g. we don't know which level and leak rate can be used on a 50GB disk which maximum reading rate is 64*10^6 bps.

Edit2: the post from drmpeg applies to .ts (not .m2ts) for which there are no arrival time stamps, so indeed the leak rate is the peak rate and filler packets are included to keep the rate constant.