View Single Post
Old 5th September 2015, 09:53   #600  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
3DPlane2OFS

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:
Quote:
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.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline