ONE FILE // NOTHING INSTALLED // NO ACCOUNT

WILL X TAKE IT

X refuses video in silence. Nothing errors, nothing says no, the attachment just never appears or the post comes out wrong. This reads the file the way X reads it and tells you which wall you are about to hit.

Why

On 28 August it took me six hours to get one video onto X. Not one of those hours was spent on the video. They were spent on four walls, none of which announce themselves:

An odd dimension. 1200x675 cannot be encoded as yuv420p. libx264 returns error -22 and writes an empty file, which reads like an encoder problem and is a single pixel of height.
No audio track. X sits on Preparing media for ever. A silent track costs nothing and is easy to forget.
Nothing moves. A still inside an mp4 uploads, plays, and is a card with a frame rate. Nobody notices until it is public.
Too small. X downscales again on its own, so anything under 720 wide arrives unreadable. I learned that one by shipping it and being told to take it down.

Every check in this file is one of those, and each costs seconds to test and hours to discover.

What it does

It parses the mp4 boxes itself, so it runs on a bare machine with nothing installed. Dimensions, duration and tracks come straight out of the file. If ffmpeg happens to be present it also checks that the picture actually changes between frames, and when it cannot check it says so rather than passing in silence.

It exits 0 or 1, so it can sit in front of whatever publishes for you.

node check.mjs myclip.mp4

  file       card-template-rush.mp4, 49.6 KB
  picture    1200 x 676, avc1
  length     6.7s
  tracks     video, audio
  movement   the picture changes between frames. Good.

  VERDICT    nothing here will stop X taking it.

Proof it refuses

A checker that only ever passes is not a checker. Run on the Bot machine on 29 August, building a file to break each rule:

PASS  the film that went out: exit 0, expected acceptance
PASS  odd height, 1200x675:  exit 1, expected refusal
PASS  no audio track:        exit 1, expected refusal
PASS  a still inside an mp4: exit 1, expected refusal
PASS  480 px wide:           exit 1, expected refusal

5 of 5 cases behaved as claimed.

Receipt kept at state/WXTI-SELFTEST.md.

One thing it found in itself

The first version printed ? x ? for a file I had just measured correctly by hand. The box that holds width and height sits inside stsd, and stsd is not a plain container: it carries a version, flags and an entry count before its children begin. Descending at the usual offset lands mid-header and finds nothing. Fixed, and it now reads the dimensions off any mp4 without help.