The .mp4 that was never H.264: how a healthy serving path hid a codec bug

A user of snipforge.video, an AI video editing SaaS run by a solo founder, reported that a shared video showed 0:00 and refused to play on an iPhone, while the same link played perfectly in desktop Chrome ^[1][3]. The interesting part is not the fix, which the author says is twenty lines ^[26], but the fact that every observable signal on the serving side was green while the product was broken for an entire device class.

Share links are a core feature: process a video, get a URL, send it to someone ^[2]. That distribution model changes the reporting economics. As the author puts it, the person hitting the bug is usually not your user but the person your user shared with, and that person does not file a bug report; they conclude the product is broken and close the tab ^[4].

The symptom pointed at the serving path, so that is where he looked first ^[6]. Shared files sit on Cloudflare R2 behind the app, and the suspect list was the standard mobile Safari lineup: byte-range support, a moov atom stuck at the end of the file for want of faststart, the Content-Type coming off R2, and CORS ^[5][6]. Range requests were honored with correct 206 responses and proper Content-Range ^[7]. The moov atom was verified at the front of the file ^[8]. Content-Type was video/mp4 ^[9]. Every infrastructure suspect had an alibi, and the serving path was, in his words, completely healthy ^[10].

ffprobe settled it in one line: the container was MP4, but the video stream inside was VP9 ^[11]. Desktop Chrome plays VP9 in an MP4 wrapper; iPhone Safari does not, and it fails with no error and no console message, just a player parked at 0:00 ^[12]. The .mp4 extension and the video/mp4 header were both telling the truth about the box and saying nothing about the contents ^[13]. Nothing a server-side health check can see is wrong here, because nothing on the server is wrong.

The correct home for the fix was the share pipeline's web-optimize step: probe the actual codecs and re-encode anything that is not H.264 video and AAC audio, rather than trusting the container ^[14]. The first patch shipped clean and did nothing. It parsed `ffprobe -v error -show_entries stream=codec_type,codec_name -of csv=p=0` output on the assumption that each line arrived as `video,vp9` ^[15][16]. ffprobe emits fields in its own fixed order, so the real output was `vp9,video` ^[17]. The parser compared the codec name to the string "video", never matched, concluded every file was fine, and returned the original untouched ^[18]. No exception, no log noise, a clean deploy, zero effect ^[18]. The author argues that a fix which runs successfully and does nothing is more dangerous than one that crashes, because a crash tells you where to look; this one sent him back to re-suspecting the innocent serving path ^[19][20].

Printing the raw ffprobe output beside the parsed verdict ended it in about thirty seconds ^[21]. With field order corrected, the probe flagged VP9, the pipeline re-encoded to H.264/AAC with faststart, and the same link played on the same iPhone ^[23].

What to watch in your own stack: whether any monitoring you own would have caught this, and whether your transcode path validates codecs or extensions. The durable changes here were a compatibility probe on every shared video before it is served, and raw probe output logged next to the parsed result so the next silent parser bug has somewhere to show up ^[24][25]. The account was published as a submission to DEV's Summer Bug Smash ^[27].