Fix HEVC TS extra data construction for 3-byte start codes#2057
Conversation
|
Decision: APPROVE Issues: none Evidence:
Review Details
|
CastagnaIT
left a comment
There was a problem hiding this comment.
thank you for the fix
please address the code comments
The VPS/SPS/PPS copy assumed 4-byte start codes on both ends, so with 3-byte start codes it prepended a stray byte (extra data misdetected as hvcC) and truncated the NAL's last byte (corrupt PPS). Emit a clean Annex-B start code and copy only the NAL, mirroring the H.264 path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
98634c2 to
ca06c19
Compare
|
Thanks for the comments, those four have been addressed with the latest push. |
|
@kodiai review |
|
Decision: APPROVE Issues: none Evidence:
|
Description
The VPS/SPS/PPS copy assumed 4-byte start codes on both ends, so with 3-byte start codes it prepended a stray byte (extra data misdetected as hvcC) and truncated the NAL's last byte (corrupt PPS). Emit a clean Annex-B start code and copy only the NAL, mirroring the H.264 path.
Motivation and context
Playback of 4k HEVC streams is failing with inputstream.adaptive while working with inputstream.ffmpegdirect.
This is a demuxer bug, independent of and complementary to xbmc/xbmc#28103. #28103 fixes Kodi's VAAPI path allocating 8-bit (NV12) surfaces for 10-bit HEVC; this fixes the invalid HEVC extra data emitted by the MPEG-TS demuxer. Software decoding plays on both platforms - it's the hardware paths that fail, for different reasons:
CBitstreamConvertermis-detects it as hvcC and can't convert.How has this been tested?
A test build for Android V22 was created and playback is now successful.
On Linux, without PR28103, the parallel_merge error is removed but playback still fails.
Types of change
Checklist: