I’ve reproduced locally on a netbook with i3-6157U, it has Iris 550. My client found on UHD Graphics 630. We both running Windows 10 64 bit.
Steps to reproduce:
1. Write a code that encodes h265 video with hardware encoder, using a sink writer.
2. Use a custom IMFMediaTypeHandler implementation to get notified when the framework calls SetCurrentMediaType. In the handler, query the new media type for MF_MT_MPEG_SEQUENCE_HEADER attribute.
3. Start encoding.
Expected result: when encoding starts, the framework should call SetCurrentMediaType, and the new one should contain MF_MT_MPEG_SEQUENCE_HEADER blob.
Actual result on Iris 550: SetCurrentMediaType is indeed called a couple of times, but the new media type never contains MF_MT_MPEG_SEQUENCE_HEADER blob.
The only way to get the information from Intel’s encoder, parse h265 bitstream generated by encoder, looking for 3 NALUs with VPS, SPS and PPS, then merge the 3 NALUs into the sequence header. The workaround has non-trivial performance costs. H265 Annex B bitstream is expensive to parse in software, NALUs don’t have lengths only start codes, need to parse the complete bit stream.
Tutorial: Using the Sink Writer to Encode Video https://docs.microsoft.com/en-us/windows/win32/medfound/tutorial--using-the-sink-writer-to-encode-vi...
H.265: High efficiency video coding https://www.itu.int/rec/T-REC-H.265-201906-I/en
P.S. nVidia’s hardware h265 encoder implemented in GeForce 1080 Ti updates the media type and provides the correct MF_MT_MPEG_SEQUENCE_HEADER blob.
P.P.S. Intel's hardware h264 encoder doesn't have this bug either. It correctly updates the media type, and provides the good sequence header blob (in case of h264 it only has 2 NALUs, SPS and PPS, the third one, VPS, was introduced in h265). The bug is specific to h265 i.e. MFVideoFormat_HEVC video subtype.