Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > (HD) DVD & Blu-ray authoring

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th July 2023, 11:55   #1321  |  Link
d3rd3vil
Registered User
 
Join Date: Jun 2016
Posts: 92
Ah shit then we got a problem
d3rd3vil is offline   Reply With Quote
Old 18th August 2023, 07:46   #1322  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 552
Quote:
Originally Posted by Sakura-chan View Post
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.

Last edited by Balling; 30th August 2023 at 19:16.
Balling is offline   Reply With Quote
Old 21st August 2023, 08:21   #1323  |  Link
varekai
Registered User
 
varekai's Avatar
 
Join Date: Jul 2006
Posts: 543
@justdan96
Thanks for your continued work on updating an indispensable tool! Much appreciated!
varekai is offline   Reply With Quote
Old 3rd September 2023, 15:52   #1324  |  Link
yannick92
Registered User
 
Join Date: Jan 2020
Location: France
Posts: 28
"WARNING" "Last AC3 Frame is Incomplete" with EAC3TO (Encoding Audio Track)

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

Name:  Eac3to Log WARNING Last Frame_Test Last git-27f1d54.PNG
Views: 281
Size:  68.6 KB

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

Name:  Eac3to Log NO WARNING Last Frame_Test TsMuxer 2.PNG
Views: 277
Size:  70.4 KB

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..

Last edited by yannick92; 10th September 2023 at 13:50.
yannick92 is offline   Reply With Quote
Old 6th September 2023, 06:58   #1325  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 552
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.

Last edited by Balling; 22nd September 2023 at 00:00.
Balling is offline   Reply With Quote
Old 13th September 2023, 21:31   #1326  |  Link
Kuler087
Registered User
 
Kuler087's Avatar
 
Join Date: Aug 2021
Location: Canada
Posts: 370
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
__________________
DoVi_Scripts
Kuler087 is offline   Reply With Quote
Old 14th September 2023, 11:14   #1327  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,470
(reason is probably, since it's simpler)
Does it add or simply keep the delay?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 21st September 2023, 19:37   #1328  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 552
Quote:
Originally Posted by Kuler087 View Post
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.

Last edited by Balling; 22nd September 2023 at 00:11.
Balling is offline   Reply With Quote
Old 22nd September 2023, 00:53   #1329  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 552
Quote:
Originally Posted by Balling View Post
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.
Balling is offline   Reply With Quote
Old 24th September 2023, 18:46   #1330  |  Link
yannick92
Registered User
 
Join Date: Jan 2020
Location: France
Posts: 28
problem after an M2TS split

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
yannick92 is offline   Reply With Quote
Old 25th September 2023, 17:36   #1331  |  Link
Hellboy.
Registered User
 
Join Date: Mar 2020
Posts: 53
Quote:
Originally Posted by yannick92 View Post
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
Hellboy. is offline   Reply With Quote
Old 25th September 2023, 18:30   #1332  |  Link
yannick92
Registered User
 
Join Date: Jan 2020
Location: France
Posts: 28
Quote:
Originally Posted by Hellboy. View Post
Is better if you report the bugs you find here:
https://github.com/justdan96/tsMuxer/issues
Ok thx, I didn't dare...
yannick92 is offline   Reply With Quote
Old 1st November 2023, 09:28   #1333  |  Link
jcdr428
Registered User
 
Join Date: Mar 2023
Posts: 6
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 ?
jcdr428 is offline   Reply With Quote
Old 1st November 2023, 19:16   #1334  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,705
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.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 4th November 2023 at 03:03.
Emulgator is offline   Reply With Quote
Old 2nd November 2023, 08:54   #1335  |  Link
jcdr428
Registered User
 
Join Date: Mar 2023
Posts: 6
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 ?
jcdr428 is offline   Reply With Quote
Old 2nd November 2023, 13:55   #1336  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,705
Quote:
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.
Quote:
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...
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 4th November 2023 at 03:12.
Emulgator is offline   Reply With Quote
Old 2nd November 2023, 17:53   #1337  |  Link
jcdr428
Registered User
 
Join Date: Mar 2023
Posts: 6
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.
jcdr428 is offline   Reply With Quote
Old 2nd November 2023, 22:52   #1338  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 133
The leak rate is the peak bitrate of the input VBR stream, capped at the maximum rate allowed for a given elementary stream type.
cubicibo is offline   Reply With Quote
Old 3rd November 2023, 12:34   #1339  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,705
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.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 3rd November 2023 at 13:49.
Emulgator is offline   Reply With Quote
Old 4th November 2023, 12:24   #1340  |  Link
jcdr428
Registered User
 
Join Date: Mar 2023
Posts: 6
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.

Last edited by jcdr428; 4th November 2023 at 12:50.
jcdr428 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.