Repository navigation
rusty_h264 rejects progressive streams that set frame_mbs_only_flag = 0 (x264 fake-interlaced) #16
Description
Summary
The SPS parser refuses every stream whose frame_mbs_only_flag is 0
(params.rs#L249-L251).
That flag only says field coding is permitted. x264's --fake-interlaced (required for
Blu-ray-compliant 1080p25/1080p30) sets it while coding every picture as a progressive frame
(field_pic_flag = 0, mb_adaptive_frame_field_flag = 0). Those streams need no interlace
tools at all, but are rejected at the first SPS.
Steps to reproduce
ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=24 -t 2 -c:v libx264 -preset veryfast -pix_fmt yuv420p \
-x264-params fake-interlaced=1:pic-struct=1 -f h264 fake_interlaced.h264
ffprobe -v error -show_entries stream=profile,pix_fmt,field_order -of csv=p=0 fake_interlaced.h264
# High,yuv420p,progressiveFeed the stream to rusty_h264::Decoder::decode one access unit at a time.
Expected
Decodes like the same content without fake-interlaced.
Actual
access unit 0: unsupported coding tool: interlace / field coding (0 frames decoded before it)
(A control encode without fake-interlaced decodes all 30 frames.)
Suggested fix
When frame_mbs_only_flag == 0:
- In the SPS, read
mb_adaptive_frame_field_flaginstead of refusing. - In each slice header, read
field_pic_flag(andbottom_field_flagwhen set), keeping the
header parse in sync. - Refuse only when a picture actually uses field tools:
field_pic_flag == 1, or
mb_adaptive_frame_field_flag == 1(MBAFF; needs full support, tracked separately). - Frame-picture POC derivation is unchanged (
delta_pic_order_cnt_bottomis already read
whenbottom_field_pic_order_in_frame_present_flagis set).
Activity
Merge pull request #26 from Remade-With-Rust/fix/16-fake-interlaced
Ttimmahlax commentedon Oct 28, 2026
Fixed in rusty_h264 0.17.0 (with
rusty_h264-decoder0.17.0 etc.), now on crates.io.Following your suggested fix: when
frame_mbs_only_flag == 0, the SPS now readsmb_adaptive_frame_field_flagand refuses only MBAFF. Height is counted in field map units, and CropUnitY is 4. Each slice header readsfield_pic_flagand refuses only actual field pictures. Frame pictures (x264fake-interlaced) decode normally. Credit to @rickeyski (#22, landed via #26).Verified against
ffmpeg -f rawvideo, on the published 0.17.0 crate:fake-interlaced=1:pic-struct=1, veryfast, with B-frames): 0/48 frames differ. Before the fix it was refused at the first SPS.no-deblock=1and 2 slices (combined with the rusty_h264 decodes P pictures wrong in the bottom macroblock row when deblocking is off #15 fix): 0/50Real interlace tools are still refused cleanly with
Unsupported, with no panic:interlaced=1; JVT CAMA1_Sony_C, CVMA1_TOSHIBA_B, CAPAMA3_Sand_F): refused with… (MBAFF)… (field picture)Full MBAFF / field decoding is still out of scope.
🤖 Generated with Claude Code