Repository navigation
libhb: signal stereo 3d frame packing in the x264 encoder - #8100
Merged
Merged
Conversation
Map the stereo 3d layout detected by the demuxer to x264's i_frame_packing, so the frame_packing_arrangement SEI (payload type 45) is written into the H.264 elementary stream in addition to the container level metadata preserved by 1d20876. Only side-by-side and top-bottom are mapped; x264 is the only H.264 encoder in HandBrake that exposes this parameter. Re HandBrake#5826 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Please test it, no one here has got a 3D TV. |
Contributor
Author
I've tested in two Sony BRAVIA 3D from the 2011 2012 era - working. This is following up on this issue: #5826 What I could not test is with other makers, but since is the same standard for DVB 3D transmissions, they also should work. |
This was referenced Sep 16, 2026
stereo3d: detect layout signalled in the video stream (frame packing SEI, st3d)
mpv-player/mpv#18490
Merged
1 task done
This was referenced Oct 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before Posting:
Description of Change:
Commit 1d20876 preserves stereo 3D metadata at the container level. This adds the elementary stream half: when the source is side-by-side or top-bottom, map
job->stereo_3d.typeto x264'si_frame_packingso x264 writes theframe_packing_arrangementSEI (payload type 45) before each keyframe.Twelve lines in
libhb/encx264.c, no new dependency:job->stereo_3dis populated atlibhb/common.c:4970and the detected layout is already logged atlibhb/work.c:719;HB_STEREO3D_SIDEBYSIDE→ 3 andHB_STEREO3D_TOPBOTTOM→ 4 are mapped, the two layouts that map unambiguously to the H.264 arrangement types;As noted in the issue, this only applies to x264: it is the one H.264 encoder in HandBrake exposing frame packing (
x264.h,int i_frame_packing). VideoToolbox, QSV, NVENC and AMF have no equivalent parameter, and x265 defines the payload type without a writer. FFmpeg's libx264 wrapper has done the same mapping since 2013 (09cb75cd).Why it matters: hardware that auto-engages 3D — 2011/2012 era 3D TVs, verified live on Sony BRAVIA sets — reads the SEI from the elementary stream and ignores the container tag. Without this, a HandBrake re-encode of an SBS source plays flat on those displays; with it, they switch to 3D automatically. In a 44 title 3D MKV library surveyed for the issue, 43/44 carried the container tag and 0/44 carried the SEI.
Tested on:
Not yet build-tested by me — the change is a straight parameter assignment alongside the existing VUI setup, but I am happy to build and verify on Ubuntu (or adjust placement/style) before merge if you prefer.
Screenshots (If relevant): n/a
Log file output (If relevant): n/a