demux()'s "not enough data, rewind and try again next time" logic
unconditionally subtracted 4 (or 6) from m_index, assuming that many
bytes were consumed scanning for a start code. But the inner scan can
also exit via reaching the end of the buffer without finding a start
code at all, having consumed fewer bytes than that - when the buffer
holds under 4 bytes total, m_index goes negative, and the subsequent
memmove(m_buf, m_buf + m_index, size) then reads before the start of
m_buf. Clamp the rewind to 0.
read8()/skip() also had no bounds check against m_len (the actual
buffer allocation) at all - readPesHeader()'s header-length fields are
only cross-checked against the outer PES packet length, not against
how much data is actually available, so a crafted stream claiming a
long header could walk m_index past the buffer. Bound both against
m_len directly, at the lowest-level primitives so every caller is
covered.
Fix#13858
1.
Robust Header Detection: Updated MpegDemux::hasNextAudioFrame to scan the buffer for a valid header. This fixes the issue where leading garbage data (often present at chapter starts) would cause the demuxer to report "no data" and get stuck.
2.
ATRAC3+ Alignment: Fixed the header skip logic in demuxStream for the 0x90-0x9F range. It now correctly skips the 4-byte sub-header, ensuring audio frames are properly aligned.
These changes should resolve the "Audio end reach" errors and missing voice in Chapters 2-4
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
Henrik Rydgård