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 11th June 2020, 11:20   #801  |  Link
justdan96
Registered User
 
Join Date: Jun 2019
Location: UK
Posts: 49
No code changes to tsMuxer at all, just amendments to the scripts in GitHub that produce packages in the Open Build Service.
justdan96 is offline   Reply With Quote
Old 19th June 2020, 09:50   #802  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Testing tsMuxeR 2020-06-11 (build 7901afa) 64-bit for Blu-ray V2.00 folder muxing

A nice-to-have suggestion before the final build is released:
Pre-loaded default value for Blu-ray V2.00 and V3.00 muxing:
Code:
--start-time 524280
A smallish bug:
While exporting a .meta file the file extension .ts is suggested.
Pressing OK without manually going to dropdown "All Files" and removing the superfluous ".ts"
will result in a concatenated and unwanted double file extension .meta.ts
tsMuxeR 2.6.12 does that correctly and suggests file extension .meta

BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 48m33s, AC-3 2.0 @192kbps
--start-time no offset, 18 custom chapters in HH:MM:SS.mmm

BDEdit 0.49b:
PLAYLIST finds
IN time 01:10:00.000
OUT time 01:58:33.320

CLIPINF complains: 00000.clpi: lists Packets 56082912.
and pops up window: "The m2ts file contains 56.076.970 packets.
Do you want to correct the packet value of ClipInfo ?"
--
Remuxed BD, this time with typical BD offset --start-time 524250
Checked with BDedit v0.49b: Start time is respected this time.
Number of Packets still diverging.

Investigating...
Manually setting chapters in BDEdit: These are respected by MPC-HC player.
...
BDedit: 11.651s minimum offset it is.
Now Player can skip back to stream start...
BDEdit 11.650s offset:
Player can not skip back to stream start, can only skip back to chapter 2.
On BDedit chapter export this is displayed a 0,1 (0 ticks, the meaning of the second 1 is unknown to me)

Narrowing it down:
tsMuxeR: tick one up: 524250 -> 524251.
This does it. Success.
Preload a minimum of 524251 ticks (or 11,650022222222222222222222222222s)
524280 ticks (or 11,65066666666666666666s) are safe.
On BDedit chapter export this is displayed a 0,1 (0 tick, the meaning of the second 1 is unknown to me)

Auto chaptering every 5min works: Player sees and respects these.
BDedit 0.49b sees these.
PLAYLIST: In BDedit all mark times look offset by 11.650s,
but MPC-HC timeline plays happily at the correct 5:00 positions.

Hmmm, and at the end these 11.650s are missing from BD folder playback in MPC-HC. WTF.
MPC-HC reports total playing time 48:33, but stops after 48:20.

BDedit PLAYLIST sees correct IN time 00:00:11.650
OUT time 00:48:44.970 length 00:48:33.320
Playing the pure 00000.m2ts in MPC-HC: These final 11.650s haven't been muxed into the .m2ts stream,
but were there in the .264 elementary stream before muxing (00:48:33:08 = 145666 frames (0-145665))

This may well be the reason why BDedit 0,49 CLIPINF complains:
00000.clpi lists Packets 56082912
A window pops up: "The m2ts file contains 56.076.970 packets.
Do you want to correct the packet value of ClipInfo ?"

These missing 5942 packets may well be the culprit.
Counterchecking: tsMuxeR 2.6.12 does the same.

tsMuxeR 1.10.6 does it better, lets me have the final 11.650s.
Hardwired first mark time: 00:10:00.000 (10 minutes)
BDedit finds 56032544 packets, won't complain about diverging number of packets.
__________________
"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; 19th June 2020 at 15:16.
Emulgator is offline   Reply With Quote
Old 19th June 2020, 22:30   #803  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Quote:
Originally Posted by Emulgator View Post
A nice-to-have suggestion before the final build is released:
Pre-loaded default value for Blu-ray V2.00 and V3.00 muxing:
Code:
--start-time 524280
Depending on the distributors, some Blu-ray PTS start at 2s, some others at 10s, many at 11.650s, others at 1h10s...
What is the community opinion, do we need to change the default 0 ? If so, to what value ?

Quote:
Originally Posted by Emulgator View Post
A smallish bug:
While exporting a .meta file the file extension .ts is suggested.
Pressing OK without manually going to dropdown "All Files" and removing the superfluous ".ts"
will result in a concatenated and unwanted double file extension .meta.ts
tsMuxeR 2.6.12 does that correctly and suggests file extension .meta
Issue opened on Github.

Quote:
Originally Posted by Emulgator View Post
BD-Mux Folderset with AVC 1280x720x50p@28Mbps, duration 48m33s, AC-3 2.0 @192kbps
--start-time no offset, 18 custom chapters in HH:MM:SS.mmm

BDEdit 0.49b:
PLAYLIST finds
IN time 01:10:00.000
OUT time 01:58:33.320
How come that you use a start time = 0, but the mpls file has a start time of 1h10s ? Did you keep the original mpls ?
a5180007 is offline   Reply With Quote
Old 20th June 2020, 01:11   #804  |  Link
outgoing
Registered User
 
Join Date: Aug 2018
Posts: 68
Quote:
Originally Posted by a5180007 View Post
Depending on the distributors, some Blu-ray PTS start at 2s, some others at 10s, many at 11.650s, others at 1h10s...
What is the community opinion, do we need to change the default 0 ? If so, to what value ?
Default 0 takes the data as it is original from the mpl, so what kind of need is there to change this behavior, I like it as it is originally from the source.
outgoing is offline   Reply With Quote
Old 20th June 2020, 09:19   #805  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Many thanks for your continued work, a5180007 !
Quote:
How come that you use a start time = 0, but the mpls file has a start time of 1h10s ? Did you keep the original mpls ?
I muxed from an elementary .avc, so no .mpls was given by me or the stream.
Unintentationally I left the default (0) that the tsmuxerGUI came up with, muxed anyway just to see if the result would be playable.

I continued testing.
Anything below 524250 ticks gives timestamps that look like underflow of a 32-bit register.
This seems to be a limitation of the TS implemetations themselves,
because other muxers (Scenarist) come up with the same start time.
No problem here, but tsMuxeR's v2 muxing end came out premature by the same amount
--------------------------------------------------------
BDedit export of chapter_00000_PTS
shows mark time as <45kHz ticks>,1

mark time = chapter time + --start-time from tsMuxeR (given 11.650s)
Magic Number involved ?

In BDedit inputting an entry mark with mark time
00:00:00.000
delivers a exported chapter time 4294443016,1
which equals
95432,067022222222222222222222222s
Resulting BD is playable from the top, but only once, can not skip back to stream start.

Looks like backwards overflow of a 32-bit counter !
(2^32 = 4294967296)

4294967296 - 4294443016 = 524280 !
There is the magic number.
What power of 2 is next ? 2^19 = 524288.

This offset indicates that somewhere 19 bits might be shifted
for a good reason. Maybe preroll for stuff I don't know at the moment...?

Importing a chapter_00000_PTS with handedited 0 ticks
delivers 11.650s mark time.

Exporting from 11.649s delivers
4294967221,1 ticks
BD can not skip back to stream start.

Exporting from 11.651s:
BD can skip back to stream start.

Test: Rounding from the .ms granularity v into 1/45000s tick granularity
Muxing with --start-time 525250 delivers crap (underflow, see above)
BD can not skip back to stream start.

Muxing with --start-time 524251..294
BD edit sees 11.650s
BDedit exports first chapter as "0,1"
BD can skip back to stream start.

Muxing with --start-time 524295
BD edit sees 11.651s
BDedit exports first chapter as "0,1"
BD can skip back to stream start.
----------------------------------
__________________
"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; 20th June 2020 at 09:31.
Emulgator is offline   Reply With Quote
Old 20th June 2020, 10:30   #806  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Repeating my tsMuxeR comparisons since I was writing to the same folder and the 3 tsMuxeRs might not have overwritten correctly.
5 muxes of the same content, results came out unchanged:
tsMuxers 2.6.12 and last version seem to lose packets at the end, but 1.10.6 has them muxed playable.

tsMuxeR 1.10.6
--start time is not implemented, GUI has no provision for that
BDedit v0.49b reports first mark time 00:10:00.000 (10min) (so this value seems to be hardwired in tsMuxeR v1), reports no Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: All frames are playable.
tsMuxeR 2.6.12
untouched --start time (GUI reports 00:00:00.000 / 0)
BDedit v0.49b reports first mark time 01:10:00.000 (1hr 10min) (so this value seems to be hardwired in tsMuxeR v2 if 0 is given), reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2.6.12
manual --start time (GUI reports 00:00:11.650 / 524280)
BDedit v0.49b reports first mark time 00:00:11.650, reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2020-06-11
untouched --start time (GUI reports 00:00:00.000 / 0)
BDedit v0.49b reports first mark time 01:10:00.000 (1hr 10min) (so this value seems to be hardwired in tsMuxeR v2 if 0 is given), reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.
tsMuxeR 2020-06-11
manual --start time (GUI reports 00:00:11.650 / 524280)
BDedit v0.49b reports first mark time 00:00:11.650, reports Packets missing.
MPC-HC playback from Bluray-folder and from stream 00000.m2ts: Both end prematurely ~12s too early.

mediainfo of the video elementary stream
Code:
General
Complete name                            : J:\4_ES\BD RB\x264 V13 RB 1996.264
Format                                   : AVC
Format/Info                              : Advanced Video Codec
File size                                : 9.50 GiB
Overall bit rate mode                    : Variable
Writing library                          : x264 core 160 r3000 33f9e14
Encoding settings                        : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=0,0 / fast_pskip=1 / chroma_qp_offset=-3 / threads=18 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=50 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=28000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=48 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.20 / aq=1:1.00

Video
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 4 frames
Bit rate mode                            : Variable
Bit rate                                 : 28.0 Mb/s
Maximum bit rate                         : 40.0 Mb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 50.000 FPS
Standard                                 : PAL
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.608
Writing library                          : x264 core 160 r3000 33f9e14
Encoding settings                        : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=0,0 / fast_pskip=1 / chroma_qp_offset=-3 / threads=18 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=50 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=28000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=48 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.20 / aq=1:1.00
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
BD RB1996 tsMuxeR 1.10.6.meta
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr  --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", fps=50, insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger
BD RB1996 tsMuxeR 2.6.12 untouched.meta
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr  --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger
BD RB1996 tsMuxeR 2.6.12 524280.meta
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr  --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500 --start-time=524280
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger
BD RB1996 tsMuxeR 2.6.16 untouched.meta
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --blu-ray --vbr  --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger
BD RB1996 tsMuxeR 2.6.16 524280.meta
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --hdmv-descriptors --blu-ray --vbr  --custom-chapters=00:00:00.000;00:01:32.080;00:03:17.320;00:05:11.000;00:05:51.720;00:07:49.640;00:10:54.040;00:13:36.440;00:15:27.040;00:16:57.000;00:18:05.360;00:19:04.080;00:23:24.720;00:25:02.960;00:27:23.560;00:30:04.920;00:34:47.400;00:42:05.240 --vbv-len=500 --start-time=524280
V_MPEG4/ISO/AVC, "J:\4_ES\BD RB\x264 V13 RB 1996.264", insertSEI, contSPS
A_AC3, "J:\4_ES\BD RB\V13 RB 1996.ac3", lang=ger
__________________
"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; 20th June 2020 at 11:30.
Emulgator is offline   Reply With Quote
Old 22nd June 2020, 14:41   #807  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
And another suggestion, just another nicety for beginners.

2.6.16:The last tsMuxeR version comes up with an empty chapter editor window.
2.6.16 offers 5min auto-chapters, the associated radio button is default.
If user ticks radio button "custom chapters" chapter editor window changes state, and stays empty.
Now if somebody enters the wrong format (frames, or SMPTE), he wont get no lead how to enter correctly.

Using tsMuxeR 1.10.6 one can easily see what chapter format is expected: HH:MM:SS.mmm
1.10.6 offers 5min auto-chapters, the associated radio button is default.
These equally-spaced chapter times are already visible in the still greyed-out chapter editor window.
If user ticks radio button "custom chapters" chapter editor window loses greyed-out and the default equally-spaced chapters become editable.
__________________
"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..."
Emulgator is offline   Reply With Quote
Old 23rd June 2020, 17:31   #808  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Quote:
Originally Posted by Emulgator View Post
If user ticks radio button "custom chapters" chapter editor window changes state, and stays empty.
@Emulgator which OS do you use? On my Windows 10, latest tsMuxer 7b159f6 is working as it should: If user ticks radio button "custom chapters", chapter editor window loses greyed-out and the default equally-spaced HH:MM:SS.mmm chapters become editable.

Edit; same for your "packets missing" issue, I cannot reproduce. Could you please confirm that tsMuxer reports the correct number (i.e. same as reported e.g. by ffmpeg for the original m2ts) of video frames processed, and progress goes up to 100.0% ?

Anybody else has the same issue ?

Last edited by a5180007; 23rd June 2020 at 17:40. Reason: me
a5180007 is offline   Reply With Quote
Old 24th June 2020, 13:45   #809  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Win7U64 SP1 here, until yesterday I tested only the 64bit version of tsMuxeR 7901afa.
32bit 7901afa still untested, will do that test in the next minutes, see below.

About missing packets: both tsMuxeRs 1.10.6 and 7901afa got fed the same .avc stream,
and BDedit 0.49b finds that discrepancy with new 7901afa and old 2.6.12 from 13.01.2014.
1.10.6 from 11.05.2009 muxes the same stream ok

Right now I haven't yet found 7b159f6 in nightlies...
Once you release 7b159f6 I will test that version too, 32bit and 64bit.

Will continue testing same stream with tsMuxeR 7901afa 32 bit now.

Code:
tsMuxeR version git-7901afa. github.com/justdan96/tsMuxer
Decoding H264 stream (track 1): Profile: High@4.1  Resolution: 

1280:720p  Frame rate: 50
H.264 muxing fps is not set. Get fps from stream. Value: 50
B-pyramid level 1 detected. Shift DTS to 2 frames
H264 bitstream changed: insert pict timing and buffering 

period SEI units
Decoding AC3 stream (track 2): Bitrate: 192Kbps Sample Rate: 

48KHz Channels: 2
Processed 145666 video frames
Flushing write buffer
Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Muxing time: 6 min 54 sec
All tests with failing muxes show the same:
All tsMuxeR v2 report all .avc frames I had encoded (145666),
progress to 100%, ring and report success.
but muxes seem to miss packets at the end, at least BDEdit tells it so
and Software players stop ~12s prematurely.
(I am not remuxing from a given .m2ts here, I feed a x264 encoded elementary stream)

From the same .avc + .ac3 stream
tsMuxeR 1.10.6 muxes 00000.m2ts with size 10.758.248.448 B
tsMuxeR 2.6.12 32-bit muxes 00000.m2ts with size 10.766.778.368 B
tsMuxeR 7901afa 32-bit muxes 00000.m2ts with size 10.766.778.368 B
tsMuxeR 7901afa 64-bit muxes 00000.m2ts with size 10.766.778.368 B

Will continue that test under WinXP32ProSP3 soonish.
__________________
"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; 24th June 2020 at 15:01.
Emulgator is offline   Reply With Quote
Old 24th June 2020, 14:52   #810  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
a5180007, good guess, there is an OS dependency indeed !

Now on my WinXP32ProSP3 tsMuxeR 2.6.12. muxes ok, the last 12 seconds are playable, BDEdit 0.49b finds no discrepancy.
(But it did not before on my Win7U64SP1.)

Unfortunately tsMuxeR 7901afa 32-bit refuses to start up on WinXP32ProSP3 with an assertion window:
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".

So I guess that all tsMuxeRs v2 share a small incompatibility with Win7 by birth around 2014,
and additionally an incompatibility with WinXP32 has come up for the new builds since maybe End of 2019.

So I can imagine now why Win10 users may not notice anything.
__________________
"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; 24th June 2020 at 15:38.
Emulgator is offline   Reply With Quote
Old 24th June 2020, 16:08   #811  |  Link
staina
Registered User
 
Join Date: Feb 2013
Posts: 67
At loaded 3D Bluray with 3D-plane undefined with in "General track options" set 3d offset to "plane 0", but right about to be set "zero".

You can this bug fix? Thank you
Attached Images
 
staina is offline   Reply With Quote
Old 24th June 2020, 19:05   #812  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Quote:
Originally Posted by Emulgator View Post
Right now I haven't yet found 7b159f6 in nightlies...
Once you release 7b159f6 I will test that version too, 32bit and 64bit.
@Emulgator 7b159f6 is nightly 2020-05-09, which is same as 2020-06-10 and 2020-06-11 as explained by @justdan96.
I can't help on the bug, I can debug only under Win10.
a5180007 is offline   Reply With Quote
Old 25th June 2020, 07:40   #813  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Quote:
I can't help on the bug, I can debug only under Win10.
Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
Hopefully a good soul will take up OS compatibilty from here.
To help with that I will go backwards and test all newer 32bit builds to find out which commit might have broken WinXP.
__________________
"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; 25th June 2020 at 07:42.
Emulgator is offline   Reply With Quote
Old 25th June 2020, 08:16   #814  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
If I go from the JFrog repository for me already the first 32bit nightly 2.6.15 from 2019-12-14--14-44-59 seems to break WinXP32 compatibility.
Code:
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".
The (available to me) previous version 2.6.12 starts up properly.
What builds came in between ?
__________________
"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; 25th June 2020 at 16:31.
Emulgator is offline   Reply With Quote
Old 25th June 2020, 08:21   #815  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Beautiful, with 2020-06-25--02-11-43 Build 0fa0738 chapters list becomes preloaded again on Win7U64 !
Does not yet respect changes in "Insert chapter every <integer> min but still:
Many thanks !

P.S.: No. I had no stream imported, just opened tsMuxer and went to the Blu-ray tab,
so it worked because of no import happening yet.
Once I import a single stream .avc or .ac3, preload chapter values disappear.
So it might be not connected with this build, but should be easier to track now.

P.P.S.: Just tested: That just described behaviour
(GUI losing preloaded chapter values on import of any stream (.avc, .ac3 tested))
was indeed already there in nightly build 2019-12-16, the previous 2019 12-14 GUI does not find its tsMuxeR.exe
__________________
"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; 25th June 2020 at 16:11.
Emulgator is offline   Reply With Quote
Old 25th June 2020, 09:56   #816  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Strange things here, exporting .meta from GUI (to myself: which?)
seems to lose CR+LF delimiter for the stream command lines, looks concatenated to me (in Windows Notepad, that is)

P.S. Got that now: 2.6.12 uses LF delimiters only ->
Windows Notepad renders concatenated text, notepad++ renders linebreaks

New builds 2.6.16 use CR+LF delimiters ->
Windows Notepad renders linebreaks, notepad++ renders linebreaks, all ok.

Soon I will test CLI...
If I can get my hand on builds in between 2.6.12 and 2.6.15 I would be willing to continue testing these.
__________________
"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; 25th June 2020 at 16:20.
Emulgator is offline   Reply With Quote
Old 25th June 2020, 16:26   #817  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
New 2020-06-25--02-11-43 (64bit Build 0fa0738) CLI with handedited .meta under Win7U64 SP1:
Unchanged. Mux Progress to 100%, success reported, all .avc frames I had encoded are reported (145666).

BD folder Playback ends ~12s prematurely in MPC-HC.
BDedit 0.49b reads 56082912 packets from 00000.clpi,
finds only 56076970 packets, this makes 5942 missing packets.
__________________
"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; 25th June 2020 at 16:29.
Emulgator is offline   Reply With Quote
Old 26th June 2020, 09:43   #818  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Quote:
Originally Posted by Emulgator View Post
Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
Hopefully a good soul will take up OS compatibilty from here.
@Emulgator the good soul might be @BloodyRipper (aka xavery on Github), he has worked quite a lot on the GUI for XP.

Quote:
Originally Posted by Emulgator View Post
If I can get my hand on builds in between 2.6.12 and 2.6.15 I would be willing to continue testing these.
No open source available for versions prior to 2.6.15.

Last edited by a5180007; 26th June 2020 at 09:52.
a5180007 is offline   Reply With Quote
Old 26th June 2020, 20:48   #819  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Emulgator View Post
Ouch. That would make the newer tsMuxeR builds unusable under WinXP and much worse, even under Win7.
The latest tsMuxer GUI works normally under my 64-bit Windows 7
But then I don't let the OS update itself, to begin with...

Regarding XP especifically, many posts ago I suggested that someone should create a dot-NET GUI for tsMuxer because everybody knows the QT devilopers are totally Linux-centric so to speak

Last edited by filler56789; 26th June 2020 at 20:49. Reason: .
filler56789 is offline   Reply With Quote
Old 26th June 2020, 21:25   #820  |  Link
BloodyRipper
Registered User
 
BloodyRipper's Avatar
 
Join Date: May 2003
Posts: 74
Quote:
Originally Posted by Emulgator View Post
If I go from the JFrog repository for me already the first 32bit nightly 2.6.15 from 2019-12-14--14-44-59 seems to break WinXP32 compatibility.
Code:
"Der Prozedureinsprungpunkt "Direct3DCreate9Ex" wurde in der DLL "d3d9.dll" nicht gefunden."
"The procedure entry point "Direct3DCreate9Ex" was not found in the DLL "d3d9.dll"".
The (available to me) previous version 2.6.12 starts up properly.
What builds came in between ?
The builds (i.e. the regular 32-bit Windows binary and the special Windows XP GUI that's currently only available as an actions artefact) work fine on my Windows XP virtual machine, but I do have DirectX 9.0c installed there (I don't recall installing it explicitly, so it must've been already installed with the rest of the system), and that message is hinting that it might be missing. Please try installing DirectX 9.0c and report back.

We don't make use of any DirectX functions directly, but I suppose the dependencies might be injected there indirectly by the compiler and/or the runtime library. The previous (i.e. pre-github) versions were compiled with a different compiler than the one we're currently using, so it is the most obvious suspect.
Quote:
Originally Posted by filler56789 View Post
Regarding XP especifically, many posts ago I suggested that someone should create a dot-NET GUI for tsMuxer because everybody knows the QT devilopers are totally Linux-centric so to speak
Qt is well supported on Windows. If you want to make a new GUI, by all means go ahead - the current GUI source is there to help you, but be aware that it does show its age and there's a lot of stuff that certainly isn't obvious at first glance. Also remember that the GUI is tied to the main binary version by the syntax of the "stream detection mode" output so the GUI can obtain necessary track information. However, seeing how we're trying to maintain backwards compatibility, old versions of the syntax will probably remain supported if it ever changes, potentially with limited functionality.

Last edited by BloodyRipper; 26th June 2020 at 21:40.
BloodyRipper 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 17:26.


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