pub struct Spatial {
pub st3d: Option<St3d>,
pub sv3d: Option<Sv3d>,
pub vexu: Option<Vexu>,
pub hfov: Option<Hfov>,
pub unknown: Vec<Any>,
}Expand description
The projection and stereo boxes of a visual sample entry. Entries hold it
as spatial: Option<Box<Spatial>>, since it is large and usually absent.
Each sample entry writes these boxes just before pasp: Spherical Video
V2 requires st3d and sv3d ahead of the optional clap and pasp, and
ISO/IEC 14496-12 §12.1.4.1 wants pasp and clap after the boxes of
other specifications. st3d comes first, as V2 asks, and in any case
before vexu and hfov: a reader may refuse an st3d that arrives after
another box has set the stereo layout. Apple does not constrain where
vexu and hfov go.
None of these boxes or their children are in Any. They only mean
something inside a sample entry, and several reuse the fourccs of
unrelated boxes (two different proj, two different equi, and ISO’s
sub-track stri). Their containers decode children by header instead.
A box that repeats, or does not decode, never fails the sample entry: its
parent keeps it verbatim, as an Any::Unknown in unknown, and logs a
warning. Children this crate does not model are kept there too. On encode,
a kept box of a modelled kind goes back at that kind’s position, because
readers may depend on the order of children.
A writer may set both families, describing the same projection: a reader that understands both may use either one. The members’ docs say what a writer should set.
Fields§
§st3d: Option<St3d>§sv3d: Option<Sv3d>§vexu: Option<Vexu>§hfov: Option<Hfov>§unknown: Vec<Any>st3d, sv3d, vexu or hfov boxes that repeat or did not decode.