MP4 tkhd/stsd boxes use encoder's codedWidth instead of original dimensions, causing green line at non-16-aligned resolutions #302
Description
When encoding H.264 video at resolutions that are not multiples of 16 (e.g., 650×650, 700×700), the exported MP4
has a visible green line on the right edge (and potentially bottom edge). This is caused by the MP4 container
reporting the macroblock-padded dimensions instead of the original requested dimensions.
Root Cause
In isobmff-muxer.ts, getVideoTrackData() uses decoderConfig.codedWidth/codedHeight from the
EncodedVideoChunkMetadata to set the track dimensions. These padded dimensions then propagate to the tkhd box
(track display dimensions) and stsd box (video sample description).
The H.264 encoder internally pads 650→656 (nearest multiple of 16) and emits codedWidth: 656 in the output
metadata. The bitstream's SPS contains the correct crop rectangle (656→650), but the MP4 container says 656×656, so
players display all 656 pixels — including the green macroblock padding (YUV 0,0,0 → green in RGB).
Reproduction
- Create a VideoSampleSource with H.264 encoding
- Feed VideoSample frames at 650×650 (or any non-multiple-of-16 resolution)
- Finalize the MP4
- Open in a video player → green line visible on the right edge
At 720×720 (multiple of 16), no issue — codedWidth === requestedWidth.
Expected Behavior
The tkhd and stsd boxes should contain the original requested dimensions (650×650), not the encoder's
macroblock-padded dimensions (656×656). This is how FFmpeg and other professional muxers handle it.
Suggested Fix
Store the original width/height from the VideoEncoderConfig and use those for the MP4 container's track/sample
description, instead of decoderConfig.codedWidth/codedHeight.
Environment
- Browser: Chrome (Windows 11)
- Codec: H.264 (avc) via VideoSampleSource
- Tested: 650×650 ❌, 700×700 ❌, 720×720 ✅, 640×640 ✅