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

[r0lZ]

OK, good news! Please keep us informed if you notice a new update of the Intel drivers for one of your machines. Thanks!

[frank]

Using our reference: Avatar.
There are 85 forced subpictures (german). The time stamps are ok but the depth values go out of sync.
The video has 23.976 fps.
Look at forced sup 57, 1:36:07 "Vater!" and the following "Mutter!": depth=10
That is too little, goes into the persons.
The old v0.56 calculates depth=40 and 28. Comparing with PowerDVD this is right.

So I can't trust BD3D2MK3D v0.61 and had to recalculate the 3D sup with v0.56 Tools. (same .3dp file, plane 02)
______
frank

[r0lZ]

There is something I don't understand! There is no change in the handling of the subtitle timings or in the way the 3D-planes are used between v0.56 and v0.61! :confused:

Or, there is only one change in v0.57: I have added the patch for the "correct frame rate" in the XML file. But since then, I have discovered that that patch causes other problems, and therefore I have removed it in v0.59. That cannot be the reason.

Anyway, I will try to compare the code of the two versions to find a culprit, but I don't think there is something really different.

[frank]

In the xml of v0.56 are really 24 fps time stamps but FrameRate="23.976".
In the xml of v0.61 are really 23.976 fps time stamps but FrameRate="25".

AFAIK you have to handle the .3dp with 24 fps.

[r0lZ]

In the xml of v0.56 are really 24 fps time stamps but FrameRate="23.976".
In the xml of v0.61 are really 23.976 fps time stamps but FrameRate="25".
The FrameRate value in the XML is not used the normal way bt BDSup2Sub. It must be 25, even if it's not at all the frame rate of the movie. It's why I have restored that value in v0.59.
The frame rate written in the XML is ignored by BD3D2MK3D, and should not influence the conversion to 3D.
The fact that the frame rate has changed in the time codes is very strange. Currently, BD3D2MK3D does not force any frame rate, and the conversion should not modify the timings of the original SUP. But I may be wrong. It is very difficult to understand how BDSup2Sub works!
AFAIK you have to handle the .3dp with 24 fps.
But IIRC it's what I do. Anyway I will verify that tomorrow. In v0.57. I have introduced so many changes that I may have modified something inadvertently.

[frank]

I know the wrong fps param of xml.
Look at help from BDSup2Sub 5.1.2: https://github.com/mjuhasz/BDSup2Sub/wiki
Supported formats.
The culprit is the Sony BDN XML format that only knows integer fps.
Mjuhasz wrote:
Note: although the BDN XML looks pretty straight forward and clean, the timing information in this format is a little weird for unknown reasons. Indeed the timings are always based on an integer frame rate. The parameter --convert-fps 24p,24p is set in v0.56 and 24p symbol means 23.976 fps. The BDN xml is always converted to real 24 fps! (x 1.001)
In v0.61 is no parameter --convert-fps and BDSup2Sub thinks it is 25 fps standard. So the time stamps are untouched 23.976 fps.
Using this with .3dp results in asynchronous depth values.

[r0lZ]

Indeed, I have removed the --convert-fps argument. And, similarly, I have removed the --fps-source 24p argument when BDSup2Sub++ is used instead of the Java version (because the ++ version doesn't have the --convert-fps option). I can restore them, but if I have removed them, that was probably because they created problems. I don't remember the exact reason, but I think it's because that doesn't work well when the user specifies a frame rate in the GUI of the Convert Subtitle to 3D tool. I have to verify that too...

BTW, maybe the culprit is Sony, but in the XML, there is a frame rate AND a dropframe field. If you specify 24fps and Dropframe true, the real frame rate is indeed 23.976. No need for floating point numbers. But BDSup2Sub stores always 25 fps and dropframe false, even when the original subtitles come from a 3DBD at 23.976 fps, and if you "fix" this by forcing the right frame rate and dropframe field, you can't get your subs in sync anymore! Furthermore, having to specify --convert-fps 24p,24p (that should not convert anything) is extremely bizarre. I persist to think that the handling of the frame rate by BDSup2Sub is not correct, or at least totally counter-intuitive.

I'll do some tests with the restored --convert-fps and --fps-source options, and if that works correctly, I'll release a new version. Anyway, I will have to find a solution! Thanks for the bug report.

[|1313|]

I got anoother question is it possible to to 2d to 3d conversions? DVDFab sucks arse i think sorry for the language. And if my favourite app dont do it does anyone else know of a tool that does it? (NOT DVDFAB)

[r0lZ]

Aaah! Vade retro Satanas! ;-)

No, BD3D2MK3D doesn't do conversions. IMO, all Windows programs that are supposed to convert 2D to 3D are bad. If you have a good 3D TV like my Samsung, you don't need to convert the 2D movies to 3D. Just use the real-time conversion of the TV. Although not perfect, it is certainly much better than any conversion by a Windows program. Anyway, don't expect miracles. No automatic 3D conversion can be really satisfactory. Professional conversions are better, but they require a huge manual work, and they are very expansive.

If you want to convert anyway, the Laewo Blu-ray to MKV Converter (http://www.leawo.org/blu-ray-to-mkv-converter/) might be better than DVDFab, but I'm not sure. I have never tried it. There are certainly other alternatives, but I don't know them.


@everybody: Please be patient if you post here or wait for an update. I have had a virus and I had to re-install Windows. My programming environment is damaged, and I need to restore a lot of things. I may be absent for some days...

[|1313|]

Thanx i just asked cause i heard that i could use Avisynth. Are you finnish? And also I wanted a free software i aint gonna pay todo crappy conversions :P

[r0lZ]

I've found an avisynth script pretending to do 2D -> 3D conversions, but that was just a joke (stupid IMO)! The only thing that it does is to duplicate the 2 images, then it uses a plugin to deform the images slightly (in a parallelogram shape) and it recombines them to SBS. When played on a 3D TV, the image appears behind the surface of the screen, and produces that "aquarium effect" typical of the 3D movies. But the image is still perfectly flat, with no 3D at all. There is NO WAY to create real 3D with simple tricks like that. And as far as I know, there in no "serious" avisynth plugin to convert to 3D. Forget avisynth.

As far as I know, all Windows software that can theoretically convert to 3D are not free. And the serious ones are extremely expansive, and reserved to professionals.

@everybody: My PC is almost restored to good shape now. But the culprit was not a virus, but the Panda antivirus! (See here (http://news.thewindowsclub.com/panda-antivirus-update-likely-brick-windows-systems-restart-74490/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheWindowsClub+%28The+Windows+Club%29).) I have still a bunch of missing exe, and I need to re-install them, but I should be able to read the forums normally, and I will try now to continue to develop BD3D2MK3D...

[frank]

--convert-fps 24p,24p (that should not convert anything)...No.
The BDN XML file must be compatible with Scenarist and other BD tools. The timings in a BDN XML file are really frame counts and non-drop. The syntax for the timings is HH:MM:SS:FF, where FF = frames.
So in the case of input fps=23.976, the timings are given in the BDN XML file as if the frame rate was 24 fps. That is what BDSup2Sub generates with --convert-fps 24p,24p. Otherwise Scenarist will reject the xml file. Other tools such as avs2bdnxml, MaestroBDSubs do the same. Reason is compatibility.
Now I understand why the .3dp file must be processed as 24 fps.
Very confusing...

[r0lZ]

Finally, here is the fix for the bug reported by Frank above. I have also added an explanation in the "Convert subtitles to 3D (with 3D-Planes)" tool, to explain why it is important to use an XML file at the correct frame rate of 23.976 fps. (Click the [?] button next to the "Source FSP" option in the GUI.)

Due to the problem I got with my antivirus, I haven't had much time to test this release. I would be greateful if you can test it carefully. (@ Frank: If you have some time, please test the new frame rate changes, and the "Source FPS" option in the Convert Subtitles to 3D tool. Thanks in advance!)

I have also added an option to use the x264 resize filter instead of the avisynth resize when the output must be resized to 720p. However, I don't recommend to use x264 to do the resize, because it is slightly slower. I haven't tested the quality of the resizes. Also, the default resize filter is now the Avisynth BicubicResize, instead of Lanczos. Bicubic is much faster, and slightly better when shrinking an image.

This release has also some other improvements and little bug fixes:

# v0.62 (March 14, 2015)
# - Bug fix: The frame rate when retrieving the Depth values from the 3D-Planes was wrong. (Thanks Frank!)
# - Minor GUI changes in the Convert Subtitles to 3D tool, including a "?" button to explain how to use the frame rate option.
# - Improvement: When "both" (VobSub and BD SUP) is ticked in tab 2, the conversion to 3D is now made only once.
# - Added the possibility to resize to 720p with x264 instead of with Avisynth
# - The default resize filter for 720p is now "Avisynth Bicubic", better and much faster than the old default Lanczos
# - Replaced the dead web page for the x264 help (the [?] button next to the Additional Options field in last tab) with a new, up to date page.
# - Updated eac3to.exe (and its associated DLLs) to the latest version (v3.28).
# - Several improvements and little bug fixes.

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

[|1313|]

I see that you included x265 why?

[r0lZ]

Oops. It's an error. I did some tests with it, and I will probably adapt the code of BD3D2MK3D to include it officially in future versions, but currently, it should not be in the toolset folder. I forgot to remove it.

BTW, the syntax of x265 is relatively close to the x264 one, and it should be relatively easy to include it, but it has no --frame-packing argument, and therefore it is impossible to include the info about the 3D format in the video stream. I don't know why that option has been omitted, but it's a pity. Also, of course, many hardware players, including most recent TVs, will not be able to decode h265 video streams. At least, it's the case of my Samsung TV. So, I do NOT recommend to encode 3D movies with that too young codec. But the compression and quality of x265 are so astonishing that I am decided to include it with BD3D2MK3D, even if it's too early. I will consider it as an experimental feature. However, do not expect it soon. It's a big work for me, because there are many things to modify, and I need time...

[frank]

x265... :(
First I want that WiDi works flawlessly and I can stream Full HD to TV / beamer without stuttering! There are so many sticks and sets but nothing works as Intel promised.
---

v0.62
I miss the warning "The file exists alredy...Should I select the temp xml..." if I use the Tools to convert subtitles to 3D. Instead, the program starts immediately and overwrites files!

I believe the 720p conversion was no good idee, the 3D picture sucks. If I look 3D, than I would like to have more picture quality than 2D, and not get eye cancer. Things are now much more complicated.
____
frank

[r0lZ]

You don't need to use the 720p resize. Same thing for x265. I don't need x265 or 720p either, but some peoples want these features, and I don't think it is overcomplicated to simply ignore that new options if you don't need them. (Of course, the defaults will still be 1080p h264.)

I'll have a look at the missing warning during the subtitles conversion. I haven't removed it, but there might be a little bug here.

[r0lZ]

Sorry, but I have verified, and the dialog about the existing XML is still present and it works as expected. However, I have changed something. It is now displayed ONLY if there are already <depth> tags in the XML file. It doesn't make sense to display a warning about the risk of overwriting the depth tags (possibly edited by the user) if the depth tags do not exist.

Also, note that the directory name containing the XML is based on the output file name, and not on the input file name. So, if you convert the same input file twice, but the second time you change the output file name, you will do a completely new conversion. No XML file is overwritten, and of course the warning is not shown, but you can't use the tags already present in the first XML. If you want to be sure to use them, the simplest and more obvious method is to select the XML with the tags as the input file.

[frank]

Ok, I'll test again later. Maybe I tested the new version with an old folder from v0.56.

[Sharc]

x265... :(
First I want that WiDi works flawlessly and I can stream Full HD to TV / beamer without stuttering! There are so many sticks and sets but nothing works as Intel promised.

I have no experience with WiDi, but none of the other streaming technologies worked satisfactory for me as soon as "wireless" (WiFi in my case) was somewhere in the loop. I replaced the WiFi with PLC, using Wifi only for the last few inches in the same room if at all, and now it rocks. It does normally not even require transcoding of the source (2D or 3D at average bitrates 10....15 Mbit/s.

[|1313|]

Oops. It's an error. I did some tests with it, and I will probably adapt the code of BD3D2MK3D to include it officially in future versions, but currently, it should not be in the toolset folder. I forgot to remove it.

BTW, the syntax of x265 is relatively close to the x264 one, and it should be relatively easy to include it, but it has no --frame-packing argument, and therefore it is impossible to include the info about the 3D format in the video stream. I don't know why that option has been omitted, but it's a pity. Also, of course, many hardware players, including most recent TVs, will not be able to decode h265 video streams. At least, it's the case of my Samsung TV. So, I do NOT recommend to encode 3D movies with that too young codec. But the compression and quality of x265 are so astonishing that I am decided to include it with BD3D2MK3D, even if it's too early. I will consider it as an experimental feature. However, do not expect it soon. It's a big work for me, because there are many things to modify, and I need time...

Thanx then i know :)

[r0lZ]

I have already adapted the code for x265, and everything seems to work fine. I have still some little things to verify and I'll release a beta for testing...

[|1313|]

Nice i will test it as soon asits out and tell you about it :)

[r0lZ]

OK, here is the beta. Please note that BD3D2MK3D doesn't check the validity of the arguments passed to x265. It doesn't warn you if you use out of range parameters, or if you encode in a format not compatible with the 3D or specific hardware. (In the other hand, some safeguards exist when you encode with x264.) Also, x265 is still unstable and heavily developed. New builds are available every days. I have included the latest builds (released today), but I can't be sure that they are bug free. So, currently, consider the x265 option as experimental, and use it at your own risk.

There are other things to consider when you encode in h265 format, such as compatibility problems. For more info, see the warning when you select the x265 encoder in the Settings menu.

Please report problems when using x265 (or x264) here, with a maximum of details. Without negative reports, I will release v0.63 final in one week or so...

Download v0.63beta1: BD3D2MK3D_v0.63beta1.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D_v0.63beta1.7z)
(Since this version is a beta, you can still download the stable v0.62 via the first post of this thread.)

[|1313|]

Ill test it. I must be very noob cause i cant even find how to change from x264 to x265 in the gui :P Found it!

[frank]

Shark:
I replaced the WiFi with PLC, using Wifi only for the last few inches in the same room if at all, and now it rocks. It does normally not even require transcoding of the source (2D or 3D at average bitrates 10....15 Mbit/s. Do you mean DLNA? With server app (WMP) on PC and the (restricted) TV player app that decodes the stream?
I want to use a notebook/Android device as wireless HD player. That's what Intel is promoting. So the Blu-ray mafia can forget their stupid players.

[youli]

Hello, r0lZ. Thank you very much for this program.

I have some ideas for improve the result quality, the program functionality expansion and compatibility of mkv-container.

I'll try to explain it by the example. Suppose that I need to get "Half - Top & Bottom" video with 1080p in the first and second cases.

Firstly, about quality.
In the avisynth script you use this line:
StackVertical(VerticalReduceBy2(Left), VerticalReduceBy2(Right))
but function VerticalReduceBy2 is a "quick and dirty" filter with bilinear interpolation (quote from there - http://avisynth.nl/index.php/ReduceBy2).
I changed it to Lanczos like in this line:
StackVertical(Lanczos4Resize(Left, 1920, 540), Lanczos4Resize(Right, 1920, 540))
In my subjective perception, i got less artefacts, more sharpness, and better detalization of the picture.
May be need propose to user a possibility to make choose for the frame stack interpolation, and including Bicubic too.

Secondly, about functionality expansion.
Some people prefer to cut the letterbox black bars for make the frame on whole TV screen 16:9 (see the pictures below).
If the source video without black bars has a ratio of 2.40:1 (1920 x 800 px), then use the line:
StackVertical(Crop(Left, 248, 140, -248, -140).Lanczos4Resize(1920, 540), Crop(Right, 248, 140, -248, -140).Lanczos4Resize(1920, 540))
If the source video without black bars has a ratio of 2.35:1 (1920 x 816 px), then use the line:
StackVertical(Crop(Left, 234, 132, -234, -132).Lanczos4Resize(1920, 540), Crop(Right, 234, 132, -234, -132).Lanczos4Resize(1920, 540))
or any other interpolation instead Lanczos.
I think this options will have own fans, even if they lose about 25% of the frame.

http://s001.radikal.ru/i194/1503/5e/305bde2f7ef9t.jpg (http://s001.radikal.ru/i194/1503/5e/305bde2f7ef9.png) http://s58.radikal.ru/i162/1503/ce/9c1915d3395dt.jpg (http://s58.radikal.ru/i162/1503/ce/9c1915d3395d.png)

Thirdly, about compatibility of mkv-container.
The new mkv features in last versions of mkvmerge cause problems of compatibility with some hardware players - "fast forward" and "rewind" functions does not work or (also) does not restore play position after stop, or (even) impossible play file.
To resolve this troubles need to add by default in mkvmerge this options:
--engage no_cue_relative_position --engage no_cue_duration --clusters-in-meta-seek

[r0lZ]

Hi youli, and welcome to the Doom9 forums. But sorry. For your first post, I'm afraid I have to refuse most of your suggestions.

For points 1 and 2, I have to disagree. Lanczos is often considered the best resize filter, but if it's probably true when the image is enlarged, it is not so good when the picture is shrunk. Bicubic is usually considered as much better, at least in that case. And if it is true that the ReduceBy2 filters are quick, I'm not sure they are "dirty". According to the doc, they are very well suited when the video has simply to be divided by 2, and it's the case here. It is perhaps possible to have a slightly better result with Bicubic resize, but I'm not sure, and the result will not be optimized for halving the picture, and the processing will be much slower. Therefore, I don't think I'll change the resize filter. (Of course, you can change it manually in the AVS script if you wish.)

For the suppression of the black borders of Cinemascope movies, I have already replied to that point several times. I strongly refuse to encourage the users to distort the picture just to suppress the black bars. Furthermore, the subtitles cannot be converted to 3D correctly if the picture has been resized/distorted, because a subtitle will appear at "wrong" places over the image, and its depth will probably not be compatible with the content of the video at that place.

Most of the time, users want just to crop the black bars, to regain a few MB of useless data. These users assume that the TV will reconstruct the black borders at playback time. Unfortunately, it's not so simple, as many TVs are unable to display correctly cropped video streams in 3D, and anyway, they are optimized for true 16:9. However, you want something different. AFAIK, it's the first time that someone wants to remove the black bars AND resize the picture to occupy the whole 16:9 area, thus distorting voluntarily the image! :eek: Sorry again, but I can't accept that! If you want to butcher your movies, do it without my help!

For your remark about the new MKV options, I must say that I don't know them. I have to learn why they may be useful and what problem can happen if you omit them. If I am convinced that they are useful, I will certainly add them. Do you know a site with a good explanation on the pro and cons of these options?

[EDIT] Found this page (https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players) with good explanations about several compatibility options of MkvMerge. It seems that a good player should have no problem with the new feature, if it has been written to ignore what it doesn't understand, as recommended. Therefore, if a player has problems with the latest versions of MkvMerge, it's the player that has bugs, and theoretically I should not have to add workarounds in BD3D2MK3D. Especially, I can't force other users of good players to remove the new MKV features, just because some players are bad. So, I propose to add a sub-menu in the Settings menu, with the options described on the GitHub page. You will have to select the options needed for your system, but they will not be enabled by default. Is it OK?

[Second EDIT] This post (https://github.com/mbunkus/mkvtoolnix/wiki/Playback-does-not-work-VLC-cannot-seek-mkvmerge-v5.9.0), also by Moritz Bumkus, confirms that the bug is in the player, not in MkvMerge. In this case, the player is VLC. (BTW, I have never understood the success of VLC. It has many bugs and compatibility problems, and is often out of standard, especially with the DVD format. If you use it, you should seriously consider using a better player.)

[|1313|]

https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/hacks.cpp
Is what i find but aint saying much!

[jdobbs]

Lanczos is often considered the best resize filter, but if it's probably true when the image is enlarged, it is not so good when the picture is shrunk. Bicubic is usually considered as much better...Yep. That's a mistake a lot of people make.

[r0lZ]

Thanks for the link, |1313|, but I prefer the human readable explanation. (See the links in the edits of my previous post.)

And thanks jdobbs for the confirmation. BTW, can you also confirm that the ReduceBy2 filters are really good to, well... reduce by 2? Or is it better to use the Bicubic filter?

[jdobbs]

Thanks for the link, |1313|, but I prefer the human readable explanation. (See the links in the edits of my previous post.)

And thanks jdobbs for the confirmation. BTW, can you also confirm that the ReduceBy2 filters are really good to, well... reduce by 2? Or is it better to use the Bicubic filter?ReduceBy2 uses bilinear resizing. I would suggest it is just as good if not better than bicubic. The improvements introduced in bicubic, lanczos, spline (and others) are there (generally) to improve the introduction of the "imaginary" pixels needed for image upscaling, not downscaling. Of course you're bound to get arguments from people either way -- like anything else.

I personally use bilinear resizing for downsizing and either lanczos or spline for upsizing. That's also what's implemented as defaults in BD Rebuilder.

[r0lZ]

OK, thanks again. Personally, I prefer bicubic for downscaling, but it's only because I prefer the rendering of the first image in the "Minimation" section of this well known visual comparison (http://hermidownloads.craqstar.de/videoresizefiltercomparasion/). I suppose that bilinear might be better or at least as good in the case of real live images. And anyway I'll stick with the ReduceBy2 (bilinear) filters for now, unless someone can prove that it's not the best solution.

[jdobbs]

OK, thanks again. Personally, I prefer bicubic for downscaling, but it's only because I prefer the rendering of the first image in the "Minimation" section of this well known visual comparison (http://hermidownloads.craqstar.de/videoresizefiltercomparasion/). I suppose that bilinear might be better or at least as good in the case of real live images. And anyway I'll stick with the ReduceBy2 (bilinear) filters for now, unless someone can prove that it's not the best solution.Yeah, I would agree that in that example bicubic definitely looks better.

[Sharc]

.....However, you want something different. AFAIK, it's the first time that someone wants to remove the black bars AND resize the picture to occupy the whole 16:9 area, thus distorting voluntarily the image! :eek: Sorry again, but I can't accept that! If you want to butcher your movies, do it without my help! ........
Just a footnote: The poster is about to re-invent anamorphic sizing which was quite common for DVDs. Theoretically it is possible, provided that the correct --sar is signalled and provided that the player reads the --sar and displays the picture accordingly. Some SW players do, but I doubt if HW players would do this correctly in general because they usually display the picture either as 4:3 or 16:9, disregarding the --sar. There is one exception for blu-ray though: One can resize the 1920x1080 to 1440x1080 using --sar 4:3 and have the player play it back as 16:9. It is fully blu-ray compliant. I used this anamorph encoding for 2D but never tried for 3D. The result would be worse anyway due to the reduction of the horizontal resolution.

[r0lZ]

Yes. I agree that theoretically, you can resize the video and then restore it to its normal display ratio with the appropriate SAR value. But it's not what youli wants. And anyway, resizing the original video two times to restore the 1:1 pixel AR implies a (small but useless) quality loss. I see no advantage in doing that.

But youli has made a hit with his third suggestion (about the MKV compatibility options). I am currently testing these options, and indeed, with that options, my Samsung TV is much more rapid when it loads the movie for the first time. (It has to seek to 4 points in the video to generate the thumbnails of its pseudo-chapters, and that takes ages.) Therefore, I wonder if I should enable the 3 parameters suggested by youli by default. (It will of course be possible to disable them.)

Anyway, I want to thank youli for having pointed this out. I was not aware of these options, but I have always been frustrated by the time needed by my TV to begin the playback of a 3D MKV. I know now why it's so long. :-)

[Sharc]

Shark:Do you mean DLNA? With server app (WMP) on PC and the (restricted) TV player app that decodes the stream?
I want to use a notebook/Android device as wireless HD player. That's what Intel is promoting. So the Blu-ray mafia can forget their stupid players.
I tried streaming from PC or from NAS to TV via WLAN. I tried dlna, Serviio (with modified script to limit the bitrate), PLEX and DSVideo with their respective Apps running on the TV. I found the fluctuating WLAN to be the bottleneck which caused stuttering and frequent buffering. Cabled (CAT5) LAN was ok, but inconvenient from floor to floor. PLC was finally most convenient and stable. For streaming to mobile devices I use the PLC/WiFi extender.
(Maybe I could also have improved the WLAN by optimizing locations, antennae or using repeaters but I went straight for PLC).

[youli]

I compared the two methods of interpolation - bilinear and Lanczos (see the pictures below).

The first frame was resized to 1920x540 by VerticalReduceBy2(Left) - left eye only, and restored to 1920x1080 by built-in DXVA decoder with Daum PotPlayer.

The second frame was resized to 1920x540 by Lanczos4Resize(Left, 1920, 540) - left eye only, and restored to 1920x1080 by built-in DXVA decoder with Daum PotPlayer.

It has a little differences, but I can not choose that is better.
Perhaps for size reduction by 2 in one axis interpolation method does not important, because it has a insignificant differences.

I'll compare again later with brighter, more detailed and grainy video.

bilinear:
http://s017.radikal.ru/i400/1503/ae/89e70d8d68ect.jpg (http://radikal.ru/fp/db4988a8c4c64a5eaa964adac6ff0d1e)
Lanczos:
http://s017.radikal.ru/i434/1503/ff/628b27b06758t.jpg (http://radikal.ru/fp/431dd945fa7a4d36a3bc382b24445239)
bilinear:
http://i004.radikal.ru/1503/fd/0a84fbacfa89t.jpg (http://radikal.ru/fp/e9546b19a14e450f9ec4d4c215a27cda)
Lanczos:
http://s019.radikal.ru/i608/1503/f8/c40550551419t.jpg (http://radikal.ru/fp/f13fce1823ca4cecbc51fc35f8156a53)

[r0lZ]

Thanks for your tests.

Take into account that a grainy input video might not be a good test. The gain is (partially) removed when the file is encoded to h264. And trying to keep the grain anyway means only that the encoder will have more work to compress the video stream, and that the resulting video will consume more disc space. You have to compare the final result after compression by x264, and take into account the compression level and the final file size as well as the image quality.

[youli]

I'm always trying to save grain. I don't like blurriness in picture. I use this x264 options to save a grain:
--psy-rd ZZZ:0.05 --no-deblock --deadzone-inter 5 --deadzone-intra 5
--aq-strength YYY --ipratio 1.10 --pbratio 1.10 --qcomp 0.80
--vbv-bufsize 78125 --vbv-maxrate 62500
ZZZ = 0.70 - 1.00
YYY = 0,50 - 0.70

also for better dark gradients:
--no-mbtree --aq-mode 3

[r0lZ]

No --tune grain ?

[youli]

No --tune grain ?

No-no!! It is very harmful option.

In the "grain" preset by default:
--aq-strength 0.5 - for flat animation only - it will make more artefacts on movies.
0,7 or more need for movies,
0.5 - 0.6 for dark movies without grain, just like DOOM.

--psy-rd <unset>:0.25 - gives highly visible contour artefacts, from 0.05 to 0.10 - better for movie

[r0lZ]

OK, thanks!

[frank]

r0lZ:But youli has made a hit with his third suggestion (about the MKV compatibility options). I am currently testing these options, and indeed, with that options, my Samsung TV is much more rapid when it loads the movie for the first time....and now you believe it. :) Bunkus wrote the comment in February. I use this two params since 2013!--engage
no_cue_relative_position
--engage
no_cue_duration
Bunkus:
As has been said those elements are additional elements, and they're purely optional; both playback and seeking can work just fine without them.
You should use it, no problems. My LG beamer and my Sony box need it. And they do not demux anything for which the params were intended.:)
This mkv specs were changed AFTER production of that hardware. And mkv is NOT an industry standard as mpeg, H.264, or Blu-ray. It is an option of the manufacturer.
r0lZ, there are a lot people that can't buy a new device just because the specs have been changed. Hardware means HARD to change. Please don't forget that.
____
frank

[r0lZ]

I have never said that I don't believe something or someone related to that parameters. If I have never implemented them, that was only because I didn't know them. Now I know them and I agree that they can be useful, and therefore I have added the possibility to enable that options (and others) in the forthcoming version. You could have requested that options before, and I would probably have implemented them a long time ago. And I know perfectly that you must live with your hardware (although I don't understand why Samsung (for example) doesn't release a fix of their firmware). There is no need to reproach me for something I was not aware of.

[youli]

I found a little bug. Subtitles lost the original color after conversion. Is possible to fix it?

Converted caption (burn-in hardcode subtitle):
http://s017.radikal.ru/i417/1503/48/770b3d24f7b4t.jpg (http://s017.radikal.ru/i417/1503/48/770b3d24f7b4.png)

Original caption:
http://s019.radikal.ru/i632/1503/5e/a33433e32f4at.jpg (http://s019.radikal.ru/i632/1503/5e/a33433e32f4a.png)

----
P.S.
r0lZ, if you want, then I can help translate your program in Ukrainian, even in Russian. ;)

[r0lZ]

Hum, the problem of the color change is strange. I have never seen that. When the original SUP is converted to VobSub (IDX/SUB), relatively small differences in the colors are normal, because the VobSub format can only use 4 colors within a fixed palette of 16 colors. But when the subtitles are converted to BD SUP or XML/PNG, there should be no color differences. Anyway, BD3D2MK3D doesn't convert the subtitles itself. It uses only BDSup2Sub (and ImageMagick when converting the PNGs to 3D). I'm pretty sure that the problem doesn't come from ImageMagick, so it should be due to a bug in BDSup2Sub or to a problem in your original SUP files.

Another possibility is that it comes from the SupTitle avisynth plugin. It is used to hardcode the 3D SUP stream on the video. You can try to use VSFilter instead (with Settings -> Hardcode Subtitle Method.) The quality will be less good, but if the colors are approximately good with VSFilter, we'll know that SupTitle is the culprit. However, I don't think so. I have hardcoded the yellow forced subtitles of Avatar with SupTitle, and the colour was perfect. Therefore, again, I suspect a problem in your original SUP.

Can you send me the original SUP? I would like to have a look. Thanks in advance. (My email address is in the Contact section near the end of the PgcEdit homepage. See my signature.)

Thanks also for your proposition to translate BD3D2MK3D. I'm not sure I'll accept, because most of the time, a translation is made once, but when an update is released with new strings to translate, it takes ages to have a correct translation. Also, I have not organised my code with multi-language in mind, and it may be difficult to re-organise it. (I know that it's my fault!) The third reason is that I don't think that there are many users who want to use BD3D3MK3D and do not know English sufficiently to understand how to use it. But I may change my mind later. Anyway, thanks again!

[EDIT] I looked closely at your Converted caption image, and I wonder if the subtitles have been hardcoded with SupTitle or with VSFilter. If you have used VSFilter, the problem might be that the light yellow in the original SUP is closer to the light gray than to the light yellow in the IDX/SUB palette. Therefore, BDSup2Sub may have selected that colour. It's not really a bug, due to the fact that the colours are always modified during the conversion to VobSub. Try to use the SupTitle plugin, and everything should be fine.

BTW, SupTitle is not the default plugin because it requires .net v4 or greater to work, and I can't assume that .net is installed. But if you have .net, it is highly recommended to use SupTitle instead of VSFilter. I will try to change the default when BD3D2MK3D detects that .net v4 or greater is available. But that will work only when BD3D2MK3D is used for the first time, so you'll have to change the option manually anyway.

[youli]

I see, thanks for your answer and sent you the SUP-file, also avisynth-script and full frame with both hardsub and PGS.

UPD:
Maybe a message in the spam folder, check it

[r0lZ]

I haven't received your email yet. Something wrong?

[youli]

I sent again now from another mail.
pgcedit@gma... is this right?