The short answer
In this local Chrome test, six file cases reported a picture and reached the end. A ProRes case also reached the end but reported zero video dimensions, zero video frames and no frame callback. A deliberately truncated MP4 failed despite a “maybe” container prediction. Check actual picture, sound and destination processing separately; the extension, prediction and ended event were not a complete video check.
What you’ll take away
- One constructed source became eight related cases, not eight independent creator videos.
- A finished media timeline can conceal missing picture evidence.
- Moving MP4 metadata changed startup observations without changing the saved packet payloads.
The question: what does a successful local playback check establish?
A workflow can accept a file, read its metadata and finish a playback timeline while still missing the result a viewer needs. We tested those narrower stages with original synthetic material so that no private video, account or paid provider was needed. We did not upload any case to LinkedIn or measure human understanding.
The source is four seconds of a moving test pattern and a 440 Hz tone, 480 × 270 pixels at 24 frames per second. Eight fixed cases cover a trailing-index H.264/AAC MP4, its stream-copy faststart pair, H.264 4:4:4, HEVC 10-bit, VP9, AV1, ProRes and one deliberately first-half-truncated MP4. The damaged case is a challenge input, not a valid codec comparison.
Freeze the cases, retain the tooling failure, run the whole matrix
The case list, source recipe and original runner were hashed before the first encoding attempt. That attempt generated all eight files but could not start Puppeteer’s absent default Chrome binary. We preserved the incomplete attempt, then froze a v1.1 tooling amendment using the already installed Chrome. Cases, encoding arguments and deadlines did not change. Neither browser nor dependency was downloaded.
Both complete corrected runs used Node 24.21.0, FFmpeg 9.0.2, Puppeteer 25.15.0 and Chrome 156.0.8078.74 on macOS/arm64. Each file received a fresh isolated browser context and muted playback. The second run reversed attempt order. Each matrix contains eight ordinary loopback attempts and two additional throttled MP4-pair attempts: ten per run, twenty total. Repeats are not twenty devices or independent samples.
All eight cases, with both ordinary attempts
“Picture evidence” refers to recorded dimensions, the first-frame callback, frame counter and end. This describes measurements, not a human quality judgment. P08 is deliberately damaged and is not intended for publication. Four additional throttled pair attempts remain in the CSV/archive.
| Original file | Container prediction | Dimensions in each run | Reported frames | Outcome in both runs |
|---|---|---|---|---|
| P01 · H.264 / AAC, MP4, trailing index | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P02 · Same packet payloads, MP4 faststart | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P03 · H.264 4:4:4 / AAC, MP4 | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P04 · HEVC 10-bit / AAC, MP4 | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P05 · VP9 / Opus, WebM | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P06 · AV1 / Opus, WebM | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Picture evidence and end |
| P07 · ProRes 422 / PCM, MOV | empty / empty | 0 × 0 / 0 × 0 | 0 / 0 | End without picture evidence |
| P08 · Deliberately truncated MP4 (first half) | maybe / maybe | 0 × 0 / 0 × 0 | 0 / 0 | Media error |
Read the picture signals alongside the end event
P01–P06 reached the end in both ordinary attempts, reported 480 × 270 dimensions and 96 video frames, and produced a first-frame callback. P07 ProRes reached four seconds and an ended event but reported 0 × 0 video dimensions, 0 video frames and no callback in both runs. Muted playback means we did not audibly review it. Calling that result successful video playback would overstate the evidence.
Independently, FFmpeg decoded 96 video frames from each of the seven undamaged files, including ProRes. That narrows the finding: the source contained decodable video, while this browser’s recorded path did not report a picture for that case. The descriptive label in the table combines recorded signals; it is not a perceptual quality score or proof about every browser, device or platform.
| Distinct cases, both runs retained | Actual ordinary-attempt evidence | Interpretation |
|---|---|---|
| P01–P06: six cases | End, dimensions, 96 reported frames and first-frame callback | Picture evidence in this environment |
| P07: one ProRes case | End at 4 s; 0 × 0; 0 frames; no callback | Ended without verified picture evidence |
| P08: one damaged MP4 | Media error 4; no loaded picture | Damaged challenge retained, not silently removed |
A container prediction did not validate the actual bytes
The browser was asked canPlayType using the container MIME type alone, without a codec string. MP4 cases returned “maybe,” including the deliberately truncated file. That file then reported media error 4 and never loaded a picture. The prediction had not examined or validated a complete usable file.
The QuickTime MIME prediction was empty for the ProRes case, and its timeline still advanced without recorded picture evidence. Do not collapse type prediction, metadata availability, a playing event, a picture callback and an ended event into one green status. Their actual values are retained in the CSV and raw event records, including missing values.
A controlled metadata pair changed startup, not the packet contents
P01 and P02 are each 287,147 bytes. Their saved audio/video packet-payload sequence hashes match, as do their independent decoded-frame hashes. The MP4 moov index starts at byte 283,043 in the trailing-index file and byte 32 in the faststart copy. Both produced 96 decoded video frames. This is a metadata-placement pair, not a comparison between two differently tuned encoders.
Under the nominal 64 KiB/s fixture, loadeddata was 972.5/990.8 ms for the trailing index and 534.3/621.8 ms for faststart across the two runs. The server requested 4 KiB writes every 62.5 ms and supported byte ranges. These are local observations, not calibrated internet speeds or a universal percentage improvement. Decoder startup, scheduling, caching outside the isolated context and range behavior can matter.
| Controlled property | Trailing index P01 | Faststart P02 |
|---|---|---|
| File bytes | 287,147 | 287,147 |
| moov offset | 283,043 | 32 |
| Packet payload sequence | Saved hash | Matching hash |
| Nominal slow loadeddata, run 1 | 972.5 ms | 534.3 ms |
| Nominal slow loadeddata, run 2 | 990.8 ms | 621.8 ms |
Keep the limits that stop an export test becoming a platform claim
All eight output byte hashes matched across the two full encoding runs. Playback timings did not: the first ordinary P01 observation was 160 ms to loadeddata versus 14.4 ms in the second run. Keep both instead of selecting the faster observation. The small loopback files, synthetic pattern, different codec settings and one machine cannot rank real-world compression efficiency or perceptual quality.
Server byte checkpoints mean bytes offered when the loadeddata notification reached the controller, not exact bytes received by a viewer at the frame’s instant. Overlapping range requests can make offered totals exceed file size. No frame callback is a review of every pixel or of speech meaning. LinkedIn’s own help separately warns that ProRes may upload but fail processing; this study did not test that platform step.
Use the complete evidence to build a better preflight
Preserve the original, identify the actual streams and inspect a complete local playback. Confirm picture dimensions and visible content as well as timeline progress, then review sound, captions and the ending. If a re-export is needed, record the changed setting and verify the resulting file. After a real publication, inspect the processed post as a separate stage.
The archive includes every original input/output through a content-addressed blob map, both complete reports, commands, diagnostics, packet/frame hashes, source and the incomplete tooling attempt. Byte-identical duplicates are deduplicated, not failed results. Follow the versioned reproduction instructions and expect environment-dependent playback observations. This is original file evidence, not reader preference, accessibility certification or customer value.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.
