[mpegts] Enlarge H.264 SPS/PPS raw_data buffers to 256 bytes#2086
Conversation
|
Decision: APPROVE Issues: none Evidence:
Review Details
|
The per-NAL raw_data buffers used to build the codec extra data were only 64 bytes. Some SPS with full VUI/HRD parameters can exceed that (e.g. Wowza-originated HLS), so the SPS was silently dropped (raw_data_size reset to 0) and the H.264 extra data ended up empty. Kodi then rejects the video stream with "Codec id 27 require extradata" and disables it, leaving an audio-only stream that immediately hits EOF. Increase the SPS/PPS raw_data buffers to 256 bytes so that for some large SPS extra data is built correctly.
9ae1d8e to
c9fc8ee
Compare
| uint8_t extra_data[1024]; | ||
| int extra_data_size; |
There was a problem hiding this comment.
a better change should be replace both with a std::vector<uint8_t>
so that the size is not hardcoded but dynamic, you will solve the problem at the root
but its fine anyway if you want to keep it like this
There was a problem hiding this comment.
It is a good idea, I will create it in another PR to test it better.
CastagnaIT
left a comment
There was a problem hiding this comment.
thanks for the fix, please backport
Description
The per-NAL raw_data buffers used to build the codec extra data were only 64 bytes. Some SPS with full VUI/HRD parameters can exceed that (e.g. Wowza-originated HLS), so the SPS was silently dropped (raw_data_size reset to 0) and the H.264 extra data ended up empty.
Kodi then rejects the video stream with "Codec id 27 require extradata" and disables it, leaving an audio-only stream that immediately hits EOF.
Increase the SPS/PPS raw_data buffers to 256 bytes so that for some large SPS extra data is built correctly.
Also extra_data was increase from 512 to 1024 to accommodate rare situations.
NAL buffers are now 256 bytes each, so a single legitimate SPS+PPS can be up to 4+255+4+255 = 518 bytes. With only 512, the guard I added would correctly refuse to overflow — but it would then drop a valid PPS, silently reintroducing a decode failure. 1024 ensures the destination can hold whatever the 256-byte NAL buffers can legitimately produce. The guard prevents the crash; the 1024 prevents truncation.
Motivation and context
Fix some streams that are not playing due to small buffer size.
How has this been tested?
Tested on Kodi 21 with a custom IA build. The falling stream was now able to be played. No regression on other streams
Screenshots (if appropriate):
Stream: https://streamtv.novotempo.com/CDN-TV-PT/smil:tvnovotempo.smil/playlist.m3u8
12:07:59.315 CDVDDemuxClient::RequestStream(): added/updated stream 1001 with codec_id 27
12:07:59.315 CDVDDemuxClient::RequestStream(): added/updated stream 1002 with codec_id 86018
12:07:59.316 Opening stream: 1001 source: 256
12:07:59.932 [WHITELIST] Searching the whitelist for: width: 1280, height: 720, fps: 29.970, 3D: false
12:07:59.979 error: OpenStream: Codec id 27 require extradata.
12:07:59.979 warning: OpenStream - Unsupported stream 1001. Stream disabled.
12:07:59.979 Opening stream: 1002 source: 256
12:08:00.004 CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder aac
12:08:00.034 Process - eof reading from demuxer
Types of change
Checklist: