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.
convertUTF.h typedefed the UTF32 type as unsigned long, which is really 64-bit
wide on LP64 platforms. Since there is a number of casts, mostly around
utf8Converter.cpp, which assume that UTF32 is 32 bits and no more, this caused
some of the pointers to point outside of their respective arrays due to pointer
arithmetic adding an offset of 8 instead of 4.
This naturally never occured on Windows, because it uses 32 bits for longs, and
the problematic code was never actually really hit because sizeof(wchar_t) on
Windows is 2, which means that the code which needed to cast to UTF32 was never
executed.
Fixes#69.
