Repository navigation
Feature request: write the frame_packing_arrangement SEI (x264 --frame-packing equivalent) #970
Description
Activity
Hi, I'm interested in working on this issue and implementing frame packing support in x265.
Is anyone currently working on this? If not, I'd be happy to take it and work on a patch.
Reacted by Daniel RamosHi @vunguyen1989, thanks for the interest!
This issue is mainly an invitation to the x265 maintainers: x265 already defines the payload type (
FRAME_PACKING = 45), and what's missing is a parameter, a CLI option and the writer, the same shape as x264's--frame-packing.
The change is small, and we are ready to send the patch as soon as a maintainer says whether they would accept it and in which shape.
If you'd like to work on it, the maintainers' answer here is the first step for either of us.The players' side is where most of the waiting is today, in FFmpeg: our pull requests #24628 (honor frame-packing persistence in the H.264, HEVC and VVC decoders) and #24643 (respect the side-data preference, so a file with both the SEI and a Matroska StereoMode no longer aborts) are open and waiting for review.
Reacted by Vu NguyenThanks @danielcamposramos for the report and the hardware testing, and @vunguyen1989 for offering to help.
We'd accept this as a dedicated option. Sending the SEI through user SEI won't work today: x265 only writes payload types 4 and 5 and drops other types. Hence, we recommend adding it as a dedicated --frame-packing CLI option similar to x264.
@vunguyen1989, please go ahead, and check with @danielcamposramos first in case their patch is already done. For testing we shall compare the output byte-for-byte with their reference SEI and real time testing on the hardware.
Reacted by Vu NguyenThanks @kirithika7.
The patch is ready: #986 adds--frame-packingas a dedicated option, off by default, with the values H.265 defines (3, 4 and 5).
The reference SEI bytes for the byte-for-byte comparison are in the pull request.
@vunguyen1989, thank you for offering. A review or a test of it would be very welcome.Reacted by Vu Nguyen and kirithika7- added a commit that references this issue
on Oct 5, 2026 Thanks @kirithika7 for the guidance, and thanks @danielcamposramos for putting the patch together!
I'll review #986 and run some independent bitstream tests against the reference SEI bytes. I'll report anything I find on the PR.
Reacted by Daniel Ramos and kirithika7
AI-assistance disclaimer: this issue was written with the assistance of an AI coding agent (Claude Code CLI, running the GLM 5.3 model), under the direction — and with the live on-hardware verification — of the owner of the TVs involved.
x265 defines the SEI payload type —
FRAME_PACKING = 45inx265.h— but there is no param, no CLI option, and no code path that writes it: greppingframe-packing/packingacrossx265cli.cpp,param.cpp,encoder.cppfinds nothing but the unused constant. The result: an HEVC encode of side-by-side / top-bottom 3D content cannot carry in-stream stereoscopic signalling at all.Why that matters in practice: hardware players that auto-engage 3D read the H.264/H.265
frame_packing_arrangementSEI from the elementary stream and ignore the MatroskaStereoModecontainer tag. We proved this live on 2011/2012 Sony BRAVIA sets (single-variable tests: byte-identical streams, only the 16-byte SEI differs; the TV engages 3D only with it), and the signalling is the standard one DVB defined for frame-compatible stereo broadcast, so era sets from other brands very plausibly behave the same. Background:https://github.com/danielcamposramos/sony-bravia-linux/blob/main/docs/3d-signalling-explainer.md
Today this gap propagates downstream:
AV_FRAME_DATA_STEREO3Dinput into (libx264.c has done this since 2013).The ask: an
--frame-packingCLI option + param like x264's (frame_packing_type: 3 = side-by-side, 4 = top-bottom, 5 = frame alternation), writing the SEI before each keyframe. x264's implementation is a compact, well-understood reference (x264_sei_frame_packing_writeinencoder/set.c, emitted inencoder/encoder.c). If the full param is too much, even exposing the write through the existing generic user-SEI payload API with documentation would let front-ends (BD3D2MK3D, ffmpeg's wrapper) wire it up in one line each.We can't contribute the encoder-side patch ourselves, but we can supply reference byte streams (a verified, hardware-proven FPA SEI NAL and the files it was extracted from) and test any build against real SEI-reading hardware.