BD3D2MK3D v1.17: Convert 3D BDs or MKV to 3D SBS, T&B or Frame-sequential MKV

[frank]

Posted by Sharc:
Has anyone tried the free Bino? Does it provide the same output to HDMI as the Stereoscopic Player? Wow!!! Thanks for the tip.
I have tested Bino and the interlaced output is the same as Stereoscopic player does. Excellent sharp picture on polarized 3D screen. Now I must say Stereoscopic player includes 98 % open source... not recommended for that money.

I tested Windows version with hTAB via HDMI.
Bino detected the input format as hTAB properly! :)
The output format must be selected manually.
Bino's picture appears faster than from PowerDVD. Performance is equal to ffmpeg.
Bino can render subpictures.
Releases for Windows, Linux and Mac OS X.
You can select all the formats IanD wished for his LG 3D TV.

But
- Bino cannot decode MVC 3D (Blu-ray 3D)
- Bino cannot decode MVC 3D from mkv (created by MakeMKV). It automatically switches to 2D play.

Bino is Open Source - so we can help to improve it. :)

[Thalyn]

I don't mean to derail the conversation, but a slight curiosity has come up which I'm hoping r0lZ (or someone else) can clarify for me: when you get the 3D planes extracted for the subtitles, how do you determine exactly which one you should be using to process the subs?

Reason I ask is I just picked up Winter Soldier, and the results I'm getting don't match up with PowerDVD. Basically I opened the playlist (.mpls) with tsMuxer and had a look at what the appropriate track's plane was listed as (track 6, plane 6, both starting from 0), then used that to process. It's fairly close on the first sub (hard to tell for sure since the disc tells PDVD to go 2D when paused), matches on the next few, but sub 5 is obviously further separated when viewed through PDVD. Being the stickler that I am, the resulting output is annoying because it's not identical to what I'm expecting - though it's still perfectly watchable.

Curiously, to me anyway, opening the ssif instead via tsMuxer gives a different 3D plane (plane 0). Using the plane suggested there, however, quite clearly shows up incorrect for one of those early subs.

Of course, that all assumes Cyberlink isn't doing something silly. They could be adding to the depth or multiplying it for all I know, and I've actually got the subs correct. Though the same process seemed to work just fine for The Wolverine, giving matching results, and World War Z looked pretty close if it wasn't the same.

[r0lZ]

BD3D2MK3D use the plane listed by tsMuxeR for the processed MPLS, unless that plane doesn't exist, is empty or has a fixed depth. In that cases, it uses the second plane with a defined depth, or the first one if there is only one usable plane.

But the difference can perhaps be related to the way the values from the planes are used. BD3D2MK3D extracts the values of all frames during which the subtitle is shown, except the 3 first and the 3 last frames, and it uses the highest depth value. I omit the first and last frames because sometimes a subtitle appears just before a cut and the values for that shot are not necessarily the best ones to use. Anyway, if the subtitle appears "inside" an object during 1, 2 or 3 frames, the brain has not enough time to realize the problem. For the same reason, the 3 last frames are not taken into account either.

Also, perhaps PowerDVD uses another algorithm to determine the final depth value, such as the average of all depth values.

Honestly, I don't know exactly how to compute the right value, because I haven't found any documentation on that subject. I have tried several slightly different methods, and I've kept the one that gives the best results, at least in my opinion. Of course, if someone can give me the exact method to use, I'll be glad to implement it.

[Sharc]

Posted by Sharc:
Wow!!! Thanks for the tip.
I have tested Bino and the interlaced output is the same as Stereoscopic player does. Excellent sharp picture on polarized 3D screen. Now I must say Stereoscopic player includes 98 % open source... not recommended for that money.

I tested Windows version with hTAB via HDMI.
Bino detected the input format as hTAB properly! :)
The output format must be selected manually.
Bino's picture appears faster than from PowerDVD. Performance is equal to ffmpeg.
Bino can render subpictures.
Releases for Windows, Linux and Mac OS X.
You can select all the formats IanD wished for his LG 3D TV.

But
- Bino cannot decode MVC 3D (Blu-ray 3D)
- Bino cannot decode MVC 3D from mkv (created by MakeMKV). It automatically switches to 2D play.

Bino is Open Source - so we can help to improve it. :)
Thanks for trying Bino. I assumed it could be a valid choice for IanD's TV, but I had no opportunity to test it myself.

[IanD]

Posted by Sharc:
I have tested Bino and the interlaced output is the same as Stereoscopic player does. Excellent sharp picture on polarized 3D screen.

Thanks for the suggestion of Bino, but if it doesn't decode MVC, then it's not much good to me as I don't have an MVC decoder on my PC: I would have to create the mkv anyway and I already have an excellent player otherwise with MPC/LAV.

Out of curiosity, if Bino doesn't decode MVC, how did you play 3D to test it?

Because the 3D TV is remote, my testing requires a standard mkv I can play back through the TV via USB, hence the greater interest in Half Row Interlaced format rather than PC players like Stereoscopic or Bino.

[Sharc]

.....Out of curiosity, if Bino doesn't decode MVC, how did you play 3D to test it?...
It accepts various 3D source formats like interleaved, OU, SBS.
MVC sources can be decoded via an avisynth script using DGMVCsource for example.

[Thalyn]

Honestly, I don't know exactly how to compute the right value, because I haven't found any documentation on that subject. I have tried several slightly different methods, and I've kept the one that gives the best results, at least in my opinion. Of course, if someone can give me the exact method to use, I'll be glad to implement it.

Works for me. Just wanted to make sure I wasn't doing anything obviously wrong, and I'll take automated-and-possibly-not-but-still-could-be-right-anyway over manually having to split everything myself any day - especially when it comes to movies with hundreds or thousands of lines to sub!

Cheers.

[r0lZ]

I don't have Winter Soldier, but if I can buy it, I'll have a look, especially at subtitle #5 of track #6.

You told me that "sub 5 is obviously further separated when viewed through PDVD". That may mean that PDVD doesn't skip the first and last frames when it computes the depth to use. If the Depth values in the 3D-planes for that frames (skipped by BD3D2MK3D but not by PDVD) are higher than the depth of the other frames, PDVD will use the higher values. Have you noticed if that subtitle appears just after or before a cut, or if the depth of the scene changes abruptly at the very beginning or end of the subtitle? If it's the case, we have the explanation. And we can discuss the interest to skip the first and lest frames if you wish...

Do you know that, as explained in various dialogs of BD3D2MK3D, you can modify manually the depth of an individual subtitle by editing the XML file of the temp_2D XML/PNG subtitle saved by BD3D2MK3D during the conversion of the subtitles to 3D? (It's why that temp directory is not deleted by default.)

I have already modified several depths because they were not perfect, and it's relatively easy. You have to figure out the right depth value and it's not always easy, but to determine approximately the depth of the objects during the display of the subtitle, I play the movie in anaglyph mode, and I try to measure the distance along the X axis between the green and red objects. That's the depth of the object. (You can also save a still frame of the T&B or SBS movie and use a paint program to measure the positions of the objects in their respective views. Of course, in SBS mode, that value must be multiplied by 2.)

Usually, I add a few pixels to the measured depth value (to detach the subtitle from the object), then I convert the XML/PNG to 3D, without specifying the 3D-plane file to force the converter to use the <Depth> tags from the XML. It's tedious to do if a lot of subtitles are badly placed, but it's easy if you need to modify only a few subtitles.

Ideally, I would like to do some kind of interactive editor with options to shift any subtitle along the X, Y and Z (depth) axis. But it's too complicated to do for my programming skills, and I doubt that many peoples need such a tool.

[Thalyn]

I don't have Winter Soldier, but if I can buy it, I'll have a look, especially at subtitle #5 of track #6.
It's not that important. More a curiosity than anything else - but it's not a bad movie if you like the comic book adaptations. If you watch the "Agents of SHIELD" series than it could be worth it, since it shows a lot of what season 1 eluded to.

Alternatively I could just upload the subtitles and the corresponding plane somewhere, so you can have a look at it. So much the better if I can find a tool which actually allows me to screenshot PowerDVD for a reference frame (any thoughts?).

You told me that "sub 5 is obviously further separated when viewed through PDVD". That may mean that PDVD doesn't skip the first and last frames when it computes the depth to use. If the Depth values in the 3D-planes for that frames (skipped by BD3D2MK3D but not by PDVD) are higher than the depth of the other frames, PDVD will use the higher values. Have you noticed if that subtitle appears just after or before a cut, or if the depth of the scene changes abruptly at the very beginning or end of the subtitle? If it's the case, we have the explanation. And we can discuss the interest to skip the first and lest frames if you wish...
I'm not 100% with my movie terminology, but the camera angle definitely abruptly changes shortly before (around half a second) subtitle #5 (starting from 1) comes up. I'm guessing that's the type of "cut" you're referring to. I wouldn't put it past PDVD to be taking the laziest possible approach to figuring out the depth, so it may well be that it's only taking the very first depth value for each sub and never looking at it ever again.

If that is the case, perhaps a user-selectable "ignore window" would be the easiest solution? Have it default to the current value, since it seems that is going to work most of the time, but allow the option to use everything for these fringe cases. Or just ignore Cyberlink completely, of course.

[r0lZ]

Hum, I don't like the idea to take only the first frame into account. In many cases, the depth value of the first frame is not the highest one, and if we use it blindly, the subtitle may be "inside" an object during a big part of the duration of the subtitle. Imagine, for example, an empty scene with only objects far away from the surface of the screen. The subtitle starts here. Then, a character enters the scene and is largely in front of the screen. The subtitle will be at a completely wrong depth, behind the character. (It's exactly the inverse situation of the case that BD3D2MK3D tries to avoid by skipping the first and last frames.) In my tests, I have often encountered similar cases.

But I agree that an (advanced and somewhat hidden) option to control the number of frames to skip at the beginning and end of the subtitle might be useful. If you set that option to 0, I guess you'll have the same result than PDVD. I will add it in the config file. (You will have to edit it manually, as I don't think I'll add that complex to understand option in the GUI.)

I don't know if it is possible to capture the output of PDVD. I guess it can capture a still image, but I suppose that it will save only the base view. And that the subtitle will not be included. Perhaps you can configure it in anaglyph, and take a screenshot with another program?

[EDIT] I was slightly wrong when I have explained that BD3D2MK3D skips 3 frames at the beginning and end of the subtitle's 3D-plane data. In fact, it skips 5 frames. Not a big difference, as 208 ms is too short for the brain to detect a problem anyway.

Now, I've added the option to change that setting in the config file, but I have modified slightly the logic. The frames to skip are the total number of frames of the subtitle divided by 6, and if that number is greater than the configured maximum margin value, that margin value is used. I had to do that to ensure that the number of remaining frames to take into account is always greater than 0, regardless of the duration of the subtitle and the (possibly high) margin value configured by the user. So, to remove completely the margin, you should set the max margin value to 0, and to skip a sixth f the duration of the subtitle at the beginning and at the end, you should use a very high number of frames, such as 1000. The default value 5 is recommended though.

I will release v0.44 soon...

[r0lZ]

# v0.44 (August 24, 2014)
# - It is now possible to define all subtitles of a subtitle stream as forced in tab 2.
# - Tools -> Convert subtitle to 3D (with 3D plane): New option "Force all subtitles as forced".
# - When a subtitle stream is converted to 3D or to another format and the "forced" option is enabled, all subtitles will have the forced flag set automatically.
# - When all captions of the BD subtitle stream are forced, the forced flag is now set in the _MUX_**_OPTIONS.txt files.
# - Added the director and date tags (if provided) in the global movie title of the mux options files.
# - Changed the charset of the Chapter files from ASCII to UTF-8 in the _MUX_*D_OPTIONS.txt files.
# You MUST save in UTF-8 format if you edit the chapter names and include special or accented characters.
# - Added the marginFor3DSubs option in the BD3D2MK3D.cfg file to control the number of frames to skip at the beginning and end of each subtitle to compute its 3D depth.
# - Fix: Bug when closing the output of MVCPlanes.exe when there is no 3D-plane in the MVC stream. (Thanks Gradius!)
# - Minor cosmetic changes.
# - Updated x264 to the latest version (v0.142.2453).

The main addition is the possibility to define a whole subtitle stream as forced. It's useful for the (not so rare) BD3Ds that have 2 streams in each language: one with all subtitles, and the other containing only the forced captions. When the "forced" option is set in tab 2, the subtitle stream will be considered as containing only forced subs, and the forced flag will be set to all subtitles during the conversion to 3D, and the conversion to 2D VobSub. (It's the BDSup2Sub option "--force-all set".) Similarly, the forced flag will be set in the _MUX_**_OPTIONS.txt files. A similar option has been added to the Tool -> Convert Subtitles to 3D (with 3D-plane). Use the preview to determine if a subtitle stream contains only forced subs.

The other changes are minor improvements or bug fixes. They include the UTF-8 charset for the Chapters files, and the new option to change the number of frames at the beginning and end of the subtitles, as discussed above. (Be sure to force BD3D2MK3D to save the config file before editing it if you want to change that value.)

As usual, download it here: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[frank]

IanD:
..if Bino doesn't decode MVC, how did you play 3D to test it?
Because the 3D TV is remote, my testing requires a standard mkv I can play back through the TV via USB, The standard output of BD3D2MK3D is 3D hSBS or 3D hTAB, not MVC. So I have tested 3D with hTAB.

If you want to play 3D MVC via USB - forget it!
1. USB is definitely not designed for 3D movies (bit rates, sizes, decoders).
2. You have to use the crippled built-in player of the TV. Most of them can not even play MKV properly. No searching, no chapters, stuttering,...

The only way is HDMI and an external player.

If someone finds a way, I am all ears.

[r0lZ]

About Bino (http://bino3d.org/): Can someone confirm that it supports full-SBS or full-T&B? I can't test it here because I don't have a 3D graphic card.

Also, someone has tested SView (http://sview.ru/en/home)?

Note also that the KMPlayer (http://www.kmplayer.com/) can display SBS or T&B as anaglyph on a standard monitor with a non-3D graphic card. Not very interesting, but I use it sometimes for my tests. (Take care however. Currently, I refuse to do the updates, because that player, excellent in the past, is becoming very bloated with crapware.)

@Frank: I play my half-SBS movies from a HDD connected via USB to my Samsung TV UE40D6500 without major problems. It is true, however, that it cannot display the subtitles embedded in the MKV file, and it displays (badly) only the text subtitles outside of the MKV container. No chapters either. So, it's not a very good solution, but so far it's certainly the best 3D picture I have seen, and I have no stuttering problem. I have tried to play my SBS movie with my LaCie LaCinema (not 3D capable) connected via HDMI, but the resulting picture is not so good (poor contrast and less sharp details), there are stuttering problems, and it is a pain to have to configure the TV in 2D to browse the menus of the LaCinema, and in 3D each time a movie starts, so it's not a good solution IMO. I use it only when it is necessary to display the 3D PGS subtitles.

[frank]

Due to specs Bino can play full-SBS/full-TAB but I didn't test it. That input formats and more are listed.

Cool, the Samsung built-in player can play hSBS automatically? Unbelievable. Was it not Samsung which used it's own encrypted format for records on USB?
But I'm right about MVC and USB.

I'm looking for LG, because I'm satisfied with polarized 3D. Cheap eyeglasses, bright and sharp picture. And in a distance of >1,5 m you cannot see single lines. But I don't trust the built-in players. My LG beamer plays not even standard MKV properly, and the service is very bad.

[Thalyn]

I've had Bino using frame sequential input before. I haven't actually tested a full AB/LR but it's got settings for it, so I can only assume it works as well.

Will have a look into sView and report back with my findings.

On the subject of KMPlayer, take a look at PotPlayer. It's written by the original KMPlayer author but without all the excess baggage. That's been my media player of choice for a while now, in tandem with the LAV filters. It supports half and full of both AB and LR, can auto-switch if you name the file appropriately (eg -abq is half AB) and also has a variety of output modes; though sadly it doesn't support sequential input.

*Clarity: AB = Above/Below (Over/Under), LR = Left/Right (Side-by-Side)

[r0lZ]

@Frank

Yes, the Samsung player can play Half-SBS and Half-T&B. It can even recognize the 3D format automatically if the frame-packing option has been correctly set when the video has been encoded with x264 (and BD3D2MK3D sets that flag). However, it refuses to play full-SBS or full-T&B, and it stretches non-16:9 videos to occupy the full screen (so movies shot in Cinemascope and encoded after having cropped the black borders are stretched vertically). And, as I wrote above, it has terrible limitations for the subtitles and it ignores the chapters.

Yes, Samsung uses its own encryption to record the digital TV channels to a dedicated hard disc (or partition) formatted with the XFS file system (the excellent Silicon Graphics file system, but very difficult to read under Windows). But the Samsung encryption has been cracked, and if you have a rooted TV connected to your LAN, it is easy to decrypt the recordings via FTP. Anyway, the user's hard disc (or partition), with AVI, MKV, or MPEG movies, in 2D or 3D can be formatted in NTFS and of course the movies are not encrypted. Since my TV has 3 USB inputs, I use 2 discs: one for the recordings, and one with my 3D and 2D movies.

My TV can play perfectly all MKVs I have tested so far, but it is sometimes very slow to start the playback (especially the first time the file is opened, because it has to scan the file to generate its 5 thumbnails). Also, it doesn't support all codecs. It doesn't handle h264 level 5 or greater (but it is happy with level 4.1 or 4.2), and it doesn't recognize AAC audio and DTS-HD. (IMO, the impossibility to play AAC is the major codec limitation.) It plays AC3 and DTS 5.1 without problem.

The active 3D glasses are very good but somewhat expensive and heavy. In the past, the Samsung glasses did not have a good reputation because they used infrared signals, not precise enough, but currently they use bluetooth signals and they work very well. However, I must admit that the passive polarized glasses are certainly better. I bought my TV for its excellent 2D quality (much better than LG IMO), and the quality of the 3D was my second criteria. For the 3D, LG is probably a better choice.

[r0lZ]

@Thalyn

I have tested PotPlayer in the past, but I did not like it much. It was still in an early stage, so I may change my mind now. Thanks for reminding me to check it!

[r0lZ]

Important bug fix for 3D subtitles

Thalyn has discovered that the BD3D2MK3D method to apply the 3D depth extracted from the 3D-planes was wrong. (See here (http://forum.doom9.org/showthread.php?p=1690724#post1690724).) The depth value extracted from the 3d-plane was correct (and the error was not related to the frames skipped at the beginning or end of the subtitle as suggested here (http://forum.doom9.org/showthread.php?p=1690754#post1690754)), but I have used a wrong method to apply the depth to the original 2D subtitles.

When a subtitle is in front of the screen (with a positive depth value), the subtitle of the left view must be shifted to the right, and the subtitle of the right view must be shifted to the left. It's exactly the opposite when the depth is negative and the subtitle appears behind the screen.

In the previous versions of BD3D2MK3D, I have wrongly assumed that the number of pixels to use for the shift was the absolute value of the depth divided by 2 for each view. With that formula, the difference (in pixels) between the two pixels was exactly the depth value. But that was wrong. The number of pixels to use is the depth value for each view, and the total difference is therefore the depth value multiplied by 2. The effect of the bug was that the subtitles appeared too close to the screen that it should.

With the new version of BD3D2MK3D, the values saved in the <Depth> tags of the temporary 2D XML file are now the depth values from the 3D-planes multiplied by 2, so that the result of the conversion to 3D is now correct. As a consequence, all <Depth> tags are now even numbers (but if you edit them manually, you can use odd depth values, if you need more precision.)

That means that you should redo the conversion of your 3D subtitles if you want correct depths. Sorry for that! Note that you should not convert a XML file with <Depth> tags already inserted by a previous version without using the 3D-plane, as the wrong depth values will be retrieved from the XML and not computed with the right formula.

Thanks to Thalyn for the discovery of that important bug, and for the numerous tests he did to confirm that the current method is the right one! Since I don't have a 3D graphic card, I was unable to do that tests myself (hence the origin of the bug).

(BTW, his tests have also confirmed that PowerDVD has also a bug with the placement of the 3D subtitles, systematically off by 2 pixels.)

# v0.45 (August 25, 2014)
# - Fix: The formula to compute the depth value extracted from the 3D-Planes was wrong. (Thanks Thalyn)

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[r0lZ]

Sorry, please wait before downloading v0.45. I have introduced a new bug! I will fix it and upload v0.45 final soon...
[EDIT] Fixed. The download is now valid.

[frank]

Thank you for your very useful info of devices. :)

For now I'll stick with my AOC d2367Ph monitor; IPS, mat, polarized 3D, 250 cd/m2, 2xHDMI, VGA (only 220 EUR!).
I'm using it 90 % with my Notebook, so I can just read 2 big DIN A4 pages. The second HDMI I can connect with the sat receiver.

[r0lZ]

OK, bug fixed. You can now download v0.45 (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z).

[frank]

My reference is Avatar. And I thought the depth was ok...

[r0lZ]

Yes, I did my tests mainly with the forced subtitles (in the Navi language) of Avatar, and most of them were OK. It's why I have deduced that the method was correct. :-(

I will re-encode Avatar with the new method to see if the result is better.

[Thalyn]

Unfortunately I don't have Avatar to check it myself, but I am running some more titles tonight with a handful of forced subs which I'll check tomorrow against the originals (using TotalMedia Theatre for reference, due to the aforementioned PowerDVD inaccuracy). If they work out - and I have no reason to doubt that they will - than I'll put it to task on a few movies with subtitles from start to finish. Naturally I won't check all 3000+ lines when I do that but it should still be a good sample size for confidence.

If nothing else, though, I can say that the new formula works perfectly for the forced English subs in both Captain America movies and The Wolverine when comparing the results to a PS3 or TotalMedia Theatre, and the math fits for World War Z (which is currently running so I'll know for sure tomorrow).

[frank]

Sorry, Avatar test failed!
If you select the forced subs
4610 Subtitle:Deu PGS (3D-plane 2), forced captions onlythen it creates ALL 1465 subs in folder 00800.track_4610.Deu_forced.3D_2D and set it to forced.

Then I used the tool Convert Subtitles.. with forced ticked and it created successfully 88 forced 3D subs BUT in the folder 00800.track_4610.Deu.3D_2D and the file 00800.track_4610.Deu.3D.sup.

[r0lZ]

Strange. The Convert Subtitles tool uses the same code than the full conversion of a 3D movie. Perhaps I have made a mistake in the calling arguments. I will have a look tomorrow. ..

Anyway, that problem is not related to the fix of the wrong depth. I may have introduced that bug when I have added the stuff to declare all subtitles in the stream as forced.

[EDIT] Oh, yes, I think I understand the problem. It is probably trivial to fix it. But you'll have to wait anyway, I'm too tired to do it now...

[Thalyn]

Well, last night's tests were a rousing success. And Tai Chi 0/Hero (Mandarin audio) were nice and easy ones to double-check - they had fixed-depth planes. Turns out I'd previously done them with a fixed depth of 6 as a result of PowerDVD's output which, as r0lZ and I discovered, is exactly 2 short of where it should be. v0.45 gave the correct 8 from start to finish. I'll take a look at The Guillotines when these are done but I have no doubts left at all.

Curiously, is the 3D Avatar anything like the collector's 2D version? I've noticed it has a "forced" subtitle track, but the timestamps on that track are completely wrong (or they were when I tried to use it). That meant all the Na'vi subtitles would have been and gone within the first few minutes if I used it. Wound up having to manually scour the full sub track (there's a lot of dialogue in that movie!) and pick out the Na'vi tracks by hand, using the forced track as a counter to make sure I got them all.

I also gave sView a look. It seems very promising - easy enough to set up, albeit a little vague without the instructions, and it gives good results. It is lacking a bit of "polish" though. Just little things, like being able to double-click the window to toggle fullscreen (alt+Enter doesn't even work), chapter support (at least chapters as defined by MP4Box) and it has limited seeking functions. But it works, seems to run nicely and gives pretty good output - at least with a passive screen.

[r0lZ]

Unfortunately, most Asian movies have 3D-planes with a fixed depth. But it is nice to know that BD3D2MK3D process them correctly. (I'm currently fixing the issue with the forced subs and I will release v0.46 soon...)

I will try Avatar in a moment (to test if the fix for the forced subs works as expected). If I remember correctly, the Navi subs are in the main subtitle streams, but with the forced flag. (I used the French streram, from the French B zone edition). I haven't noticed problems with the timings.

Thanks for your report about sView.

[r0lZ]

Here is the new version, that should be stable now. At least I hope so! ;-)

The bug with the forced subtitles reported by Frank here (http://forum.doom9.org/showthread.php?p=1691055#post1691055) should be fixed. I have just demuxed Avatar and the forced subtitle stream contains only the forced subtitles. :-) However, I have not made many tests, and there might still be some problems related to the forced subs. Please let me know if you encounter a problem.

Note that the file name of the subtitle stream has the "_forced" extension only when the stream with the label "forced captions only" in tab 2 is demuxed. The "_forced" extension is not added for a regular stream when the user ticks the "forced" option in tab 2. It's not a bug. The "_forced" extension means "containing only the forced subs extracted from a regular stream".


# v0.46 (August 26, 2014)
# - Fix: Bug introduced in v0.44: When demuxing a subtitle stream with forced captions only, all subtitles were demuxed. (Thanks Frank)
# - Rmoved the bell ringing sometimes at the end of the extraction of the 3D-planes from the MVC stream.


Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[r0lZ]

This one is not a bug fix! ;-)

It contains several improvements. Notably, the 3D planes are now saved in the MKV, so that you can redo the 3D conversion of your 2D subtitle streams without having to demux the whole BD again. That may be useful, for example if you need to fix some subtitles with wrong depth values or if you want to include a new subtitle file. Of course, if you want the possibility to convert the 2D streams later, you must select the option to mux them in 2D as well as in 3D (the "both" option in tab 2). Note that the 3D-planes are extracted from the MVC stream only when at least one subtitle stream must be converted to 3D, because it's a relatively long operation. If you have not selected any stream or if you mux them in 2D only, the 3D-planes are not extracted, and, of course, not included in the MKV file.

I have also added a new tool to extract the attachments from the MKV files (because MkvExtractGUI2 has a bug that has never been fixed, and cannot extract the attachments).

There is also another new tool to extract the non-forced subtitles only from a XML subtitle file (in 2D or 3D). I have written it because I have hardcoded the forced subtitles of Avatar on the video, but I wanted to keep also the full stream. Since it doesn't make sense to display the forced subtitles over the hardcoded ones, I needed a way to remove them. Since that may be useful to others too, I have implemented it as a new tool.

The other improvements are minor things. For example, you can now check if a new version has been released, and when it's the case, you have the option to download it.

# v0.47 (August 29, 2014)
# - Added the information about the subtitle streams and their 3D-planes in the 3D-planes.log file.
# - The 3D-Planes files are now saved as a ZIP attachments in the final MKV file.
# - New Tool: Extract Attachments from MKV file. (Requires mkvextract.exe or the MKVToolnix package.)
# - New Tool: Extract Unforced subtitles from XML/PNG. (Handy to hardcode the forced subs and keep the other ones in a muxed stream).
# - Added "Check for update: in the Help menu
# - Tool -> Convert Subtitle to 3D (with 3D plane) requests now the language name when converting a SUP file and the language code is not present in the file name.
# - Added a "?" button in tab 2 to display help on the DTS conversion to AC3 and to check if the ArcSoft DTS Decoder is installed and working properly.


Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[Thalyn]

You might need to put up a bugfix for that one - when it comes up asking to select the language for the resulting generated 3D subtitles I'm having trouble interacting with the new little window. Basically it's not accepting any input aside from moving it around by dragging the title bar, and even while doing that it's behind the window for all the other settings. It seems to be happier the second time around, though, and that includes simply hitting the "Convert subtitles to 3D..." button again and dismissing the error.

On a slightly different note, I've found another curiosity. I've been running through the last of my movies with forced subs and occasionally I'll see a "UndefinedFrameDepths" in the XML. Fairly obvious in function and the number following it indicates the number of frames the subtitle is visible for which don't have a defined depth. Thing is that often seems to return a 0 output, where a 0 isn't necessarily correct when viewed from the original disc. The first two subtitles in Immortals are correctly set to 0, but Cars 2 has a 0 where a 14 should be and John Carter has a 0 where a 10 should be. Setting the margin to 0 only affected Cars.

If you combine that with the behaviour of TotalMedia Theatre, which actually changes the depth while the sub is still displayed, I'm wondering if there's actually some kind of "rolling" depth - each subtitle is displayed at the depth last encountered before it goes up if a new depth wasn't set on the first frame. This would also fit in with most players given they don't even bother displaying a "soft" subtitle in the event you skip the first frame it's displayed, suggesting they don't give two hoots about what happens after that first frame.

To that end, I've uploaded the John Carter forced sub track and corresponding planes file. Sub #30 ("Let Sola have a hatchling.") is the one that gives a 0 from the tool but visual inspection suggests a 10 (or there-abouts) is more appropriate.

https://mega.co.nz/#!c8EiWBhL!8QYi_HspP3CoPNMiTUcSA8jP9MANRHlxRWdypB99nTI

[r0lZ]

OK, I think I've fixed the bug of the language selection window behind the others. Can you confirm that you had that problem when doing a complete conversion of a BD to 3D (and not when converting a subtitle with the "Convert subtitle to 3D" tool) ? It is strange that you had that dialog when converting a BD. Normally, it is used only when the language is unknown, and when a BD is converted, the language is known, because it is retrieved from the MPLS by tsMuxeR. Therefore, the window should not be opened.

Also, BD3D2MK3D assumes that the language code present in a IDX or XML file is correct and doesn't ask you to confirm it. Therefore, the window should be displayed only for BD SUP conversions. And even in that case, BD3D2MK3D tries to find the language automatically with the file name. For example, with this file name, it assumes French: 00800.track_4609.Fra.sup. And if it doesn't find the ISO language code in the file name, it searches also for the full name of the language (in English only), like in this example: subtitle_French.sup. It's only when all that methods fail that it displays the little dialog.

BTW, that dislog is also used when you click the [...] button in Settings -> Automatic streams selection. In that case, it should work normally. Can you confirm that too?


I will have a look at your subtitles. Normally, a subtitle depth is considered undefined if all depth values in the 3D-planes for the frames corresponding to the "window" have the value 0x80 (or -0 once translated into depth value). Many BDs have 32 3D-planes, but most of them are made of undefined depths only, and are therefore deleted after their extraction, because they are totally useless. Some non-empty 3D-planes have some values with undefined depths, but normally they should be present only in frames without subtitles. When there are defined and undefined frames, BD3D2MK3D uses of course only the defined depths to compute the final depth. Of course, when it finds only undefined depths, it cannot compute the right value, and assumes 0. It is not possible to change the depth of a specific subtitle when it is displayed, therefore BD3D2MK3D uses always the highest valid depth (not counting the undefined -0 values). I wonder why other programs assume a depth of 10 if all depths are undefined. Maybe it takes the last (or next) valid depth encountered in the 3d-plane? Anyway, I'll have a look right now...

[r0lZ]

OK, no need to reply to my questions in the post above. I have found and fixed the problem. It was happening when using the Tool and (probably) not when processing a whole 3D BD. There was no problem when using the language selection dialog from the Automatic Stream Selection setting dialog. Thanks for having submitted that bug!

I still have to understand what's happening with the wrong depth of the 3D subtitle, and I will release v0.48. In the meantime, I have deleted v0.47. If you want to download BD3D2MK3D, please come back in a moment...

[r0lZ]

After a quick analyse, I see that the depths of the frames of subtitles #29 and #30 are indeed undefined. There is a lot of undefined values before that frames, and I don't think the player takes its value from the last valid frames. However, soon after the frames of that 2 subtitles, there are some frames with a depth of 7. Now, I must understand why they are used by other programs and not by BD3D2MK3D. That may be because BD3D2MK3D uses non-drop time codes, and the other programs use drop frames. But that's strange. I have closely verified with several BDs, and the cuts in the movies correspond exactly with abrupt changes in the depth values of the 3D planes, so I have supposed that my method is correct. Perhaps there are exceptions.

To easily debug, I have modified the UndefinedFrameDepths tag to display also the frame numbers (as computed currently by BD3D2MK3D). Here is what it displays for subtitles #29 and #30:

<Event InTC="00:34:31:15" OutTC="00:34:32:15" Forced="False">
<Graphic Width="209" Height="54" X="853" Y="822" Depth="0" UndefinedFrameDepths="15, frames=49669 to 49693, window=49674 to 49688">temp_2D_0029.png</Graphic>
</Event>
<Event InTC="00:34:32:20" OutTC="00:34:34:10" Forced="False">
<Graphic Width="658" Height="54" X="629" Y="822" Depth="0" UndefinedFrameDepths="29, frames=49698 to 49736, window=49703 to 49731">temp_2D_0030.png</Graphic>
</Event>

If you examine the 3D-plane with an hex editor, you'll see that the depths are undefined from frame 38750 up to frame 49728. Then the depth is 7 in frames 49729 to 49782 (54 frames), and they are followed by a lot of 4s.

So, I guess that I have to compute that frame numbers using drop time codes. They will probably be correct. But I have to understand when I must use drop time codes and when not. It's probably in the header of the 3D-planes, but currently BD3D2MK3D ignores it. Anyway, that will be a relatively important modification for me, and I think I will release v0.48 immediately, even if that problem is still not fixed.

Damn! I HATE that crazy NTSC frame rates. We are in the 21st century, and continuing to use them for digital HD (and especially forcing the whole world to do the same thing) is probably the most stupid thing the designers of the BD standard have made! It would have been so simple to simply use the film rate of 24fps! It's what most European 2D BDs do, but it's prohibited for the 3D! Unbelievable! :devil:

[r0lZ]

Well, the short tests I did are not sufficient to be sure of the method to use, so I will have to make numerous tests with my collection of BD3Ds. That will take much time, so I have decided to release immediately the bug fix for the problem of the language selection window introduced in the latest version.

But the problem of the wrong depth values is still NOT fixed. You may want to wait some days if you need to do conversion with 3D subtitles. In the meantime, v0.48 should work fine for the conversions without subtitles or with 2D subtitles only.

# v0.48 (August 30, 2014)
# - Fixed a bug in v0.47b1 with the new language selection dialog appearing beneath the other windows and impossible to use and close.

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[Thalyn]

While I know accuracy is important, I can't help but feel I should apologise for finding these bizarre exceptions. I don't like creating extra work for people who are already putting in so much effort unless it's absolutely necessary, and no-one can argue you haven't gone above-and-beyond with this tool.

Knowing that the planes are just a basic hex list (I didn't even think to look!) even disproves my theory of a "running" plane, since the last defined value at that point would have been a 2 where my pixel-counting estimates suggest it should be a 5 or 6 - and that previous 2 would then also have been applied to sub #29 which is actually rendered as a 0 (but could be a 1 since I'm verifying with PDVD for now as my TMT is only a trial and I can't always borrow a PS3). Gah! At least it only seems to be 1 out of about 50 subtitles that are actually negatively affected by this. Still means its worth manually checking ones which report the undefined depth just to be sure, and that's still a lot easier than having to do every single one of them by hand.

Plus side, the language selection dialogue worked just fine.

[r0lZ]

Don't worry. I appreciate your help, and I ask you explicitly to continue to notify me of the discrepancies or bugs you find. Especially with the problems related to the subtitles, that I can't check easily due to my lack of appropriate hardware. Each time I want to check the accuracy of the 3D subtitles generated by BD3D2MK3D, I have to hardcode them on a video, and of course, that means that I have to recompute the whole movie with x264. It's a long operation, and therefore I can't do many tests. For that reason, I need the help of everyone.

Anyway, I should have examined the Depth values in the temp 2D XML files with more attention. The fact that there are some warnings about undefined depths when converting subtitles coming from the original BD is an evidence that something goes wrong. I have just finished to encode Avatar during the night, but this time I've used a frame rate of 24fps instead of 23.976 to translate the timecodes of the subtitle stream to frame numbers. In other words, I have assumed that the subtitle streams (at least the XML streams converted from the original SUP file by BDSup2Sub) use drop frame timecodes. If that assumption is correct, the result should be slightly better than my previous encodings, and the obviously wrong depth of a couple of subtitles (that I have previously attributed to slight authoring errors) should be correct now. I still have to watch the movie, but if it's the case, the fix is probably easy. It is sufficient to modify the frame rate in my code. But I must be sure that the fix works for every movie, and in other words that there is no "hidden" drop frame flag in the header of the 3D planes. As you can see here (http://forum.doom9.org/showthread.php?p=1656564#post1656564), Bigotti5 helped me much to decipher the content of that header, but there are still unknown bits in the header. It is possible that we don't have yet the information necessary to correctly compute the frame numbers if the frame rate to use depends of the BD.

Anyway, first things first. I will watch my last encode of Avatar and if it is convincing, I will release a new beta soon. Then, you will have to test if the 3D subtitles are correct.

BTW, you can already do some tests at 24fps if you wish. Use 3DBD2MK3D to generate the project, but re-generate the 3D subtitle stream(s) with the Convert subtitles to 3D (with 3D-planes) tool. In the tool's dialog, simply change the frame rate from 24/1.001 to 24, and overwrite the original 3D subtitle stream. You can then encode normally (or, if you have already encoded the h264 stream and you don't need to hardcode the subtitles, just launch the _MUX_3D.cmd batch to generate the final MKV). And enjoy the movie, hopefully with good 3D subtitles. :-)

[Thalyn]

I suppose there is also one other possibility we have to consider: whether tsMuxer is returning the correct plane or not. All the correction in the world won't make a lick of difference if we're using the wrong input data, after all.

On the same note, I'm going to have to look into getting a second opinion for my own tests. Given previous experience we also can't assume that PowerDVD is using the correct plane so I'll need a more permanent option for double-checking the results than a 15-day trial of TMT or a curious brother.

[r0lZ]

I think tsMuxeR does the job well. Usually, subtitle stream #0 uses the 3D-plane #0, subtitlle #1 use plane #1, and so on. That seems coherent. However, in some BDs, there are several MPLS that references exactly the same M2TS file(s), with the MVC stream (therefore it's a 3D MPLS), and with the same audio and subtitle streams, but without the 3D-planes information, or with a different 3D-plane information. For example, for a movie with 3 subtitle stream, the first MPLS could assign 3D-planes 0, 1 and 2, the second 1, 2 and nothing for the third subtitle stream, and the third MPLS could have all 3D-planes set to "zerro" (sic).

Also, I still don't know what means that "zerro" 3D-plane. It doesn't seem to be 3D-plane #0, and currently BD3D2MK3D treats it as undefined. But since there are also subtitle streams without any indication for the 3D-plane, there must be a difference. I suppose that when tsMuxeR shows nothing, that means that the info is missing from the MPLS, and when it shows "zerro", that means that it has found the info. The question is, why is it decoding that info to "zerro"?

When there are several MPLS referencing the same 3D content, BD3D2MK3D displays by default only one MPLS. (You can force it to display all 3D MPLS with the "Show all 3D playlists" button in tab 1.) And it tries to show the MPLS with the "best" 3D-planes description: the first one with all subtitles with a 3D-plane. (The "zerro" info being assimilated to "missing".)

Note also that on some 3DBDs, there are also subtitle streams in the M2TS file of the dependent view (MVC). They are often exact copies of the streams present in the AVC, and I wonder what is the benefit to include the same streams twice. Note that eac3to does not show that "secondary" subtitle streams, but it fails when trying to demux the main streams, because that additional streams have the same ID than the corresponding streams in the AVC. Therefore, it mixes two streams together, and issues a lot of error messages about overlapping timecodes. The resulting demuxed streams are unusable. (tsMuxeR 3D doesn't have that problem.)

Sometimes, like in Avatar, there is only one additional stream in the MVC, and it is a full-size image (without transparency) with a text telling something like "Put your 3D-glasses now" during the whole duration of the movie. I don't understand why they need that subtitle in the main movie. IMO, that message should be displayed only before the movie begins. Anyway, that subtitle has no 3D-plane information, and I guess it's normal, since it is totally opaque.

I have seen also sometimes movies with only 1 subtitle stream, but there are 2 non-empty 3D-planes in the MVC. The first one (#0) has a fixed depth, and 3D-plane #1 has valid depth values. The subtitle stream is correctly associated with 3D-plane #1. I wonder why the authoring program has created that useless 3D-plane #0, but anyway, the info of tsMuxeR is correct.

So, in short, I think we can trust tsMuxeR, but I would like to understand why it displays "zerro" sometimes, and I'm not totally sure that the logic used by BD3D2MK3D to determine the "best" MPLS to show in the case of several identical playlists is correct, although, as far as I know, it is always coherent.

[Thalyn]

That all being the case, I think I have a new hypothesis as to what's happening; again using John Carter as reference.

I'm wondering if there's some kind of plane "hierarchy" where those frames defined as 0x80 (effectively nothing) actually use a different plane to source their information from. Using TMT to double-check for the correct offsets I have determined that subs 29 and 30 of track 10 have depths of 1 and 6 respectively. Using the frame numbers from your earlier post the assigned plane 7 has those locations as entirely 0x80, but if I check the other files I find a 1 and 6 present at what appears to be an appropriate location in plane 1 (no other planes have these values nearby). Plane 1 is used for subtitle track 9, which is the one right before the one I'm using.

In saying that, the frame numbers don't exactly match up - the movie frame is before the offset I'm checking by 52 frames. I'm taken to believe there's actually a small delay at the beginning of most streams used in video to allow for syncing which could explain the offset. My napkin math doesn't quite match up with your tool either so there's obviously a discrepancy I'm not taking into consideration, so that could be expected (napkin math puts the difference at 63-64 frames depending on rounding). The 0x06 entries start at offset 49743 in the plane file while TMT shows sub #29 changing depth at the very end.

The question is whether this hierarchy is simply a case of "If not found, use previous track's plane (and keep going back as necessary)" or "If not found, use pre-designated plane" - answering which would require more knowledge of how the MPLS structure works than I have. I'm inclined to believe it's simply a "previous track" deal myself but I have nothing over a gut feeling to back that up. Both seem wasteful since 0x80 takes as much storage space as the correct value, unless the planes are compressed using a system like RLE8 in which case it would be slightly more storage efficient.

This may also be what's indicated by a "zerro" plane - one which simply references another in its entirety, in the event it doesn't actually mean "all zeros". Though why it isn't just assigned to the other plane directly is again confusing.

Unrelated, I don't recommend TMT for 3D playback. At least, not if you have a passive screen - it produces the same aliasing I observed when simply taking alternating scanlines for each stream, yielding a watchable-but-slightly-unpleasant result.

*ed: A simpler but possibly still correct way for these 0x80 subs to get a depth could be just a simple plane "stack". JC, for example, has 10 subtitle tracks with the one I'm wanting to use conveniently being the last. To get the final depths it could just load all the depths starting from the first subtitle track and ending with the requested one, overwriting the depths as it goes with 0x80 meaning "keep the existing value". As such it would load (in order) plane 8, 0, 5, 9, 2, 3, 6, 4, 1 and then 7. It seems wasteful and inconvenient, but so is having undefined depths to begin with.

[r0lZ]

Hum, interesting theory, but I don't think it is correct, because the method is unnecessarily convoluted. Also, if your theory is correct, that means that subtitle track #0, usually associated with 3D-plane #0, will have only a single plane to retrieve its depth values, but subtitle stream #1 will have 3D-planes 1 and 0, and so on up to subtitle stream #31, that will have the possibility to find its depth values within 32 different 3D-planes. That's obviously unfair for the first streams (usually the most important ones). OK, you suggest other methods, but again there is no evidence that something like that is supposed to happen, and if it's the case, we have no way to determine the correct order anyway. But I'll remember the idea. When converting a subtitle that does not comes from the original BD (for example when it's a SUP converted from a SRT downloaded from the internet), it might be a good idea to use several planes to avoid undefined depths. I may implement that idea later, but for the present, I want to solve the problem of the original subtitles first.

In fact, I don't think your theory is correct mainly because I did some new tests and modified my code accordingly, and I think now that everything works as expected. It is still necessary to confirm that the new code works in all cases, but I'm confident.

I have written a new function to analyse the content of the 3D-planes, and output the "shots" in human readable form. That means that for all series of identical depth values, it outputs the frame number corresponding to the start of the series, the depth value, and the number of frames with that depth value, before the next "cut". My idea was that normally, the depth values within the 3D-plane must change abruptly when there is a cut in the movie (and the two shots have different depths). I have then compared the frames of the beginnings of the shots with the shots of a little bonus video from T.S. Spivet. My theory is certainly correct, because the frame numbers of the changes are similar in the 3D-planes and in the clip. However, the changes in the 3D-planes comes systematically 3 frames before the cut in the movie. I don't understand why, and I still have to verify if similar discrepancies exists with other 3DBDs. But the important thing is that the shift is identical at the beginning of the clip, and near its end. That proves simply that there is a 1:1 relationship between the depth of the shots of the movie and the 3D-planes, and that there is really 1 byte per frame in the 3D-plane. It's not something new, but it's a confirmation that we are correct up to that point.

So, I have decided to modify the output of the temp 2D XML file produced when a 2D stream is converted to 3D. In addition to the <Depth> tag (and the optional <UndefinedFrameDepth> tag), I have added a <Debug> field with the start and end frame number of the subtitle (as computed by BD3D2MK3D), the start and end frame of the "window", and the content of the 3D-plane within the window in human readable form. Then, I have played an AVS script with the movie and the original SUP stream, frame by frame with AvsPmod, and I have verified if the subtitles appear and disappear exactly at the frame numbers printed in the <Debug> field of the XML (and I have tried to determine if the depth value is also logical, although I have not measured precisely). That test confirms that the method used until now to compute the frame numbers WAS WRONG. The problem is that in the XML and IDX files, the start and end times of the subtitles are expressed in timecodes and not in frame numbers. Since I need the frame numbers to retrieve the depth from the 3D-plane, it is necessary to convert them. The conversion used the real frame rate (23.976, or more precisely, 24/1.001). My error was to assume that like in the DVDs, the frame rate to use was the "non-drop timecodes". As a consequence, the conversions to frame numbers were wrong, and the error was important, mainly near the end of the movie. I have of course tested with "drop timecodes" (and assumed therefore a frame rate of 24fps) and with that method, all frame numbers printed in the XML match exactly the frame numbers I saw when I have played the AVS. Also, all subtitles of the short movie I have used to test have now perfectly defined values, and one and only one depth. I'm almost sure that all problems came from that error.

Note that computing the frame numbers at 24fps is NOT the same thing as converting the whole subtitle stream at 24fps. The conversion of the subtitle must still be made at 23.976, but the computation of the depth values from the subtitle's timecodes must be done at 24fps. It is therefore not sufficient to overwrite the original 3D subs with a new conversion made with the conversion tool at 24fps, as I suggested earlier.

I have also encoded Avatar with all French subtitles hardcoded on the video, but I have not watched it yet. IMO, the result will be perfect, and that will confirm that the new method is correct.

The last annoying thing is that shift of 3 frames I have noticed with the cuts in the 3D-planes. Since that 3 frames are less than the default value for the "window" (5 pixels), it has no visible consequence. But if the shift is greater than 5 frames in some BDs, I will have to understand why that happens, and how to fix the problem. But I think that it's probably a minor authoring bug, or perhaps a deliberate shift, because I have noticed also that no subtitle appear directly after a cut in the movie. There is always at least 3 frames between the cut and the appearance of the subtitle. Same thing before the cut. The subtitles end always at least 3 frames before the cut. So even with a window of 0, the shift has no consequence. It remains that that shift is difficult to understand and somewhat annoying. I will therefore do some new tests (and watch Avatar) before releasing the new version, just to be sure. Then we will have to verify if the new method works in all times, and that there is no "drop vs. non-drop" flag hidden somewhere in the header of the 3D-planes. That means that it will still be necessary to verify carefully the conversions of the subtitles to 3D. It's why I will not remove the debug code from the next versions, so that everybody will be able to use the tools to verify...

[Thalyn]

I'll definitely defer to your wisdom regarding my theory. I'm nowhere near as experienced with all of this as you are - I'm just a bit of a math nut who can find patterns (sometimes where there isn't even meant to be one to find).

The 3 frame shift does actually make sense of what I've been seeing in TMT, however. A lot of times the subtitle will suddenly adjust depth just before it stops being displayed (another thing which makes it less-than-desirable for 3D playback) - and that jump corresponds to the depth of the following subtitle. Presumably that also corresponds with a scene cut but I can't actually say I've paid that much attention to it. Because they don't seem to like frame-by-frame viewing I've never been able to get an accurate count of exactly how long that shift lasts but 3 frames isn't outside the realm of possibility. Sadly, I've no way to determine whether any have ever been over 5 because it really is just a fraction of a second, plus it is a little jarring to watch.

I look forward to testing the results of your new methods. A couple of titles have given me slightly off results so far, soI've got a baseline to test against.

[r0lZ]

You can preview a MKV movie frame by frame with a simple avisynth script:

FFMpegSource2("movie.mkv")
Info()

The FFMpeg avisynth plugin must be properly installed, and the script takes ages to start the first time because ffmpeg has to scan the whole MKV file to generate its ffindex file. But when it has started, you can accurately play the movie frame by frame and see the frame number in the info. I use the AvsPmod (http://forum.doom9.org/showthread.php?t=153248) GUI to play the script and I use exclusively the cursor keys, or I type timecodes or frame numbers for "big jumps". That works pretty well. (However, you cannot seek with the 3D scripts generated by BD3D2MK3D due to the lack of the seek support in the current MVC decoders, so you have to do your tests with the encoded MKV, or with the 2D M2TS.)

In my latest tests (after the fix explained above), I have never seen "cuts" inside the depth values corresponding to a particular subtitle. So, maybe your test is biased by the bug of the current version, or you have a movie with a larger shift than the 5 frames of the default "window". Anyway, I guess that problem will be solved with the new version...

[r0lZ]

Finally, the fix for the 3D-planes bug is here. It was difficult to fix it, because in addition to the wrong frame rate used previously when converting the timecodes of the subtitles to frame numbers (23.976 fps non-drop frames instead of 24 fps drop frames timecodes), Thalyn has discovered a big bug in the output of tsMuxeR. I have had to implement a workaround for that bug, and that was not easy, difficult to test, and somewhat tedious. But this version should work well and has been extensively tested by Thalyn and myself.

The problem of tsMuxeR is that it retrieves the streams in the M2TS (or SSIF) files rather than in the MPLS file. That's normal for a demuxer, because the MPLS does not always lists all streams present in the M2TS files. But the drawback is that tsMuxeR shows the streams in the order of their IDs, and not in the order of the MPLS. In the other hand, all players shows the audio and subtitle streams as they are in the MPLS, and not necessarily in the order of their IDs. It was therefore difficult for the user to check what streams he wants to include in the MKV with the preview, since the streams are not necessarily presented in the same order. But that's not the main problem.

As you know, tsMuxeR shows also the number of the 3D-plane associated with a specific stream. To properly convert the subtitles to 3D, the right 3D-plane must be used. But the 3D-plane numbers are stored in the MPLS file, in the order of the MPLS, and not in the order of the IDs. Hence the tsMuxeR bug. It assigns the 3D-planes sequentially to the streams, but since the streams are not in the order of the MPLS, the corresponding 3D-planes are sometimes completely wrong!

Currently, BD3D2MK3D uses a workaround to restore the audio and subtitle streams in their correct order and to re-assign the 3D-planes to the right subtitle streams. I have the intention to write myself a complete parser of MPLS files, but I need some time and the info needed is difficult to get (hence this thread (http://forum.doom9.org/showthread.php?t=171140)). Since I wanted to quickly fix the 3D-plane bug, I have preferred to implement a temporary workaround. I will do the parsing myself in a forthcoming version.

Luckily, with the previous versions, the 3D-planes are usually correctly assigned to the subtitle streams, because the order of the subtitle streams in the MPLS is often equal to the order of the IDs. But unfortunately it's not always the case. So, if you have created 3D subtitles with a previous version of BD3D2MK3D, it may have used a wrong 3D-plane, and the depths of the subtitles can be more or less wrong. You may want to verify if the subtitles are correct with the new version, and convert them again if needed.

To see if a subtitle had a wrong 3D-plane with an old version, open the BD in the new version, select the playlist, and examine the list of subtitle streams in tab 1. You will see strings like "Stream #0", "Stream #1", "Stream #2", "Stream #3"... That numbers correspond to the order of the IDs, used by tsMuxeR. If the MPLS file lists the streams in a different order, that streams will be presented in a non-increasing order, such as "Stream #0", "Stream #2", "Stream #1", "Stream #3"... In this example, the streams #0 and #3 have not moved, and they had therefore the correct 3D-plane with the previous versions of BD3D2MK3D. You don't need to re-convert them. But as you can see, streams #1 and #2 have been inverted, and therefore the 3D-planes were wrong in the previous versions. You should therefore verify them, and if the depths of the subtitles are obviously incorrect, you should re-convert them to 3D with the correct 3D-plane. Sorry for that!

Here is a concrete example. This is what you can see when you select 00004.mpls of the 3DBD The Smurfs:

Streams of 00004.mpls, 1:42:43, 16 chapters, 00002+00003.ssif :

Video : MPEG4/ISO/AVC (Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976)
Video : MPEG4/ISO/MVC (H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976 3d-pg-planes: 32)
Audio : Eng DTS-HD (Bitrate: 1536Kbps core + MLP data.Sample Rate: 48KHz Channels: 5.1 (DTS Master Audio))
Audio : Eng AC3 (Bitrate: 448Kbps Sample Rate: 48KHz Channels: 5.1)
Audio : Fra AC3 (Bitrate: 448Kbps Sample Rate: 48KHz Channels: 5.1)
Audio : Nld AC3 (Bitrate: 448Kbps Sample Rate: 48KHz Channels: 5.1)
Audio : Nld AC3 (Bitrate: 448Kbps Sample Rate: 48KHz Channels: 5.1)
Audio : Ita AC3 (Bitrate: 448Kbps Sample Rate: 48KHz Channels: 5.1)
Audio : Eng AC3 (Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2)
Audio : Eng AC3 (Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2)
Subtitle: Eng PGS (Stream #0 3d-plane: 0)
Subtitle: Eng PGS (Stream #1 3d-plane: 1)
Subtitle: Ara PGS (Stream #5 3d-plane: 3)
Subtitle: Nld PGS (Stream #4 3d-plane: 14)
Subtitle: Fra PGS (Stream #2 3d-plane: 11)
Subtitle: Hin PGS (Stream #6 3d-plane: 4)
Subtitle: Ita PGS (Stream #3 3d-plane: 2)
Subtitle: Eng PGS (Stream #7 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 5)
Subtitle: Ara PGS (Stream #11 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 6)
Subtitle: Nld PGS (Stream #10 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 13)
Subtitle: Fra PGS (Stream #8 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 12)
Subtitle: Ita PGS (Stream #9 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 15)
Subtitle: Eng PGS (Stream #12 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 7)
Subtitle: Ara PGS (Stream #16 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 9)
Subtitle: Nld PGS (Stream #15 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 16)
Subtitle: Fra PGS (Stream #13 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 10)
Subtitle: Ita PGS (Stream #14 Resolution: 1920:1080 Frame rate: 23.976 3d-plane: 8)

The streams in red have moved, and therefore the 3D-plane numbers ware wrong in the previous versions.

Note that in addition to the different order, tsMuxeR shows also always all streams physically present in the M2TS/SSIF files. However, sometimes, a stream is skipped in the MPLS file, because, for various reasons, the author of the BD doesn't want it to be accessible to the users. When it's the case, that stream cannot have a 3D-plane, because the 3D-planes are defined only for the streams really present in the MPLS. Since it is possible to demux it anyway, currently BD3D2MK3D continues to list it, but it is rejected to the end of the list, it has no 3D-plane and I've added the stream 'Phantom track!', to let the users know that that stream is not officially present in the MPLS. If you decide to demux it anyway, BD3D2MK3D will pick an existing and valid 3D-plane, but without guarantee that it's the right 3D-plane to use. If you want to demux that track anyway, it might be a good idea to click the "Show all 3D playlists" button, and see if there is another MPLS that uses that track "officially". (A good example of this are the Japanese audio and subtitle tracks of 300: Rise of an Empire. In the main movie MPLS, the 2 Japanese tracks are phantom tracks, but there is an additional MPLS file with the English and Japanese languages only.)

Big thanks to Thalyn for having discovered that bugs in my code and in tsMuxeR, and for having tested numerous betas!

In addition to the fix for the wrong frame rate and wrong 3D-plane numbers, the new version fixes also some other minor bugs, improves some things and adds a new hidden debug option (useful mainly for me and the beta-testers). I'm too lazy to describe that points in details, but here is the change log:

# v0.49 (September 10, 2014)
# - Fix: Changed the frame rate when converting the time codes of the subtitle files from 23.976 to 24 (drop frames timecodes).
# - Fix for a tsMuxeR bug: The order of the audio and subtitle tracks is not always correct. The order is now restored.
# - Fix for a tsMuxeR bug: When the order of the subtitle streams is wrong, the 3D-plane numbers were assigned to the wrong streams!
# - Added the number of changes of depth value in the stats about the 3D-planes data.
# - Fix: Tool -> Convert subtitles to 3D (with 3D planes): It was impossible to convert only the forced subtitles when the input format was XML/PNG.
# - Improved the detection of the language from the filename when processing a BD SUP file from the Tools menu.
# - Tool -> Find dependent-view (MVC) file(s): Improved method to detect the M2TS of the MVC streams
# - In tab 1, you can now copy the content of the two lists to the clipboard by right-clicking the listbox.
# - Added the hidden option "debug" in the config file to run the program in debug mode.
# - Added Debug -> 3D-plane debug info, to display the content of a 3D-plane file in human readable form.
# - Added Debug -> Show tsMuxeR/eac3to's MPLS info, to show the unmodified output of tsMuxeR or eac3to for the current MPLS.


Please download the new version (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z) and don't use the older versions any more!

[r0lZ]

Here is a list of the 3D BDs affected by the 3D-planes bug of tsMuxeR, discovered so far by Thalyn, Nico and me. If you discover other examples, please let us know.

300: Rise of an Empire (Has also a "phantom" Japanese subtitle track) (Only some editions)
Despicable Me
Dredd
Frankenweenie
Ghost Rider 2 (Has also a "phantom" English subtitle track)
Gravity
John Carter (Only some editions)
Need For Speed
Pacific Rim
Rio
Sanctum
The Great Gatsby
The Smurfs
Thor II (Only some editions)
Wolverine

There are much more BDs with the audio tracks presented in the wrong order, but since that was not the cause of bugs with the previous versions, I don't list them here.

I will check my 3DBD collection to see if I can find more examples, and I will add them in this post...

[Marty]

Hi all,

i am a newbie in using bd3d2mk3d soft and solves the problem. After click on Convert subtitles to 3D, pop up error window, i atach this

14374

Edit: im using Win7-64 bit, Java 32-bit i have installed

[r0lZ]

Welcome to the Doom9 forums, Marty.

I don't know the cause of this error. Are you sure that you have the latest version of java? (32-bit is OK.)

Try to use the C++ version of BDSup2Sub, and see if it helps. (Change the version to use with the Settings menu. I don't recommend yo use the ++ version, but in this case, maybe there will be a better error message, or it will work just fine.)

What is the source of the subtitle you are converting? I see it's an XML file. I guess you have converted another stream to XML first. What program did you use to do that conversion, and what was the format of the original stream?

I suppose that the error can be caused by something odd in the source XML file, like a malformed string. Have you manually modified it before converting it?

Can you send me the "Titanic 3D.xml" file as well as the 3D-plane file, and, if you still have it, the "temp.3D_left.xml"? (You'll find my email address at the bottom of the PgcEdit home page (http://download.videohelp.com/r0lZ/pgcedit/#contact).)

[Marty]

Thx for quick reaction.

Yes i have latest version of 32-bit Java. I converted .srt subtitles in 3D subtitler.

I progressed by this video guide - https://www.youtube.com/watch?v=vuBhJ0yVTOM

[r0lZ]

I didn't know that guide. Thanks for the link.
I received the files, and I will have a look...

[r0lZ]

Oops! I see. There is a big bug when converting subtitles to full-SBS or full-T&B. I will release a fix very soon.
Thanks for the bug report!