Using aspect ratios throughout our stack can reduce rounding errors caused by repeatedly computing sizes in pixels.
In particular:
- VideoDecoderConfig stores a |natural_size|, but it is only accurate if the encoded video's |visible_size| matches the configuration. Passing an aspect ratio solves the problem.
- VideoFrame's |natural_size| is usually scaled for display. Passing an aspect ratio could make this more accurate (and remove the need to compute it in decoders).
One issue:
- 1x1 stand-in frames still need an explicit |natural_size|, because otherwise they will appear to be very small. Some overall concept of scale is still required.
One extension:
- H.264 decoders should use in-stream pixel aspect ratio information, but only if the VideoDecoderConfig does not contain an explicit pixel aspect ratio.
Comment 1 by sande...@chromium.org
, Apr 27 2018MP4: 'pasp' box contains pixel aspect ratio, and if present it is authoritative over the stream. WebM: If present, DisplayWidth/DisplayHeight encode natural size. It is undocumented how this relates to in-stream metadata. H.264: Pixel aspect ratio is optional in the VUI (SPS). AOM: Each frame encodes the visible ('display') size and optionally a natural ('rendering') size as well.