Signal frame-packed 3D in H.264 transcodes, and correct the 2011-2012 Bravia profiles

[danielcamposramos]

Closes #6329.

Two changes, both from measurements on real hardware: a KDL-46EX725 (2011) and a KDL-46HX855 (2012).

1. Frame-packed 3D is never signalled in the elementary stream

3D TVs of the frame-compatible era auto-engage 3D from the H.264 frame_packing_arrangement SEI (Annex D, payload type 45) carried in the elementary stream. x264 writes it only when asked (frame-packing=N). The container-level stereoscopic tag is a separate signal: it does not survive a remux to MPEG-TS, and in the DVB frame-compatible 3DTV spec (ETSI TS 101 547-2) the in-stream SEI takes precedence over it.

So a 3D transcode currently arrives at those renderers as perfectly correct frame-packed video that they have no way to recognise, and it plays flat.

FFMpegVideo.getVideoTranscodeOptions() now adds -x264-params frame-packing=N on libx264 transcodes whose output is frame-packed:

Output layout	frame-packing
sbsl / sbsr / sbs2l / sbs2r	3 (side by side)
abl / abr / ab2l / ab2r	4 (top bottom)
irl / irr	2 (row alternation)
ml / mr (2D output), anaglyph	not signalled

The value follows Output3DFormat when the renderer sets one, since that is the layout actually leaving the encoder, and otherwise the source layout. It is skipped when CustomFFmpegOptions already contains -x264-params, and it only applies on the libx264 path (GPU encoders do not take x264 parameters).

This mirrors the equivalent change in HandBrake, PR #8100, merged 16 September 2026.

2. The Bravia profiles transcode things these sets play natively

Measured with a pass-through DLNA server, files byte-exact on the wire, tracks copied without re-encoding:

• MP4 is played directly. Sony-BraviaEX725.conf had no f:mp4 line at all, so every MP4 was transcoded on a set that advertises http-get:*:video/mp4:* as a wildcard and plays H.264 in MP4 without help.
• E-AC3 is decoded from MP4, including 7.1, and the set reports it on screen as "Dolby Digital Plus". Transcoding it to AC-3 is a real loss. Worth noting because it is counter-intuitive: the sets' HDMI input does not accept E-AC3 as a bitstream at all, so decoding a file and accepting a bitstream are genuinely different capabilities here.
• DTS is silent in MP4 while the video plays, which the existing "DTS is not supported" note now states precisely.
• Matroska is not advertised at all, so an MKV is filtered out of the browse listing rather than merely failing to play. Recorded as a comment so the next person does not try to add it.

Changed: Sony-BraviaEX725.conf, Sony-BraviaHX.conf, Sony-BraviaHX75.conf.

Scope, stated honestly

The two sets above are what I measured. The profile changes are applied to the configs whose UpnpDetailsSearch matches those same chassis generations, because Sony shipped one software platform per chassis generation rather than per model — one application catalog and one firmware line served every set in a generation, which is documented here. If you would rather keep the changes to the exact models measured, say so and I will narrow them.

I have not extended this to Sony-BraviaEX.conf, Sony-BraviaNX70x.conf or Sony-BraviaNX800.conf: those cover older models I have no hardware for, and adding MP4 support to a set I cannot test seemed the wrong side of the line.

Testing

The 3D signalling half is verified end to end on both sets, through two independent servers (Serviio and Kodi's UPnP, which never transcodes): an MP4 carrying the SEI switches the TV into 3D automatically, the identical file with the SEI stripped — a difference of 791 bytes, picture data untouched — plays flat, and a Matroska carrying only the container StereoMode tag is not listed at all. Method and files: https://github.com/danielcamposramos/sony-bravia-linux/blob/main/docs/3d-signalling-ecosystem.md

I could not run the UMS test suite locally (no Maven, and Java 25 here against the project's 17), so the Java change has had a syntax check only and needs CI. It is a small, isolated addition to one options block, but please treat it as untested by me.

[danielcamposramos]

For triage, I searched this repo for anything else either half of the PR would close, so you do not have to.

Closed by this PR: #6329 only. That is the honest answer — I searched open issues for 3D, stereoscopic, frame packing, SBS, side by side, Output3DFormat, anaglyph, Bravia, Sony, E-AC3 and Dolby Digital Plus, and nothing else open is about either the in-stream 3D signal or these sets' audio handling.

Not closed by this PR, listed so they are not conflated with it:

• MP4 files not visible and DLNA device not detected on startup (v15 regression from v13) #6099 — MP4 not visible, Sony KDL-43WF665, reported as a v15 regression from v13. Different set (2017 W series, Android era), different cause, and this PR does not touch that profile. Mentioning it only because "Sony" and "MP4" both appear and I would rather rule it out explicitly than leave you guessing.
• The older 3D issues in the tracker are all a different subject: Failed to resume movie with 3D subtitle #587, Issues with 3D subtitles #878, Unable to watch 3D movies with external subtitles #893 and 3D.ass subtitles not recognized #745 are subtitle handling on 3D video, and (FEATURE) On-the-fly 2D to 3D Video Conversion for VR Headsets  #3486 and (FEATURE) 2D to 3D Algorithmic Enhancement #3723 were 2D-to-3D conversion feature requests. None involve the frame-packing SEI.

Wider context, if it is useful. This is a signalling gap that runs across the whole chain rather than a UMS quirk, and the same finding has been taken to the other projects in it. HandBrake merged the equivalent encoder change (PR #8100, 16 September 2026, closing their #5826). Reports are open at FFmpeg (#24530, #24531), mpv (#18489 with PR #18490), MKVToolNix (#6309, for the container side), Jellyfin (PR #18060 comment), Gerbera (#3937) and Kodi (#29337).

Each project owns a different link: the encoder writes the SEI, the muxer keeps or drops the container tag, the server decides whether to remux, and the TV reads only the SEI. UMS sits at the point where a correct file can still lose the signal, which is why it is worth having here.

[danielcamposramos]

Following up on the triage above with a deeper sweep, since the first pass only covered 3D wording. I also searched the open issues for Dolby, AC3, E-AC3, passthrough, 5.1, transcode audio, Bravia and KDL.

Still only #6329 is closed by this PR. Nothing else open turns on the frame-packing SEI or on these sets' audio handling.

Same family, different mechanism — not closed by this PR, but worth reading alongside it:

• UMS trancode instead muxe codec with ffmpeg. #1775 — UMS transcodes video and audio when only the audio is unsupported (reported against Chromecast). Same underlying waste as the E-AC3 half of this PR, where the fix here is simply to stop declaring a codec unsupported when the device decodes it. That issue needs audio-only transcoding logic, which this PR does not touch.
• Level parameter in supported formats #5974 — no way to express per-resolution level limits in a profile. Adjacent in spirit: both are about a profile describing a device accurately enough that UMS stops guessing. The MP4 line I added leans on H.264 level support that today can only be stated coarsely.

Ruled out, so they are not conflated:

• MP4 files not visible and DLNA device not detected on startup (v15 regression from v13) #6099 — Sony KDL-43WF665, MP4 not visible, reported as a v15 regression. Different generation (2017, Android TV era), different cause, and this PR does not touch that profile.
• Video stream is always transcoded, cannot be prevented #1804 — always-transcoded UDP stream via web.conf, Samsung. Unrelated path.
• The older 3D tickets (Failed to resume movie with 3D subtitle #587, Issues with 3D subtitles #878, Unable to watch 3D movies with external subtitles #893, 3D.ass subtitles not recognized #745) are subtitle handling on 3D video, and (FEATURE) On-the-fly 2D to 3D Video Conversion for VR Headsets  #3486/(FEATURE) 2D to 3D Algorithmic Enhancement #3723 were 2D-to-3D conversion requests. None involve the in-stream signal.

One observation you may want, offered as a hypothesis rather than a measurement. The E-AC3 finding is probably not specific to these two sets: a TV of that era can decode Dolby Digital Plus from a file while its HDMI input refuses the same codec as a bitstream, and those are separate capabilities that a single profile line tends to blur. If other profiles in the repo were written from HDMI specs rather than from playback tests, they may under-declare in the same way. I have only measured the two Sony sets I own, so I am not going to touch anyone else's profile on a guess — but if you want the same method applied to a specific renderer and someone can run the files, I am happy to write up the test set.

[SubJunk]

If other profiles in the repo were written from HDMI specs rather than from playback tests, they may under-declare in the same way

Unfortunately this is the reality of our project - we make a first pass at renderer configs based on their manuals, and then it is up to individual people to test and optimize if they want the best experience for their renderer, as you have.

Thanks for the contribution, I will merge it now