Open Bug 1132797 Opened 9 years ago Updated 2 years ago

Resolve intended meaning of GMPBufferType and fix existing code to agree

Categories

(Core :: Audio/Video: GMP, defect, P3)

defect

Tracking

()

People

(Reporter: kinetik, Unassigned)

References

Details

GMPBufferType appears to be implicitly defined as a host-endian value, which makes sense as the rest of the API also does this.

However, GMPVideoCodecType::kGMPVideoCodecH264 has the following documentation:

"Encoded frames are in AVCC format; NAL length field of 4 bytes, followed by
frame data. May be multiple NALUs per sample. Codec specific extra data is
the AVCC extra data (in AVCC format)."

And the NAL length field in AVCC is big-endian.

Reviewing the current code using this API that I have access to, we have the following situation:

WebrtcGmpVideoEncoder treats GMP_BufferLength16 and 32 as host-endian and GMP_BufferLength24 as little-endian.

WebrtcGmpVideoDecoder treats GMP_BufferLength32 as host-endian.

GMPVideoDecoder treats GMP_BufferLength32 as big-endian (by simply passing AVCC data through directly, as the GMPVideoCodecType::kGMPVideoCodecH264 comment suggests is intended).

Prior to the refactoring in bug 1128794, EMEH264Decoder treated GMP_BufferLength32 as big-endian, and continues to do so by now sharing the code with GMPVideoDecoder.

FakeVideoEncoder treats GMP_BufferLength32 as host-endian, but contains a comment about converting to network byte order (big-endian).

VideoDecoder from gmp-clearkey treats GMP_BufferLength32 as big-endian.

OpenH264VideoEncoder and Openh264VideoDecoder treat GMP_BufferLength32 as host-endian.
Blocks: 1121258
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Component: Audio/Video: MediaStreamGraph → Audio/Video: GMP
Rank: 28
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.