Known records represented as JSON, MessagePack, CBOR, BSON, Protobuf, Arrow, and related formats for testing round trips, schema handling, type preservation, and binary decoders.
The records as MessagePack: a compact binary serialization that maps onto the JSON data model, common in caches and RPC. For testing MessagePack codecs and JSON↔MessagePack conversion.
The records as CBOR: the IETF concise binary object representation used in IoT and COSE/WebAuthn. For testing CBOR decoders and JSON↔CBOR conversion.
The records as BSON: the binary-JSON encoding MongoDB stores documents in. For testing BSON decoders and JSON↔BSON conversion.
A single protobuf User message in binary wire format (varint + length-delimited fields): the serialized counterpart to the user.proto schema. For testing protobuf decoders without the generated code.
Valid Protobuf wire record with string, uint32, and string fields for schema-guided decoding. Stable P8 artifact p8-convert-protobuf-source.
Proto3 schema companion declaring the three fields used by the binary creator record. Stable P8 artifact p8-convert-protobuf-schema.
Expected JSON semantic result for the schema-guided Protobuf decode. Stable P8 artifact p8-convert-protobuf-expected.
Valid wire bytes intentionally supplied without a matching schema so tools must preserve unknown field 15. Stable P8 artifact p8-convert-protobuf-missing-schema.
Binary orc source for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-source.
Json semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-json.
Csv semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-csv.
The compiled Polish MO twin. Plural entries are encoded the way msgfmt does it (the original is 'singular\\0plural' and the translation is the 3 forms joined by NUL), and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
The compiled Russian MO twin. Plural entries are encoded the way msgfmt does it (the original is 'singular\\0plural' and the translation is the 3 forms joined by NUL), and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
The compiled Arabic MO twin. Plural entries are encoded the way msgfmt does it (the original is 'singular\\0plural' and the translation is the 6 forms joined by NUL), and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
The compiled Welsh MO twin. Plural entries are encoded the way msgfmt does it (the original is 'singular\\0plural' and the translation is the 6 forms joined by NUL), and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
One span carrying every OTLP AnyValue kind, string (plain, Unicode, multi-line, empty), int64 encoded as a JSON string, double, bool, array, nested kvlist and base64 bytes. Includes an integer above 2^53 to catch decoders that route int64 through a JavaScript number.
Every numeric form the exposition format permits: NaN, +Inf and -Inf, negative zero, denormal and maximum doubles, and a uint64 counter beyond the exact range of a double. Parsers that route values through a JSON number or a 32-bit float fail on this file specifically.
Every geometry in the territory as a bare WKT string, one per line and in master order. Attributes are deliberately absent so the file isolates geometry serialisation from attribute mapping.
The geometry half of a point shapefile: a 100-byte header carrying the shape type and bounding box, then five 20-byte Point records. The file is useless on its own: attributes live in the .dbf and the coordinate system in the .prj, which is the point of shipping the whole component set.
The index that lets a reader seek directly to record N of the .shp instead of walking the file. Its header duplicates the .shp header exactly, and a mismatch between the two is the most common way a hand-edited shapefile goes wrong.
The attribute table as a dBase III file: fixed-width, space-padded, ASCII numerics. Field names are capped at ten characters and there is no type for dates-with-time or for nested values, which is why shapefile export loses so much of a modern schema.
Three single-part PolyLine records, each carrying its own bounding box, a part index and a run of little-endian coordinate doubles. PolyLine and Polygon share this layout, which is why the shape-type byte in the header is the only thing that distinguishes an open line from a closed ring.
Unlike the point index, these entries have different lengths because each PolyLine holds a different number of vertices. That makes it the useful case for testing seek logic: a reader that assumes a fixed stride reads the first record correctly and then garbage.
The road attribute table, including a numeric field declared with two decimal places. DBF stores numbers as right-justified ASCII, so the declared width and decimal count are the only thing that says 9.40 is not 940.
Three Polygon records, one of which has two rings: the Mill Court parcel and its courtyard. Shapefile winds rings the opposite way to GeoJSON (exterior clockwise, holes anticlockwise), and it has no explicit hole marker, so winding is the only signal a reader has.
The parcel index, whose second entry is markedly longer than the others because that record carries two rings. Use it together with the roads index to check that seek logic handles multi-part records as well as multi-record files.
The parcel attribute table, joined to the .shp purely by record order: there is no key and no explicit link. Deleting a geometry without deleting its row shifts every subsequent attribute onto the wrong shape, silently.
A single WKT value for the Kestrel Bay town centre. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the four-vertex Coast Road. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the Mill Court parcel and its courtyard. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for all three parcels in one geometry. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for a point, a line and a polygon in one value. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A point with an explicit Z dimension tag. Some producers write `POINT Z (x y z)` and others write `POINT(x y z)` with no tag at all, so a parser has to cope with the dimension being declared or merely implied by the ordinate count.
A point with an M (measure) ordinate rather than a Z. Written without the tag this is indistinguishable from a Z geometry, and a parser that assumes the third ordinate is elevation silently converts a 345-second measure into a 345-metre altitude.
A three-vertex line carrying both elevation and a measure, so each position has four ordinates. GeoJSON tops out at three, which makes this the fixture that shows what a WKT-to-GeoJSON conversion has to drop and whether it says so.
PostGIS's extended WKT, which prefixes the geometry with `SRID=4326;`. It is not part of the OGC standard, so a strict WKT parser rejects the whole string, while a PostGIS-aware one gets the coordinate system for free.
One EMPTY value for each WKT geometry type, one per line. Empty geometries are what spatial operations return when nothing is left, and round-tripping them is where a database driver usually turns a typed empty into a plain NULL.
Twenty-one raw bytes: a byte-order flag, a little-endian geometry-type code of 1, and two float64 ordinates. This is the wire format PostGIS, GeoPackage and most spatial drivers actually move geometry in.
The same point encoded both ways, plus a polygon, as uppercase hex: the form WKB takes when it travels through a text column or a SQL console. The byte-order flag is the first byte of each string, so the two point encodings differ everywhere after it.
PostGIS EWKB, where the SRID is carried by OR-ing 0x20000000 into the geometry-type word and appending the code. A strict OGC WKB reader sees type 0x20000001 instead of 1 and either fails or, worse, reports an unknown geometry type.
The same harbour light written to 1 decimal place, enough to identify which country you are in. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
The same harbour light written to 2 decimal places, enough to identify which town you are in. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
The same harbour light written to 4 decimal places, enough to identify which building you are in. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
The same harbour light written to 6 decimal places, enough to identify which doorway you are standing in. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
The same harbour light written to 9 decimal places, enough to identify far finer than any consumer receiver can fix. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
The same harbour light written to 15 decimal places, enough to identify beyond what a float64 can hold for a coordinate at all. The ladder exists because coordinate precision is almost always chosen by accident, and shipping six unnecessary digits multiplies the size of every geometry in a tileset.
Five features whose coordinates are the values that break naive JSON number handling: 17-significant-digit doubles, the classic 0.1 + 0.2 artefact, the largest float64 below 180, a 1e-7 offset, and coordinates written in exponent form. Re-serialising this file is where a parser quietly loses or gains a digit.
A NetCDF-3 classic file holding a 4x5x6 air-temperature field with full CF-1.8 coordinate metadata: standard names, axis attributes, units on every variable, and a declared _FillValue. Use it to check that a reader attaches units and coordinates to the array rather than returning bare numbers.
The same temperature field stored as int16 and recovered through the CF packing attributes scale_factor and add_offset. This is the failure that parses cleanly and is silently wrong: a reader that ignores the attributes returns values around -2000 instead of 260-292 K.
Three CF time coordinates over the same six records: hours from the Unix epoch, days from 2026-01-01, and the same days under a 365_day calendar. A decoder that assumes one epoch, or ignores the calendar attribute, dates the records wrongly without raising anything.
A NetCDF-3 file with a genuine unlimited record dimension, so the record variable is stored interleaved rather than contiguously while the fixed-size station variable is not. It exercises the striding path that a reader written only against fixed dimensions gets wrong.
The same 4x5x6 temperature grid written in the 64-bit offset variant of NetCDF-3, whose only visible difference from the classic file is the fourth magic byte and the width of the header offsets. Use it to check that format sniffing looks at the version byte instead of stopping at the 'CDF' signature.
One variable that hides absent data three different ways at once: two _FillValue cells, one legacy missing_value cell and one raw NaN, with valid_min and valid_max also declared. Averaging the raw array without honouring all three gives roughly -60 K instead of a real mean.
Four physical quantities on one shared (time, station) grid, each with its own CF units string including the dimensionless '1' and the UDUNITS 'm s-1' spelling. It is the fixture for a unit-aware layer that has to keep four different unit systems straight in a single file.
The baseline rung of the BITPIX ladder: a 24x16 synthetic star field stored as unsigned bytes, the one integer width FITS holds without a BZERO shift. Every image in this family carries the same scene so a decoder can be scored across data types.
FITS has no unsigned 16-bit type, so unsigned data is stored signed with BZERO = 32768 and recovered as BZERO + BSCALE * stored. Every stored value in this image is negative, so a reader that ignores the scaling returns an entirely negative frame while parsing the file perfectly.
Single-precision FITS pixels including two NaNs, which is the only way the standard marks undefined data for floating BITPIX, plus one +Inf. Statistics computed without NaN-aware reductions come back as NaN for the entire frame.
The top rung of the BITPIX ladder, carrying the identical synthetic scene as IEEE-754 doubles with DATAMIN and DATAMAX declared. It is the reference against which the 8-, 16- and 32-bit members of the family are scored for precision loss.
A 32-bit integer image carrying a complete tangent-plane WCS: 1-based CRPIX reference pixels, a deliberately negative CDELT1 so right ascension runs the other way, and an ICRS frame. It targets the two mistakes every WCS implementation makes first, the 1-based origin and the flipped axis.
A three-HDU FITS file whose primary unit is header-only (NAXIS = 0) with the real data in named SCI and MASK extensions. A reader that only ever looks at HDU 0 reports an empty file, which is exactly the bug this fixture is built to catch.
A FITS binary table with four typed columns, big-endian numerics packed with no inter-field padding and TUNIT declaring milli-jansky on the two flux columns. It is the fixture for a table reader that has to build a row struct from TFORM codes rather than guess widths.
A header of 47 cards, so END lands well past the first 2880-byte block, alongside repeated HISTORY and COMMENT cards that legally share a keyword. A parser that reads one block and stops never sees END and truncates the metadata.
Integer FITS images mark undefined pixels with the BLANK keyword, and BLANK is compared against the stored value before BZERO and BSCALE are applied. Scale first and the four undefined pixels turn into a perfectly plausible zero, which is the ordering bug this file exists to expose.
A completely valid FITS file consisting of one 2880-byte header block and no data unit, which the standard permits whenever NAXIS is 0. It separates readers that model the data array as optional from readers that treat 'no pixels' as corruption.
A three-group HDF5 file laid out the way a real bench run is (raw arrays, a processed derivative that names its source in a derived_from attribute, and a metadata group) with units on every dataset. It is the walk-the-tree fixture: a reader has to recurse rather than assume a flat namespace.
One array stored twice in the same file: chunked with the shuffle and gzip filters applied, and contiguous with no filters at all. Comparing the two proves a reader ran the HDF5 filter pipeline rather than reading raw chunk bytes.
A compound-dtype dataset mixing an integer key, two float measurements, a fixed-width byte string and a boolean flag in a single record. It is the fixture for readers that must map an HDF5 record type onto a native struct without reordering or repadding the fields.
Fixed-width byte strings, variable-length UTF-8 strings and UTF-8 attribute text in one file, including Greek, CJK and combining diacritics. HDF5 hands fixed-width strings back as padded bytes and variable-length ones as decoded text, and conflating the two is where string handling usually breaks.
Four measured quantities where the uncertainty lives in dataset attributes rather than a parallel column, with the coverage factor spelled out so k=1 and k=2 values cannot be confused. It is the fixture for a pipeline that must propagate uncertainty it read from metadata.
The CF NetCDF grid expressed with HDF5's own dimension-scale mechanism, so each axis of the 3-D array points at a real coordinate dataset through DIMENSION_LIST references. It lets a reader be tested on scale resolution instead of on filename conventions.
A MATLAB v7.3 variable store, which is an HDF5 file with a 512-byte MATLAB user block and MATLAB_class attributes: the bytes are the same whichever extension you give it. Because MATLAB is column-major, A appears in HDF5 as its own transpose, which is the conversion bug this fixture is built around.
Eight levels of nested groups, each holding a dataset whose values equal its own depth. Any tree walk that caps recursion depth or flattens names silently loses the lower levels, and the depth-valued arrays make that immediately visible.
Twelve datasets, one per numeric HDF5 type, each holding the extreme values of that type including the uint64 and int64 limits that do not survive a trip through a double. It is the fixture that exposes a reader which widens everything to float64 on the way in.
One array reachable under four names: itself, a hard link sharing its object address, a soft link resolved at access time, and a soft link pointing nowhere. A walker that counts names instead of object addresses reports four arrays and then crashes on the dangling one.
Five degenerate but entirely legal datasets, a rank-0 scalar, a zero-length vector, a (0, 5) array, a single-element vector and a NULL dataspace, plus an empty group. None of them is corrupt, and a reader that reports them as errors is the thing being tested.
The baseline .npy fixture: a 12x8 float64 array in version 1.0 format with a little-endian descriptor and the header padded to the mandatory 64-byte alignment. Every other array in this family varies exactly one property away from it.
The identical temperature field carried by the CF NetCDF and HDF5 fixtures, stored as a bare float32 .npy. Comparing the three shows exactly what a plain array container loses: the numbers survive, the units and axes do not.
Nine int16 values including both type extremes, stored little-endian so the descriptor in the header reads '<i2'. It is one half of an endian pair whose values are identical and whose bytes are not.
The same nine int16 values written big-endian, so the header descriptor reads '>i2'. A loader that ignores the descriptor and assumes native little-endian order returns 13330 where the file says 4660, without any error.
Seven doubles written big-endian, including negative zero and values at both ends of the exponent range. Byte-swapping a double is unrecoverable by inspection. Swap pi and you get 3.2e-192, which looks like a plausible tiny number rather than an error.
A 6x10 boolean mask stored as one byte per element, because .npy does not bit-pack booleans however tempting that assumption is. The True cells follow a simple divisible-by-three rule so a mis-decode is obvious rather than plausible.
The real FFT of a 64-sample sine stored as complex128, where each element is an interleaved pair of doubles rather than two separate planes. Readers without a complex type usually flatten it, which doubles the reported length and shifts the peak bin.
A 16-record structured array carrying a value, its uncertainty and a quality flag, with the physical unit encoded in the field-name suffix because .npy has nowhere else to put it. The header descriptor is a list of field tuples rather than a single type string, which is the parsing branch this file exercises.
A 4x6 matrix of 0..23 stored row-major, so the byte sequence begins with the first row. It is one half of a memory-order pair that is indistinguishable from its twin unless the header's fortran_order flag is honoured.
The same 4x6 matrix stored column-major with fortran_order set to True in the header. Ignoring that one boolean does not produce an error, it produces a transposed matrix: the quietest failure in the whole .npy format.
A 300-field structured array whose descriptor is too long for a version 1.0 header, forcing format version 2.0 and its four-byte header-length field. A hand-rolled parser that assumes the two-byte 1.0 field mis-locates the data section entirely.
A structured array whose field names use Greek and CJK characters, which is the only reason format version 3.0 exists: its header is UTF-8 where 1.0 and 2.0 are latin-1. A parser that decodes the header as latin-1 mangles all three names.
Five timestamps stored as datetime64 with second resolution, where the unit is part of the dtype descriptor and the values on disk are plain int64 epoch seconds. Dropping the unit turns 2026-01-01 into the integer 1767225600 without any complaint.
Every structurally interesting float16 value in one array: one plus epsilon, the largest finite value, the smallest normal and subnormal, negative zero, infinity and a NaN. It is the compact half-precision counterpart to the float32 and float64 boundary fixtures.
A valid .npy file with a full header, a declared (0, 4) shape and a data section of zero bytes. It preserves the column count across an empty result, and it separates readers that model emptiness from readers that treat it as failure.
A rank-0 .npy holding a single double, whose header shape is the empty tuple rather than (1,). Indexing it with [0] raises rather than returning the value, so it separates parsers that model rank properly from parsers that assume at least one axis.
An npz-style bundle: a ZIP whose members are .npy files, which is exactly what NumPy's savez produces. np.load opens it by ZIP magic rather than by extension, so the arrays load straight from this .zip; rename it to .npz for tooling that checks the suffix.
The identical five arrays bundled with deflate instead of stored, which is the only difference between NumPy's savez and savez_compressed. Loading both and comparing proves a reader ran the decompressor rather than trusting stored-size shortcuts.
Sixteen doubles as a bare 128-byte block with no header, so byte order is knowledge the reader has to bring rather than something the file declares. It is one half of an endian pair that only a correct assumption tells apart.
The same sixteen doubles written in network byte order, so every eight-byte group is the mirror of the little-endian twin. Decoding it with the wrong assumption produces small plausible-looking numbers rather than an error, which is why this pair exists.
A DICOM Part 10 file built byte by byte: 128-byte preamble, the DICM magic, an explicit-VR file meta group and a 27-element dataset ending in 16-bit pixel data. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
The same synthetic phantom written with the implicit-VR transfer syntax, where element types never appear on the wire and a reader must consult a data dictionary to know that Rows is a 16-bit integer. The file meta group stays explicit VR, which is the mixed-mode detail parsers most often miss. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
The identical element stream with the 128-byte preamble and the DICM magic stripped, which is how DICOM often arrives out of a network transfer or a database blob column. It is not a conformant Part 10 file and its content is entirely recoverable, so a reader should fall back rather than reject.
Download-only EDL timeline fixture 01 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-01.
Download-only EDL timeline fixture 02 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-02.
Download-only EDL timeline fixture 03 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-03.
Download-only EDL timeline fixture 04 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-04.
Download-only EDL timeline fixture 05 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-05.
Download-only EDL timeline fixture 06 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-06.
Download-only EDL timeline fixture 07 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-07.
Download-only EDL timeline fixture 08 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-08.
Download-only EDL timeline fixture 09 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-09.
Download-only EDL timeline fixture 10 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-10.
Download-only EDL timeline fixture 11 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-11.
Download-only EDL timeline fixture 12 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-12.
Download-only EDL timeline fixture 13 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-13.
Download-only EDL timeline fixture 14 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-14.
Download-only EDL timeline fixture 15 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-edl-15.
Download-only FCPXML timeline fixture 01 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-01.
Download-only FCPXML timeline fixture 02 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-02.
Download-only FCPXML timeline fixture 03 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-03.
Download-only FCPXML timeline fixture 04 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-04.
Download-only FCPXML timeline fixture 05 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-05.
Download-only FCPXML timeline fixture 06 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-06.
Download-only FCPXML timeline fixture 07 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-07.
Download-only FCPXML timeline fixture 08 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-08.
Download-only FCPXML timeline fixture 09 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-09.
Download-only FCPXML timeline fixture 10 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-10.
Download-only FCPXML timeline fixture 11 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-11.
Download-only FCPXML timeline fixture 12 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-12.
Download-only FCPXML timeline fixture 13 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-13.
Download-only FCPXML timeline fixture 14 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-14.
Download-only FCPXML timeline fixture 15 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-fcpxml-15.
Download-only OTIO timeline fixture 01 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-01.
Download-only OTIO timeline fixture 02 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-02.
Download-only OTIO timeline fixture 03 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-03.
Download-only OTIO timeline fixture 04 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-04.
Download-only OTIO timeline fixture 05 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-05.
Download-only OTIO timeline fixture 06 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-06.
Download-only OTIO timeline fixture 07 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-07.
Download-only OTIO timeline fixture 08 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-08.
Download-only OTIO timeline fixture 09 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-09.
Download-only OTIO timeline fixture 10 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-10.
Download-only OTIO timeline fixture 11 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-11.
Download-only OTIO timeline fixture 12 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-12.
Download-only OTIO timeline fixture 13 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-13.
Download-only OTIO timeline fixture 14 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-14.
Download-only OTIO timeline fixture 15 carrying a deterministic two-second edit reference without embedding playable media. Stable P8 artifact p8-video-timeline-otio-15.
