View Single Post
Old 2nd September 2014, 11:14   #91  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
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...
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline