Choosing video codec IP: specify more than H.264 or H.265

Turn the codec name into an implementation contract

ITU-T H.264 and H.265 define video-coding standards; they are not complete product descriptions for a particular IP block. For each required standard, record encode/decode direction, profile, level and—where applicable—tier, bit depth, chroma format, dimensions and frame rate. A decoder qualification does not establish encoder capability, and an 8-bit mode does not establish a 10-bit mode.

Identify the exact configuration to be licensed. A technology roadmap or research architecture may discuss more standards than a released core supports. Ask for a versioned support matrix, conformance evidence and representative output streams that your receiving equipment can actually decode.

Sources: 1 · 2

Specify simultaneous streams and memory traffic

Two UHD 3840 × 2160 streams at 60 fps represent 995.328 million active pixels/s in total. Four 1920 × 1080 streams at 60 fps total 497.664 million pixels/s. These illustrative pixel counts help size the workload, but equal aggregate pixels/s does not prove equal codec performance: scheduling, references, picture structures and bit depth also matter.

Request peak and sustained memory bandwidth, reference-buffer capacity and behavior when streams start or stop independently. Run encode and decode concurrently if the product requires both. Record clock and memory assumptions so that a single-core benchmark is not mistaken for a complete multi-stream subsystem result.

Evaluate rate, quality and latency together

Use a common clip set and identical quality-measurement rules. Specify target bitrate, permitted bursts, rate-control mode, keyframe interval and buffering constraints. Include high motion, texture, noise and abrupt scene changes. A favorable average bitrate can hide burst behavior that overflows the actual transport or storage budget.

For low-delay operation, timestamp first input, first useful output and complete-picture output separately. State picture reordering and look-ahead assumptions. Compare configurations that meet the same receiver compatibility, quality and latency constraints, rather than treating a software-preset comparison as universal compression superiority.

Qualify the implementation path and handoff

For FPGA, request the exact device, tool version, frequency and LUT/BRAM/DSP usage. For ASIC, request synthesis constraints, process/library assumptions, verification deliverables and physical-design responsibilities. FPGA operation is useful evidence but is not proof of timing, area or power on a different ASIC process. Agree driver, register-model and integration support before selection.

Bring these to your IP evaluation

• Prepare an encode/decode and profile/level support matrix.
• Define simultaneous streams, memory and receiver constraints.
• Request reproducible quality, rate-control and latency results.