Initial PTS offset is set to 378000000 (in 90000 Hz) which is 1h10min.
Commercial Blu-ray initial offsets are generally 10-12 sec.
PTS offset is reduced to 900000 = 10 sec.
The size of the data read from the stream and copied to the buffer should be limited to DEFAULT_FILE_BLOCK_SIZE to avoid the 'Not enough buffer for parse video stream' error.
Left-shifting by an amount which is more or equal to the type's width is undefined in both C and C++. This could happen in BitStreamWriter when m_bitWrited was zero, and resulted in inconsistent results between Intel and ARM targets.
On Intel, the amount of bits to shift is explicitly masked to its lower 5 (for 32-bit values) or 6 (for 64-bit values) bits. This is documented in the instruction set reference. Effectively, the amount of bits to be shifted is the actual amount modulo 32 or 64. In this particular case, asking the CPU to shift by 32 bits left the value unchanged.
ARM does not place any requirements on the behaviour of the CPU when the amount to shift is larger than 32/64 - the instruction set reference just says that the register is supposed to be "holding a shift amount from 0 to 31 in its bottom 5 bits. ". However, MSVC documentation suggests that values in registers might appear to "wrap around" when shifting by more than 32 or 64 bits, which is indeed what was observed here.
The fix essentially amounts to emulating Intel behaviour (as it was the original development platform and presumably most assumptions were made with it in mind, even if unknowingly) by not touching the value if the amount of bits to shift is 32.
AddString's documentation clearly says that its second parameter is supposed to
be the number of characters to display. Since the vector returned by toWide() is
always null-terminated and the termination character is included in its size(),
this resulted in AddString() treating the termination character as something it
is supposed to actually draw.
Perhaps some versions of AddString() explicitly stop at the termination
character and don't process any further characters : this is probably why this
issue has gone unnoticed for so long.
Fixes#598
As per ECMA 167 [8.3.1 File Set Descriptor Sequence], there should be a Terminating Descriptor after the File Set Descriptor
Plus renaming "ExtentFile" to "ExtendedFileEntry" to comply with UDF 2.50 / ECMA 167 name.
jcdr428
jcdr428
Daniel Kamil Kozar
Dan
quietvoid