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. |
18th August 2023, 07:46 | #1322 | Link | |
Registered User
Join Date: Feb 2020
Posts: 552
|
Quote:
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. |
|
3rd September 2023, 15:52 | #1324 | Link |
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 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.. Last edited by yannick92; 10th September 2023 at 13:50. |
6th September 2023, 06:58 | #1325 | Link |
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. |
13th September 2023, 21:31 | #1326 | Link |
Registered User
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 |
21st September 2023, 19:37 | #1328 | Link | |
Registered User
Join Date: Feb 2020
Posts: 552
|
Quote:
Last edited by Balling; 22nd September 2023 at 00:11. |
|
22nd September 2023, 00:53 | #1329 | Link | |
Registered User
Join Date: Feb 2020
Posts: 552
|
Quote:
|
|
24th September 2023, 18:46 | #1330 | Link |
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 |
25th September 2023, 17:36 | #1331 | Link | |
Registered User
Join Date: Mar 2020
Posts: 53
|
Quote:
https://github.com/justdan96/tsMuxer/issues |
|
25th September 2023, 18:30 | #1332 | Link | |
Registered User
Join Date: Jan 2020
Location: France
Posts: 28
|
Quote:
|
|
1st November 2023, 09:28 | #1333 | Link |
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 ? |
1st November 2023, 19:16 | #1334 | Link |
Big Bit Savings Now !
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. |
2nd November 2023, 08:54 | #1335 | Link |
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 ? |
2nd November 2023, 13:55 | #1336 | Link | ||
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,705
|
Quote:
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:
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. |
||
2nd November 2023, 17:53 | #1337 | Link |
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. |
2nd November 2023, 22:52 | #1338 | Link |
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.
|
3rd November 2023, 12:34 | #1339 | Link |
Big Bit Savings Now !
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. |
4th November 2023, 12:24 | #1340 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|