Skip to content

PATTERN Cited by 1 source

Asymmetric send-receive codec

Allow each side of a video call to use a different codec for sending vs receiving, exploiting the fundamental asymmetry between encoding complexity (high) and decoding complexity (lower) to maximize fleet-wide coverage of the higher-quality codec.

Structure

  1. Negotiate support for multiple codecs at call setup.
  2. Classify each device's capability independently for encoding and decoding via patterns/ml-based-device-eligibility.
  3. If a device can decode AV1 but cannot encode it in real-time → it receives AV1 from capable peers but sends H.264.
  4. The peer (high-end device) receives H.264 and decodes it trivially.

Outcome

  • The weaker device still benefits from AV1's compression efficiency on its incoming video stream.
  • AV1 coverage expands from "both-sides-capable" to "at-least-one-side-capable."
  • At fleet scale, this significantly increases the fraction of calls benefiting from AV1 quality.

When to apply

  • A newer codec offers better compression but requires significantly more compute for encoding than decoding.
  • The device fleet is heterogeneous (mix of high-end and mid/low-end).
  • Both codecs can be negotiated and the runtime can switch per-direction dynamically.

Canonical instance

Meta's AV1 RTC deployment (Source: sources/2026-06-22-meta-adopting-av1-for-real-time-communication-rtc-at-scale): mid-range Android devices that cannot encode AV1 can still decode it, so they receive AV1 from high-end peers while sending H.264.

Seen in

Last updated · 559 distilled / 1,651 read