3D auto-detection restored on era BRAVIA (2011-2012) over DLNA — frame-packing SEI + stock Serviio 2.5; help us test other 3D-capable sets

[danielcamposramos]

TL;DR: 2011–2012 Sony BRAVIA 3D TVs auto-engage 3D when the H.264 elementary stream carries a frame_packing_arrangement SEI (payload type 45) — and they ignore the Matroska StereoMode container tag, which is the only 3D flag web rips carry. Net effect: every DLNA-served 3D MKV plays flat on these sets. We reverse-engineered this on real hardware, restored fully automatic 3D with stock Serviio 2.5 + one renderer profile + two small tools, and are publishing everything in this repo. Details, evidence, and a community testing ask below.

the model alone.

Audience: Serviio developers and community. We (a right-to-repair project,
own hardware, own LAN) reverse-engineered why 2011–2012 3D-capable BRAVIA
sets never auto-engage 3D over DLNA, then fixed it with stock Serviio 2.5
plus two small add-ons and one renderer profile. This note documents the
mechanism, the fix, and what we believe Serviio could adopt so the solution
reaches 3D-capable renderer families we cannot test.

Hardware tested (both ends of the family)

TV	year	chassis	line
KDL-46EX725	2011	AZ2-F	EX (entry)
KDL-46HX855	2012	AZ3	HX (high-end)

Identical DLNA sink PN matrices on both (captured live via
ConnectionManager:GetProtocolInfo): AVC only in MPEG-TS, AC-3/MPEG-1 L2 the
only audio decodable inside TS, no Matroska PN at all. One renderer
profile serves both; the only real silicon difference found is AVC decoder
generation (see footnote).

The discovery

These TVs auto-engage 3D (on-screen notice, e.g. "Foi detectado um sinal 3D")
when the H.264 elementary stream carries a frame_packing_arrangement
SEI (payload type 45) — the standard stereoscopic signalling of H.264
(stereoscopic high profile family). They do not read the Matroska
StereoMode container tag — which is the only 3D flag web rips carry.

So the 3D pipeline breaks at exactly two places in any DLNA server:

1. Remux path (MKV → TS): the ES is copied bit-exact, the container tag
   is dropped, and no SEI exists in-file → the TV plays the SBS/T&B frames
   flat.
2. Re-encode path: profile XML has no way to pass x264 encoder
   parameters (--frame-packing), so even a freshly re-encoded 3D file
   carries no SEI → flat.

Proof was single-variable: byte-identical clips with and without the 16-byte
SEI — the TV flips only with it. Live-proven 2026-09-13 on both sets:
re-encode path across three codec families (MPEG4-ASP AVI, VC-1/WMV,
MPEG4 MOV full-SBS 2560×720) and lossless remux path (SEI injected in-file).

The fix (runs today on stock Serviio 2.5)

1. user-profiles-3d.xml — one extra profile, "Sony Bravia EX7xx/HX8xx
   (3D Enhanced)" (id sony2011x, extends stock sony2011). Deploys as
   config/user-profiles.xml. Output policy MPEG-TS + AC-3; h264 re-encode
   targets (not the stock mpeg2video, which cannot carry frame-packing at
   all) for over-spec and catch-all paths; no DAR="16:9" squeezes.
2. ffmpeg-3d-wrapper.sh — installed as /usr/local/bin/ffmpeg in
   front of the real binary on the Serviio host. Whenever Serviio re-encodes
   with libx264 and any input is 3D-flagged (Matroska stereo_mode tag,
   filename tokens sbs/tb/[3D]), it appends
   -x264-params frame-packing=3|4 (3 = side-by-side, 4 = top-and-bottom).
   Decisions are logged. SEI is ignorable metadata, so non-3D renderers are
   unaffected.
3. bravia_sei3d.py — for the remux path, where nothing can be injected
   in flight: losslessly inserts the x264-verbatim frame_packing SEI before
   every IDR of the existing stream (no re-encode, ~0.002% size growth),
   remuxes, restores the Matroska StereoMode tag, verifies, replaces
   in place. Idempotent — files that already carry the SEI are skipped.

What Serviio could adopt upstream

• Bundled ffmpeg ≥ 9 auto-injects frame-packing SEI from Matroska stereo
  side data on x264 encode — that alone would obsolete our wrapper for the
  re-encode path (our host runs system ffmpeg 6.1.6).
• Encoder parameters per profile — profile-XML access to x264 params
  (frame-packing, and we'd add weightp/weightb, see footnote) would turn
  the transcode-path fix into a pure-profile fix, no host-level wrapper.
• Remux-side SEI injection — the general fix: on video-copy/remux
  delivery paths, carry the container's stereo flag into the elementary
  stream as SEI (a bitstream filter). That covers the remux path with no
  preprocessing and zero quality cost, for any renderer that auto-detects
  from SEI.
• Scope beyond Sony: frame-packing SEI is standard H.264 signalling, not
  a Sony mechanism — we simply cannot test other manufacturers' era sets
  (Samsung/LG/Panasonic/Toshiba 3D DLNA renderers). A per-profile "inject
  stereoscopic signalling" toggle (or even a debug log line when a 3D-flagged
  file is delivered without SEI) would let the community verify on their own
  hardware quickly and map which renderer families auto-detect.

Requirements — what works on the fly vs. what needs pre-processing

With the profile + wrapper deployed on the Serviio host:

File situation	3D handling
Non-h264 video (MPEG4-ASP AVI/MOV, VC-1/WMV, msmpeg4, MJPEG, DV, theora…)	On the fly — re-encode path; wrapper injects SEI; TV flips. Proven on AVI, WMV, MOV.
Over-spec h264 (HEVC, 10-bit, >L4.1, >1920 wide)	On the fly — re-encode + wrapper SEI.
Subtitle burn-in, online feeds (3D source)	On the fly — burn/online transcode re-encodes + wrapper SEI.
h264 ≤L4.1 8-bit + AC-3 audio	Needs one-time pre-processing — pure remux is bit-exact, nothing can be injected in flight. Run bravia_sei3d.py once (lossless, in-place, idempotent); plays 3D forever after.
h264 ≤L4.1 8-bit + other audio (aac/eac3/dts/truehd/…)	Needs one-time pre-processing — video is stream-copied (only audio transcodes). Same one-time SEI injection.
HEVC 3D, 10-bit 3D	On the fly (re-encoded to h264), at the CPU cost of a full encode.

A whole library can be fixed overnight:
bravia_sei3d.py "3D Movies" --recursive --in-place (dry-run first with
--dry-run).

Footnote — 2011 vs 2012 AVC decoder generation

Before testing other era sets, know this: the 2011 EX7xx AVC decoder
cannot decode H.264 weighted prediction (weighted_pred_flag=1 /
weighted_bipred_idc=2): black screen, audio only. The 2012 HX8xx
decodes the same stream fine. Every 2015+ WEB-DL we sampled carries weighted
prediction, so such files need a re-encode (x264 weightp=0:weightb=0) for
2011-generation silicon — regardless of 3D. Don't misread that black screen
as a 3D/SEI problem: position reporting still advances and audio plays.

Files (this repo, tools/serviio/)

• user-profiles-3d.xml — the renderer profile (single profile, both lines)
• ffmpeg-3d-wrapper.sh — transcode-path SEI injection wrapper
• bravia_sei3d.py — lossless remux-path SEI injector
• README.md — full evidence base and test log (sink matrices, profile
  chain analysis, live proof timeline)

Community ask: help map which sets auto-detect

We could only test our own two TVs (both ends of Sony's 2011–2012 family).
The signalling involved is standard H.264 stereoscopic syntax, not a Sony
mechanism — so other era 3D-capable DLNA renderers (Samsung, LG, Panasonic,
Toshiba…) plausibly auto-detect the same way. A quick test for any set:

1. Serve an SBS file remuxed without the SEI (a plain MKV→TS remux) —
   expect flat.
2. Serve the same file with the SEI injected (bravia_sei3d.py --dry-run
   then in-place, or any x264 encode with --frame-packing 3).

If your TV flips only in case 2, it reads the SEI — report brand / model /
year in this thread and we'll keep a list. That list is exactly what a
Serviio-side "inject stereoscopic signalling" option would need.

Where everything lives

• tools/serviio/user-profiles-3d.xml — the renderer profile
• tools/serviio/ffmpeg-3d-wrapper.sh — transcode-path SEI injection
• tools/bravia_sei3d.py — lossless remux-path SEI injector
• tools/serviio/README.md — full evidence base and test log

Questions, corrections, and test results welcome.

[danielcamposramos]

Update — first cross-brand data point (Samsung), and testing just got easier

Two developments since this went up.

A cross-brand confirmation, from someone who would know. r0lZ, the author of BD3D2MK3D (the reference tool for authoring 3D MKVs, maintained for about twenty years), replied on his tool's support thread that the disappointing 3D behaviour is not a Sony quirk: "this is common among most major brands. My Samsung TV has exactly the same problem." (BD3D2MK3D support thread, post #602).

To be precise about what that is and is not: it is a symptom-level confirmation from an expert, that a Samsung 3D set fails to engage 3D on the same content, not yet the controlled two-file test below run on that Samsung. So it does not isolate the mechanism on Samsung. But it is exactly the signal you would expect if the cause generalises, and it is consistent with the whole premise here: frame-packing SEI is standard H.264 stereoscopic signalling, not a Sony mechanism, so any era set that auto-detects from the elementary stream would behave the same way. It moves "plausibly other brands too" to "at least one other brand, reported by a credible source."

Producing a test file is now trivial. When this was written, making a with-SEI clip meant an x264 command line. That changed: HandBrake merged support for writing the frame-packing SEI (PR #8100), so a current HandBrake build now produces the with-SEI half of the test directly from the GUI. Reports on the player side were also filed with mpv (#18489 / PR #18490) and FFmpeg, and mpv's own 3D users have independently reported the panel detecting the signal but the display path refusing to switch, so the finding is being looked at from several directions at once.

The ask still stands, and the Samsung case is now the most valuable one to close. If you have an era 3D set from any brand, the two-file test is unchanged:

1. Serve an SBS/TAB clip remuxed without the SEI — expect flat.
2. Serve the same clip with the SEI (HandBrake with frame packing, bravia_sei3d.py, or any x264 --frame-packing 3).

If it flips only in case 2, it reads the SEI. Report brand / model / year here and I will keep the list. A Samsung owner running exactly this would turn r0lZ's report into a confirmed mechanism, and would be the first entry on that list from outside Sony.

[danielcamposramos]

Update (2026-09-18): the original Dolby track can be kept too, and a second server confirms the 3D fix

Two results since the first post, both owner-verified on a KDL-46EX725 and re-confirmed on a KDL-46HX855.

1. The fix is not Serviio-specific. The same files were served through a completely different server — Kodi's built-in UPnP server, which never transcodes — and behaved identically: an MP4 whose only 3D signal is the frame-packing SEI engaged 3D automatically; the same file with the SEI removed (791 bytes, -bsf:v filter_units=remove_types=6) played flat; the MKV was not listed at all, because these sets do not advertise video/x-matroska. So the SEI is sufficient on its own, from any server that passes bytes through unchanged.

2. These sets decode Dolby Digital Plus internally — and the TS remux was throwing it away. With the original track copied bit-exact into MP4:

Track	On the set
AC-3 5.1 / 2.0	plays, "Dolby Digital" on screen
E-AC3 5.1 / 7.1	plays, "Dolby Digital Plus"
AAC 5.1	plays
DTS 5.1	silent

The Serviio profile in this repo used to normalise everything to AC-3 in MPEG-TS, because MKV can only reach these sets through TS and they cannot take E-AC3 there. For MP4 sources that conversion is unnecessary and lossy, so user-profiles-3d.xml now ships a second profile, "3D Enhanced, Surround" (sony2011xs): MP4 + H.264 ≤L4.1 + {AC-3, E-AC3, AAC} is served native, and only audio the set cannot decode in MP4 (DTS, TrueHD, FLAC, MP3, LPCM) is transcoded — now at 640 kbps, which is the maximum the sets' own EDID declares.

MKV cannot benefit: Serviio has no mp4 target container, so Matroska must still go to TS. The way out for an existing 3D MKV library is a one-time lossless remux to MP4 (video copied, Dolby copied, SEI added if missing), after which it is served untouched.

Measurements and method: https://github.com/danielcamposramos/sony-bravia-linux/blob/main/docs/audio-capabilities.md