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

[r0lZ]

Well, not really. Slow presets encode slower, but with a better compression, or, for the same compression, a better quality. So, if you have enough time and if disc space is important, you may want to use a slow preset. But take in mind that if you select a slow preset (slower than the default "medium"), the encoder will probably use a higher level automatically. If compatibility is important, you may have to select the Force level 4.1 option, and doing so restrict somewhat the power of the slow presets.

IMO, the default value (preset medium) is very well chosen by the x264 team. It is a good balance between speed, compression ration, quality and compatibility. It's only because I prefer smaller files that I encode usually with the preset Slower (and force level 4.1). I have tried to use also the veryslow and placebo presets, but they are really too slow for my PC, and the benefit is not very important. Sometimes, I use also fast presets (even ultrafast) to do quick tests, when disc space doesn't matter.

Note that in CRF or CQ mode, changing the preset affects mainly the file size, while when you encode in ABR or 2-pass, since the bitrate is fixed, it's the quality that is affected.

[Wolfy59]

Thanks r0lz. To date, i use the slow preset with forced 4.1 level. By reading you, i think i ll keep like this.

[thahandy]

Originally Posted by r0lZ

[...]
I have already used MkvMerge without problem to do just that (with The Hobbit). It works perfectly and it keeps the audio, subtitles and chapters correctly synchronised in the second part. IMO, MkvMerge in "append mode" is the best solution.

Seems I had some "total frames" issue's with the first disk and ending up with one second (24frames) black frames at the end of the video file (after merging the two files, they are in the middle of the movie where they got merged)

After some "time to fps" calculations and some demux tests, it seems the 00800.mpls file was the issue in my case.
I just edited the _ENCODE and the AVS file to changed the correct frames to process and everything went fine

tsdemux

d:\TITANIC 3D Disc 1\00800>T:\TOOLS\BD3D2MK3D\toolset\tsMuxeR.exe 00800.demux.meta "d:/TITANIC 3D Disc 1/00800" (demux.meta using 00800.mpls)
Network Optix tsMuxeR. Version 2.6.9. www.networkoptix.com
Decoding H264 stream (track 1): Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
H.264 muxing fps is not set. Get fps from stream. Value: 23.976
Decoding H264 stream (track 2): H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
MVC muxing fps is not set. Get fps from stream. Value: 23.976
0.0% complete
Decoding DTS-HD stream (track 3): Bitrate: 1536Kbps core + MLP data.Sample Rate: 48KHz Channels: 5.1 (DTS Master Audio 24bit)
99.9% complete
Processed 155361 video frames <- BD3D2MK3D used this number
Processed 155361 video frames <- BD3D2MK3D used this number
100.0% complete
Flushing write buffer
Demux complete.
Demuxing time: 9 min 21 sec

d:\TITANIC 3D Disc 1\00800>T:\TOOLS\BD3D2MK3D\toolset\tsMuxeR.exe 00800.demux.meta "d:/TITANIC 3D Disc 1/00800" (demux.meta using 00001.m2ts)
Network Optix tsMuxeR. Version 2.6.9. www.networkoptix.com
Decoding H264 stream (track 1): Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
H.264 muxing fps is not set. Get fps from stream. Value: 23.976
0.0% complete
Decoding DTS-HD stream (track 2): Bitrate: 1536Kbps core + MLP data.Sample Rate: 48KHz Channels: 5.1 (DTS Master Audio 24bit)
99.8% complete
Processed 155337 video frames <-- correct frames
100.0% complete
Flushing write buffer
Demux complete.
Demuxing time: 2 min 47 sec

eac3to gave the same result (It was not able to extract the video-stream(s) (not supported) but the audio-stream worked fine. to get frame numbers)

eac3to

t:\DEMUX\BD3D2MK3D\toolset>eac3to G:\BDMV\PLAYLIST\00800.mpls 4: dts.dts
M2TS, 2 video tracks, 7 audio tracks, 10 subtitle tracks, 1:48:00, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
[...]
a04 A remaining delay of +1ms could not be fixed.
a04 Creating file "dts.dts"...
Video track 2 contains 155361 frames.
Video track 3 contains 155361 frames.
eac3to processing took 8 minutes, 18 seconds.
Done.

t:\TOOLS\BD3D2MK3D\toolset>eac3to g:\BDMV\STREAM\00001.m2ts 2: dts2.dts
M2TS, 1 video track, 7 audio tracks, 10 subtitle tracks, 1:47:59, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
[...]
a02 A remaining delay of +1ms could not be fixed.
a02 Creating file "dts2.dts"...
Video track 1 contains 155337 frames.
eac3to processing took 5 minutes, 55 seconds.
Done.

I assume MVC has something todo with it? Other 3D disks seems to be fine.


No need to fix (I doubt you can). Just info for others to read

Originally Posted by r0lZ

[...]
Anyway, I need to replace the current procedure that retrieves the available disc space. It fails with many languages. Thanks for the information.

seems "wmic logicaldisk where "DeviceID='C:'" get FreeSpace /format:value" works fine to. (info) I don't know if it works under XP to.
But it seems you found already a solution.

[thahandy]

For those want to encode a 2D version instead just remuxing the demuxed video file, change the following files:

* edit "_MUX_2D_OPTIONS.txt" and add a new line under "--default-track"

--default-track
0:yes
00800.track_4113.264 (<- not the same for every movie)

to

--default-track
0:yes
#00800.track_4113.264 (<- copy this line, you need it later)
00800_2D.264 (<- output video name)

* save and exit _MUX_2D_OPTIONS.txt
* make a copy of "_ENCODE.cmd" (for example _ENCODE_2D.cmd)
* edit _ENCODE_2D.cmd and change the following line:

--output "00800.264" "_ENCODE_3D_MOVIE.avs"

to

--output "00800_2D.264" "00800.track_4113.264" (<- paste the filename you copied in _MUX_2D_OPTIONS.txt)

and

if exist "_MUX_3D.cmd" cmd /c "_MUX_3D.cmd"

to

if exist "_MUX_2D.cmd" cmd /c "_MUX_2D.cmd"

* remove this part: "--frame-packing 3" (or 4)
* save and exit _ENCODE_2D.cmd

Now run _ENCODE_2D.cmd

/edit

Originally Posted by r0lZ

[...]
Note that you forgot to remove the "--frame-packing 3" (or 4) argument in _ENCODE.cmd. It sets the frame packing so that the TV should automatically recognise the video as 3D SBS (or T&B).
[...]

Added, thanks!

[r0lZ]

It's strange, that frame number problem. I have never noticed that.
And BTW BD3D2MK3D demuxes the M2TS with tsMuxeR, as you can see in the demux.meta file. However, it needs to demux the M2TS files when the MPLS contains several M2TS (or SSIF) files (used for multi-angle/seamless branching), because tsMuxeR is unable do demux them if you specify the MPLS. Is it the case of your movie?

Thanks for the disc space trick. It works fine indeed. Currently, I've found a solution with the DIR command, but if it fails again, I'll use your trick.

Thanks also for the method to encode the 2D version. Indeed, the MUX_2D files are made to mux easily the 2D version without re-encoding. I use sometimes a similar trick than yours to mux a re-encoded version with the existing MUX_2D files, but I do not edit the _ENCODE.cmd and the avisynth script to encode it. I prefer to launch the untouched MUX_2D files to create the lossless 2D MKV, and then give it to the Simple x264 Launcher to re-encode it. Then I edit the _MUX_2D_OPTIONS.txt file to change the file name of the h264 file.

Note that you forgot to remove the "--frame-packing 3" (or 4) argument in _ENCODE.cmd. It sets the frame packing so that the TV should automatically recognise the video as 3D SBS (or T&B). Many players or TVs ignore that flag, but if you have, like me, a Samsung TV, it will switch to 3D mode automatically. Not really what you want for the 2D version! Especially because there is no way to force it to play the file normally, in 2D!

@everybody:
If you are interested, I can probably easily generate a _ENCODE_2D.cmd and _MUX_2D_REENCODED.txt files, so that you will not have to edit anything to obtain a 2D version. Let me know if you think that will be useful for you...

[Airmiles]

Don't we already have handbrake for that?

Although you need to use MakeMKV first, so maybe, this would indeed be a good one-stop-shop-solution.

Now I am thinking of it, yeah, just do it :-)

[r0lZ]

In fact, almost everything is already in the Project directory, as thahandy has discovered. The necessary files are already demuxed, and there is already a file to mux the 2D MKV. The only thing that is missing is the command to re-encode the 2D video, and a modified MUX_OPTIONS file to mux it to MKV.

I think I'll do it later, but currently I haven't much time, because I'm helping slavanap to debug his work. It's something much more important and valuable for us, including (indirectly) for BD3D2MK3D. I'll let you know when that will be ready...

[frank]

Latest BD3D2MK3D v0.72 from 18.8.2015 shows old v0.71.

[r0lZ]

Yep, I have noticed that little problem. I forgot to change the version string. But it's v0.72 anyway.
I'll try to release v0.73 soon just to erase that problem, but currently there is not much new things in v0.73 so I prefer to wait a bit more.

Thank you very much r0lZ for sharing your work. It is excellent and very usefull.
Would you, please, make it a bit more attractive by adding a subtitles conversion tool from XML/PNG to Scenarist's .ofs file?
Personally, I prefer remuxing and I've lost the original subtitles' depth in the 3D Blu-ray remuxes I've made.

If not, could you give me the .ofs file format so as I could write such a tool?
I would highly appreciate your help.
Respectfully.

[r0lZ]

Well, I don't know at all the OFS file format, but according to the BDSup2Sub doc, it exports the XML/PNG files in a way compatible with Scenarist:

Supported Formats

Blu-Ray SUP: import (since 1.0) and export (since 1.6)
Sony BDN XML (as used by Sonic Scenarist HDMV): import and export (since 3.3.0)
HD-DVD SUP: import (since 1.9)
VobSub (SUB/IDX): import (since 3.5.0) and export (since 1.0)
DVD-SUP (SUP/IFO): import and export (since 3.9.0)

[...]
Note that BDSup2Sub will only export 8bit palettized PNGs with transparency (via tRNS tag) for maximum compatibility with Sonic Scenarist HDMV.

[...]
18.04.2009 3.2.0 -> 3.3.0

Changed: added support for importing/exporting Sony BDN XML/PNG format (used by Sonic Scenarist).
Images are automatically cropped on import.

So, it seems that the XML/PNG format is directly compatible with Scenarist, and it should be possible to import directly the XML/PNG file in Scenarist. However, the 3D PNGs are saved by ImageMagick and not directly by BDSup2Sub. If the 3D PMGs cannot be imported, you may have to load the XML/PNG or the final BD SUP stream in BDSup2Sub, and export it again to XML/PNG, to force BDSup2Sub to convert the images to 8bit palettized PNGs with transparency, as it seems that only that precise format is recognised by Scenarist.

I will see if it is possible to save the PNGs with ImageMagick directly to the right format, but it's probably not possible. Anyway, converting the streams manually should not be difficult for you.

I've googled for information about the OFS file format, but I can't find useful info. If you really need your subtitles in that format, you should ask more knowledgeable persons in the Subtitle or Scenarist forums.

Thank you r0lZ for answering me.
Scenarist accepts Sony BDN XML format, indeed. But, it accepts Z depth as either a constant for all subtitles or determined for each subtitle in .ofs file which obviously is propitiatory format and that's why it cannot be seen in public.
As I said, I keep 3D Blu-ray movies for myself remultiplexed loosing their original subtitles depth. Just put some constant -2 or -3 - no matter what.
Seeing the tool you use to extract the depth from .mvc I thought there was left only a small step towards making a perfect 3D Blu-ray remux - .ofs format.
Maybe its specification costs some money? It couldn't be secret.

[r0lZ]

Ah, OK, I understand. You need what I call "3D-plane", but in Scenarist format. ("3D-Plane" is the term used by tsMuxeR, and I have adopted it too, but I don't think it is official.)

I know that an official format exists (with an additional header), but I don't know it exactly, and I don't know if it's that format that is used by Scenarist.

Someone has asked the source files of the MVCPlane.exe (written by Nico) to add that header. I have no more news, but I will try to contact him. Perhaps he has already a modified version with the right header, or he will probably be able to give us the OFS file specs. Anyway, if he is right, indeed the job should be easy. The 3D-Plane is already almost what you need, except that it doesn't have the header.

In the meantime, if someone know where I can find the description of the header, please let me know...

[thahandy]

This? Z Depth -> BDN and OFS Technical Documents

[r0lZ]

Yeah, it's exactly what I need. Thanks!

But I would like to have also a simple example, comprising a 3D BDN stream with its associated OFS file. (The actual depth values in the OFS file do not matter, and can be constant, as long as they are not 0 or "undefined".) Please be sure to give a stream compatible with a BD3D, at 23.976 fps.

With the description and a concrete example, I will almost certainly be able to generate compatible headers to convert the 3DP files to OFS, and to "attach" the OFS to the XML/PNG file, so that it will be imported automatically when the BDN stream is loaded in Scenarist. Then, I will need also some beta testers to test if everything works as expected (because I don't have Scenarist).

[bigotti5]

An OFS file is only usefull if there are no depth values in dependent stream or you want to create new values.
Remultiplexing in Scenarist keeps all original depth values - no need for an OFS file.
Just assign original 3D plane to corresponding pg stream.

[r0lZ]

Yes, thahandy told me exactly that via PM. However, the OFS file will be very handy for peoples who are re-encoding the original BD to BD25, because in that case the depth offsets are lost during the re-encoding operation.

Anyway, I want to change the current format of the 3D-planes used by BD3D2MK3D to OFS, because that will be more universal, and peoples will be able to use the files generated by BD3D2MK3D with Scenarist if they want.

[thahandy]

Originally Posted by r0lZ

Yes, thahandy told me exactly that via PM.

wut? I assume U where pointing to SpasV. I'm just your external google guy posting the specs of OFS (I was unable to find samples) I have nothing to do with OFS itself.

[r0lZ]

Originally Posted by thahandy

wut? I assume U where pointing to SpasV.

Oh, yes, sorry.

BTW, I have been able to generate a sample myself, but with a buggy version of 3DTitle. Not sure it is correct, but at least I have a basis to work. I think I'll do a simple program to convert the 3DP files to OFS first, and when it will be sufficiently tested, I'll integrate the OFS file format directly in BD3D2MK3D.

[r0lZ]

Here is the 3D-Plane to OFS converter: 3DPlane2OFS.7z

It's a very rudimentary program, with a bad GUI, but it should be sufficient to check if the file format of the generated OFS files is correct and compatible with Scenarist (and other BD authoring programs such as Sony Blu-Print).

According to the OFS file format doc and the only example of OFS file I have, it should work fine, but I'm still not sure that everything is correct. In particular, it seems that generating the OFS file is not sufficient to be able to load it in Scenarist. It is apparently also necessary to add a Stereoscopic field in the XML file, to associate the OFS with the XML/PNG stream. 3DPlane2OFS does that too if you select an existing XML file as output, instead of a new OFS file. In that case, the OFS file is created in the same directory and with the same file name than the XML, and the XML is modified automatically.

You can also save the converted 3D-Plane directly to a new OFS, but in that case the XML is not modified, and I don't know if it is possible to associate the OFS with the subtitle stream manually in Scenarist. Please let me know if it's possible.

Note that the OFS data must have a GUID to uniquely identify it. 3DPlane2OFS generates the GUID randomly, but I'm not sure it has the right format. According to the example I have, it must have this form in the XML: {522551CE-0002-8934-AFA9-7E541327A03D}. But in the OFS file itself, it is saved in binary, but with strange inversions of the different parts. Therefore, I would appreciate if someone could check if the GUID is correct and can be used correctly by Scenarist. I have no idea of how it is possible to check that, but for information, here is the extract of the OFS file format doc:

guid: A 16-byte field that may be used to reference this offset metadata sequence in the
context of many graphics streams in one clip sharing the same offset metadata
sequence. This value may also be used to trace this offset metadata sequence in case
subsequent processing (e.g. import into authoring system) copies and divides it into
many parts. This value is generated upon creation of a new offset metadata sequence.

In case you don't have a BDN XML/PNG stream and a 3D-Plane to test the program and you don't want to process a BD with BD3D2MK3D just to obtain a stream and a 3D-Plane, you can download a sample here: 3DPlane2OFS_sample.7z
Note that the XML has already been processed by 3DPlane2OFS and contains therefore the "Stereoscopic" fields. It is however possible to process it again. The Stereoscopic fields will simply be replaced, and the OFS file overwritten. You can also delete the OFS file and replace the XML with its backup to start over from scratch.
Note also that the Depth values present in the XML have been added automatically by BD3D2MK3D. They are useless for Scenarist, and it should simply ignore them. The Depth values are not present in the backup of the XML.

I have also some doubts about the format of the depth values. Obviously, they are saved in the OFS exactly like in the BD offset sequences and the 3D-Planes extracted by BD3D2MK3D. Each frame has its own offset value. The offset (or Depth or Parallax value) is stored in bits 0-6 of the byte. Bit 7 is the "direction" of the depth. 0 is toward the spectator and 1 is toward the horizon. Therefore, the valid range of the depth values is 0 to 127, where the "sign" bit indicates the direction. 0 (hex 0x00) is therefore the surface of the screen. It doesn't make sense to specify a depth of 0 with the direction toward the background (hex 0x80, or -0) but that value is used in (almost) all 3D-Planes to represent the "undefined depth". Undefined depth values should be present only when no subtitles are displayed, and it's the case in good 3D-planes. The problem for me is that there is no reference to that 0x80 value in the OFS doc, and I don't know how it is interpreted by the authoring program. It should NEVER convert it to 0, and I would like to be sure that it doesn't do that.

Also, currently, the 3D-Planes saved by BD3D2MK3D begins always at the very first frame of the movie, and therefore I have assumed that the start timecode to store in the OFS is 0:00:00.0, but I don't know if I have to take into account the time code of the video stream, with the preroll. (I don't think so, but who know?)

Please test the OFS and XML files produced by 3DPlane2OFS as far as possible, with Scenarist or any other BD authoring app that supports the OFS files. When I will be sure that it is bug free, I will integrate the conversion to OFS format directly in BD3D2MK3D.

Please check in particular the following points:
- Is it possible to load the modified XML with its attached OFS at the same time?
- If not, is it possible to attach the OFS file to a BDN stream without 3D offset sequence from within the program?
- Can you try to modify slightly the GUID in the XML file, and load it again. Is it still possible to load the OFS at the same time, or does the authoring program trigger an error?
- Are you sure that the right depth values are multiplexed with the MVC stream when the BD is authored? (It should be possible to compare them with the original 3D-Plane if you process the BD with BD3D2MK3D.)
- Can you verify that the "undefined depth values" (0x80) are preserved by the authoring program?
- Can you verify if the time code is correct, or if the offset values have been shifted?

Anyway, thanks for any test you can do.