![]() ![]() (It's why it is a very, very bad idea to crop the black borders of the 3D movies.) They stretch the picture to occupy the whole screen anyway. Note also that many TVs (notably most Samsung TVs) assume that all 3D movies are in 16:9, and ignore completely the SAR in the AVC stream and the Picture AR in the MKV header. Again, the value to use depends of the player, and although it seems that 16:9 works for all players for Half-SBS and Half-T&B, it's not as easy for Full-SBS and T&B, and again, you have to check yourself the correct value for your hardware player. Is it the size of the two joined pictures (as saved in the MKV) that matters, or the final size of a single view? These 2 sizes are 16:9 for Half-SBS and Half-T&B, but the width or height is 2 times as big for Full-SBD and Full-T&B. It its value is easy to figure out for a 2D movie (16:9 or 1920:1080 for example), the value for Half and Full SBS and T&B are less straightforward. the AR in the MKV header describes the size of the picture. Unfortunately, BD3D2MK3D cannot know that, and I have adopted 1:1 by default, but this can be changed with Settings -> Full-SBS/T&B Aspect Ratio. Stricto sensu, they have square pixels in the h264 stream, but some players (notably most LG TVs) require respectively 1:2 or 2:1. The value to use is not clear for Full-SBS or Full-T&B. Most, if not all TVs and hardware players require 1:1, even if the pixel is rectangular. It seems logical to assume therefore that Half-SBS would require a SAR of 2:1, but it's not the case. (According to some sources, SAR was previously called PAR, Pixel AR.) AFAIK, in the AVC streams of a 2D BD, the SAR is always 1:1. A SAR of 1:1 corresponds therefore to square pixels. I don't remember exactly its definition, but it describes the aspect ratio of the pixel. SAR (in h264) means Sample AR, not Size AR. ![]() ![]() I have fixed the bug, and I will release a new version soon, probably tomorrow.īTW, may I know why you have selected the DVD SUB format rather than BD SUP? The quality of the subtitles is less good, and if your player supports the BD SUP format, I strongly recommend to use it! Also, I recommend to use exclusively the BD SUP format to burn (hardcode) the subtitles in the movie, if you use that feature. ![]() So, I have verified the palettes, and indeed, I've found that I have introduced a bug in v1.5, due to the new method used to convert the subtitles to 3D. But now, I have realized that you did not convert to BD SUP, but rather to DVD SUB. Since the palette is never used when the program converts the 3D PNGs to BD SUP, I did not understand why the colours were wrong. When the final 3D XML/PNG stream is converted to DVD SUB, the generated palette is used, and the subtitles should look better than with the original default palette. It's why I've added an analysis of the original colours of the subtitles, and BD3D2MK3D generates two palette files (one for BDSup2Sub.jar and one for ++, as they are different). You can edit it in the GUI, but the palette is never modified dynamically by BDSup2Sub itself to better clone the colours of the original subtitles. Unfortunately, to do that, it uses a fixed palette. And now, I understand better the problem.Īs I wrote above, when the subtitles must be converted to IDX/SUB (DVD format), BDSup2Sub (++ or Java) has to reduce the numbers of colours from 16 millions to just 4, and the 256 levels of transparencies also to 4. So, I did not understand that indeed, it's what you did. You have replied that when I've asked if you have converted the subtitles to DVD SUB format. I use the Program Subtitle Edit just to check the SUB. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |