In WebCodecs, VideoDecoder is expected to return the error if decode fails, but decoding some corrupt H264 data is unexpectedly okay on Windows. More specifically, [this test](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/testing/web-platform/tests/webcodecs/videoDecoder-codec-specific.https.any.js#466) creates a corrupt H264 data in AVCC format, and then try decoding it. The expected result is to get an error, but the expected error isn't returned from our decoder. > Input data must conform to Annex B of ISO/IEC 14496-10. The data must include the start codes. The decoder skips bytes until it finds a valid sequence parameter set (SPS) and picture parameter set (PPS) in the byte stream. Since [Windows's H264 decoder](https://learn.microsoft.com/en-us/windows/win32/medfound/h-264-video-decoder) only accepts H264 data [in Annex B format](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wmf/WMFVideoMFTManager.h#51-54), `H264ChangeMonitor` will convert the the data [into AnnexB format](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#123) if the format is AVCC. What happens is that the conversion is unexpected okay, and surprisingly the converted data cause no issue to our decoder. The decoder will [return `MF_E_TRANSFORM_NEED_MORE_INPUT`](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wmf/MFTDecoder.cpp#334,346) in the test mentioned above, which is a normal signal asking for more data. I think we should rework [`AnnexB::ConvertSampleToAnnexB`](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/agnostic/bytestreams/AnnexB.cpp#18) so that we can catch the corrupt data during the conversion.
Bug 1848193 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In WebCodecs, VideoDecoder is expected to return the error if decode fails, but decoding some corrupt H264 data is unexpectedly okay on Windows. More specifically, [this test](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/testing/web-platform/tests/webcodecs/videoDecoder-codec-specific.https.any.js#466) creates a corrupt H264 data in AVCC format, and then try decoding it. The expected result is to get an error, but the expected error isn't returned from our decoder. > Input data must conform to Annex B of ISO/IEC 14496-10. The data must include the start codes. The decoder skips bytes until it finds a valid sequence parameter set (SPS) and picture parameter set (PPS) in the byte stream. Since [Windows's H264 decoder](https://learn.microsoft.com/en-us/windows/win32/medfound/h-264-video-decoder) only accepts H264 data [in Annex B format](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wmf/WMFVideoMFTManager.h#51-54), `H264ChangeMonitor` will convert the the data [into AnnexB format](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#123) if the format is AVCC. What happens is that the conversion is unexpected okay, and surprisingly the converted data cause no issue to our decoder. The decoder will [return `MF_E_TRANSFORM_NEED_MORE_INPUT`](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/wmf/MFTDecoder.cpp#334,346) in the test mentioned above, but which is a normal signal asking for more data. I think we should rework [`AnnexB::ConvertSampleToAnnexB`](https://searchfox.org/mozilla-central/rev/503938c13ef2dd174705dc0f6d0683ae43074ccc/dom/media/platforms/agnostic/bytestreams/AnnexB.cpp#18) so that we can catch the corrupt data during the conversion.