The repository now contains a clang-format file which should be used when committing new code. Additionally, a new workflow job is added which checks the conformance of source files to the specified formatting rules.
Fixes#47.
For w64, data length includes data metadata (16 bytes) and size (8 bytes)
So 24 bytes have to be substracted from the length read in the stream.
For lpcm, tsMuxer considers frames of 5 ms and rounds up the last block for frame alignment.
So it is normal for the demux to be slightly larger thant the original wav stream.
Fixes#136.
* Don't include <QtGui>, which is a leftover from Qt4 and causes literally
everything to be pulled into the TU.
* Use forward declarations instead of includes where possible.
* Replace aggregated Ui* classes with aggregation via pointer, which allows
these classes to be forward-declared and thus further reduce the number of
included headers. Aggregation via pointer has been the default in Qt Creator
for some time now.
* Fix minor warnings reported by Clang.
* Move QnCheckBoxedHeaderView to a separate file.
* Move QtvCodecInfo to a separate file, change initializer list to inline member initialization.
* Create an actual QMake .pro file instead of stuffing it in MXE build scripts.
* Fix 32-bit integers being used as pointers to QtvCodecInfo objects in 64-bit Windows builds.
* Update information in the "About" tab.
Limiting the reading pace of packets to the Bluray Tranfer Rate value actually creates another issue -timegap between two PCR packets create by tsMuxer can be larger than 100ms.
This issue can be worse than the one solved...
I haven't managed to solve this new issue, so for the time being I prefer to revert on the previous merge #101.
Version is automatically switched to V3 when HEVC is detected.
In case the user wants to force the V3 format for AVC, he will be able to do it via the V3 option in the Blu-ray tab.
tsMuxer called FT_Done_Face also if FT_New_Face reported an error. This caused
FT_Done_Face to be fed with a pointer that was either already freed in a
previous iteration of the loop, or was totally uninitialised from the start.
Fixes#63
fps info can be either in VPS or SPS nal, or both, or none.
tsMuxer reads fps from VPS nal only.
This patch allows tsMuxer to find fps in SPS when not present in VPS.
Plus bug sorted out in flags reading (8 bits in lieu of 1 bit)
I_end values in ClipInf CPI Table are determined by thresholds on I-frame sizes.
These threshold sizes are different for TS_Recording_Rate <= 60000000 (HD), and for TS_Recording_Rate > 60000000 (4K).
This patch solves issue #107
The commit must be merged after commit #111 for V3_flags / Dolby Vision Integration.
- Separate the V3 flags (for index.bdmv) from the HDR metadata (for .mpls)
- With V3_flags the UHD_BLURAY DiskType is not needed anymore
- Add subpath for Dolby Vision
- Change BD Type to 66/100 GB and TS-Recording_Rate to 109 mbps when 4K is detected
Since AppImage essentially creates a separate filesystem that the GUI binary
runs from, it's not possible for it to be aware of the existence of the main
binary that's alongside the actual AppImage file that's supposed to be run by
the end user.
The only solution to this that I can see now is copying the main binary into the
AppDir, which makes the file reside alongside the GUI binary inside the
filesystem that AppImage creates.
Fixes#103.
The BD Player cannot read faster than the TS_Recording_Rate.
The TS_Recording_Rate is hereby fixed to 6 MB/s for 2K (25/50 GB disk), and 13.625 MB/s for 4K (66/100 GB Disk).
Therefore the difference of ATS between two consecutive packets cannot be less than 846 PCR units for 2K, and 373 PCR units for 4K.
Those two values have been checked to be the standard for ATS difference between two video packets in several commercial HD and UHD Blu-rays.
As per T-REC.H-222.0 (ISO/IEC 13818-1) Table 2-22, video stream_id is 1110 xxxx for video stream number xxxx.
As checked on multiple commercial Blu-rays, video stream_id should be 1, not 0.
This fix solves error reported by `BD-ROM Part3 Verifier`:
`----------------------------------------------
Error ID : HEVC0116
Target File : 00000.m2ts <HEVC PID=0x1011>
Target Field : <PES packet of the HDMV HEVC video stream>.stream_id
Section No : 9.19.7
Error Message : stream_id is set to 0xe0.
File offset of PES packet = 776.
Explanation : stream_id: This field shall be set to 1110 0001b.
- - - - - - - - - - - - - - - - - - - - - - -
[HEVC0116] : 346 times.
----------------------------------------------`
Currently tsMuxer does not detect suffix nals (non VCL nals placed after the VCL nals in the nal unit).
Therefore these nals are placed first in the TS PES, before the AUD or next frame nal.
This patch fixes the above.
Unfortunately, we don't have enough history to be able to tell for sure, but it
seems like this was introduced somewhere between 2.6.12 and 2.6.13. The only
reason for this replacement that I can see is trying to prevent the shell from
treating the space-separated parts of the file paths as separate tokens.
Unfortunately, the string returned by QDir::tempPath() can legitimately contain
spaces, as there is nothing preventing the user from having a "fancy" temporary
directory path.
The real reason behind this line remains unknown. tsMuxer GUI currently doesn't
use shell for spawning processes, and arguments to the binary are properly
passed as a QStringList instead of one long string with command and arguments,
where the described issue could actually occur.
Fixes#93.
Currently tsMuxer does not detect suffix nals (non VCL nals placed after the VCL nals in the nal unit).
Therefore these nals are placed first in the TS PES, before the AUD or next frame nal.
This patch fixes the above.
Currently tsMuxer does not detect suffix nals (non VCL nals placed after the VCL nals in the nal unit).
Therefore these nals are placed first in the TS PES, before the AUD or next frame nal.
This patch fixes the above.
Currently, buffer overflow is not avoided in all cases, i.e. nextNal can have end buffer value instead of start of next nal value.
This results in the AUD NAL not being always at the begining of a PES packet.
This patch solves this by ensuring that when nextNal == bufEnd, data is always added to buffer.
The original code paired the position inside the langComboBox with an address
into the shortLangList/fullLangList arrays by leveraging the second QVariant
argument of QComboBox::addItem. This was achieved by casting the pointer firstly
to a void*, and then to a qulonglong. However, the code using these QVariants
in QComboBox signal handler functions has since been changed to always call
toString(), which was incorrect and led to addresses being shown in the UI in
the form of longish decimal numbers.
Funnily enough, it looks like these shenanigans weren't even really needed : the
only part of the language pair used in the signal handler functions is the
three-letter code, which can be simply converted to a QString at the time
QComboBox::addItem is called.
Fixes#87.
