CALF Cam video stripped of 3D metadata #5826

Activity

1. galad87 commented on Mar 5, 2024

   

   galad87

   on Mar 5, 2024

   Contributor

   More actions

   I guess this falls in the "patches are welcomed" camp. If it's side-by-side with metadata in the container it should be easily doable, do you have a sample mp4 file?

   👍React with 👍1Reacted by Daniel Ramos
2. sr55

   added

   Patch / Help Welcome

   on Mar 5, 2024
3. github-actions

   added

   Stale

   on Nov 5, 2024
4. sr55

   added

   Enhancement

   and removed

   Stale

   on Nov 5, 2024
5. HandBrake

   deleted a comment from github-actions on Nov 5, 2024
6. danielcamposramos commented on Sep 15, 2026

   

   danielcamposramos

   on Sep 15, 2026

   Contributor

   More actions

   AI-assistance disclaimer: this comment 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.

   Great to see commit 1d20876 ("libhb: preserve the stereo 3d metadata") land on master for 1.12.0 — that fixes the container-tag half of this issue (and NEWS confirms: "Stereo 3D and spherical video mapping metadata are now preserved").

   There is a second half, and for a class of real hardware it is the only half that matters: the H.264 bitstream itself still carries no 3D signalling. Players that auto-engage 3D — era 3D TVs (we proved it live on 2011/2012 Sony BRAVIA sets, single-variable tests) — read the frame_packing_arrangement SEI (payload type 45) from the elementary stream and ignore the Matroska StereoMode tag. The background with the hardware proof is here:
   https://github.com/danielcamposramos/sony-bravia-linux/blob/main/docs/3d-signalling-explainer.md

   Concretely: a HandBrake re-encode of an SBS source still plays flat on those sets, because no encoder path writes the SEI. In a real-world 44-title 3D MKV library we surveyed, 43/44 carried the container tag and 0/44 carried the SEI — every one plays flat on SEI-only hardware.

   The fix is small and the data already flows. title->stereo_3d now reaches the job (common.c:4970), so in libhb/encx264.c when job->stereo_3d.type is set, map it to the x264 param:

   if (job->stereo_3d.type == HB_STEREO3D_SIDEBYSIDE)
       param.i_frame_packing = 3;   /* side-by-side */
   else if (job->stereo_3d.type == HB_STEREO3D_TOPBOTTOM)
       param.i_frame_packing = 4;   /* top-bottom */

   x264 writes the SEI itself before every keyframe — no new dependency, a few lines in one file. ffmpeg's libx264 wrapper has done exactly this mapping since 2013 (commit 09cb75cd), so the pattern is well-established upstream of you.

   Notes:

   • The SEI is ignorable metadata — players that don't understand it are unaffected (it's standard H.264 stereoscopic signalling, the same mechanism DVB standardized for frame-compatible 3D broadcast).
   • HEVC/x265 has no equivalent param today (x265 defines the payload type but has no writer) — that one genuinely needs upstream x265 work; the ask here is only the x264 mapping.
   • This is deliberately NOT an MVC-decode request (the subject of the closed [Enhancement] MVC-3D support #1467) — it only concerns inputs that are already SBS/TAB.

   Happy to submit the PR if the approach sounds right.
7. galad87 commented on Sep 16, 2026

   

   galad87

   on Sep 16, 2026

   Contributor

   More actions

   That seems ok, even if it will work only in x264, not for all the others H.264 encoders.

   Anyway, please don't use AI to write messages.

   👍React with 👍1Reacted by Daniel Ramos
8. danielcamposramos commented on Sep 16, 2026

   

   danielcamposramos

   on Sep 16, 2026

   Contributor

   More actions

   Thank you for your answer! On the x264 only, it is the only H.264 encoder in HandBrake that exposes frame packing (i_frame_packing, x264.h:492); VideoToolbox, QSV, NVENC and AMF have no equivalent parameter, and x265 defines the payload type without a writer. So this is a small win where it's available (specially old 3D TVs/Projectors - not verifed, but as my AI assisted investigation on the internet showed, probally right for the hardware of the same period and on until they discontinued the media), not a general solution — same scope ffmpeg has had since 2013.

   Patch attached: two lines in encx264.c after the VUI block, mapping job->stereo_3d.type (already populated at common.c:4970 by your 1d20876 work, and already logged in work.c:719) to param.i_frame_packing. No new dependency.

   Tested on 2011/2012 Sony BRAVIA sets, which auto-engage 3D from the SEI and ignore the container tag — before the patch a HandBrake re-encode plays flat, after it the sets switch to 3D automatically.

   I've opened the PR here:
   #8100

   PS: Not a justification, but kind of two anyways... I'm Autistic and Brazilian, so I use AI to help with code and make sure to have a properly written English and not akward communication — the work and the hardware testing are mine.

   PS2: Sorry for any English errors, did not used translator or AI on this one)
9. danielcamposramos commented on Sep 16, 2026

   

   danielcamposramos

   on Sep 16, 2026

   Contributor

   More actions

   I guess this falls in the "patches are welcomed" camp. If it's side-by-side with metadata in the container it should be easily doable, do you have a sample mp4 file?

   https://www.youtube.com/playlist?list=PLiNolhz54tErAOg8tc2wJ7wfXKS2fy1T-

   You can use any youtube downloader for the tests.
10. galad87

    added a commit that references this issue on Sep 16, 2026

    libhb: signal stereo 3d frame packing in the x264 encoder (#8100)

    ...

    b0145ad
11. galad87

    closed this as completedon Sep 16, 2026