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 29th August 2019, 14:45   #61  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Gser View Post
Demuxing DTS-HD files with the lossless part included also produces non-compliant .dts files (should be .dtshd) that DTS-HD Master Audio Suite fails to recognize. eac3to and mkvextract also have this problem.
IIRC, it's because the Master Audio Suite and the certified BD authoring tools expect that the .DTSHD files
(High-Resolution Audio, Lossless with or without the "core", and DTS Express)
include a header and a footer — but the containers, even the Blu-Ray transport stream, are not expected to store the DTSHD header and footer.

EDIT — I wrote "even the Blu-Ray transport stream" but
I should have written «especially the Blu-Ray transport stream», because
a transport stream cannot have global headers.

Last edited by filler56789; 29th August 2019 at 23:51.
filler56789 is offline   Reply With Quote
Old 11th September 2019, 21:50   #62  |  Link
outgoing
Registered User
 
Join Date: Aug 2018
Posts: 68
any progress in the tsMuxer project?
outgoing is offline   Reply With Quote
Old 13th September 2019, 10:12   #63  |  Link
TEB
Registered User
 
Join Date: Feb 2003
Location: Palmcoast of Norway
Posts: 363
I have access on a Harmonic A/V Analyser at work, and i can run through some TS files and check for compliancy if its needed!
TEB is offline   Reply With Quote
Old 15th September 2019, 06:25   #64  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by outgoing View Post
any progress in the tsMuxer project?
Not yet, sadly

But while the bug fixes and the enhancements don't happen, I have a couple of suggestions:

1) an overdue update to the README.md — for example, the instructions for building tsMuxer with MinGW-w64 && MSYS2 are not entirely correct, in fact they are a bit misleading;

2) forget the QT-based GUI and replace it with a .NET/Mono one — I think stax76 could do this
filler56789 is offline   Reply With Quote
Old 15th September 2019, 08:51   #65  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
forget the QT-based GUI and replace it with a .NET/Mono one
Why? (personally I prefer Qt/C++ over .NET)
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 15th September 2019, 10:27   #66  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Selur View Post
Why? (personally I prefer Qt/C++ over .NET)
Good question
In other words, I don't have a good answer for that.

Personally I would like a GUI which could be [easily] compiled in MinGW-w64, just like Xvid's VfW configuration dialog can...
but then perhaps I would be "asking for too much"

Last edited by filler56789; 15th September 2019 at 10:38. Reason: disambiguation
filler56789 is offline   Reply With Quote
Old 16th September 2019, 04:16   #67  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
And FWIW, a new issue has been opened
(but not by me)

https://github.com/justdan96/tsMuxer/issues/9
filler56789 is offline   Reply With Quote
Old 17th September 2019, 08:26   #68  |  Link
justdan96
Registered User
 
Join Date: Jun 2019
Location: UK
Posts: 49
I've been able to get a build pipeline working to easily create Windows and Linux builds using Docker, I'll next try to add Mac and if that all appears to work I'll push to the repo. The readme will have to be updated for sure but it's going to make compiling a heck of a lot easier. I'll add the binaries that are produced to the repo as well.

Sorry for the recent lack of updates, my job has been keeping me very busy recently. If there is anyone else who wants to get involved please do - pull requests are always welcome!
justdan96 is offline   Reply With Quote
Old 17th September 2019, 09:39   #69  |  Link
staina
Registered User
 
Join Date: Feb 2013
Posts: 67
When will release new version supporting UHD Bluray, eventually how is far her development?

Thank you Staina
staina is offline   Reply With Quote
Old 19th September 2019, 21:38   #70  |  Link
justdan96
Registered User
 
Join Date: Jun 2019
Location: UK
Posts: 49
At the moment I'm focusing on being able to consistently produce binaries for all platforms (Windows, Linux, Mac) and ensuring that the output is bug-free.
justdan96 is offline   Reply With Quote
Old 22nd September 2019, 09:04   #71  |  Link
outgoing
Registered User
 
Join Date: Aug 2018
Posts: 68
Thanks anyway to everyone involved in the development of this excellent program.
outgoing is offline   Reply With Quote
Old 16th October 2019, 09:03   #72  |  Link
staina
Registered User
 
Join Date: Feb 2013
Posts: 67
Quote:
Originally Posted by r0lZ View Post
Most of the times, it works fine, because the subtitles streams are stored in the MPLS in the order of their PID, like this:
(The first number is the order in the playlist, the second is the PID.)
1. 4608 ENG - 3D-Planes 1
2. 4609 JPN - 3D-Planes 2
3, 4610 TUR - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
But that order is not at all mandatory. The streams can be stored in the MPLS in a different order, like this:
1. 4608 ENG - 3D-Planes 1
2, 4610 TUR - 3D-Planes 2
3. 4609 JPN - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
Note the inversion of the PID of streams 2 and 3. The two streams are stored in a relatively unusual order, but it's perfectly legal, and that happens! In the example above, the 3D-Planes are correctly assigned, because they are tied to the correct stream, in the order of the playlist. But tsMuxeR fails, when it show the information for such a 3D BD, because it assumes that the streams are stored in the order of their PID:
1. 4608 ENG - 3D-Planes 1
3, 4609 JPN - 3D-Planes 2
2. 4610 TUR - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
The effect is that, in this example, streams 2 and 3 have the wrong 3D-Planes.

Note also that sometimes, a MPLS doesn't references all streams. Some subtitle streams are present in the M2TS, but not in the MPLS, like this:
1. 4608 ENG - 3D-Planes 1
X. 4609 JPN
2. 4610 TUR - 3D-Planes 2
3. 4611 RUS - 3D-Planes 3
4. 4612 POL - 3D-Planes 4
In this example, the JPN track is not referenced in the MPLS, and therefore it cannot be selected when that MPLS is played with a real BD player. I call it a "phantom stream", present in the M2TS, but not in the MPLS. Usually, another MPLS references that stream normally. I have no idea why some BDs are authored that way, but it's relatively frequent, especially for the Japanese language.
As a consequence, in this example, the JPN track has no 3D-Plane assigned (in this MPLS of course). BDSup2Sub should simply omit it, and display only the streams referenced in the MPLS, like this:
1. 4608 ENG - 3D-Planes 1
2. 4610 TUR - 3D-Planes 2
3. 4611 RUS - 3D-Planes 3
4. 4612 POL - 3D-Planes 4
But it doesn't do that. Again, it assumes wrongly that the 3D-Planes must be assigned one at a time to all streams in the M2TS, in the order of their PID, and it shows this:
1. 4608 ENG - 3D-Planes 1
X. 4609 JPN - 3D-Planes 2
2. 4610 TUR - 3D-Planes 3
3. 4611 RUS - 3D-Planes 4
4. 4612 POL
Again, it's completely wrong (except for the first track). The unreferenced JPN track appears where it should be hidden, and it inherits the 3D-Plane of the next stream. Then, all 3D-Planes are off by 1. And the POL stream has lost its 3D-Plane completely.

I think that the problem is that tsMuxeR doesn't use really the MPLS to retrieve its information, at least for the stuff related to the 3D-Planes. Since it is a muxer/demuxer, it prefers to trust what it finds in the M2TS (or SSIF) files, and it assumes that the PIDs of the streams determines their order. But that's not correct. The 3D-Plane numbers are stored in the MPLS and are based on the information and order from the same MPLS.

Trust me, I have studied closely that bug, after several problems I have encountered when I have written BD3D2MK3D. It's obviously a major bug. BTW, you can use my program to examine how the 3D-Planes are assigned to the subtitle streams. I have written my own MPLS parser, because it was impossible to trust the 3D-Planes information displayed by tsMuxeR.
You're right, checked I'm my 3D movies and at some is 3D-plane other in tsMuxer compared to BD3D2MK3D. I hope that the BD3D2MK3D displays these value right so I shall have to these 3D movies recreate.
staina is offline   Reply With Quote
Old 16th October 2019, 09:32   #73  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
Yes, the 3D-Plane list is right in BD3D2MK3D, because it is extracted from the MPLS file, and not guessed blindly like with tsMuxer.

@ developers: This is an important bug. Please do not forget it when you will fix the tsMuxer bugs. Thanks in advance.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV

Last edited by r0lZ; 28th February 2020 at 11:19. Reason: typo
r0lZ is offline   Reply With Quote
Old 25th October 2019, 22:09   #74  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Bug creating unsynchronized HEVC streams

Hi all, before all I thank the tsMuxer developer for his fantastic software, and for accepting to release the source code.

Quote:
Originally Posted by jdobbs View Post
it misses frames, or more accurately it thinks some frames are a part of a previous frame and muxes them as a part of it. The result is a stream that gets progressively more out of sync (at least those that are encoded for blu-ray UHD by X265)
There is a bug creating unsynchronized AV with some HEVC files, due to insufficient size of coded picture buffer.
In brief, when reading a nal the end of the buffer is reached before finding the next nal start_code, and the PTS is not incremented for this nal.

(Edit: correction changed)
I have corrected the bug on my side by simply changing the line 7 in avPacket.h from:
Code:
const static int MAX_AV_PACKET_SIZE = 32768;
to
Code:
const static int MAX_AV_PACKET_SIZE = 800000;
I am not a developer and have limited coding knowledge, so I won't submit a patch.

Last edited by a5180007; 4th November 2019 at 22:17. Reason: Added jdobbs quote
a5180007 is offline   Reply With Quote
Old 26th October 2019, 21:24   #75  |  Link
a5180007
Registered User
 
Join Date: Jun 2014
Location: Marrakech, Morocco
Posts: 253
Quote:
Originally Posted by jdobbs View Post
It also uses the wrong stream type
Replace lines 41 and 42 in tsPacket.h
Code:
//static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x06;
with
Code:
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
// static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x25; /* HEVC conforming to profile */
Edit note: should normally be 0x25, but seems to be 0x24 in UHD Blu-rays

Last edited by a5180007; 26th October 2019 at 21:34. Reason: Edit note
a5180007 is offline   Reply With Quote
Old 26th October 2019, 21:41   #76  |  Link
justdan96
Registered User
 
Join Date: Jun 2019
Location: UK
Posts: 49
What would be the simplest way to check that these changes have resolved the issues?
justdan96 is offline   Reply With Quote
Old 26th October 2019, 23:41   #77  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by a5180007 View Post
Replace lines 41 and 42 in tsPacket.h
Code:
//static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x06;
with
Code:
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
// static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x25; /* HEVC conforming to profile */
Edit note: should normally be 0x25, but seems to be 0x24 in UHD Blu-rays
Thanks for chiming in.
But an actual solution should be not a mere replacement, but an additional possibility plus a "Select_Case" thing

(apologies for the VBspeak ).

Because tsMuxer is a transport stream multiplexer, not only a basic Blu-Ray authoring tool.
filler56789 is offline   Reply With Quote
Old 31st October 2019, 12:52   #78  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by staina View Post
When will release new version supporting UHD Bluray, eventually how is far her development?
Very far, sadly.

And the fact that the new tsMuxeR is becoming Linux-centric (so to speak) only makes things worse IMNSHO.
filler56789 is offline   Reply With Quote
Old 4th November 2019, 03:43   #79  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Okay, since the GitHub repository was created 3.5 months ago and the owner has released ZERO binaries thus far, here go two CLI .exes built from the "improved" source-code...
Notice, the "improved" source-code requires a POSIX-threaded compiler, so I had to download old packages from the MinGW-w64 project @ SourceForge and use them in my MSYS2 environment; no way I would screw my MSYS2 setup with the "toolchains" provided by the MSYS2 devilopers.
The 32-bit binary seems to be OK; the 64-bit .EXE requires the three DLLs included in the archive.
No GUI because I have no interest in downloading the terabyte-sized QT5 stuff.

LINK: http://www.mediafire.com/file/mx0pzj...reads.rar/file

Last edited by filler56789; 4th November 2019 at 03:45. Reason: typo
filler56789 is offline   Reply With Quote
Old 6th November 2019, 10:48   #80  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by nevcairiel View Post
Its a shame that they don't want to implement the stuff with native threading. winpthreads is kinda crappy.
Especially since someone already did all the work and made a header file with std::thread support for win32 threading model as well.

https://github.com/meganz/mingw-std-threads
Many thanks for the useful post, nevcairiel

I followed the instructions and managed to build the new tsMuxeR with the Win32-threaded GCC
filler56789 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 14:28.


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