BD3D2MK3D: Convert 3D BDs or MKV to 3D SBS, TAB or FS MKV - Support thread

[capitain_jack]

BluDave, if you are interested in the explanation of the problem, have a look at the discussion at Doom9. It's somewhat technical but the problem is caused by a "big" subtitle that must be encoded in a special way (multiple ODS) and the SupTitle avisynth plugin doesn't handle it correctly. Unfortunately, the source code is lost, so the bug will not be fixed. Luckily, it is possible to convert any BD subtitle stream to 3D in DVD SUB format with BD3D2MK3D. The quality is not optimal, but at least, you have your video with the subtitles.
Thanks again for having reported the problem.

First: thank you for BD3D2MK3D — it is the one tool in the ecosystem that gets 3D signalling right by default (frame-packing SEI in the stream via x264 `--frame-packing`, stereo mode in the MKV header, and the AVC3Dmodifier tool to fix existing files). I'm posting because we spent the last weeks reverse-engineering *why* 3D rips play flat on hardware, and BD3D2MK3D turns out to be the reference implementation of the answer. Two small feature thoughts follow — and one thing we'd
like to share back.

**What we found (live hardware proof):**
we reverse-engineered 3D auto-detection on 2011–2012 Sony BRAVIA sets (own hardware, own LAN) and proved by single-variable tests that they auto-engage 3D **only** from the H.264 frame_packing_arrangement SEI — the Matroska stereo mode tag is ignored by the hardware entirely. Same as your Doom9 statement: "many hardware players support only the frame-packing and ignore the MKV stereo-mode." The signalling is the DVB-standard one for frame-compatible stereo, so other era 3D brands very plausibly read it too. In a real-world 44-title 3D library (web rips + disc conversions), 43/44 carried only the MKV tag and 0/44 the SEI — all flat on hardware.

**The whole chain now runs hands-off on my LAN:**
both TVs play the library through a modified Serviio instance (renderer profile + a lossless SEI injector that repairs tag-only files — open source, Linux/CLI, a cousin of your bundled h264Modify: https://github.com/danielcamposramos/sony-bravia-linux), and two Android TV boxes (Rockchip RK322x and Allwinner H616) play the same files with their HDMI output auto-switched into 3D SBS/TAB mode by a small watcher that reads VLC's media session and keys off the "[3D]" filename prefix — no remote button press anywhere in the house.

The campaign is also landing upstream: the HandBrake team just merged a patch from this work (x264 now writes the frame-packing SEI on encode, closing their long-standing 3D-metadata issue), with the ffmpeg reports (including a real decode bug their tracker had never seen) filed after it.

Two feature thoughts, both small:

1. **Custom-encoder path:**
when the user supplies a custom encoder command (e.g. NVEncC) instead of x264/x265, the output today carries no frame-packing SEI and there's no warning — only the MKV tag survives, which the hardware ignores. Since the tool already bundles h264Modify/AVC3Dmodifier, could the custom path auto-run it on the output to inject the SEI (or at least pop the same loud warning the x265 path gets)?

2. **AVC3Dmodifier as CLI:**
the "Modify 3D format tags in MKV or AVC" tool would be a great command-line entry point — it's exactly the operation ecosystem tools (media servers, library fixers) need to batch-repair tag-only files on other OSes. A Linux/CLI sibling would let non-Windows users fix whole libraries the way Windows users already can.

And the share-back: we couldn't find any published root-cause writeup connecting "hardware reads SEI only" to "rips carry tag only" — the community's standing answer to "why doesn't my TV auto-engage 3D on my MKV?" has always been "press the 3D button manually". You documented the mechanism in BD3D2MK3D's help years ago; our contribution is the live-proven diagnosis, the remux-path injector, and the upstream work so source producers stop emitting SEI-less files in the first place. If you see anything we got wrong — you know this corner of the ecosystem better than anyone — a correction on the thread would be gold.

[r0lZ]

Wow ! What an impressive post ! First, thanks for the thanks !

As for the disappointing 3D performance on Sony TVs, unfortunately, this is common among most major brands. My Samsung TV has exactly the same problem. We just have to live with it.

A small detail about x264's frame packing. It allows you to specify stereo encoding, but it doesn't let you specify which view (left or right) comes first. However, this is possible with the SEI frame-packing. Fortunately, BD3D2MK3D always encodes the left view first (as is the case with most SBS/TAB files available online), and that’s what x264 assumes. So everything works fine. It is also a pity that x265 doesn't have a similar option (but it's probably because h264 is theoretically the video encoding that MUST be used for 3D). On the other hand, h264Modify has all the necessary options to specify the 3D packaging type and the order of the two views. However, it lacks support for the Frame Alternate format, but BD3D2MK3D has implemented a workaround. I'll check to see if there's a new version of h264Modify that fixes this omission.

Using the 3D extension is a cheap solution, but it is by no means standard and only works with certain devices. BD3D2MK3D still supports this system, for those who need it (hence the option Settings -> Output file name -> 3D format extension).

Regarding your first suggestion, BD3D2MK3D does not, in fact, force users who choose to use a custom command for video encoding to follow a specific approach. This aspect is therefore entirely the user’s responsibility. It goes without saying that I cannot “correct” the command to include the missing argument, because—if it exists at all—it differs certainly for each encoder. However, I can add a line to alert the user in the “Custom encoder warning” dialog. That’s a good idea. Thank you.

I don't quite understand the second suggestion. Do you want the ability to run BD3D2MK3D from the command line to add frame-packing to an existing MKV file? Why not use h264Modify directly? It's an executable included in the H264 Patcher and BDTools toolkit. I assume it works fine on Linux with Wine HQ. In any case, h264Modify isn't my project, and I can't make a Linux version of it. Sorry. But its author, Videofan3D, is very responsible. I don't know if he is still active, but you may try to ask him a Linux version.

Thank you for your active role in improving 3D programs and devices by promoting the writing of the correct SEI messages. And, to answer your last question, no, I don't see anything wrong with what you explained so well.

[capitain_jack]

Wow ! What an impressive post ! First, thanks for the thanks !

As for the disappointing 3D performance on Sony TVs, unfortunately, this is common among most major brands. My Samsung TV has exactly the same problem. We just have to live with it.

A small detail about x264's frame packing. It allows you to specify stereo encoding, but it doesn't let you specify which view (left or right) comes first. However, this is possible with the SEI frame-packing. Fortunately, BD3D2MK3D always encodes the left view first (as is the case with most SBS/TAB files available online), and that’s what x264 assumes. So everything works fine. It is also a pity that x265 doesn't have a similar option (but it's probably because h264 is theoretically the video encoding that MUST be used for 3D). On the other hand, h264Modify has all the necessary options to specify the 3D packaging type and the order of the two views. However, it lacks support for the Frame Alternate format, but BD3D2MK3D has implemented a workaround. I'll check to see if there's a new version of h264Modify that fixes this omission.

Using the 3D extension is a cheap solution, but it is by no means standard and only works with certain devices. BD3D2MK3D still supports this system, for those who need it (hence the option Settings -> Output file name -> 3D format extension).

Regarding your first suggestion, BD3D2MK3D does not, in fact, force users who choose to use a custom command for video encoding to follow a specific approach. This aspect is therefore entirely the user’s responsibility. It goes without saying that I cannot “correct” the command to include the missing argument, because—if it exists at all—it differs certainly for each encoder. However, I can add a line to alert the user in the “Custom encoder warning” dialog. That’s a good idea. Thank you.

I don't quite understand the second suggestion. Do you want the ability to run BD3D2MK3D from the command line to add frame-packing to an existing MKV file? Why not use h264Modify directly? It's an executable included in the H264 Patcher and BDTools toolkit. I assume it works fine on Linux with Wine HQ. In any case, h264Modify isn't my project, and I can't make a Linux version of it. Sorry. But its author, Videofan3D, is very responsible. I don't know if he is still active, but you may try to ask him a Linux version.

Thank you for your active role in improving 3D programs and devices by promoting the writing of the correct SEI messages. And, to answer your last question, no, I don't see anything wrong with what you explained so well.

Not asking to run BD3D2MK3D from the command line, I am sorry for the unclear ask.
The request was about AVC3Dmodifier ("Modify 3D format tags in MKV or AVC", your tool): a command-line entry point for it, so Linux users can batch-repair tag-only files without the GUI. The use case is headless servers: media libraries live on Linux boxes where Wine isn't always an option; I wrote my own injector (bravia_sei3d.py, open source, mentioned in the post) precisely because nothing native existed. h264Modify under Wine is fair advice for desktop users though, and thanks for the pointer to Videofan3D, I'll try reaching him about a Linux version.
And thank you twice: once for the warning-dialog line, that closes the custom-encoder gap for future users. And once for the Samsung confirmation, you just told me the problem was never Sony-specific (as I suspected), which matches the DVB-standard signalling.
My Samsung-owning friends owe you a beer.

[r0lZ]

Well, AVC3DModifier IS the GUI. It calls mainly h264Modify.exe to set or modify the AVC 3D packing information. MKVPropEdit (from MkvToolnix) is also called but only to set the MKV stereoscopy mode as well. And MKVInfo is called to retrieve the current MKV tag (if any) and display it in the GUI.

What you want is what AVC3Dmodifier.tcl basically does, but 90% of the code is related to the GUI and many functions are defined in the main BD3D2MK3D tcl script. It is not easy to adapt the tool as it has not been designed to be independent and it is tied to BD3D2MK3D.

However, I will see what I can do. If it's easy enough, I may create an independent TCL script without any GUI. But as I wrote elsewhere, I don't work any more on my computer (except to reply to users, fix a bug or implement a very important thing). I'm getting old and I live now in the mountains, under the sun. I don't want to spend too many time on my computer. Therefore, I cannot promise that I'll do it, especially right now. After a torrid summer, the weather is finally very good, and I want to take this opportunity to go for walks and bike rides in the mountains. So, sorry, but you will have to wait. Stay tuned.

[capitain_jack]

Well, AVC3DModifier IS the GUI. It calls mainly h264Modify.exe to set or modify the AVC 3D packing information. MKVPropEdit (from MkvToolnix) is also called but only to set the MKV stereoscopy mode as well. And MKVInfo is called to retrieve the current MKV tag (if any) and display it in the GUI.

What you want is what AVC3Dmodifier.tcl basically does, but 90% of the code is related to the GUI and many functions are defined in the main BD3D2MK3D tcl script. It is not easy to adapt the tool as it has not been designed to be independent and it is tied to BD3D2MK3D.

However, I will see what I can do. If it's easy enough, I may create an independent TCL script without any GUI. But as I wrote elsewhere, I don't work any more on my computer (except to reply to users, fix a bug or implement a very important thing). I'm getting old and I live now in the mountains, under the sun. I don't want to spend too many time on my computer. Therefore, I cannot promise that I'll do it, especially right now. After a torrid summer, the weather is finally very good, and I want to take this opportunity to go for walks and bike rides in the mountains. So, sorry, but you will have to wait. Stay tuned.

Fully understood!

Mountains over monitors, and after a hot summer the good weather wins . No pressure on the CLI at all; "stay tuned" is plenty.

And honestly, waiting is something this corner of the ecosystem is used to.

You already had the diagnosis in May 2020 "AFAIK, only x264 can include the --frame-packing tag necessary to instruct many TVs and players to switch automatically" and it took six-plus years and an AI-assisted volunteer campaign before anyone streamed the fixes into the toolchain (HandBrake merged it, ffmpeg/x265/mpv are in the queue).

By that measure, whatever you decide about AVC3Dmodifier, whenever you feel like it, is soon.

Meanwhile Linux users aren't stuck: our own lossless injector (bravia_sei3d.py) does the same job from the command line today, and if ffmpeg accepts the bsf request (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/24531) the operation becomes a standard one-liner for everyone.

If your standalone Tcl script ever happens, it lands on friendly ground.

Enjoy the walks and the rides, the mountains have better weather than any home theater .

A nice warm summer to you from Brazil! We're just tipping into spring down here, so someone should be enjoying the sun.

[BenMcLean]

When I'm encoding regular 2D movies with Handbrake, I have Handbrake set up to re-encode any LPCM audio tracks to FLAC while setting all other formats to passthrough. Wish I could get equivalent behavior from BD3D2MK3D.

[r0lZ]

LPCM is so rare on a BD3D disc that I don’t think it’s worth the effort. And it’s always possible to convert an audio track (in the project folder) and edit the __MUX_ED_OPTIONS.xml file to change the file to be multiplexed (or to use Mkvtoolnix to add the FLAC file to the final MKV).

Which BD3D disc did you have with an audio track encoded in LPCM?

[BenMcLean]

LPCM is so rare on a BD3D disc that I don’t think it’s worth the effort. And it’s always possible to convert an audio track (in the project folder) and edit the __MUX_ED_OPTIONS.xml file to change the file to be multiplexed (or to use Mkvtoolnix to add the FLAC file to the final MKV).

Which BD3D disc did you have with an audio track encoded in LPCM?

Magnificent Bodyguards.

I guess LPCM is pretty rare but what happens a little more commonly is TrueHD / Dolby Atmos which seems to get dropped from the endcodes.

[r0lZ]

Atmos is not supposed to be present on a 3D BD (except on illegal remuxes).
But you can keep the lossless/HD versions of TrueHD or DTS-HD.
BTW, IMO, a good BD should offer one of those compressed lossless formats instead of the uncompresses LPCM, a waste of space.

[retro_gamerc64]

[Attachment 94022 - Click to enlarge]

Hi,

I just attempted to download BD3D2MK3D from the download link in this thread, but windows defender on windows 10 keeps flagging it as a trojan. Is the download compromised or is it another issue?

[r0lZ]

Indeed, the latest version of Defender flags the 7Z archive as infected. However, when I have released it, Defender was perfectly happy. Furthermore, if you extract the content of the archive and then you scan the output folder, Defender doesn't find any problem. And scanning the archive with other (better) antivirus programs (including Emsisoft) generates 0 warnings. Therefore, I guess it's again a false positive by Defender, not a problem with BD3D2MK3D.
However, for security, I'll release a new version tomorrow. I cannot do it sooner, as I have to finalize it. And this night, I will scan my entire computer with several antivirus programs.
Anyway, thanks for the information.

[r0lZ]

OK, I have finished the new version. It is not flagged any more as suspect by Windows Defender. But there are still 5 antivirus programs with red warnings on VirusTotal. Don't worry. It's usual with that 5 programs. They consider as a virus the fact that the archive includes a tool able to hide a window (used by BD3D2MK3D to hide the useless Command Prompt output window when BDSup2Sub++ is running.) Note also that my computer has been scanned tonight with 4 antivirus programs (including Defender) and no virus was found.

I have not tested the new version carefully, because IMO it was important to "fix" the false positive of Windows Defender as soon as possible, but the modification to the BD3D2MK3D source code are not important and will certainly not introduce new problems. However, a problem could come from one of the updated third-party tools. They are virus-free, but a modification of the way they work can possibly introduce an incompatibility with BD3D2MK3D. That has been the case two times in the past, but I don't think that will happen now. If someone detects a problem, please let me know.

[r0lZ]

BD3D2MK3D v1.40 released !

v1.40 (October 12, 2026)
- Fix: Due to changes in Mkvtoolnix, Tools -> Add/Remove 3D video format tags to/from a MKV or an AVC file did not work correctly anymore.
- The “Custom encoder warning” has been modified to prompt the user to specify the 3D packing format on the command line.
- Updated the MVCSource avisynth plugin by Jens with v0.13.0
- Updated the x265 encoder to v4.3+62-811d154
- Updated the Mkvtoolnix tools to v102.0 'Little Houses'
- Replaced H264Modify.exe with v2.31 (should not be different from old version)
- The 7Z archive of v1.39 was erroneously flagged as infected by Windows Defender. This version is certainly not infected.

As usual, you can download the latest version here or on the BD3D2MK3D homepage.