Skip to content

RTP header selects the wrong bit-field layout on macOS #268

Description

@idy

Description

On macOS, libpeer can serialize the first two RTP header octets with the wrong C bit-field layout. For an RTP v2 Opus packet with marker 0 and payload type 111, the encoder emits 02 de instead of the expected 80 6f.

Root cause

src/rtp.h includes <machine/endian.h> in the __APPLE__ branch. That header exposes BYTE_ORDER, BIG_ENDIAN, and LITTLE_ENDIAN, but the later bit-field selection compares __BYTE_ORDER with __BIG_ENDIAN and __LITTLE_ENDIAN.

Because those underscored identifiers are undefined in this branch, the preprocessor evaluates the first comparison as 0 == 0 and selects the big-endian declaration on a little-endian Apple host.

Reproduction

  1. Build libpeer on macOS with Apple Clang.
  2. Initialize an RtpEncoder with CODEC_OPUS.
  3. Encode one payload and inspect the first two bytes passed to the packet callback.
  4. Observe 02 de; compiling the same source with __BYTE_ORDER=__ORDER_LITTLE_ENDIAN__ produces 80 6f.

Expected behavior

The Apple branch should map the endian macros it imports to the identifiers used by the bit-field selection, or the fixed RTP header should be serialized explicitly without relying on implementation-defined C bit-fields.

A minimal fix can bridge BYTE_ORDER to __BYTE_ORDER in the Apple branch. #267 pursues the broader explicit-serialization approach and can be evaluated independently.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions