Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph [Archive] - Page 3

slavanap

10th February 2014, 14:08

Thank's slavanap and god job ;)

Pacific Rim recode in progress... :D

Slow decoding with i7 3930k :(
F:\MVCPlayer\MVCtoAVI.exe>"F:\MVCPlayer\MVCtoAVI.exe\Tools\x264\x264_x86.exe"
"F:\MVCPlayer\MVCtoAVI.exe\Preview.avs" --profile high --crf 18
--preset faster --level 4.0 --sar 1:1 -o "H:\ssifSource4.1\sample.avs.mkv"
avs [info]: 1920x1080p 1:1 @ 10000000/417083 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 4.0
[10.1%] 18986/188858 frames, 9.98 fps, 16172.58 kb/s, eta 4:43:45

frencher, thank you for testing!

The process is slow because Intel Decoder uses only one thread to decode.

The possible optimization is using a hardware accelerated version of Intel Media SDK library (libmfxhw64.dll, notice not "sw", but "hw"). But that version depends on other files, so I need to investigate this first.
With this library installed, to enable hardware acceleration simply add "-hw" option to intel_params, like this: intel_params = "-hw -d3d"

Thalyn

10th February 2014, 15:00

Pacific Rim is just slow. Even with hardware decoding my current x264 settings run it at around 15fps, where I'm normally seeing low to mid 20s.

There's also a second section to check if you want certainty, Frencher: just after 1:12:40 a Kaiju (monster) thumps a Jaeger (robot) on the head and the scene messes up similarly to the one R0lz mentioned.

HWK

10th February 2014, 15:56

frencher, thank you for testing!

The process is slow because Intel Decoder uses only one thread to decode.

The possible optimization is using a hardware accelerated version of Intel Media SDK library (libmfxhw64.dll, notice not "sw", but "hw"). But that version depends on other files, so I need to investigate this first.With this library installed, to enable hardware acceleration simply add "-hw" option to intel_params, like this: intel_params = "-hw -d3d"

No, it doesn't for hardware option you need specific type of Intel processor on board and it has nothing to do with specific library. Hardware decode will only function if supported processor is used and driver version for GPU is correct.

One of the supported configuration is Haswell CPU i7 4770K with integrated GPU HD 4600 use by videofan3d.

sef

10th February 2014, 16:02

..to enable hardware acceleration simply add "-hw" option to intel_params..
Option "-hw" also slow .. 20fps (FRIM.. shows 40-60fps.(Core i3,HD 3000))

HWK

10th February 2014, 16:11

Not sure if it helps, but about a week back I used frimsource.dll and was able to get 10 fps. However I was encoding to 3D Blu-ray so they were two instance. Also I was using preset quality over speed, which may have influence on speed.

slavanap

10th February 2014, 17:54

sef,
Option "-hw" also slow .. 20fps (FRIM.. shows 40-60fps.(Core i3,HD 3000))
Maybe the point is FRIM uses even-odd representation of the result (even frames for one view, odd ones for another), while my solution use sbs or over-under representation?

HWK,
No, it doesn't for hardware option you need specific type of Intel processor on board and it has nothing to do with specific library. Hardware decode will only function if supported processor is used and driver version for GPU is correct.

One of the supported configuration is Haswell CPU i7 4770K with integrated GPU HD 4600 use by videofan3d.
Try this out:
http://rghost.ru/52338125
create "C:\Program Files (x86)\Intel\Media SDK\" folder, copy libmfxhw64.dll file there and import install.reg to the registry. Be sure to run *.reg file from explorer to be sured that values will add to x64 registry section. Then, try to use "-hw -d3d" options.
My fps increased from 2.4 to 3.2 at Intel Core i5-2430M @ 2.4GHz

sef

10th February 2014, 19:08

Maybe the point is FRIM uses even-odd representation of the result (even frames for one view, odd ones for another), while my solution use sbs or over-under representation?
Is that a rhetorical question?:)(actually don't know,maybe)

HWK

10th February 2014, 19:24

sef,

Maybe the point is FRIM uses even-odd representation of the result (even frames for one view, odd ones for another), while my solution use sbs or over-under representation?

HWK,

Try this out:
http://rghost.ru/52338125
create "C:\Program Files (x86)\Intel\Media SDK\" folder, copy libmfxhw64.dll file there and import install.reg to the registry. Be sure to run *.reg file from explorer to be sured that values will add to x64 registry section. Then, try to use "-hw -d3d" options.
My fps increased from 2.4 to 3.2 at Intel Core i5-2430M @ 2.4GHz

thanks, this should be interesting. Just to confirm out of box for -hw option is not supported.

frencher

10th February 2014, 23:48

frencher, thank you for testing!

The process is slow because Intel Decoder uses only one thread to decode.

The possible optimization is using a hardware accelerated version of Intel Media SDK library (libmfxhw64.dll, notice not "sw", but "hw"). But that version depends on other files, so I need to investigate this first.
With this library installed, to enable hardware acceleration simply add "-hw" option to intel_params, like this: intel_params = "-hw -d3d"

;)

All hardware acceleration crash on my computer :( (-hw -d3d11 tested)
I will do more tests when I have a little time

With DirectShowMVCSource.dll And pacific Rim

F:\MVCPlayer\MVCtoAVI.exe>"F:\MVCPlayer\MVCtoAVI.exe\Tools\x264\x264_x86.exe" "F:\MVC Player\MVCtoAVI.exe\Preview.avs" --profile high --pass 1 --bitrate 8192 --preset veryslow --level 4.0 --sar 1:1 -o "H:\Decodeurs MVC\ssifSource4.1\00098.mpls.mkv"

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile Main, level 4.0
[4.3%] 8077/188858 frames, 29.75 fps, 8082.45 kb/s, eta 1:41:17

frencher

10th February 2014, 23:53

Look at 1:06:14. Soon after, you'll see the monster that appears in the fire. The bottom of the image is bad, then the whole image becomes bad. There are 6 bad frames in total.

First bad image in the sequence (Only the bottom part is bad):
http://imagizer.imageshack.us/v2/xq90/600/skjg.png (https://imageshack.com/i/goskjgp)
Last bad image:
http://imagizer.imageshack.us/v2/xq90/31/m367.png (https://imageshack.com/i/0vm367p)

There's also a second section to check if you want certainty, Frencher: just after 1:12:40 a Kaiju (monster) thumps a Jaeger (robot) on the head and the scene messes up similarly to the one R0lz mentioned.

No problem here (tested frame by frame) DirectShowMVCSource & SSIFSource 4.1 :)

Nico8583

10th February 2014, 23:58

You don't have bad frames with SSIFSource 4.1 ?
Have you tried DGMVCSource or FRIMSource ? Perhaps your source differs than others and you don't have this bug ?!

frencher

11th February 2014, 00:01

You don't have bad frames with SSIFSource 4.1 ?
Have you tried DGMVCSource or FRIMSource ? Perhaps your source differs than others and you don't have this bug ?!

I will do more tests when I have a little time
Pacific Rim with DirectShowMVCSource.dll And SSIFSource 4.1 no problem here ;)
Broken source, Any DVD or DVDFab :confused:

Cedvano

11th February 2014, 08:18

Look at 1:06:14. Soon after, you'll see the monster that appears in the fire. The bottom of the image is bad, then the whole image becomes bad. There are 6 bad frames in total.

First bad image in the sequence (Only the bottom part is bad):
http://imagizer.imageshack.us/v2/xq90/600/skjg.png (https://imageshack.com/i/goskjgp)
Last bad image:
http://imagizer.imageshack.us/v2/xq90/31/m367.png (https://imageshack.com/i/0vm367p)

On a downloaded version of Pacific Rim, there is this problem. (Show on other forum). There is a bad version on internet.

Or it's on a bad disk series.

r0lZ

11th February 2014, 09:39

It's a bad disk series. Confirmed by 3 sources, including me.

I know that some ISOs downloaded from the net cannot be used to test, because they can be bad rips. But with Pacific Rim, there are too many reports of the same problem to be an hazard. Also, when you demux a bad rip of a BD, the demuxer issues several warnings. (It's at least the case with eac3to; I'm not sure for tsMuxeR.) I have tried to demux Pacific Rim with tsMuxeR and eac3to and there was no warning.

Last evidence: The same disc (or ISO) can be processed correctly with all AVC or MVC decoders not based on the Intel Media library.

frencher

11th February 2014, 11:36

I think of a decryption problem here remains my opinion because a disc is first and foremost a master.
If master is damaged, eac3to must return a stream error to demux that does not seem to be the case.
On the other movies we have this problem:
Avatar (which decryption is only partial at the beginning)
Journey to the Center of the Earth
Legend of the Guardians: The Owls of Ga'Hoole

Je penserai à un problème de décryptage çà reste mon avis car un disque vient avant tout d'un master.
Si ce master est abimé, eac3to retournerai obligatoirement une érreur de flux au demux ce qui ne semble pas être le cas.
D'autre films on eu ce problème:
Avatar (dont le décryptage n'est que partiel au début)
Voyage au centre de la terre
Le royaume de ga'hoole - la légende des gardiens

r0lZ

11th February 2014, 12:17

On the other movies we have this problem:
Avatar (which decryption is only partial at the beginning)
Journey to the Center of the Earth
Legend of the Guardians: The Owls of Ga'HooleCan you specify the approximative time codes (or frame number) of the errors?

AFAIK, I did Avatar without problem, but I may have missed a bad frame somewhere.

allanlee

11th February 2014, 13:31

I will do more tests when I have a little time
Pacific Rim with DirectShowMVCSource.dll And SSIFSource 4.1 no problem here ;)
Broken source, Any DVD or DVDFab :confused:

As mentioned by r0lZ:
DirectShowMVCSource is based on CoreAVC (CoreMVC) -- So Decoding without problem is not something strange.
DGMVCSource, FrimSource & MVCSource all give messy screens in other systems, if SSIFSource 4.1 don't, maybe trying out those 3 on your system could give an answer.

Source difference could be another cause -- US/EU/CEE/... versions may not have identical Video/Audio streams.

frencher

11th February 2014, 14:09

Legend of the Guardians: The Owls of Ga'Hoole 00:05:41 when the father asks the sheet on the head (quand le père pose la feuille sur le tête)

r0lZ

11th February 2014, 14:35

I will try to encode Pacific Rim with ssifsource4 when my current encoding will be finished. (I'm currently testing another problem, reported by someone, with Monsters vs Aliens in 2-pass mode, where the number of frames is different during the second pass. It's a long test encode, and so far, I think there is no real problem...)

Nayker

13th February 2014, 14:49

I have the latest version of an error has occurred:
I have the latest version of an error has occurred:
Encoding _ENCODE_3D_MOVIE.avs
Movie: Predator 3D Half.OU
Encoding started 13.02.2014 17:31:16,96

D:\kino\Predator 3D Half.OU\00000_mpls>"D:\kino\BD3D2MK3D\toolset\avs2yuv.exe"
"_ENCODE_3D_MOVIE.avs" -frames 153265 -o - | "D:\kino\BD3D2MK3D\toolset\x26
4_x64.exe" --crf 18 --preset medium --tune film --profile high --level 4.1 -
-keyint 250--deblock -3:-3 --me umh --subme 9 --trellis 2 --rc-lookahead 60 --aq
-strength 0.7 --threads 8 --frame-packing 4 --qpfile chapters_3D.qpfile --ou
tput "00000_mpls.264" --frames 153265 --demuxer y4m --stdin y4m -
D:\kino\BD3D2MK3D\toolset\x264_x64.exe: unknown option -- 3
_ENCODE_3D_MOVIE.avs: 1920x1080, 24000/1001 fps, 153265 frames
error: wrote only 3085668 of 3110400
bytes

what am I doing wrong?

upd
problem solved

--crf 18 --preset medium --tune film --profile high --level 4.1 --keyint 250--deblock -3:-3 --me umh --subme 9 --trellis 2 --rc-lookahead 60 --aq

r0lZ

13th February 2014, 15:03

I don't know. Sometimes, x264 produces that error, and I have never understood why.

Note that sometimes, even with that error, it is possible to mux the file and it works as expected. Have you tried? Does MKVMerge accept the h264 file?

Anyway, I suggest to begin by fixing your command line:
-
D:\kino\BD3D2MK3D\toolset\x264_x64.exe: unknown option -- 3

I suppose the --deblock argument is wrong, or there is a missing space between --keyint 250 and --deblock.

[EDIT] You have found the problem when I was typing my reply. :-)

r0lZ

13th February 2014, 15:13

I will try to encode Pacific Rim with ssifsource4 when my current encoding will be finished.
Done. And I can confirm that ssifsource4 (v4.1) doesn't have the problem!

But I have noticed that the version of libmfxsw64.dll included in the ssifsource4 package is v4.12.12.3, and same thing for the 32-bit version. The current version of libmfxsw32.dll (distributed with DGMVCDecode and FRIMSource) is v5.13.12.7. Therefore, I wonder if the bug is present only in v5+, or if it is caused by another thing. I have just launched a new encoding of Pacific Rim, with FRIMSource and the Intel lib v4.12.12.3 (32-bit). It it doesn't have the problem, that will confirm that Intel has introduced the bug recently, and that is is not due to a bug in FRIM or DGMVCSource. Otherwise, I will have to do more tests...

jdobbs

13th February 2014, 15:45

Done. And I can confirm that ssifsource4 (v4.1) doesn't have the problem!

But I have noticed that the version of libmfxsw64.dll included in the ssifsource4 package is v4.12.12.3, and same thing for the 32-bit version. The current version of libmfxsw32.dll (distributed with DGMVCDecode and FRIMSource) is v5.13.12.7. Therefore, I wonder if the bug is present only in v5+, or if it is caused by another thing. I have just launched a new encoding of Pacific Rim, with FRIMSource and the Intel lib v4.12.12.3 (32-bit). It it doesn't have the problem, that will confirm that Intel has introduced the bug recently, and that is is not due to a bug in FRIM or DGMVCSource. Otherwise, I will have to do more tests...That would be good to know. Thanks.

allanlee

14th February 2014, 06:06

That would be good to know. Thanks.

Short clip test shows that v4.12.12.3 with DGMVCSource & FrimSource have bad frames, while curret version (5.13.12.7) with ssifSource4.1 still works fine.

Bug seems to be elsewhere.

Nico8583

15th February 2014, 12:45

A question for Full SBS/OU users : what soft do you use to play Full SBS/OU MKV ? And is there a quality difference between Full SBS and Full OU ?

sef

15th February 2014, 14:00

A question for Full SBS/OU users : what soft do you use to play Full SBS/OU MKV ?

Only .mkv, or any other container?..(Stereoscopic Player)

And is there a quality difference between Full SBS and Full OU ?

Answers to this question will be subjective, I do not see the difference ..

Nico8583

15th February 2014, 14:17

Only .mkv, or any other container?..(Stereoscopic Player)

Answers to this question will be subjective, I do not see the difference ..

I would like to create MKV so only MKV :) and Stereoscopic Player is a great player but I'm searching alternative solution (XBMC would be the best choice if possible ;) )

Yes it's subjective, do you make Full SBS or TB ? Or other ?

Thanks !

sef

15th February 2014, 14:35

..do you make Full SBS or TB ? Or other ?

Yes, I did and do. About alternatives: frencher's soft:), TotalMedia Theatre, Bino ..

Thalyn

15th February 2014, 14:49

PotPlayer is my "go to" viewer, with Bino for experimenting with frame sequential.

Full OU/SBS should, theoretically, look identical - depending upon how they're processed. I say that because I'm fairly sure when using a polarised screen (row by row display) that PotPlayer will reduce the size first and then split it up into rows, which makes them look the same as their half-dimension counterparts. In which case there becomes more of a difference between the two, in the same way there's a difference between half-SBS and half-OU. If they were just interleaved from the full frames than there would be no visible difference, and they'd look the same as frame sequential.

If you're using twin projectors or sequential (active) 3D than it probably wouldn't make a difference at all which full format you used.

Incidentally, I do all of mine as half-OU. I'd rather use frame sequential but the compatibility just isn't there.

Nico8583

15th February 2014, 20:18

Thanks for your responses.
Have you tried Bino plugin for XBMC ?

slavanap

16th February 2014, 04:20

Next version of ssifSource4. Still alpha.
http://rghost.ru/52455885

A bunch of parameters added.
Now you can dump any intermediate data to files.
For example, for dumping avc_view, mvc_view and combine_view raw data just run
ssifSource("file.ssif", 100000, intel_params = "-d3d", avc264 = "avc.h264", string mvc264 = "mvc.h264", muxed264 = "combined.h264", stop_after = SA_MUXER);

frame_count here will be ignored, but you have to play one frame next (in the VirtualDub, for example), when the dump process completes for proper completion (closing processes, pipes & files). Try with debug=true, and you'll see what I mean.

Also a support for ldecod (compiled ldecod from JM 18.6 included in the package).
Its sources available here: http://iphome.hhi.de/suehring/tml/
I plan to add an OpenMP support into this decoder, to speedup the process.

Also you can play combined.h264 and avc.h264&mvc.h264 files with the plugin - just do not specity "ssif_file" parameter (the first one).
Don't forget to change the width & height parameters in this case (set to FullHD by default).

ADD:
And don't forget to check the FPS. The plugin sets it to 24000/1001 by default.

r0lZ

16th February 2014, 11:46

allanlee

16th February 2014, 13:18

Excellent! With the new dump parameters, it will be possible to check why the other Source filters have glitches with Pacific Rim.

Your decoder could become excellent if you can really speed it up. Currently, it is much slower than the other MVC Source filters, and for that reason, it is not really useful.
It is also necessary to find a way to process all SSIF files from a MPLS easily. Currently, you have to repeat the ssifsource command as many times as there are SSIF files to decode. It's not acceptable, giving the fact that some BDs have more than 100 SSIF parts in a single MPLS!
I have also noticed that ssifsource4 uses much more memory that the other filters. Is it because it uses pipes?

Thanks, and good luck!

I think the speed and memory usage should be due to pipes.
Multiple ssif in one mpls problem currently can be solved by using: eac3to *****.mpls -demux (or import the mpls into tsMuxer and extract connected avc+mvc stream), and to my knowledge, it's highly recommended to do so even there's only 2 ssif (or m2ts) files in one mpls, since mpls can define the "real" start and end point of ssif/m2ts streams, which means in some case simply join multiple streams together will lead to incorrect total runtime (e.g. black frames).

Playing around with ssifSource4.2, will come back with test results soon. Hopefully this time the origin of the gitches can be find out.

slavanap

16th February 2014, 13:53

allanlee

16th February 2014, 14:13

Can anybody tell me how to glue avc&mvc .h264 files from different ssif files? Just add NALUs from one file and then from another?
Yes, memory consumption is because of pipes. It might be reduced, if needed.

For me, I'll use eac3to or tsMuxer to "join", since I have few knowledge about NALUs. @_@
If they are referred by an mpls, it's always better to extract streams using mpls, instead of simply glue/connect them together (which has the risk of bringing in additional frames).

Nico8583

16th February 2014, 15:50

r0lZ

16th February 2014, 19:58

Next version of ssifSource4. Still alpha.
Hum, I can't get it to demux the video streams of Pacific Rim. When I use the syntax you have provided, I see this error message:

ERROR:
Can't retrieve frame #0 !
Frame #-1 should be the next frame.
Note: ssifSource filter supports only sequential frame rendering.

However, the output files are correctly created on disc, and without having to seek/render more frames, the size of the files grow up to approx 4.9 GB for the AVC stream, 2.5 GB for MVC, and 12.8 GB for the combined stream. Then the file sizes do not change anymore, and the Source filter seems to be dead.

Unfortunately, the files extracted so far are not sufficient to reach the rendering glitch, so I can't use them to test.

As far as I know, there is no way to specify to render frame #-1, so I don't know what to do.

BTW, there are 2 little errors in the example you gave above. The parts in red must be removed:
ssifSource("file.ssif", 100000, intel_params = "-d3d", avc264 = "avc.h264", string mvc264 = "mvc.h264", muxed264 = "combined.h264", stop_after = SA_MUXER);

pistacho

16th February 2014, 20:03

I've been testing the problematic test streams upload here (http://forum.doom9.org/showthread.php?p=1666166#post1666166) (Pacific Rim) and by the time I reached the same or similar conclusions that others (allenlee (http://forum.doom9.org/showthread.php?p=1667914#post1667914), r0lz (http://forum.doom9.org/showthread.php?p=1667236#post1667236)) have commented on this forum:

The cause of corrupted frames is NOT in the demuxers (eac3to/tsMuxer) or in the combiners (MVCCombine or integrated FRIM/DGMVC/MVCsource equivalents).
The cause seems a bug in the Intel Quick Sync decoder itself but only is present if it match certain combinations: certain streams (e.g. Pacific Rim fragment) + certain decoder initialization params. + certain mode hw/sw decoding.

At the moment, I do not know the exact conditions that have to give, but I found a way that seems to solve the problem in SW mode. It is a "workaround" because I do not think it can be a long-term solution and the bug is still present in HW mode.

This version really did not intend to fix this but other small improvements and update to Intel Media SDK 2014.

I've updated the MVCsource thread with this test version...
http://forum.doom9.org/showthread.php?p=1668665#post1668665

EDIT:
Since MVCsource has not an explicit param. to force hw/sw decode, to ensure SW is used and workaround fix is "active" you can rename temporally Intel Quick Sync driver location e.g.:

C:\Program Files\Intel\Media SDK to C:\Program Files\Intel\_Media SDK_

pistacho

16th February 2014, 20:41

More info:

ssifSource v4.1 in hw mode also has a frame corruption in same fragment.

e.g.:

LoadPlugin("T:\DOWNLOADS\ssifSource4.1\ssifSource2.dll")
ssifSource("E:\BDMV\STREAM\SSIF\00000.ssif", 208, horizontal_stack = true, intel_params = "-hw -d3d", debug = true)

Would be nice if someone else could confirm this on another system

pistacho

16th February 2014, 21:02

And the definitive test:

MPC-HC supports playing SSIF files and incorporates an internal Intel Quick Sync decoder.

Do not need anything else!

http://imageshack.com/a/img812/5027/5hh7.png

http://imageshack.com/a/img208/8792/zxaq.png

Same corruption in same point :)

Thalyn

17th February 2014, 06:03

That's actually the LAV video decoder (v0.60.1.5 judging by the dialogue) - not something built in to MPC-HC. But it does add nicely to the pile, which includes Handbrake, to suggest the issue is with QuickSync and/or how it's implemented in that particular version.

slavanap

17th February 2014, 07:35

Hum, I can't get it to demux the video streams of Pacific Rim. When I use the syntax you have provided, I see this error message:

However, the output files are correctly created on disc, and without having to seek/render more frames, the size of the files grow up to approx 4.9 GB for the AVC stream, 2.5 GB for MVC, and 12.8 GB for the combined stream. Then the file sizes do not change anymore, and the Source filter seems to be dead.

Unfortunately, the files extracted so far are not sufficient to reach the rendering glitch, so I can't use them to test.

As far as I know, there is no way to specify to render frame #-1, so I don't know what to do.

BTW, there are 2 little errors in the example you gave above. The parts in red must be removed:
When the filesize completes change just seek to another frame in VertualDub, and then the process will be completely completed (for example, if you use SA_MUXER, then MVCCombine.exe exits).
This error that shows (about wrong framenumber) is a workaround and prevents the decoder output processing code to run, because you specified that pipeline must be over after muxer (SA_MUXER) or demuxer (SA_DEMUXER)

slavanap

17th February 2014, 07:48

I'm agree with r0lZ, SSIF is not suitable because many BD use more than 1 SSIF. MPLS would be a greater choice, but it must considers multi-angles playlists...
Do you plan to add other format supported by Intel Media Decoder, like H264 2D, VC-1, MPEG2 ?

Ok, I'll support param for VC-1, MPEG2 support. H264 2D is supported already, and should work (I hope).

Then I have another question @all
Does anybody knows format of mpls file?
What information is in there for each m2ts/ssif fragment?

r0lZ

17th February 2014, 11:02

When the filesize completes change just seek to another frame in VertualDub, and then the process will be completely completed (for example, if you use SA_MUXER, then MVCCombine.exe exits).OK, I'll try that.
This error that shows (about wrong framenumber) is a workaround and prevents the decoder output processing code to run, because you specified that pipeline must be over after muxer (SA_MUXER) or demuxer (SA_DEMUXER)Can you change that message to something more meaningfull? For example, to "Ignore this message. The demuxing is in progress..." And, if it's possible, add the number of the frame currently demuxed?

Then I have another question @all
Does anybody knows format of mpls file?
What information is in there for each m2ts/ssif fragment?
I have searched that too, but found only partial or very cryptic info. I'm also interested in a comprehensive file format description.

sef

17th February 2014, 15:35

What information is in there for each m2ts/ssif fragment?

https://github.com/acdvorak/bdinfo-c/blob/master/parse_mpls.c ??

r0lZ

17th February 2014, 16:28

AFAIK, that code is valid for 2D MPLS files only. It doesn't "know" the 3D extensions.

sef

17th February 2014, 18:10

..ssif fragment?

.mpls provides information only about m2ts(main and dependent)..

frencher

20th February 2014, 01:44

Simple tutorial (Sorry in french) for change Video, Audio, Subtitle track from original 3DBD to new FULL 3DBD ISO ;)

Changer la piste VFQ (AC3 5.1 @ 448 Kbps) en VFF (DTS 5.1 @ 1536 Kbps) BD3D d'exemple "Gravity 3D" (Zone 1)

01 - Extraire l'intégralité de l'ISO original sur un disque dur (prevoir jusqu'à 150 Go)
02 - Prendre le MPLS du film ou de la partie à modifier, dans notre cas c'est ".\BDMV\PLAYLIST\00098.mpls"
03 - Ouvrir "00098.mpls" avec un éditeur Hexa pour trouver les (m2ts) associés dans notre cas ".\BDMV\STREAM\00098.m2ts"+".\BDMV\STREAM\SSIF\00098.ssif" vue AVC et ".\BDMV\STREAM\00104.m2ts" vue MVC
04 - Les partie CLPI ".\BDMV\CLIPINF\00098.clpi" synchro AVC, ".\BDMV\CLIPINF\00104.clpi" synchro MVC sont nécessaire
05 - Ouvrir ".\BDMV\PLAYLIST\00098.mpls" avec Network Optix tsMuxeR v2.6.11 (http://forum.doom9.org/showthread.php?t=168539) (version que j'ai utilisé)
06 - Dans l'onglet "Input" Mettre en Output (Blu-ray ISO) et choisir le dossier ou sera créé l'ISO par exemple "00098.mpls.iso"
07 - Dans l'onglet "Blu-ray" Mettre dans Options (First MPLS file) ".\BDMV\PLAYLIST\00098.mpls" = 98
08 - Dans l'onglet "Blu-ray" Mettre dans Options (First M2TS file) ".\BDMV\STREAM\00098.m2ts" = 98
09 - Créez l'ISO via ".\BDMV\PLAYLIST\00098.mpls" après avoir remplacé La piste VFQ (AC3 5.1 @ 448 Kbps) en VFF (DTS 5.1 @ 1536 Kbps)
10 - Déplacez tous les fichiers à remplacer hors de la structure de l'ISO original sur disque dur ici nous avons "00098.mpls", "00098.m2ts", "00104.m2ts", "00098.ssif", "00098.clpi", "00104.clpi"
11 - Monter "00098.mpls.iso" dans un lecteur virtuel
12 - Extraire dans un autre dossier ".\BDMV\PLAYLIST\00098.mpls"
".\BDMV\STREAM\00098.m2ts"
".\BDMV\STREAM\00099.m2ts"
".\BDMV\STREAM\SSIF\00098.ssif"
".\BDMV\CLIPINF\00098.clpi"
".\BDMV\CLIPINF\00099.clpi"
13 - Renommer "00099.m2ts" en "00104.m2ts"
14 - Renommer "00099.clpi" en "00104.clpi"
15 - Editer avec un éditeur Hexa "00098.mpls" pour remplacer (00099M2TS) par (00104M2TS) et enregister la modification
16 - Replacer les fichiers finis dans la structure de l'ISO original sur disque dur ".\BDMV\PLAYLIST\00098.mpls"
".\BDMV\CLIPINF\00098.clpi"
".\BDMV\CLIPINF\00104.clpi"
".\BDMV\STREAM\00098.m2ts"
".\BDMV\STREAM\00104.m2ts"
".\BDMV\STREAM\SSIF\00098.ssif"
17 - Monter l'iso Testé avec "DVDFab Virtual Drive v1.5.0.0" et testez le
18 - Si tout à fonctionné votre film se lance en VFF (DTS 5.1 @ 1536 Kbps) et vous pouvez recréer un ISO fonctionnel ;-)

pommesmatte

20th February 2014, 21:06

Just noticed that the current release uses VerticalReduceBy2 for achieving HalfTaB Encodes.

Afaik that incorporates a quite big information loss compared to a "real" resize filter like LanczosResize or BicubicResize.

Am I wrong?

r0lZ

20th February 2014, 22:19

IMO, ReduceBy2 (http://avisynth.nl/index.php/ReduceBy2) is a good compromise between speed and quality, and it should be equivalent to the BilinearResize that was the default with the previous versions. Don't forget that the image is divided exactly by 2 (in one direction), and therefore a simple algorithm is more than sufficient to archive good results. It's not like complex resizes with a lot of artifacts. Here, it is theoretically sufficient to merge each pair of pixels in a single pixel, and for that matter, the simpler resize filters do an excellent job, often superior than the complex filters like lanczos or spline. Bicubic is usually not recommended to reduce an image (even by a factor different than 0.5), and bilinear is well known to give better results in that case. Anyway, if you prefer another filter, you can manually edit the script.

pommesmatte

21st February 2014, 12:57

Thanks for the excellent explanation.
Makes sense with the factor 2.

pistacho

23rd February 2014, 17:21

Coming soon ;)

http://111.imagebam.com/download/9z53_xg9qNiwjNV6HzGjSQ/31000/309990414/MVCenc.png

slavanap

23rd February 2014, 18:41

Cedvano

23rd February 2014, 19:25

Coming soon ;)

http://111.imagebam.com/download/9z53_xg9qNiwjNV6HzGjSQ/31000/309990414/MVCenc.png

Great ! I'm waiting... :o

frencher

23rd February 2014, 23:55

Next version of ssifSource - 4.3
http://rghost.ru/52622403
mplsSource function added to play mpls-files.
Note, it may not work with some mpls-files (duplicate parts may follow at the end of the file. See mpls_tool output for more info).
mpls_tool.exe shows the order in which ssif/m2ts files will follow in the result video.
Run "mpls_tool NNNNN.mpls" and look through "Stream Clips" section.

Good news slavanap ;)
My test with mpls
Script error: there is no function named "mplsSource"
(H:\ssifSource4.3\sample.avs, line 49)

SA_DEMUXER = 0
SA_MUXER = 1
SA_DECODER = 2

# function proto:

# ssifSource(
# string ssif_file, # path to ssif file
# int frame_count, # precise framecount
# bool avc_view = true, # whether to show base view
# bool mvc_view = true, # whether to show dependent view. If 'false' then muxer stage skipped (MVCCombine is not used)
# bool horizontal_stack = false, # whether to stack both views horizontally or vertically
# bool swap_views = false, # whether to exchange views positions (top/bottom, left/right)
# string intel_params = "", # addiditional params for intel decoder. if the first symbol is not '-', then
# # you also should specify video type (mpeg2|h264|vc1|mvc|jpeg)
# bool debug = false, # whether to show debug consoles
# int use_ldecod = false, # whether to use JM decoder instead Intel decoder
# string avc264 = <using_autogenerated_pipename>, # filenames to dump intermediate data (or import data into the pipeline)
# string mvc264 = <using_autogenerated_pipename>,
# string muxed264 = <using_autogenerated_pipename>,
# int width = 1920, # necessary if you don't use demuxer step (ssif_file is not spicified)
# int height = 1080, # you should specify avc264 and/or mvc264 or muxed264 parameter then
# int stop_after = SA_DECODER # stop pipeline at any part (for dumping intermediate data)
# );

# mplsSource(
# string mpls_file, # path to mpls file
# int ssif_path, # path where ssif files is placed (isn't necessary, if you specify mpls file at bluray disc)
# ------------------------
# same as for ssifSource: # these parameters below delivered unchanged to ssifSource function
# ------------------------
# bool avc_view = true,
# bool mvc_view = true,
# bool horizontal_stack = false,
# bool swap_views = false,
# string intel_params = "",
# bool debug = false,
# int use_ldecod = false,
# );

# NOTICE:
# * when mplsSource is used then the error message about what frame is should be decoded next displays incorrectly (it contains wrong frame number)
# * all parameters combinations were not tested. Plugin may crash with wrong parameters
# * not all mpls files are processed correctly (see diagnostic info for what ssif(m2ts) files is used for playing mpls file)

LoadPlugin("ssifSource2.dll")
#ssifSource("..\samples\ISO\BDMV\STREAM\SSIF\00001.ssif", 465, intel_params = "-d3d", debug = true)
mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = false, intel_params="-d3d", debug = true)

H:\ssifSource4.3>mpls_tool.exe "P:\BDMV\PLAYLIST\00098.mpls"
P:\BDMV\PLAYLIST\00098.mpls
===========================

Playlist duration: 01:30:58.495

Tracks (13):

type #
------------------------ --
Primary Video: 1
Primary Audio: 4
Subtitle (PGS): 7
Interactive Menu: 1
Secondary Video: 0
Secondary Audio: 0
Picture-in-Picture (PiP): 0

Stream Clips (1):

idx filename duration
--- ---------- ------------
1: 00098.M2TS 01:30:58.495 245632261

Chapters (zu):

idx start time
--- ------------
1: 00:00:00.000
2: 00:13:08.830
3: 00:21:33.542
4: 00:29:12.668
5: 00:39:59.856
6: 00:48:49.051
7: 00:57:00.667
8: 01:08:08.418
9: 01:15:27.148
10: 01:23:50.567

slavanap

24th February 2014, 09:15

frencher,
Looks like wrong version of ssifSource2.dll loaded from somewhere else (maybe from Avisynth "plugins" directory). Specify full path for LoadPlugin function and it'll fix the problem.
I just tested it in a clear environment and it works fine.

LoadPlugin("H:\ssifSource4.3\ssifSource2.dll")
#ssifSource("..\samples\ISO\BDMV\STREAM\SSIF\00001.ssif", 465, intel_params = "-d3d", debug = true)
mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = false, intel_params="-d3d", debug = true)

P.S. I'll do a minor fix to ssifSource output to the console later, because info messages now messes up in the console (when use x264 encoder).

@all
EDIT:
The mpls_tool output for wrong mpls files, I told you about, looks like this:
ignore bad chapter
ignore bad chapter (repeats 174 times)
d:\BDMV\PLAYLIST\00020.mpls
===========================

Playlist duration: 05:55:50.078

Tracks (2):

type #
------------------------ --
Primary Video: 1
Primary Audio: 1
Subtitle (PGS): 0
Interactive Menu: 0
Secondary Video: 0
Secondary Audio: 0
Picture-in-Picture (PiP): 0

Stream Clips (302):

idx filename duration
--- ---------- ------------
1: 00021.M2TS 00:01:10.696 3181303
2: 00021.M2TS 00:01:10.696 3181303 (repeats 302 times)

Chapters (zu):

idx start time
--- ------------
1: 00:00:00.000
...
129: 02:29:38.344

Press any key to continue . . .
One part duplicates many times at the end. And the filesize of these mpls files is about 20kB.
Although, these files might be made for infinite playback.

EDIT2:
If mvc_view=true then the plugin uses ssif files (for every part in mpls file) from SSIF folder.
If mvc_view=false then it will use m2ts files for base view decoding.

EDIT3:
For now the plugin doesn't use swap_views autodetection based on mpls file. I will add it soon.

frencher

24th February 2014, 13:16

mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = true, intel_params="-d3d", debug = true)
x264 [0.9%] 1129/130874 frames, 10.94 fps, 536.36 kb/s, eta 3:17:44

And with...

mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = false, intel_params="-d3d", debug = true)
x264 [1.2%] 1566/130874 frames, 21.83 fps, 1054.84 kb/s, eta 1:38:42

Can you fix path problem ?
Good update ;)

slavanap

24th February 2014, 20:58

Can you fix path problem ?
Good update ;)

Thank you! :)
To fix the "path" problem locate and delete ssifSource2.dll in the folder "c:\Program Files (x86)\AviSynth 2.5\plugins"

frencher

24th February 2014, 23:30

Thank you! :)
To fix the "path" problem locate and delete ssifSource2.dll in the folder "c:\Program Files (x86)\AviSynth 2.5\plugins"

Strange :confused:

http://i59.tinypic.com/5xlxep.png

slavanap

25th February 2014, 00:10

Strange :confused:

http://i59.tinypic.com/5xlxep.png

I see. Then it might loaded from other directory (depends on path variable and the files in directory, from where you start .exe file that loads the .avs file.)
You may see from where dll is loaded with Process Explorer tool, for example. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
http://oi58.tinypic.com/20gzed1.jpg

r0lZ

25th February 2014, 00:34

You can also use the command prompt and type:where ssifSource2.dll
You should see the locations from your PATH where the dll can be found and loaded by Windows, sorted by order of "preference".
In the case of ssifsource, you should delete all instances referenced by the where command.

frencher

25th February 2014, 10:36

OK i have found the problem
My player load ssifSource2.dll (with magic path) from my player (in same path)
I have just renamed your ssifSource2.dll (4.3) to ssifSource4.dll and works correctly ;)

slavanap

25th February 2014, 21:54

r0lZ

26th February 2014, 00:12

Next version of ssifSource 4.4: http://rghost.ru/52667911Hum, I can't go to that page:
Sorry, but rghost.ru is blocked on this network.
This site was categorized in: Pornography
I will try tomorrow with another DNS, but you should consider to post your new versions on a site less questionable.
Decoding speed increased (with using ldecod.exe instead Intel decoder)Really? Ldecod is faster than the Intel lib? I can't believe that!

sef

26th February 2014, 06:03

Thanks slavanap!

use_ldecod = true.. (ldecod has some problem with some BD3D)..

http://i58.fastpic.ru/big/2014/0226/fd/2e4c88cf2361dad60d3f35d2e7ed43fd.jpg

..Decoding speed increased (with using ldecod.exe instead Intel decoder)

At me, ldecod and Intel have same speed: ~10fps..(Core i3 HD 3000)..

frencher

26th February 2014, 06:57

Next version of ssifSource 4.4: http://rghost.ru/52667911
Swap views flag autodetection added (turns on, if no swap_views parameter specified to mplsSource),
Decoding speed increased (with using ldecod.exe instead Intel decoder),
Default parameters a little bit changed (now ldecod decoder is used by default),
dll renamed to ssifSource4.dll, and other minor fixes.

If you detect any bugs, artifacts or other non-proper things with new decoder (ldecod) or plugin itself, please report.

EDIT:
already uploaded but forgot to change the script comment, in sample.avs line 35 should be
# bool swap_views = <autodetection>,
instead
# bool swap_views = false,

With ldecod: Green frames with Ice Age 4 3D
mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = true)
x264 (Ultrafast) [0.8%] 1023/130874 frames, 21.06 fps, 390.55 kb/s, eta 1:42:46

With Intel: Good with Ice Age 4 3D
mplsSource("P:\BDMV\PLAYLIST\00098.mpls", mvc_view = true, intel_params = "-d3d", use_ldecod = false)
x264 (Ultrafast) [0.8%] 1027/130874 frames, 11.03 fps, 396.25 kb/s, eta 3:16:15

How use Multi-Angle ?

slavanap

26th February 2014, 11:03

Hum, I can't go to that page:
Sorry, but rghost.ru is blocked on this network.
This site was categorized in: Pornography
I will try tomorrow with another DNS, but you should consider to post your new versions on a site less questionable.
Really? Ldecod is faster than the Intel lib? I can't believe that!

I couldn't know that. Here is another link: http://sendfile.su/946154

They have similar speed now. For me, ldecod is 2fps faster. 12fps vs. 10fps

slavanap

26th February 2014, 11:08

With ldecod: Green frames with Ice Age 4 3D

With Intel: Good with Ice Age 4 3D

How use Multi-Angle ?
Thank you for testing, frencher!! :)
It looks like my expectations about JM decoder haven't met. :( Looks like ldecod.exe just crashed this time.
I'm not sure I can speed up Intel sample_decode.exe decoder, although its sources is available from the Intel Media SDK.

About multi-angle, can you name any title that available in Blu-ray and uses multi-angle?
Does Ice Age 4 3D use multi-angle?

pistacho

26th February 2014, 11:20

BDtoAVCHD Version 2.1.2 (02/26/2014)

New: Ability to shrink 3D Blu-Ray to BD-25 or BD9 keeping 2D+3D ISO MVC format (movie only). The obtained BD9 discs are playable on most 3D Blu-Ray players.

http://111.imagebam.com/download/14b5ksWkflEaq5204_M3cA/31067/310664971/MVCenc2.png

http://forum.doom9.org/showthread.php?t=154957

r0lZ

26th February 2014, 11:47

Here is another link: http://sendfile.su/946154Thanks. I got it now.

They have similar speed now. For me, ldecod is 2fps faster. 12fps vs. 10fpsIs it a new version of ldecod?

frencher

26th February 2014, 13:05

Thank you for testing, frencher!! :)
It looks like my expectations about JM decoder haven't met. :( Looks like ldecod.exe just crashed this time.
I'm not sure I can speed up Intel sample_decode.exe decoder, although its sources is available from the Intel Media SDK.

About multi-angle, can you name any title that available in Blu-ray and uses multi-angle?
Does Ice Age 4 3D use multi-angle?

Yes Ice Age 4 3D use Multi-Angle "00800.mpls" ;)

slavanap

26th February 2014, 14:56

Is it a new version of ldecod?
It is a little bit modified version of JM18.6.
I add OpenMP pragma for one of the most often used function call. Now these calls executes in separate threads.
I can upload the patch file to original JM decoder with this change if you want.

Cedvano

26th February 2014, 15:16

r0lZ

26th February 2014, 16:02

It is a little bit modified version of JM18.6.
I add OpenMP pragma for one of the most often used function call. Now these calls executes in separate threads.
I can upload the patch file to original JM decoder with this change if you want.I see. Thanks.
I don't need the patch. I just wanted to know why that version is faster than the original.

Thalyn

28th February 2014, 08:28

Ha-freakin'-za! Finally got a fully working decode of Pacific Rim without using CoreAVC. SSIFSource4.4, using the JM18.6 path, worked just fine.

Speed wise it's decent but the decoder was taking a huge chunk out of it - I was showing up to 40% of my CPU time (according to the Task Manager in Win8.1) being used for decoding, with x264 often using less than 60% (even when the decoder wasn't using the full 40%) suggesting x264 was being starved for frames. End result was 11.36fps, as compared to around 13fps for FRIM in software, 14fps for MVCSource in software or 15.5fps for DGMVC in hardware (all with matching x264 settings), but at least it worked. CPU in use is an i7 4770K running at 4.2GHz with HT enabled.

It did have an issue with MeGUI, however. It would crash upon attempting to queue the file (APPCRASH in MpegSplitter_mod.ax module) each and every time. Fortunately it would crash after it actually added it to the queue so I could just reload MeGUI and set it to task. I was having difficulties with the debug flag initially but these seem to have abated following a restart (it was crashing even attempting to load the file before queuing it, leaving orphaned tasks).

Gonna give it a crack at Escape in a little bit. Fingers' crossed it should be OK.

Update: Bah! Bah, I say! Escape gets to frame 54,981, then just repeats the end frame until the count is met. MeGUI's log gives the following lines:
[Information] [1/03/2014 4:05:59 AM] Error writing to pipe! | 0x0000006d: The pipe has been ended.
[Warning] [1/03/2014 4:05:59 AM] WARNING: Decoder output finished. Frame separator can't read next frames. Last frame will be duplicated as long as necessary (73368 time(s)).
[Information] [1/03/2014 4:05:59 AM] Error writing to pipe! | 0x0000006d: The pipe has been ended.
[Information] [1/03/2014 4:05:59 AM] Error writing to pipe! | 0x000000e8: The pipe is being closed.

Plus side, it doesn't give the error from earlier. It just seems to lose the pipe at the same place, consistent across two attempts (including multiple restarts between them).

pistacho

1st March 2014, 11:18

DGMVCsource b22 vs. FRIMsource v1.22 vs. MVCsource v2.1.2

Yes! Comparisons are odious (but help to improve) :)

System specs: Intel i7-3770K (Intel HD Graphics 4000)
Graphics drivers: 10.18.10.3345
Test tool: AVSMeter v1.7.6 (by Groucho2004)

AVSMeter.ini
CreateLog=0
PauseBeforeExit=1
FrameRange=0,-1
InvokeDistributor=1
AllowOnlyOneInstance=1
LogEstimatedTime=0

DGMVCsource.avs
LoadPlugin("T:\DOWNLOADS\dgmvcsource100b22\DGMVCdecode.dll")

DGMVCSource("T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.avc.h264", "T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.mvc.h264", view=0, frames=5000)

FRIMsource.avs
LoadPlugin("T:\DOWNLOADS\FRIM_x86_version_1.22\x86\FRIMsource.dll")

FRIMsource("mvc", "T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.avc.h264", "T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.mvc.h264", num_frames=5000)

MVCsource.avs
LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.avc.h264", "T:\TEMP\CLOUDY WITH A CHANCE OF MEATBALLS 2.mvc.h264", 5000, 2)

http://111.imagebam.com/download/6O3f2YYHWyVFz2HPnIhRAQ/31126/311259289/DGMVCsource.png

http://109.imagebam.com/download/5cpDm8KNvOKMXamlQArmZA/31126/311259298/FRIMsource.png

http://109.imagebam.com/download/ozFRcLamOliXXng3p10JWA/31126/311259292/MVCsource.png

http://101.imagebam.com/download/Hm_qepRrlf_NyGpyDsbxuw/31126/311259287/Bars-graphic.png

slavanap

1st March 2014, 11:42

Ha-freakin'-za! Finally got a fully working decode of Pacific Rim without using CoreAVC. SSIFSource4.4, using the JM18.6 path, worked just fine.

...

Gonna give it a crack at Escape in a little bit. Fingers' crossed it should be OK.

Update: Bah! Bah, I say! Escape gets to frame 54,981, then just repeats the end frame until the count is met. MeGUI's log gives the following lines:

Plus side, it doesn't give the error from earlier. It just seems to lose the pipe at the same place, consistent across two attempts (including multiple restarts between them).

Thalyn, thank you very much for testing! :)

Does you tried to use parameter use_ldecod=false for ssifSource/mplsSource for Escape? With this param ssifSource plugin will use Intel decoder instead JM18.6.
Also, how many parts Escape consists of? And is there .ssif files in STREAM\SSIF folder for all of them?

Unfortunately, I didn't have MeGUI and didn't tested the plugin with it. As for MpegSplitter, it actively uses Windows COM. This may be the issue. So I'll try to find out whether isolating MPEGSplitter into separate thread can fix this.

P.S. Also you can find out what and where crashed by checking Windows Event Log right after the crash (Start->Run type eventvwr.msc, then at the left pane select Windows Logs -> Application, crashes/errors are marked with red icon; use F5 for update).

Thalyn

1st March 2014, 17:00

Escape's only a single ssif file. I've also got it running off a HDD to get better access times in order to eliminate as many problems and bottlenecks as possible.

I haven't given it a try with the Intel decoder yet. I'll let that run tonight and get back to you on the results. Given my past experiments and experiences I'll leave it with the default settings, which is interestingly suggesting it's using SDK v1.6 - perhaps a little hint as to something you've discovered?

Straight off the bat the CPU usage of Sample_decode.exe is about half, though to be fair this is a different title (I didn't watch Escape's stats when I was using ldecod before). X264 CPU usage is also a bit lower, but it seemed to be hitting the drive quite a lot early on which was lowering its usage further. Perhaps it's MVCCombine that's causing the bottleneck - have you toyed with Neuron2's DGMVCCombine (http://neuron2.net/dgmvccombine/dgmvccombine102.zip) to see if any extra speed can be had (assuming it supports pipes)?

Admittedly it's only just started, it's currently sitting at 11.71fps as compared to the 21.69fps I got previously from FRIM through hardware, but it is slowly climbing. In fact, by the time I reached this part of the post it had hit 11.79fps - though curiously harddrive access has dropped to almost nothing and x264's CPU usage is a tiny 20%!

*update*
Insert a second "Ha-freakin'-za!" here - it appears to have worked. Being an animation it's hard to tell from quick glances if sync is gone (which would indicate missing frames) but it's pretty damned close if it has, so I won't know for certain if there's any problem until I watch it start to finish. Final transcode speed was 12.36fps, so something is definitely slowing it down without using any processor time to do so.
*end*

In more technical aspects, however....

The crash as it's presented when I tell it to queue:
Description:
Stopped working

Problem signature:
Problem Event Name: APPCRASH
Application Name: MeGUI.exe
Application Version: 1.0.2418.0
Application Timestamp: 526ab90e
Fault Module Name: MpegSplitter_mod.ax
Fault Module Version: 1.6.8.7378
Fault Module Timestamp: 530a2a5d
Exception Code: c0000005
Exception Offset: 0002e0e6
OS Version: 6.3.9600.2.0.0.256.48
Locale ID: 3081

As presented in the Event Viewer:
Faulting application name: MeGUI.exe, version: 1.0.2418.0, time stamp: 0x526ab90e
Faulting module name: MpegSplitter_mod.ax, version: 1.6.8.7378, time stamp: 0x530a2a5d
Exception code: 0xc0000005
Fault offset: 0x0002e0e6
Faulting process ID: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report ID: %13
Faulting package full name: %14
Faulting package-relative application ID: %15

And the accompanying Information entry in the Event Viewer:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MeGUI.exe
P2: 1.0.2418.0
P3: 526ab90e
P4: MpegSplitter_mod.ax
P5: 1.6.8.7378
P6: 530a2a5d
P7: c0000005
P8: 0002e0e6
P9:
P10:

Attached files:

These files may be available here:
C:\Users\Thalyn\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_MeGUI.exe_972f6e465ca02b3aaaba79883db4cc71935cef5c_00000000_0f94bbb0

Analysis symbol:
Rechecking for solution: 0
Report ID: 4afbef50-a157-11e3-bfe1-74d02b2b53ef
Report Status: 2048
Hashed bucket:
(wish this forum had "spoiler" tags so I could reduce the footprint of this post)

Nico8583

3rd March 2014, 00:11

Hi,
If anyone use Full SBS or TAB, how do you use subtitles ?
Like Half SBS / TAB, is it necessary to make one subtitle for left and one for right ?
Thanks !

r0lZ

3rd March 2014, 01:00

To my knowledge, currently, it is not possible to convert the subtitles to Full-SBS or Full-T&B. If your TV or player is smart enough, it will show the 2D subtitle stream in 3D, but don't expect miracles.
You can, of course, hardcode the subtitles on each view of the video stream (with a small X offset to add 3D-depth), but hardcoded subtitles are not an elegant solution.

Nico8583

3rd March 2014, 12:17

Thanks r0lz, so it's not possible to "duplicate" subtitles on both sides like Half SBS ?

Thalyn

3rd March 2014, 12:36

Theoretically you could create something large enough to span both frames, but it would need to be done using SSA (or similar) or an image-based system (PGS or SUB/IDX). SSA would have to duplicate the same line twice with positioning settings changed appropriately, while image-based methods would just need really, really large images (1920x2160 for full-OU, 3840x1080 for full-SBS) with the appropriate locations and offsets. I don't know if these image-based formats allow for such large frames, though, so that could be a fly in the proverbial ointment.

I should point out that I've never actually tried this myself, however. I'm still doing half-OU encodes for compatibility, and so far I've hard-coded all my subs as I don't have anything I'd be watching without them.

r0lZ

3rd March 2014, 13:10

The problem is that the SUB/IDX format supports only the standard resolutions (PAL, NTSC, 720p and 1080p). (The IDX file contains only a single parameter with the video format, but it doesn't contain the width and height, or a SBS or T&B option.)

It is not difficult to create the large PNG images theoretically suitable for Full-SBS/T&B, as Thalyn suggested, and obtain the right subtitles in PNG/XML format, but there is currently no way to convert them to SUB/IDX. And even if you can manage to convert them correctly, the player will probably not "understand" that unofficial format.

BTW, I have tried to do it for the old version of BD3D2MK3D (that supported Full SBS/T&B encoding), but I have abandoned the idea. I know for sure that BDSup2Sub truncates the PNG files to 1920x1080 anyway, even if you edit the IDX file, for example to set the format to 2160p.

Unfortunately, currently, the only way to display correct 3D subs on a Full-SBS or T&B movie is to hardcode them on the video. With some work, it's possible.

If you are interested, I have written a tool that can convert the original 2D subs to 3D using external tools (ImageMagik and BDSup2Sub++). It works only for Half-* formats, but it can probably be easily adapted to create 2 different SUB/IDX streams, to hardcode them on the right views of the video streams. Also, when I have written the (now obsolete) BD3D2AVS, my first attempt to hardcode the subtitles with a constant 3D offset was made with Crop, AddBorders and Stack commands in the avisynth script, to apply the right offset to the 2 views, but that was very slow. IMO, creating 2 different subtitle streams should be much more rapid. But I guess you don't want to hardcode your subs. Right?

Nico8583

3rd March 2014, 13:32

Thanks for your detailled response :)

No I don't want to hardcode subtitle so thanks for your proposition but I don't need your tool (at least now, but I don't know in the future :) ).

So PNG/XML format might support Full SBS ? What is the interest to convert subs to SUB/IDX ? Or I let original PGS subtitle but I lose 3D depth...

r0lZ

3rd March 2014, 15:23

As far as I know, PNG/XML is only a "temp" format used to prepare the subtitles for an encoder or an authoring program, that converts it to one of the standard formats. Of course, PNG images can have whatever resolution you want. The XML file keeps track of the timings and positions of each individual PNG file. Since it's a text file, you can of course change the positions and store whatever values are suitable for Full-SBS or T&B. But if you cannot convert that file back to a format supported by the MKV container and unknown to most (if not all) players, it's useless.

The problem of the depth is complex. In fact, in a 3D-BD, the depths of each individual subtitle of a particular stream are stored in an extension of the MVC stream. Currently, afaik, there is no practical way to extract that information from the MVC stream (but I've requested that feature and hopefully it will be implemented in tsMuxeR when Roman will have some time). So, currently, you can only add a global depth for ALL subtitles of your subtitle stream (when the stream is converted to Half-3D, or when it is hardcoded on the video). That doesn't make much sense, and some good hardware or software players can already display the 2D subs in 3D, with a constant depth. So, IMO, currently, you can probably live with the original 2D subs and hope that your next TV will be able to display them correctly, with a depth that you can configure yourself. Unfortunately, most 3D TVs (including my Samsung TV) cannot do that. Of course, it will be much useful to convert the subs to 3D later, when it will be possible to use the depth values from the MVC stream, as that will allow us to keep the subtitles with the correct depth and display them exactly like in the original BD.

Converting the subtitles to 3D is currently mainly useful if you read the MKV file with a player that doesn't know that the file is in 3D, and you send its output to a 3D TV. Of course, in that case, you can't use 2D subs, because they will never be duplicated on each view. It's what I do with my LaCie LaCinema HDD and my Samsung TV. But it's still not perfect, because the LaCie resizes the subtitles slightly, and of course, the depth is affected. Also, most players are completely confused if the original video has horizontal black borders that have been cropped when the video has been re-encoded, because the Y position of the subtitles is wrong for the cropped video, and the subtitle is displayed outside of the visible area, or in a completely wrong position. (BTW, It's another important reason to NEVER crop the black bars of a 3D movie shot in Cinemascope format.)

As you can see, displaying correctly non-hardcoded 3D subs is a nightmare, even with Half-SBS or Half-T&B. So, trying to do it with Full SBS or T&B is, imo, almost impossible.

jbuszkie

11th March 2014, 16:27

I've glanced at the start and end of this (long) thread..
I've seen mention of several tools..

Which one should/could I use to create SBS (half is fine)
from a 3D iso created by DVDfab.

The first post seems to outline a process.. but I'm guessing it's outdated? And there is a single tool (or a couple) with a gui that will do that job?

Ability to do something with captions would be a plus!

Thanks!

r0lZ

11th March 2014, 16:48

jbuszkie

13th March 2014, 20:51

Thanks!

one quick question.. What version of AVIsynth do I need?
I see a
2.5.8 ST 32bit and
2.6.0 ST 32bit (still in alpha)

I also see some unofficial builds like
2.5.8 MT 64bit

I have 64bit win7

Jim

r0lZ

14th March 2014, 00:24

frencher

14th March 2014, 14:30

The "classic" 2.5.8 ST 32bit version is needed. Currently, the 64-bit version is still unstable, and many plugins exist only in 32-bit version. But you can use the x64 version of the x264 encoder (included in the BD3D2MK3D package) with avisynth 32-bit. On a 64-bit machine, that speeds up the conversion a bit.

Try 2.6.0 MT x86 works with all therads

Threads = 12
SetMTMode(3,Threads) # i7 3930k have 12 Threads
Video = DirectShowSource("Video.mp4", audio=true, convertfps=false).ConvertToYV12()
SetMTMode(2)

jbuszkie

14th March 2014, 20:46

Try 2.6.0 MT x86 works with all therads

Threads = 12
SetMTMode(3,Threads) # i7 3930k have 12 Threads
Video = DirectShowSource("Video.mp4", audio=true, convertfps=false).ConvertToYV12()
SetMTMode(2)

ST vs. MT?? Single Thread and Multi- Thread? Is that what they mean?

frencher

14th March 2014, 21:00

ST vs. MT?? Single Thread and Multi- Thread? Is that what they mean?

Look here (http://www.svp-team.com/wiki/Main_Page) ;)

jbuszkie

14th March 2014, 21:04

Also.. r0lZ, I downloaded you tool.. and pretty cool..
I'd like to say thanks to you.. (and all the others that make these great guis/tools

A couple of specific questions..

First a general one.. You tool just creates a script.. I still have to run the script manually?

Next... The CRF value? the default is 23.. What to people use?
23 only produced a 3-4G file from a 18ish Gig file. That's a SBS as well the quality is cut in half further.

Last.. If I want to use the Multi thread thing... Where do I set that with your GUI?

And thanks again!

Jim

jbuszkie

14th March 2014, 21:10

Look here (http://www.svp-team.com/wiki/Main_Page) ;)

Ok.. I'm missing something... I see something about SVP... But nothing that describes ST vs MT when talking about AVIsynth?

r0lZ

14th March 2014, 23:18

Yes, the batch file must be run manually. I prefer that method. The GUI is only an useless window that consumes resources for nothing during the encoding phase.

CRF 23 gives excellent results for a very good compression ratio. Usually, I lower that value a bit (down to 20) when the image quality of the original movie is extremely important, but it's very rare. 22 or 23 is what I use usually. That default value is very well chosen by the specialist who wrote x264, and I trust them.

And yes, the resulting file may be between 1 and 4 GB, depending of the movie, its length, and the preset used when you encode. With the CRF mode, when you select a slower preset, the quality of the video doesn't change much, but the size of the file is reduced. Anyway, don't worry. 3GB for a movie correctly encoded with x264 is more than sufficient. Can you see a real loss in quality (except the half resolution) ?

Sorry, my GUI is made for the Classic version of avisynth. It doesn't support the MT version directly. And imo the MT version is useless in our case, because x264 needs much more processing power than avisynth, and it is better to give it all treads, and reserve only one thread to avisynth. Of course, if you wish, you can edit the script manually before encoding it, but use the MT avisynth at your own risk.

Thanks for the thanks! :-)

frencher

14th March 2014, 23:38

Hi r0lZ,

After some tests I could see a marked improvement with the latest version of x264 and Avisynth MT to double encoding speed cases.
A bit like when you go x264 process "up" the frame rate will drop down (tested with ldecod method)

Nico8583

15th March 2014, 21:41

Does anyone knows a little BD 3D Demo ISO with subtitles streams ? I have Netblender Demo 3D disc but it doesn't contain any subtitle stream...

r0lZ

15th March 2014, 23:07

There are many short movies given as bonus on the Pixar BDs, but they are part of big BDs. Is it OK for what you want to do?

Nico8583

16th March 2014, 10:52

Yes it should be OK, could you tell me an example ?

r0lZ

16th March 2014, 11:40

On "Monster Inc. 3D" (not "Monsters University"), you'll find "Partysorus Rex" (a short from the Toy Story Toons series), with subtitles in several languages, including French. The collection of howlers ("Bêtisier" in French) that was included in the credits of the original 2D main movie has been removed from the 3D version, but has been added as a bonus on the 3DBD. It has also several subtitle streams. "For the Birds" ("Drôles d'oiseaux sur une ligne à haute tension"), on the same BD, has only a few English subtitles. So, on that 3DBD, you have 3 shorts with subtitles. That should be sufficient for your tests. :-)

Nico8583

16th March 2014, 19:31

Thanks ;-)

b0mb

18th March 2014, 15:17

That's not credible. The resolution of the video is not at all related to the depth effect. I can admit that the video may be a bit less sharp (since its resolution is divided by 2), and perhaps that there is less "detail" in the depth, but certainly not that the depth is reduced.

There have been long discussions of a French forum on the supposed superiority of half-T&B over Half-SBS, because the parallax depends of the horizontal direction and therefore is more precise when the X resolution is not divided by 2. Theoretically, it's true. But the parallax plays only a small role in the perception of the relief. The brain is much more important. And the conclusion of the experts on the forum is that half-SBS gives excellent results, not less good than half-T&B (or full-SBS). Of course, if you really think that full-SBS is superior, you will perhaps see a difference. But it's pure religion. And anyway, if there is a small difference, it's in the precise position of the "planes", not at all in the global depth of the scene, simply because the parallax do not change when the resolution is reduced. It is only somewhat blurred, exactly like the precision of the pixels.

after weeks of testing different formats i came to the conclusion that you were right with what you´ve said ;)

r0lZ

18th March 2014, 16:22

Thanks for your long tests and for letting us know. :-)

Nico8583

19th March 2014, 18:26

I'm going to try to make (thanks to r0lZ to advise me ;) ) a soft to convert BD sup to SBS/TAB 3D sup/xml/sub (like Neisklar Suppe3D with other functionnality).
If you use Suppe3D and have suggestions, don't hesitate to tell me.

Nico8583

20th March 2014, 19:27

after weeks of testing different formats i came to the conclusion that you were right with what you´ve said ;)
What is your conclusion ? Do you mind Full SBS is superior to Half SBS even on first minutes of Avatar ? :)

jbuszkie

20th March 2014, 19:51

Yes, the method has evolved greatly, and currently, you can do it with a GUI and much more rapid MVC decoders. BD3D2MK3D converts a BD3D to Half-SBS (or T&B) MKV, with chapters and as many audio and subtitles streams as you want. You can also hardcode the subtitle stream on the video if you wish. The download link is in my signature. You have to install Avisynth if you haven't it already. See the help menu.

There are other GUIs as well, but I prefer to leave their authors present them.

I do like the tool.. Is there something similar for non 3D movies?
I need recode the ones I've watched into something smaller. sometimes there are multiple playlist and it's tough to figure out which one is the correct one. You tool kinda showed the similarities and difference in the playlist and could be useful to figure out the correct play list and turn it into a MKV.

Or is makemkv the way to go then handbrake to shrink?

I was looking for a sticky that had a list of guides!

Now if I could just get the subtitles to work with my player for SBS! (works in VLC so probably an issue with my player!)

Thanks,

Jim

r0lZ

20th March 2014, 20:44

Well, I haven't made an equivalent GUI for 2D BDs, but when I have to recode a movie, usually I use eac3to or tsMuxeR to examine the MPLS files and their associated M2TS parts. When I know what file I want to grab, I use either tsMuxeR or MakeMKV to build an intermediate M2TS or MKV file. I re-encode it with Simple X264 Launcher (http://forum.doom9.org/showthread.php?t=144140), and I remux the intermediate M2TS or MKV with MkvMerge (and, of course, I replace the video stream with the re-encoded one).

I don't like the MakeMKV GUI much, because it has no preview, and it is often extremely slow. So, perhaps I'll do something similar to BD3D2MK3D for 2D movies later, but honestly, I'm not sure. It is somewhat difficult and long to figure out all steps to encode a 3D movie to SBS or T&B, but it is much more simple to re-encode a 2D movies, and I'm not sure it is really necessary to develop a new GUI to do it.

BTW, I suppose that you have noticed that BD3D2MK3D generates also a batch file to mux the 2D movie to MKV (without re-encoding). Of course, that works only with the 2D version of a 3D movie, but it's a good starting point to re-encode it with x264 if you wish.

(Sidenote: I have also developed a plugin for PgcEdit to re-encode any PGC with x264. That plugin has not been released yet, and anyway, it cannot handle BD discs. I should release it soon...)

jbuszkie

20th March 2014, 22:30

Separate question...

These 3d SBS mkvs..

What hardware player are people using to play them?

Do you guys have experience with the mede8er?

Sorry if this is off topic..

Jim

r0lZ

21st March 2014, 10:01

All Smart TVs from Samsung, LG, Panasonic, Philips and probably all other major brands can display 3D SBS MKVs. Some have limitations (like my Samsung that cannot display the embedded subtitles). You can also use a Smart BD player, that will convert the SBS file to regular 3D images, and send them at 48fps to the TV, exactly like for any 3D BD. Anyway, your TV must be 3D to handle that images properly.

I have no experience with 3D "hardware boxes", as I have only an old Lacie LaCinema multimedia HDD, that cannot handle 3D files. I can use it to sent the SBS images to the TV, and let the TV separate them, but it's not a good solution, because the OSD of the Lacie is also "decoded" and is of course impossible to read. Anyway, your TV must be 3D, and if you have a 3D TV, you don't need an external multimedia box. The mede8er can be an excellent multimedia player, but it's the TV that will display the 3D movies in 3D anyway.

Nico8583

25th March 2014, 21:55

A little question : I'm on Windows 7 x64 and I don't have any codec pack installed on a PC. This PC is only use to encode movies, not for playing. Is it necessary, recommended or totaly useless to install a codec pack (like ffdshow, klite or other) in order to encode from AVS (VC-1, MPEG2 or H264 sources) to x264 ?

frencher

25th March 2014, 21:59

frencher

25th March 2014, 22:00

Nico8583

25th March 2014, 22:29

Thanks ;)
I can encode without Matroska and FFDShow, so do you know why is it necessary ?

frencher

26th March 2014, 00:13

Thanks ;)
I can encode without Matroska and FFDShow, so do you know why is it necessary ?

For MVC DirectShowMVCSource.dll and other 3D filters use Embedded codecs.
Now for playing standard video you need FFdshow and Splitter ;)

Nico8583

26th March 2014, 07:42

For MVC DirectShowMVCSource.dll and other 3D filters use Embedded codecs.
Now for playing standard video you need FFdshow and Splitter ;)

Thanks, it's not for playing so I don't need its :)

r0lZ

26th March 2014, 11:25

Right. The codecs are necessary only to play the BD files, and therefore they are required for the preview. But if you can figure out what MPLS must be encoded without the preview, you don't need them.
Hi r0lZ,

Try in same folder Film.mkv and Film.srt works with my Samsung 6500D ;)
I know that my TV supports external SRT files, but I want to use external (or, if possible, internal) SUB/IDX files, and that's not possible. I don't want to have to convert the original SUP to SRT using OCR. Too much work and risks of errors.

Furthermore, the TV shows the SRT in 2D, without any depth effect, and it's not suitable at all for a 3D movie. And, when the subtitle is very long, the TV splits it at random positions, and shows it on 3, 4 or even 5 lines of text! It is not rare to see subtitles occupying the whole bottom half of the screen! Samsung has made a very bad job with the subtitles support. It's my biggest deception with my TV. :-(

slavanap

8th April 2014, 23:17

Recently I actively use ssifSource4, so I'd like to share new version with minor bugfixes that I've found.
http://sendfile.su/965540
Also, there is a new tool filmtester.exe to verify ssifSource output readiness.
This tool reads all the avs-file output and checks for frame duplication sequences longer than 2 (by default) frames. As you know ssifSource (if decoding fails) copies the last successfully decoded frame till the end of the sequence, thus with this tool you can check, whether or not x264 encoding will be successful without wasting processor time for the encoding.
I think, this tool might be useful for testing other plugins' output as well.

pjvader

9th April 2014, 00:39

i have looked everywhere but i'm not having any luck!
is it possible to use multiavchd to create a full frame sequential/frame packing (sorry its late it's whichever one is used for 3d bd!) 3d clip (i.e. add the playlist then use cut start to edit it) im trying to create a demo disc of 2d and 3d clips with the dts-HD sound intact but i'm getting stuck when it comes to full HD 3d:o and scenarist seems a bit :eek: thanks

r0lZ

9th April 2014, 09:38

Thanks slavanap.
Can you confirm that your filmtester.exe needs to decode the whole movie to verify the duplicated frames? In that case, I suppose it takes a long time anyway. It's not as long as encoding the movie, but it's a waste of time anyway. Right?

@pjvader:
Wrong thread. Here, we are doing exactly the opposite. Anyway, to create a 3D BD, the first step is to encode your video in MVC. Maybe the FRIM encoder (http://forum.doom9.org/showthread.php?t=169651) can help. Then, try the new 3D tsMuxeR (http://forum.doom9.org/showthread.php?t=168539) to create the BD structure.
I don't know multiavchd enough to reply to your question.

slavanap

9th April 2014, 14:10

r0lZ,
yes, it's a wasting a time somehow, but I wasted much more time with encoding badly dumped blu-ray with x264 with all the plugins (ssifSource2, ssifSource4-ldecod, ssifSource4-intel).
So, yes, it decodes whole movie, but for me it's more faster than failed encoding with x264. And I can decode simultaneously with different plugins, because decoding process uses few threads.
And, btw, this tool shows its statistics during the decoding in real-time.
First parameter is avs-file, just try out.)

r0lZ

9th April 2014, 14:15

OK, thanks. Note that I haven't written that your tool is useless. I was just wondering if you have found a way to detect problems without having to decode the whole movie. I'll try it later. Currently, I'm working with Nico on a tool to generate real 3D subtitles, with the depth of each individual subtitle retrieved from the MVC stream.

slavanap

9th April 2014, 14:23

I see. Actually, if you need a depth of the place in a frame to where the subtitle should be placed, it simply might be extracted via motion estimation, for instance. I'm familiar with it.

r0lZ

9th April 2014, 15:00

Good to know. Currently, we are only using the 3D-planes embedded in the MVC stream. They contain exactly what we need. But a tool to generate the depth values automatically without relying on an existing 3D-plane could be useful. We'll let you know if we need that...

slavanap

9th April 2014, 15:29

Also, this tool that's already available, might be useful for you (try to find motion between the views):
http://compression.ru/video/motion_estimation/index_en.html

P.S. It might be useful to set max vertical motion to ~4% of frame height, and max horizontal motion to ~12% of frame width.

moamoa

13th April 2014, 18:27

Hi

I am able to rip my 3D blurays to SBS fine.

Two questions though.

1. Current it converts to 1920x1080 SBS. Can it do 3840x1080 SBS? If so, what do I do to get that.

2. Audio. If the sound is 7.1 HD DTS. Can I mix it down to 5.1 DTS, so my AMP can handle it?

Thanks :)

r0lZ

13th April 2014, 20:01

moamoa

14th April 2014, 12:27

1. Currently, Full-SBS is not supported. However, you can modify the AVS script yourself and remove the two "HorizontalReduceBy2" commands. The original line:
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
should be replaced with:
StackHorizontal(Left, Right)
However, I do not recommend to encode in full-SBS (or full T&B) because that format is not supported by most TVs and by many software 3D players. Furthermore, it is not possible to convert the subtitles to 3D when the output format is full-SBS or full-T&B. Therefore, you will have to remove the subtitles or use only the 2D subs. (See the subtitle option in tab 2.)

2. Yes. Tick the DTS-HD core option in tab 2.

Thanks you.

Re the 3D, that worked good. I will be using the files with a Pivos XS media player which will take 3840 SBS and convert that to framepacked output to projector, so I think for me, it will be perfect.

Re the DTS-HD, does ticking the box not just add the DTS-HD 7.1 track (from the ISO) to the file? My amp will not handle that, so need it converted to DTS 5.1 (older format). Are you saying tick the box, converts it it 5.1? This is what I need.

Nico8583

14th April 2014, 16:41

DTS-HD tracks are composed with a DTS Core (older format like you say) and a lot of data to make the track HD. So when you tick the box, you tell to the soft to extract and keep only DTS core, so there is no conversion but you get DTS 5.1 track ;)

r0lZ

14th April 2014, 17:20

Nico8583

14th April 2014, 18:34

After read and discuss a lot with some people and experts, I think DTS is the best choice for most of users. DTS-HD is necessary only if you have a huge and expensive HC installation with a dedicated room. DTS-HD costs useless disk space, IMO...

r0lZ

14th April 2014, 19:49

I fully agree. My point is that DTS-HD should be playable with a "normal" DTS decoder, but of course, in that case, the HD part of the stream is totally useless, and the 5.1 core is largely sufficient.

Nico8583

14th April 2014, 20:20

Yes, DTS-HD should be playable on any player with a DTS decoder ;)

moamoa

14th April 2014, 21:37

Yes, Nico is right. Just tick the box, and the stream should be compatible with your hardware.

(But afaik, a DTS HD track is read by the old players that do not understand the HD format as the "older format", and they should see only the 5.1 core. DTS-HD is supposed to be backward compatible, so I don't understand why you need to convert it to 5.1. That option is mainly there for peoples who do not want to include a very heavy HD track and prefer the lighter 5.1 core, but IMO it should never be necessary to tick it for compatibility reasons. I guess the problem comes from your media player that "knows" DTS-HD and sends the 7.1 channels to your projector in decoded form. Probably the projector cannot handle 7.1 channels and fails. IMO, the media player should have an option to use only the core, and send the 5.1 channels to the output. Can you confirm that?)

I can confirm this works fine. Don't know what I did wrong :/ first time.

One little issue, which is easy to work around. When you make the backup with MakeMKV the files is puts in the the directory;

ISO\Movie Name\BDMV\STREAM\SSIF

Are named like;

00021.ssif.smap

I need to manually go into these and rename them;

00021.ssif

Before the tool will pick up the ISO directory as valid. Be handy if it recognised these... oh, and the option so keep 3840 for SBS in the GUI.. But both these are easy to workaround. So thank you! excellent tool !!! :)

r0lZ

14th April 2014, 23:23

For the smap extension, I don't think I can do something. The external tools called by my program need a standard BDMV structure, and I have no way to force them to consider the smap files. I don't know why MakeMKV creates that non-standard files, but the workaround should be a fix in MakeMKV, not in my program. However, if you wish, I can perhaps write a little tool to rename all files from a specific BDMV\STREAM\SSIF folder to automatically remove the .smap extension. Then, you should be able to open the BD folder without problem. But you will not be able to easily restore the .smap extension, if that's necessary for any reason.

For the Full-SBS/T&B, it's not so simple. As I wrote above, the 3D subtitles are incompatible with that format (due to a limitation in the SUB/IDX file format) and I will have to modify the GUI to take the new format into account, and prohibit to include 3D subtitles when Full-SBS or T&B has been selected. I'm not sure it's a good idea. But I will see what I can do...

slavanap

14th April 2014, 23:58

moamoa, r0lZ,

Just a tip:

rem This .bat file creates hardlinks for smap files. pls, check whether it works on your Windows version.

cd BDMV\STREAM\SSIF\
for %%f in (*.smap) do mklink /H %%~nf %%f
pause

r0lZ

15th April 2014, 08:07

Nice idea! MkLink should work with Windows 7 or greater. And since BD3D2MK3D requires at least Win7, I'll implement that trick.

Of course, it won't work if the source directory is a mounted ISO. Someone can confirm that the .smap files are illegal in a real BD and therefore that a working ISO must have regular ssif files?

Nico8583

15th April 2014, 08:12

I have tried MakeMKV and .smap, and rename files to ssif seems to not be sufficient. .smap files are about few kilobytes, not like real ssif files. On MakeMKV forum, there is a (Linux ?) script to rebuild SSIF files from .smap and it's not a simple rename, AFAIK...

r0lZ

15th April 2014, 08:17

(But afaik, a DTS HD track is read by the old players that do not understand the HD format as the "older format", and they should see only the 5.1 core. DTS-HD is supposed to be backward compatible, so I don't understand why you need to convert it to 5.1. That option is mainly there for peoples who do not want to include a very heavy HD track and prefer the lighter 5.1 core, but IMO it should never be necessary to tick it for compatibility reasons. I guess the problem comes from your media player that "knows" DTS-HD and sends the 7.1 channels to your projector in decoded form. Probably the projector cannot handle 7.1 channels and fails. IMO, the media player should have an option to use only the core, and send the 5.1 channels to the output. Can you confirm that?)
Someone pointed me to this explanation about TrueHD and AC3 (https://trac.bunkus.org/wiki/FAQ%3ATrueHDAndAC3). I guess a similar explanation apply to DTS-HD and DTS. And if it's the case, that explains why the "HD core" option must be ticked in BD3D2MK3D if you want to mux an audio file compatible with the old DTS decoders (and similarly for the AC3 core). It's a pity that MKV has such a limitation, but unfortunately it's a fact.

I wonder if I should remove that option and apply the extraction of the core anyway, since when the option is unticked, the final MKV file may contain DTS-HD or TrueHD streams that are incompatible with most players. Someone has a good reason to keep that option?

Nico8583

15th April 2014, 08:18

Not for me, I make all my MKV with core only, I don't have sufficient installation to keep HD audio

r0lZ

15th April 2014, 08:27

OK. I think I'll leave that option, but I'll add a warning when the user unticks it to explain that the resulting track will be incompatible with most players.

Thalyn

9th May 2014, 08:05

So it's been a little while since I've gone through my 3D collection, but a thought occurred to me the other night while correcting a subtitle issue: instead of a normal bilinear resize, would a weighted resize or even straight-up discarding scanlines work out better?

Essentially I had a play with full-size 3D frames. PotPlayer (my software of choice), however, renders these such that they look identical to half-OU as it applies a resize filter before interleaving the rows for each eye. The results are fine, but I can't help wondering if they could be better - particularly on angles very near horizontal. In essence I would attempt to retain different detail with each eye, rather than the same detail, in an effort to produce a "better" result.

The idea is to either A) de-interlace both eyes, then weave the even lines of the left (remembering video starts at row 0) and odd lines of the right, thus relying on the human brain to "fill in" the missing lines (I suspect this is how PowerDVD and its ilk work anyway when using a passive display), or B) apply some kind of offset reduction that gives preference to every second line (25/50/25 weighting) instead of equal preference to pairs (50/50 weighting). The scripts, just off the top of my head (modifications welcome) would be something like the following (keeping in mind these assume that you've already decided whether AVC is Left or Right):

#Method A
Left = SeparateFields (Left)
Left = SelectEven (Left)
Right = SeparateFields (Right)
Right = SelectOdd (Right)
Return StackVertical (Left, Right)

#Method B (I suspect I have the wrong syntax here, but hopefully enough of the idea is apparent to get what I'm on about)
Left = Left.BilinearRezise (Left.Width, Left.Height / 2, 0, -0.5)
Right = Right.BilinearResize (Right.Width, Right.Height / 2, 0, 0.5)
Return StackVertical (Left, Right)

Obviously, Method A would give the best results when displayed on a passive 1080p screen if that's indeed the way PowerDVD and the like work on the same display. However it's effectively throwing away half the available detail and I question whether this is actually going to be noticeable in the event a display with sufficient resolution is used to view it - either a 2160p passive or any 1080p+ active. Method B, on the other hand, attempts to retain that detail in the same way as a basic resize does in such a way that the two eyes still see slightly different results without wasting anything, theoretically giving better "effective" resolution regardless of the display in use.

Some quick testing suggests (to me) that Method B is viable but I only have a passive screen to test it on (and haven't performed thorough analysis of the results as yet). But for others who might have considered and/or tried it, is this something worth looking into or am I just trying to find a solution where there isn't a problem to begin with?

r0lZ

9th May 2014, 09:06

I'm not sure I understand your point. I don't know PotPlayer, and therefore I don't know what it does with 3D videos, but it should display the 2 views in such a way that the 3D rendering hardware can display them correctly. Apparently, your hardware requires interleaved scanlines. Right? And, if I understand correctly, you suggest that instead of doing a standard resize to divide the height of the 2 views by 2, it could be better to discriminate one every 2 scanlines, and keep only the even scanlines for the left eye and the odd ones for the right eye. Still correct? IMO, there are two problems with that idea.

The left and right views are different (except when the objects are exactly "on the surface of the screen"). Therefore, with your method, the left eye will see only the even scanlines, and the right eye only the odd scanlines. IMO, that may create a flickering effect, that can be very unpleasant.

The second problem is that removing the scanlines can, in some cases (such as during the end credits), remove some very important information, such as thin horizontal lines. If the same thin line is kept on the other view, that will also create obvious differences in the left and right views, and that differences are difficult to "understand" by your brain. That may be also an unpleasant effect.

But I agree that your idea is not bad, and I encourage you to test it. (Unfortunately, I have only a 3D active Samsung TV, and I can't test it myself.) Take in mind, however, that that method is only suitable for a very specific hardware, and will probably give extremely bad results if the movie is displayed on hardware that is not suitable, such as an active 3D TV. You may have to throw away all your encodes when you will buy a new TV!

Note also that in the past, before the 3D blu-ray technology, there has been some 3D-DVDs using a technique similar to your idea. I have some of them, and I have converted them to T&B. The idea was to store the left view in the even scanlines and the right view in the odd ones. Since DVDs are in standard PAL or NTSC format, they are interlaced by nature, and therefore the left and right views are displayed alternately, at 50 or 59.94 fields per seconds. It is therefore sufficient to synchronize the active shutter glasses with the AC power to hide the right field for each eye. Of course, the quality of these 3D-DVDs was not good, because the remaining vertical resolution is extremely limited (240 scanlines per field in NTSC!) But that worked!

Final tech note: I haven't verified, but you may have to add the AssumeFieldBased() instruction at the beginning of your script for method A. And the BilinearResize() used in script B does NOT simply remove scanlines. BilinearResize() is a fast resize, but it merges the scanlines together, and you cannot obtain what you want. Perhaps it's possible with PointResize, but I don't know how to force it to select the right scanlines.

Thalyn

9th May 2014, 14:07

Yeah, I use a 1080p passive screen with row-based separation. Somehow I forgot to mention that.

The fine lines you mention was something I had considered but not specifically with Method A. The prospect of detail which exists on one eye but not the other, especially with a slow "crawl" that causes it to alternate could be quite horrid. I'd have to experiment with it, but I can see that being a dealbreaker with how it could potentially interact with active 3D (not that I have any intention of ever using it, but you never know for certain).

Method B wasn't so much to discard every second line but rather to merge them in with lower weighting. So instead of having lines A, B, C, and D become A + B, C + D for both eyes, you'd get A + 50% B, 50% B + C + 50% D for the left and 50% A + B + 50% C, 50% C + D + 50% E and so forth for the right. This would still potentially have "crawl" but it would be significantly reduced.

I guess all I can really do is experiment, but I need to figure out how exactly to do the weighted resize properly; assuming I haven't accidentally gotten it right.

*update*
Testing with The Immortals:

Discarding scanlines entirely is off the table. The results had even more noticeable edges than using a traditional resize, along with fairly pronounced crawl on moving horizontal edges. While perfectly watchable it was clearly worse than the easier alternative. Not only that but it was slower (approximately 85% of the speed) and created a larger file (42% larger) making it worse in pretty much every way.

Attempting to use a weighted merge, however, was very nearly the same speed (97% as fast as a straight reduction) and produced a file only slightly bigger (roughly 4%). As to whether it's worth it? Hard to tell. Those are small enough increases that it's worth further experimentation, but I'll need to figure out a better way to evaluate it than "Yeah, that doesn't look terrible" when ultimately I can say the same of either reduction technique. Some light crawling was evident on credits (to be fair, this is also evident with normal vertical reduction) but nothing during the movie seemed to show anything.

The reduction I applied used the following code, based on the description of the "ReduceBy2" command:

Left = MergeChroma (Left.BilinearResize (Left.Width, Left.Height / 2, 0, 0.5), \
Left.BilinearResize (Left.Width, Left.Height / 2, 0, 1))
Right = MergeChroma (Right.BilinearResize (Right.Width, Right.Height / 2, 0, -0.5), \
Right.BilinearResize (Right.Width, Right.Height / 2, 0, -1))

I'm only assuming that's providing me with the 25%/50%/25% weighting I'm after, with the left and right using offsets 1 pixel apart for the 50% lines, but that's purely a guess and I could use some input from someone more knowledgeable on how BilinearResize works.

*Update 2*
Found a work-around for not being able to pick my resizing kernel, by way of the following:

Left = Blur (Left, 0, 1)
Left = SeparateRows (Left, 2)
Left = SelectEven (Left)
Right = Blur (Right, 0, 1)
Right = SeparateRows (Right, 2)
Right = SelectOdd (Right)

Ultimately that applies a 25/50/25 blur to the entire frame, then picks out alternating scanlines for the left and right eye, which theoretically gives exactly the same results as what I'm after. In fact, the Left view there should be identical to using the VerticalReduceBy2 command. I have no idea whether that's the most efficient way to do it or not but quick testing suggests that it's still within spitting distance (less than 4% difference) of a traditional resize. I'll have to run a more extensive test to compare filesizes but that's a 2 hour job and I want to do stuff with my system right now.

As for the results? Still very, very hard to tell. Comparing a 2D frame this method gives better output (less soft) than a more traditional bilinear resize (even one using a 25/50/25 kernel), especially when subtitles are concerned, though obviously still inferior to the source image. But when comparing in 3D? The results are definitely very good but I can't definitively say that they're better; though I can't say that they're any worse, either.

*Final update*
Well, I've had an opportunity to do a full run and... I'm still not convinced that I'm looking at a solution to a problem that even exists. Does it work? Yes. Is it any better? Well... I know I like the results and plan on using this method going forward, but without the ability to see a live comparison between the two I can't say it's actually worthwhile. I'm not prepared to call it a bust but I think anyone who's been following my experiment can be safe in the knowledge that I haven't completely changed the playing field.

Final results for this particular stream (Immortals) put the filesize at roughly 105% of a standard bilinear resize, however the speed was only around 91% of normal; though I may have skewed that slightly with multitasking at the time. The speed difference isn't entirely unexpected but I have no way of determining whether the increased filesize is from more detail retention or simply worse compression due to the frame packing not optimising as well with the variations I've introduced.

pommesmatte

12th May 2014, 13:20

r0lz, you said you are working on a method for the real depth in 3D subtitles?

How soon do you think you may be successful?
I will then postpone some of my encodings. :)

r0lZ

12th May 2014, 14:14

Very soon. I have already successfully encoded 3 BDs with the subtitles at the right depth. However, I don't want to release the new version immediately, because there are still some bugs to fix, and I need more time to verify that everything works as expected.

In fact, I'm working on that part with Nico8583. He has already almost finished an exe to extract the 3D-planes from the MVC streams, but I've just discovered a bug that must be fixed. Since Nico is currently doing a little trip, that cannot be fixed before the middle of this week.

Nico is also working on the exe to convert the PNG images of the subtitle stream (previously converted to XML/PNG format) to 3D, but there is a big problem with the transparency of the background, and he is still searching for a solution. On my side, I did the same work with ImageMagick, and that works perfectly well, but it's very slow. I still don't know if I will release the new version of BD3D2MK3D with my method, or if I will wait for a solution for Nico's method. I may release my method soon, and replace it with Nico's exe when it will be ready.

Anyway, I can't release it before Wednesday or Thursday. Please be patient...

Nico8583

13th May 2014, 22:05

I'm here :) I'm going to fix bugs now ;)

r0lZ

14th May 2014, 13:37

As promised, here is v0.35 of BD3D2MK3D (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z).

# v0.35 (May 14, 2014)
# - The subtitles are now converted to 3D using the depth information from the 3D-planes of the MVC stream.
# - Added a tool to extract the 3D-planes from the MVC demuxed stream. Thanks Nico8583!
# - Added a tool to convert subtitles to 3D using the individual depths from the 3D-plane.
# - It is now possible to include both 2D and 3D versions of the subtitles in the final MKV file.
# - Added a tool and an option to convert the DTS and WAV files to AC3
# - Uses now mpls_dump.exe to list and filter the MPLS files when the BD is opened.
# - Fix for the missing SSIF files when processing a BD folder created by MakeMKV.
# - The program now remembers the last directory used when loading or saving the tags from tab 3.
# - Updated MkvMerge and x264 to their latest versions.

The main improvement is the conversion of the subtitles to 3D using now the "real depth" extracted from the 3D-planes of the original BD. As a consequence, the previous "Subtitle Depth" setting has been removed and is now replaced with a new "Additional Depth" setting. Normally, that setting can be left to 0, but sometimes the 3D subtitles are too close to the objects of the 3D image and it might be necessary to "unstick" them somewhat. You can set the additional depth to a small value such as 1 or 2 to do exactly that.

If you have an existing BD3D2MK3D project (with the original MVC and SUP files), you can convert the SUP file to real 3D using the two new tools available in the Tools menu. Just be sure to overwrite the 3D IDX/SUB files with the new conversion, and mux the MKV file again (with _MUX_3D.cmd).

The quality and precision of the depth of the 3D subtitles converted with the new method depend greatly of the 3D-plane of the original BD. Some planes are not very well defined, and may give relatively bad results. However, usually, the result is much better than when an arbitrary fixed depth is used, like with the previous versions.

Note that currently, the conversion of each individual 2D subtitle is made using ImageMagick (convert.exe) and is somewhat slow. I hope Nico will find a solution for the opaque background bug of his tool. If it's possible, the conversion should take much less time with his exe.

Huge thanks to Nico8583 for MVCPlanes.exe. As far as I know, that exe is now bug free, and can extract the 3D-Planes from the MVC stream much faster than the original tool that I wrote some time ago in Tcl/Tk. Thanks Nico! :-)

As usual, the latest version of BD3D2MK3D can be downloaded here: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

Please report any bug or problem you may encounter with the new 3D subtitle conversion method. Thanks in advance.

Nico8583

14th May 2014, 14:13

You're welcome, and thanks r0lZ for your help and your good software ;)

mini-moose

15th May 2014, 11:55

that new 3D subs feature sounds nice!

I was wondering - what happens if you just use the .sup extracted from the blu-ray instead of converting it to vobsub? Does the sup file contain the depth info needed or that comes from the 3d structure.
Many players have no issues playing the sup files as is, as long as they are muxed in. mkvmerge also applies a compression on them, so they only take about 1/2 their actual size.

Nico8583

15th May 2014, 12:20

No, SUP doesn't contain depth info. Depth info is extracted from MVC stream. So if you use sup without conversion, you'll get a 2D display (like a classical BD). You can convert SUP 2D to SUP 3D or SUB/IDX 3D :)
I'm going to try to work on a 3D subtitles converter like r0lZ said but for the moment only BD3D2MK3D can convert it ;)

r0lZ

15th May 2014, 13:24

Yes, Nico is right. The original SUP file is a standard 2D subtitle stream (and is used also when you watch the BD in 2D).

Surprisingly, on many BDs, the subtitle stream is duplicated in the dependent view M2TS. That means that the same subtitle stream is present twice in the SSIF (and BTW, eac3to fails to demux them because it gets confused by the two streams with the same ID). When I saw that BDs, I was almost sure that the second subtitle stream was somewhat different from the first, and was designed to be used for the dependent view. But I was wrong. That stream is exactly identical to the other one, and therefore it is not sufficient to use it to get the 3D effect. Finally, I have learned that the 3D info is stored in SEI messages in the MVC stream. Since that stream must be demuxed anyway by BD3D2MK3D, it was not very difficult to write a little exe that extracts the messages from the MVC stream and build the 3D-planes as independent files. (It's MVCPlanes.exe written by Nico.) The info contained in these planes is sufficient to know what parallax value to use for each individual subtitle and to build the 3D subs. As far as I know, there is no other way to get the 3D subs right (except of course by playing the original 3D BD with a 3D BD player).

BTW, MVCPlanes.exe gives also some interesting info about the 3D "intensity" of the movie. It shows you the minimum and maximum parallax values, as well as the average value for the movie. That may be useful to know approximately if the movie has globally a deep or small depth. Of course, you must take in mind that the depths given by the 3D-planes are the depths to be used for the subtitles, and they do not necessarily reflect the real depth of the movie. But if you know for example that the maximum parallax value is 10 for a movie, and 50 for another one, you can bet that the second one has more impressive 3D effects.

Note also that when the subtitles are converted to 3D, a similar information is printed to the log by BD3D2MK3D, but this time, only the values needed for the subtitles of the converted stream are taken into account. They may be useful if you want to fine-tune the additional depth value and redo the conversion with the two tools in the Tools menu.

As far as I know, BD3D2MK3D is the first program that can convert the BD subtitles to 3D with the real depth. However, I'm still not absolutely sure that it does it correctly. I don't know exactly how to interpret the parallax values and use them to deduce the displacement of the left subtitle along the X axis. If you can see for sure that some subtitles are obviously not at the same depth in the original BD and in the MKV generated by BD3D2MK3D, please let me know. Thanks in advance!

tyee

17th May 2014, 01:08

The latest download has file date stamps of 2012. Is this correct?

Oh, I see the link is for the other app - BD3D2AVS.7z. Needs correcting??

r0lZ

17th May 2014, 06:20

Oops, yes. Sorry!
Here is the correct link: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)
I've corrected the links in my previous post too. Thanks!

Wolfy59

18th May 2014, 19:59

Hi all, How can i use the last 3d tsmuxer to have the correct 3D subtitle Depth with the Nico's tool ?
r0lZ do you think it s possible to add an option to your BD3D2MK3D to have a bd 25 iso using frim encoder ?
Thanks for the work you do here.

r0lZ

19th May 2014, 09:01

I'm not sure I understand your questions.

BD3D2MK3D uses tsMuxeR 3D to extract the MVC stream, yes. But normally, any demuxer should do the job correctly (unless it removes the SEI messages on the fly). MVCPlanes.exe (by Nico) is used only to retrieve the 3D-planes SEI messages from the MVC stream and build a list of parallax values for all frames of the movie (the *.3dp files). The command line is easy, but if you want a GUI for that part, you can use Tools -> Extract 3D Planes from MVC.
The conversion of the subtitles to 3D is currently made by BD3D2MK3D only, and not yet by a CLI exe. So, currently, you need to use Tools -> Convert Subtitles to 3D (with 3D-Planes).

For the ISO, the answer is no. BD3D2MK3D, as its name implies, converts a BD3D to a 3D MKV file (in SBS or T&B format). It is not at all designed to copy (or shrink) an original 3DBD to a recordable BD25 or BD50. (However, it has an option to create a BD compliant h264 file, and you can theoretically use a BD authoring program to build a standard BD containing a 3D SBS or T&B video.)

Wolfy59

19th May 2014, 21:37

Nico8583

19th May 2014, 23:00

Firstly you can extract depth only from MVC stream, not from SUP file.
Secondly you cannot use SUP 3D created by r0lZ soft (or mine if I can release it) with AVC/MVC ISO because depth is used to calculate SBS or TAB subtitles positions (and AVC/MVC is not SBS or TAB).
So I'm sorry but I think my tool cannot help you...

r0lZ

20th May 2014, 07:42

OK, if I understand correctly, you want to rebuild an ISO with the original AVC and MVC streams, plus a new SUP file you have generated yourself, and have that subtitles use the correct 3D depth, like the original subtitle streams of the BD. Correct?

If, and only if, the original MVC stream has already some valid 3D-planes, then you can use one of them when you add your new subtitle stream and you remux the BD. tsMuxeR 3D has an option to change the 3D plane of any subtitle stream. Just select one existing 3D-plane for your new subtitle stream. It can be already used by another subtitle stream, that doesn't matter. (Selecting the best 3D-plane can be tricky, and if the depth of your subtitles is not correct, you can try another 3D-plane. However, most of them should give approximately the same result.)

Our tools (Nico's MVCStreams or my BD3D2MK3D) are not necessary to do that. You need only tsMuxeR 3D. But MVCPlanes can be somewhat useful to verify what streams are already present in the MVC stream, and to examine their statistics. It's not mandatory, but that can help to identify the "best" 3D-plane to use.

Note also that I've read that it is sometimes difficult to assign an existing 3D plane to a new subtitle stream with tsMuxeR, because the option is not enabled or something like that. I'm not sure it's the truth, but if it's the case, please post your questions on that subject in the tsMuxeR 3D thread (http://forum.doom9.org/showthread.php?t=168539). Our thread here is devoted to the conversion of 3D BDs to SBS or T&B, and not to the remux of an original 3D BD. Thanks.

Wolfy59

20th May 2014, 17:30

Thanks for answers i will try to find another way :-)

uluhara

25th May 2014, 09:30

Hello there,

and greetings from Germany.

I found BD3D2MK3D while searching for a way to test the 3D capabilities of my SamsungTV.

My first test subject was TinTin, and everything worked like a charme! Great Software.

My second test was to be Avatar3D - which has forced subs - and now something happened I did'nt expect ... when I play the finished file my Samsung TV shows the text two times, once left and once right, the left one seems to be in the back, the right one in front...

Any idea what I am doing wrong?

r0lZ

25th May 2014, 10:57

Welcome to the Doom9 forums, and thanks for your appreciation. :-)

There are two kinds of subtitles: 2D and 3D. The subtitles to use depend of the way you watch your movie, and of your hardware.

The 2D subtitles are "normal" subtitles. They have to be displayed by the TV and rendered in 3D by the 3D engine of the TV. That means that the TV must duplicate the subtitle on the two views, possibly with a little displacement along the X axis so that it appears with a certain "depth", in front of the surface of the screen. The main drawback of the 2D subtitles is that the TV has no way to know at what depth each subtitle must be displayed. With my Samsung TV, for example, the subtitles are placed "on the surface of the screen", and there is no way to display them at a different depth. Therefore, almost all subtitles appear "inside" the objects that are in front of the screen, and that produces a very unpleasant effect, and a torture for the brain.

In the other hand, 3D subtitles are converted to 3D by BD3D2MK3D itself. That has a very important advantage: The "real" depth can be extracted from the original blu-ray disc and used to compute the right depth for each individual subtitle. The final subtitle stream contains therefore a single subtitle stream for the two views, but with each subtitle repeated twice; one for each view. For instance, on a Side by Side conversion, the two subtitles will be placed on the right and the left of the screen, exactly at the position where they should be on the single SBS combined view. But that means that the TV must display the subtitles over the SBS images before enlarging each image and sending them to the right eye. Some TVs show the subtitle after having displayed the images, and therefore they display the "double" subtitle on a "single" image. Of course, that doesn't work. 3D subtitles is what you should use anyway if you send the SBS or T&B image to the TV with an external rendering engine, such as a multimedia hard disc or a PC that doesn't "know" that the movie is in 3D.

There is also a third solution, and imo it's the best one. With BD3D2MK3D, you can "burn" (or "hardcode") the subtitles over the video when the SBS or T&B movie is computed. That way, you will have the guarantee that the subtitles are correctly placed, and that the TV will not have to "guess" at what depth the subtitle must be displayed. The subtitles will be placed at the correct depth, and the TV will not "know" that there are subtitles with the movie. It's the solution I have used personally for the forced subs of Avatar, and it works pretty well. Of course, there is also a drawback. Since the subtitles are hardcoded, there is no way to turn them off, or to select another subtitle language. And muxing other subtitle streams doesn't make much sense, since they will be displayed by the TV on top of the hardcoded subs. That solution works therefore best if you are interested in only one language.

According to your description of your problem, you have used the 3D option, but the TV treats the 3D subtitles as a 2D stream, and displays them incorrectly. So, unless there is an option to display the 3D subs in 3D in your TV, you should use the 2D version of the subtitles. (In tab 2, under "Subtitles types", select either "2D only" or "2D then 3D". I recommend the latter one, because you will have the two possibilities.) I encourage you to try also the hardcoded subtitles. Despite the drawbacks, it's the best way to display the subtitles correctly, regardless of the hardware used.

Final note: If you have computed your version of Avatar with the subtitle types set to "3D only" and you want to try the version "2D only", and you still have the BD3D2MK3D project, you don't need to restart everything over. Just edit the _MUX_3D_OPTIONS.txt file to change the file name and title of the subtitle stream. Use the 2D version of the idx file instead of the 3D version. Then, double-click the _MUX_3D.cmd file to regenerate the MKV file, with the 2D subtitles. That file will probably work fine on your TV but the subtitles will not be placed at the correct depth. (Of course, to hardcode the subtitles on the video, you have to regenerate the entire project, and use the correct option in the last tab.)

mini-moose

29th May 2014, 09:04

I had some time today to play around with the recent version.

I have some questions:

1) Tried to load the generated AVS in virtualdub and all it's showing is a black screen. Though encoded output is fine.

2) Should I prefer to crop the black bars, how would I do that? I know r0lz doesn't recommend it but I prefer it like that. In the old versions the avs contained crop/resize switches, I don't see any on current ones.

3) There are lots of .3dp files left on working directory after preparation is done. Are those needed?

4) After project was created I wanted to make a 3d Sup using 3d-planes cause I find sup (when muxed in) works a lot better than vobsubs with some players. I launched the tool and chose bd sup, input file (original extracted sup) and output file, but I'm not sure what to choose for 3-D plane file as there are about lots of .3dp files (3D-Plane-00.3dp - 3D-Plane-31.3dp in this case). Not exactly sure to which extracted sup file they relate as I extracted 2 of them. Maybe I'm supposed to use the temp_2D.xml and not the original sup itself? I guess there is a simple way to do it, but I'm finding it confusing to figure out the right way doing it manually (not as part of the project generation).

Might be a good idea to generate both .sub and .sup, or have an option to choose when setting up to generate the project. Choosing .sup though would require an adjustment in the mux cmd as they won't play externally as far as I know.

thanks.

edit: I tried applying standard crop and it seems to work fine, though I haven't tested it on tv yet.

Privateer5000

31st May 2014, 09:55

And again hi from Germany.
I found this little nice prog when i started encoding of 3D Movies after buying my first 3D TV 3 months ago. Awesome work and especially now the feature with the correct 3D depth of the subtitles. AWESOME!!!!

@mini-moose

When you open a Movie with BD3D2MK3D go to the 2nd Tab "Streams" and take a look at the Subtitles. After each Subtitle you can see which 3DPlane is used. i.e. "4608 Subtitle: Eng PGS (3D-plane:0)".
I personally also prefer the BD SUP format for my Subtitles. I let BD3D2MK3D create the project without starting the encoding process. Then i use the created XML File, because the XML File already has the correct depth information in it und convert it by Hand into BD SUP format. After that just edit the _MUX_3D_OPTIONS.txt and have fun.

@r0lZ:
is it possible to implement an option in the 2nd Tab to choose the output format for the subtitles? Would make things a bit more comfortable, just an idea.
Oh, nearly forgot. Some Movie's like the german BD of "The three Musketeers" had problems concerning subtitles. After opening the BD the program says "Subtitle: Deu PGS (3D-plane:zerro)" and the conversion aborts with an error message saying that the program expects an integer value. I had to convert the Subtitles by hand, luckily there was only 1 3D-Plane after using "Extract 3D-planes from MVC" with a fixed depth. I had the same problem with 1 or 2 other movies, but sadly i forgot which one but all had a maximum of 2 3D-planes and only 1 had no fixed depth. By Analysing the 3D-planes with your tool i found out which 3D-plane was used by a subtitle, 1 was the complete subtitle and the other was the forced.
Is this "3d-plane:zerro" thing a problem of the Ripper or a problem of the movie, what do you think. Is there another way to see which 3d-plane a subtitles uses?

Sebastian

r0lZ

31st May 2014, 10:18

@mini-moose

1) Not sure why. Perhaps because you don't have the same settings when using VDub than with the _ENCODE.CMD script. It changes the current system PATH variable to include the toolset:
set path=D:\Tools\BD3D2MK3D\toolset;%path%
The decoder you have used may require the path correctly set to find libmfxsw32.dll.

2) There was a rezise to 720p switch in the old versions, that's right, but I have never implemented any crop option.
If you really want so, you can add manually a crop command in _ENCODE_3D_MOVIE.avs, but you will also have to modify _MUX_3D_OPTIONS.txt to specify the new aspect ratio.

Crop command syntax:
Crop(int left, int top, int -right, int -bottom, bool "align")
Example:
Crop(0, 140, -0, -140)
To be inserted after the DGMVCSource (or FRIMSource) command.

Mkvmerge syntax for the aspect ratio (in _MUX_3D_OPTIONS.txt):
--aspect-ratio
0:2.4
(The two examples above are approximately what you need for a movie shot in Cinemascope.)

[edit] I see that you have already tried the crop. You may have to remux with the correct aspect ratio now.

3) The 3d-planes files are needed to convert the subtitles to 3D with the correct depth values. You can safely delete them before encoding the movie, but they may still be useful if you need to rebuild the 3D subtitles with the "Convert Subtitle to 3D (with 3D-plane)" function in the Tools menu, for example to use another Additional Depth value, to convert your subtitles with another 3D-plane, or to convert additional subtitles downloaded from the internet to 3D). Anyway, that files do not take much disc space, and like other files that are no longer necessary when the project has been generated, I prefer to leave them in the working directory. They may be useful to diagnose a problem or bug and experienced users may need to examine or modify them to suit their needs.

4) The fact that there are several 3d-planes for the same 3D movie is surprising, since the depth to use for any subtitle in any language can theoretically be identical. But the fact is that several 3d-planes are planned by the BD3D standard. That may be because a specific subtitle in, say, English, may be longer once translated in another language, such as French. That means that the subtitle bitmap may be larger than the original one, or that the subtitle has to be shown longer on screen. In both cases, it may be partially over other "objects" of the current scene, and therefore they may require other depth values. Anyway, there are several planes, and we must select the best one.

Normally, when a subtitle is present in the original BD, it has an associated 3D-plane. You can see the planes numbers with the subtitle descriptions in tabs 1 and 2, after having opened the BD3D. Of course, if you want to add a subtitle downloaded from the internet, you will have to select an existing 3d-plane, and hope that it will be suitable for your stream. Have a look at the 3D-Planes.log file. You will see some interesting stats on each 3d-plane that may help you. You may also have to experiment. (And it's also for that reason that the 3d-planes are not deleted.)

Note that the first time you convert a subtitle to 3D, it creates the temp 2D XML/PNG files, but the XML file is then modified to include the new (and non-standard) tags "Depth". If you want to regenerate the 3D file with the depth values extracted from the 3D-plane during the first try, you can simply edit the XML file to change the depth of a few subtitles that may not be correct. To use the depth values from the Depth tags of the XML file instead of the depth values from the 3D plane, specify the XML file as input and DO NOT specify any 3D-plane file. (BTW, the possibility to fix depth errors by editing the 2D XML explains also why that XML and PNG files are not deleted when the final 3D sup or idx/sub file has been generated.)

It is easy to generate yourself the 3D SUP if you really need it. Currently, BD3D2MK3D supports only the SUB/IDX format, because it's the format that is supported by most players. AFAIK, the SUP streams (internal or external) can only be displayed by a few players.

Note that I have tried to use the SupTitle avisynth plugin and a 3D SUP file when the user wants to hardcode the subtitle on the video, but it has crashed with almost all tests I did, so currently, the IDX/SUB format is also used for the hardcoded subtitles. It's a pity, because the SUP format has more colors and transparency values and therefore a much better antialiasing, and of course the compatibility is not a problem when it is hardcoded on the video. If someone knows a version of SupTitle.dll or another avisynth plugin that works well with HD SUP files, I'm interested.

r0lZ

31st May 2014, 10:37

@Privateer5000

You have replied to mini-moose when I was writing my own reply. Thanks for him.

As I can see, mini-moose is not alone to want the SUP files in the MKV. It should be easy to add an option to select it rather than the SubRip format, but be warned: your subtitles will not be displayed by most players! Anyway, I will probably add that option in the next version.

3D-plane:zerro - I have never understood what that message means exactly. Apparently, "zero" means "not assigned", but I'm not sure. Unfortunately, Roman, the author of tsMuxeR 3D has stopped to work and doesn't reply any more at his threads and PMs, so I can't have confirmation. I'm not sure that I'm right, because there are also BDs or subtitles without any 3D-plane messages at all. Anyway, although I have already seen that "3D-plane:zerro" message, I have never tried to encode a movie with that strange message, and therefore I have never encountered the bug. Thanks for reporting it. I will fix it as soon as possible...

r0lZ

31st May 2014, 10:50

Hum, I have verified my code, and it seems that the "3d-plane: zerro" case has been correctly taken into account, or at least I can't find any bug. However, my program assumes that there is a space after "3d-plane:" and before "zerro". But in your message, you have written "3d-plane:zerro" without any space. Are you sure it's the syntax displayed in tab 1? If my code does its job correctly, that information should be removed in tab 2. (Of course, if the plane number is valid, the 3d-plane information is not removed in tab 2.)

Also, my code is case sensitive, and therefore it may not detect things like "3d-plane: Zerro" or "3D-Plane: zerro". Can you copy here the exact string you see in tab 1? (Sorry, I don't remember in what BD I have seen that case, and the ISOs I have currently on my HDD have correct plane numbers.)

mini-moose

31st May 2014, 11:27

thanks for your detailed resonse r0lz. I'm happy to see my instincts were mostly right.

1) Perhaps because you don't have the same settings when using VDub than with the _ENCODE.CMD script. It changes the The decoder you have used may require the path correctly set to find libmfxsw32.dll.

vdub opens the avs just displays a black screen. I tried copying over all the dlls from the tool set and that didn't help. Tried loading libmfxsw32.dll in avs but judging from the avs erro it's isn't an avisynth plugin (seems to be intel sdk). Maybe I need a
copy in sys?
It's not very important. I was trialing crop and it was easier to preview in vdub than encode a clip (which is what I ended up doing).

Crop command syntax:
Crop(int left, int top, int -right, int -bottom, bool "align")
Example:
Crop(0, 140, -0, -140)
To be inserted after the DGMVCSource (or FRIMSource) command.

Mkvmerge syntax for the aspect ratio (in _MUX_3D_OPTIONS.txt):
--aspect-ratio
0:2.4
[edit] I see that you have already tried the crop. You may have to remux with the correct aspect ratio now.

That's what I ended up doing. used crop after AssumeFPS. I remember asking you about crop back when coreavc was in use and the command was much more complex so wasn't sure it's that simple here :)
I'm not entirely sure the AR flag in mkvmerge is even necessary. I tried it with and without and mediainfo/avinaptic both report the same AR. It doesn't hurt, but not sure it's really needed.

3) The 3d-planes files are needed to convert the subtitles to 3D with the correct depth values.
thanks for explaining.

4)Normally, when a subtitle is present in the original BD, it has an associated 3D-plane. You can see the planes numbers with the subtitle descriptions in tabs 1 and 2, after having opened the BD.

Note that the first time you convert a subtitle to 3D, it creates the temp 2D XML/PNG files, but the XML file is then modified to include the new (and non-standard) tags "Depth".

Reason I was asking was that I wanted to generate a sup file instead of vobsub and one of the required fields (which I later found out was somewhat optional) was what 3dp file to use and with 32 different ones I wasn't sure what to do.
At the end I used the temp_2D.xml located in 00001.track_4608.En.3D_2D and left the 3dp box empty. If I understand correctly from the replies, that was the right way to do it.

mini-moose

31st May 2014, 11:29

@mini-moose

When you open a Movie with BD3D2MK3D go to the 2nd Tab "Streams" and take a look at the Subtitles. After each Subtitle you can see which 3DPlane is used. i.e. "4608 Subtitle: Eng PGS (3D-plane:0)".
I personally also prefer the BD SUP format for my Subtitles. I let BD3D2MK3D create the project without starting the encoding process. Then i use the created XML File, because the XML File already has the correct depth information in it und convert it by Hand into BD SUP format. After that just edit the _MUX_3D_OPTIONS.txt and have fun.

thanks. I believe that's what I ended up doing :)

mini-moose

31st May 2014, 11:41

As I can see, mini-moose is not alone to want the SUP files in the MKV. It should be easy to add an option to select it rather than the SubRip format, but be warned: your subtitles will not be displayed by most players! Anyway, I will probably add that option in the next version.

Subtitles are a bit of a pain. It all depends on what you are using to play the video. Pretty much every hardware player has it's own quirks when it comes to what/how it can display the various formats. Some would not play vobsubs at all, some only muxed, some only external, some would display them too big and can't position them. Since there are so many such players - from Dune to Popcorn Hour to tv media ports (not to mention different models for each), there is no one sub format that would work seamlessly on everything. For example a friend of mine that has Dune reported muxed sups work fine but vobsubs don't, another with Popcorn Hour reported the same thing. So I guess it's a matter for each user to find what works best with his gear.
I'm happy to read you'll likely add an option for sub format export. Note that when using sup, the mux cmd would need to be modified, because I don't think anything plays sups externally. Not even popular software players (which usually have the least amount of quirks and restrictions).
mkvmerge applies compression on sup by default so they don't actually take as much space as their original size (I think with compression it's about 1/2).

r0lZ

31st May 2014, 12:32

I tried copying over all the dlls from the tool set and that didn't help. Tried loading libmfxsw32.dll in avs but judging from the avs erro it's isn't an avisynth plugin (seems to be intel sdk). Maybe I need a copy in sys?Yes, it's the Intel library, used by the two MVC decoders. You can copy it somewhere in your PATH, like in system32 (on a 32-bit system) or SYSWOW64 (on a 64-bit system), or you can edit your PATH variable to include the toolset. But I'm still not sure that it will work, because the two decoders are supposed to load the lib from the directory where they reside.

That's what I ended up doing. used crop after AssumeFPS. I remember asking you about crop back when coreavc was in use and the command was much more complex so wasn't sure it's that simple here :)Yes, that's simpler with the new decoders, because they produce the frames in standard HD format. The old decoders produced the frames already stacked in SBS or T&B format, and therefore it was necessary to divide them before applying the crop.

I'm not entirely sure the AR flag in mkvmerge is even necessary. I tried it with and without and mediainfo/avinaptic both report the same AR. It doesn't hurt, but not sure it's really needed.Correct, the right AR should be present in the h264 stream, and therefore you can probably assume that MkvMerge will retrieve it correctly. But you must at least remove the AR definition from the _mux_3D_options.txt file, as otherwise it will force the wrong 16:9 AR.

Reason I was asking was that I wanted to generate a sup file instead of vobsub and one of the required fields (which I later found out was somewhat optional) was what 3dp file to use and with 32 different ones I wasn't sure what to do.
At the end I used the temp_2D.xml located in 00001.track_4608.En.3D_2D and left the 3dp box empty. If I understand correctly from the replies, that was the right way to do it.Yes, if the 3D-plane that has been automatically used by BD3D2MK3D during the first conversion is correct. (I have already encountered a lot of 3DBDs with wrong, empty or non-assigned 3D-planes, and BD3D2MK3D tries to select the right plane automatically, but can fail in some difficult cases.)

Subtitles are a bit of a pain. It all depends on what you are using to play the video. Pretty much every hardware player has it's own quirks when it comes to what/how it can display the various formats. Some would not play vobsubs at all, some only muxed, some only external, some would display them too big and can't position them. Since there are so many such players - from Dune to Popcorn Hour to tv media ports (not to mention different models for each), there is no one sub format that would work seamlessly on everything. For example a friend of mine that has Dune reported muxed sups work fine but vobsubs don't, another with Popcorn Hour reported the same thing. So I guess it's a matter for each user to find what works best with his gear. I agree. But I'm pretty sure that the compatibility is much better if you use the VobSub format. It's why I haven't tried to implement the BD SUP format.

I'm happy to read you'll likely add an option for sub format export. Note that when using sup, the mux cmd would need to be modified, because I don't think anything plays sups externally. Not even popular software players (which usually have the least amount of quirks and restrictions).
I'm not sure I understand. What should be changed (in addition to the file extension, of course)? Currently, the subtitles are muxed INSIDE the MKV container, and you write that you "don't think anything plays sups externally". So, if they are internal, it's perfect, no? (If you need them outside the MKV container, you can simply copy and rename the subtitle files as well.)

mkvmerge applies compression on sup by default so they don't actually take as much space as their original size (I think with compression it's about 1/2).
As you can see in the _MUX_3D_OPTIONS.txt, my tool turns the compression off, also for compatibility reasons. The subtitle files do not consume much disc space anyway, and it is well known that many players refuse to decode the compressed subtitle streams.

--compression
0:none

mini-moose

31st May 2014, 12:45

But you must at least remove the AR definition from the _mux_3D_options.txt file, as otherwise it will force the wrong 16:9 AR.

Ah yes, I usually don't use the mux cmd so I didn't think of that :)

So, if they are internal, it's perfect, no? (If you need them outside the MKV container, you can simply copy and rename the subtitle files as well.)

Yes, that would be fine. Sorry for failing on looking into the mux options again.

my tool turns the compression off, also for compatibility reasons. The subtitle files do not consume much disc space anyway, and it is well known that many players refuse to decode the compressed subtitle streams.

That's a good point I didn't think of. I know when mkvm used header compression by default, that caused issues with a lot of players. I guess the same can happen with sub compression.
Sup files consume more space than vobsubs. Still, not a big deal if you just add one or two such streams. I don't consider space consumption a big issue anyway but some do.

Did you try using sup files yourself? I'm curious if they work on your playback setup or not (don't know what it is).

r0lZ

31st May 2014, 12:57

No, in fact, nothing work with my Samsung UE40D6500 TV, except external SRT (text) files. And the subtitles from the SRT are very badly displayed. The font is way too big. A long subtitle can be divided in a lot of lines. (I have seen subtitles divided in up to 6 lines and occupying more than the lower half of the image!) The subtitles are displayed "on the surface of the screen" when they are used with a 3D movie, and there is no way to specify a fixed depth. Samsung did a very bad job. :-(

It's why I prefer to hardcode the subtitles on my 3D movies. At least, I'm sure that they will be displayed correctly, and with the right depth. But of course, I can't store several subtitles streams for the same movie, because it doesn't make sense to display a subtiutle stream over the hardcoded subtitles.

BTW, to examine the individual depths of the 3D subtitles generated with the 3D-planes, I recommend to hardcode them. Subtitles displayed by the player may be at a wrong position, or may have been scaled up or down. In all cases, you can't trust what you see.

mini-moose

31st May 2014, 13:07

No, in fact, nothing work with my Samsung UE40D6500ץ
It's why I prefer to hardcode the subtitles on my 3D movies.

BTW, to examine the individual depths of the 3D subtitles generated with the 3D-planes, I recommend to hardcode them.

Aww, that's too bad. I guess hardcoding is the way to go in such cases. A lot of those players have been designed to do the minimum, which causes a lot of issues having everything work perfectly all the time. The case is especially evident in tv media ports which are a side extra feature and not the main thing.

r0lZ

31st May 2014, 14:22

Yeah. I have also an old LaCie LaCinema HDD, and that one displays the embedded IDX/SUB and other formats, but it's not a 3D player, and therefore the TV must decode the SBS. Unfortunately, the LaCie changes the position and size of the 3D subtitles and therefore they are displayed at the wrong depth. Anyway, it is a pain to use the TV to decode the SBS signal sent by the Lacie, because the OSD of the Lacie is decoded as well, and since it has not been encoded in SBS, you imagine the result!

Currently, don't have a 3D graphics card in my PC, but I will certainly have one with my next PC. I hope that dedicated players such as Stereoscopic Player can display the 3D subtitles correctly.

Privateer5000

31st May 2014, 22:50

Just found another BD with the "zerro" thing.
Resident Evil Retribution. The String from Tab 1 is:
"Subtitle: Deu PGS (Stream #0 3d-plane: zerro)".
BD3D2MK3D

I attached Screenshots to this Post of Tab 1 and 2. I also attached a Screenshot of the Error Message when BD3D2MK3D aborts. This Message appears when the conversion process for the subtitles is supposed to start. All Streams are demuxed, the 3d-planes are extracted from the mvc file (2 files in this case) and the 2D Subtitle are present in IDX/SUB format. As you can see, this movie has only 1 Subtitle. Both 3d-planes have the same stats. Same number of frames, same starting frame and same end frame. The only difference is that the fixed depth is different, one has 9 and the other 11. Do you known how a 3D BD Player knows which depth is correct?

Concerning Problems with BD SUP and Players. I use the BD SUP format at least six months or longer with my 2D Movies and didn't encounter any Problems. On my HTPC i use Media Player Home Classic which is enclosed in the K-Lite Codec Pack or the Combine Community Codec Pack. No Problems. On my Android Phone (Galaxy S4 Active) and Tablet (Xperia Tablet Z) i use MX Player, no matter if the movie is on the SD Card or if i stream it via DLNA from my HTPC.
I have a passive Grundig 3D TV and i use the Top-Buttom Method and let the TV decode the Top&Buttom Image. Without Cropping all Subtitles are displayed at the right position and as far as i can say from what i have seen till now all with the right depth. To be honest i never tried the media Player of my TV because my HTPC is hooked up directly to my TV.

Hope this helps.

r0lZ

1st June 2014, 09:47

OK, I see. Excellent description of the bug. I should be able to fix it. Thanks.
(BTW, you can copy/paste the content of the error dialogue. It's easier than making screenshot.)

You are lucky if the solution with your HTPC and MPC works for you. But it's not the case of everyone. For example, in my case, the TV and the PC are connected via the ethernet cable and my router, and therefore I can play files stored on the HDD of the PC with my TV, but it's still the TV that has to render the 3D. Anyway, since it is possible to play the BD SUP files with more players than I thought, I will support that format, in addition to the current SubRip format.

[EDIT] Damn! That was so simple! I haven't noticed the "zerro" typo in tsMuxeR. In my code it is spelled correctly "zero", and of course, the test to convert that pseudo plane number to a real number did not work. That will be easy to fix.

Now, it would be nice if I could also understand the meaning of that "zerro". I don't know what plane I should use when that case happens.

When BD3D2MK3D opens the 3D BD, it tries to show only the relevant 3D titles. For example, it excludes the very short titles and the menus. Sometimes, the same movie is present several times (in fact, several MPLS files reference exactly the same SSIF files, in the same order). In that case, BD3D2MK3D tries to select the "best" MPLS, notably by analysing the plane numbers of the subtitle streams. BD3D2MK3D keeps the MPLS that has a valid (non-"zerro") 3D-plane associated with each subtitle stream. But when there are no MPLS with enough 3D-plane definitions, it selects the one with the most numerous 3D-planes definitions. If the user wants to convert a subtitle without a 3D-plane, it uses the second valid 3D-plane (usually plane #1), or the first one if there is only a single valid 3D-plane. (It uses the second plane by default because I have noticed that often the first plane is less complete than the second one, probably because it corresponds to the original language of the movie and that there are less things to translate.) Of course, I can't be sure that the selected plane is the best one, and I don't think there is another method to find the best one.
Note that you can examine all 3D MPLS files in your BD if you click the "Show All 3D Playlists" button. You can even select a MPLS with less 3D-plane definitions if you wish, but of course it's not recommended.

pharaoh

1st June 2014, 09:53

Hi r0lZ and all. Sorry if this is covered somewhere in previous 108 pages. I skimmed thru, but to no avail. My objective: use MakeMKV and BD3D2MK3D to generate half-HD OU mkv copies of my 3D blu-ray's. So far, I've done three disks, with a 33% success rate. The failure mode is one of the two eyes being garbled up.

Summary:
1) Monster House - I got a warning after decoding that the two video streams had different number of frames. I encoded anyway and the result was the right eye garbled.

2) How to Train Your Dragon - no warnings, and perfect result.

3) Hobbit 2 part 1 - no warnings, but the LEFT eye garbled. See attachment. What's even more interesting is that the first 205 seconds of the movie are fine (good 3D). Then, in the middle of a scene, the artefacts start and remain for the rest of the film.

Of course, in all cases I see the initial disclaimer when I try to open folder containing the copy of the disk created by makemkv - "due to BD structure, reading from a copy may not work", or something like that. So I guess I shouldn't be to surprised. But the fact that it worked once gives me hope.

My process flow:
- create a "backup" with MakeMKV.
- remove the .smap extensions from the ssif folder
- run BD3D3MK3D, open the folder containing the backup
- set my encoding options and title and go
- after decoding is finished, run "_encode.cmd"
- hope for the best

My questions:
1) Is it a sync issue during decoding? Why? Any way, automatic or manual to re-sync the frames?
2) Can you explain the why there is a difference between the disk structure and the backup?
3) Is there any way to extract the left and right eye tracks directly from an MVC video track instead of the disk structure?

Thanks!

mini-moose

1st June 2014, 10:38

Of course, in all cases I see the initial disclaimer when I try to open folder containing the copy of the disk created by makemkv - "due to BD structure, reading from a copy may not work", or something like that.

What size is your backup? never tried makemkv for 3d backup but I know in other softwares it comes out twice the size which is why it's usually recommended to backup to .iso which also keeps the structure intact. Sadly, I think makemkv doesn't have an .iso option.

Privateer5000

1st June 2014, 10:47

I had the best experience with ISO Files, mounted with a Virtual Drive. Except that "zerro" Thing by some subtiltes i had no problems with BD3D2MK3D.
Lets give it a try and use another Software to make your "Backup".

mini-moose

1st June 2014, 11:15

Lets give it a try and use another Software to make your "Backup".

Main problem is that other softwares cost more money..

r0lZ

1st June 2014, 11:18

That sync problems can happen when the BD has not been correctly ripped. In case of a read-error, the ripper may stop with an error message, or continue silently. In the latter case, chances are that some frames will be missing, or impossible to decode. Of course, when the BD is converted to SBS or T&B, the missing frames are skipped, and a desync occurs between the left and right views. Since the MVC stream (usually the right view) depends of the AVC stream (the other view), after a desync problem, the dependent view cannot be decoded properly.

I don't know if MakeMKV does its job correctly when it encounters a read error, but imo your best chance is to retry to rip the BD in better conditions (after having cleaned up the disc, and/or with another BD drive, and/or with another ripper program). Also, I think that ripping the BD to an ISO and mounting that ISO may give better results than copying all files to a folder on HDD. Unfortunately, afaik there is no other ways to re-sync the frames.

There is a big difference between the disc structure and the backup of a 3D BD. (The backup of a 2D BD is more or less identical to the original.) That difference concerns only the backups as files in a folder, and not if your backup is an ISO.

The 3D BD standard is an extension to the original 2D BD standard, and has to be compatible with the 2S standard. For that reason, the 3D BDs have exactly the same disc structure than a 2D BD, with MPLS and M2TS files in the same directories. A 2D player "sees" only that 2D files. But in a 3D BD, there are other files and extensions of the MPLS files. One of the major differences is that there is a new MPLS file for the second view. That MPLS is encoded in MVC and requires the corresponding AVC M2TS to be decoded correctly. The 3D player could read and decode the 2 files at the same time and display the 3D images. However, to do so, it would have to read data from the AVC file, then data from the MVC file, and again from the AVC and then MVC, and so on. That would require to constantly jump from a position in the disc (within the AVC file) to another position (in the MVC file) then back to the AVC file, and so on. It's not possible with a slow medium like a BD, and therefore the 2 streams are also present as a combined 3D stream.

Of course, it is not possible to include two times the same movie (once in 2D and once in 3D) because that would require too much disc space. Therefore, the 3D BDs use a trick at the file system level. The 3D movie is stored in a SSIF file that is the combination of the 2 M2TS files, interleaved one into each other. That means that there are 3 entries for the same data in the directory of the 3D BD: One M2TS entry for the 2D AVC stream (seen by the 2D and 3D players), one M2TS entry for the MVC stream (not used by the players but present anyway), and one SSIF entry for the AVC+MVC streams (seen by the 3D players only). It is important to understand that the SSIF entry points to the data pointed to by the two M2TS entries, and therefore that the data is present only once. The trick is similar to the hard links of the NTFS file system, but with the addition that the SSIF "link" points to two embedded files at the same time. Therefore, when the 3D BD is copied to the hard disc, the copier "sees" 3 files and copies them all. By doing so, it copies the dame data two times: once for the two M2TS files, and once for the SSIF. The final copy on HDD occupies therefore about two times the disc space of the original 3D BD. It's why I recommend to rip the 3D BDs as ISOs, because that preserves that complex disc structure and that takes less disc space and less time to do the copy. But you should be able to convert also the files copied on HDD to SBS or T&B anyway. The decoders do not need the original disc structure to work correctly, as long as it can find the necessary files.

It is theoretically possible to extract the 2 views from the 2 M2TS files (or from the combined SSIF), but that will not solve the problem of the desync. What you have on your HDD is almost certainly somewhat bad, and you have to start from a good copy. (You can also start from the original BD decoded on the fly by AnyDVD, but I don't know what happens in case of a read error.)

[EDIT] There have been 3 replies when I was typing this long reply. As you can see, they suggest the same thing than me. Do a good backup to an ISO.

mini-moose

1st June 2014, 12:00

That sync problems can happen when the BD has not been correctly ripped.

Yeah, my best bet is that makemkv isn't the best ripper for 3D.

pharaoh

1st June 2014, 12:47

Thanks for detailed info. Makemkv backup is about the same size as the disk itself, certainly not double. The backup of a 3d disk is also about 1.5x the size of the 2D mkv file that makemkv makes, which sounds about right given that the second eye consumes about 50% the space of the first eye. The backup basically contains the BDMV folder and the CERTIFICATE folder. Maybe the makemkv guys figured out how not to copy the data twice. Something to do with that .smap extension, perhaps?

I got hooked on Makemkv (long before 3D) because it is free and so far has decripted everything I've thrown at it. But thank you for mentioning that read errors might be the root cause. I recall now seeing some "...failed hash check" errors in the makemkv log. I didn't know what they meant so just ignored them. I'll investigate that further.

That said, I don't mind trying the backup to iso approach. So how do I backup to ISO, and then mount and decrypt, for free?

mini-moose

1st June 2014, 13:31

I got hooked on Makemkv (long before 3D) because it is free and so far has decripted everything I've thrown at it.

That said, I don't mind trying the backup to iso approach. So how do I backup to ISO, and then mount and decrypt, for free?

I never tried backing up 3D with makemkv, also don't know what .smap files are.

I don't know of any free softwares to decrypt blurays, maybe there are but I'd suspect non of them would be as good as commercial ones (specifically AnyDVD HD).

You can try and install an anydvdhd trial, backup one of the discs you had issues with to .iso and see if you get the same issues or not. Just as a way to validate or refute the theory the 3d back up using makemkv is the cause.

Mounting tools are easy to find free, I prefer Virtual Clone Drive myself.

Privateer5000

1st June 2014, 13:32

The HD Decrypter of DVDFab for example is always free, even when the trial expires but it could happend that it can't decrypt new BD's (never had that case, but it has to be mentioned). AnyDVD has a trial period of 21 Days and there are some ways to extend this. Google is here your best friend ;)
To mount an ISO you can use DVDFab Virtual Drive, Virtual Clone Drive or Daemon Tools Lite, all Freeware.

mini-moose

1st June 2014, 13:38

AnyDVD has a trial period of 21 Days and there are some ways to extend this.
It would be a problem when discs need server assistance. As far I know trial versions do not have the possibility to do that.

The HD Decrypter of DVDFab for example is always free
Yeah, I assume it will have some problems with some newer discs but could be an option. Note that dvdfab has made some changes recently to their products (I believe due to some lawsuit). I'm not convinced the free HD decrypter still works as it used to.

r0lZ

1st June 2014, 13:47

To mount the ISO under Win 8, you just have to double-click it. No additional program is needed. Not sure for Win 7.
I like WinMount, because it can also mount ZIP, RAR and 7Z archive files, but it is not free.

r0lZ

1st June 2014, 16:16

Here is the new version of my GUI.

It fixes the "3D-plane: zerro" bug and lets you select either the VobSub or BD SUP format for the subtitle files (in 2D and 3D modes). It fixes also another bug in the Chapter File Converter.

Please note that I have NOT tested the fix for the zerro bug. Please try the new version with a BD that failed previously. Thanks.

Note also that the original SUP files are still converted to IDX/SUB format in 2D, even when the BD SUP format has been selected. I use that conversion to determine a couple of things, like the number of forced subtitles in the original stream, and it was too difficult to remove it. But the stream is converted to 3D in the right format, and the right file is muxed in the final MKV file.

# v0.36 (June 1, 2014)
# - It is now possible to mux the subtitles in BD SUP format instead of VobSub (IDX/SUB) format.
# - Fix: Crash when trying to convert a subtitle stream to 3D with the 3D-plane "zerro" (sic).
# - Fix: Tool -> Convert Chapter File was unable to load OGM chapter files demuxed by some versions of MkvExtract.

As usual, download it here (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z).

mini-moose

1st June 2014, 17:04

Great, thanks r0lz.

trumpet205

2nd June 2014, 04:17

Hi everyone,

I'm a rookie on Doom9. I bought number of Blu-ray 3D over the years, and now would like to convert them to H-TAB. I can use MakeMKV to rip it into MKV, then use tsmuxer to demux AVC and MVC streams.

I don't know how to proceed from there. Is there an Avisynth example I can follow?

Privateer5000

2nd June 2014, 07:32

There is an easy way to convert your 3D BD's . Throw away makemkv, rip your BD's to an ISO file and use BD3D2MK3D provided by r0lz 2 Posts above yours. It is the only software right now which creates 3D Subtitles with the right depth like the genuine BD. Easy to use and userfriendly. Even Commercial Software like DVDFab is not able to reach the efficencie of BD3D2MK3D (DVDfab creates 12 GB+ Files with CRF 18-20 and BD3D2MK3D makes files smaler 9 GB from the same Movie with equal CRF Settings) and this here is for free.

r0lZ

2nd June 2014, 10:15

:goodpost:
Thanks for the ad, Privateer5000! :rolleyes:

trumpet205

2nd June 2014, 19:19

I don't care about subtitle, and I prefer to encode them using MeGUI. ;)

r0lZ

3rd June 2014, 12:40

# v0.37 (June 3, 2014)
# - Added an alt 3D detection mode to try to open badly authored 3D BDs (without the SSIF folder).
# - Now uses the new alt 3D detection mode when the SSIF folder contains only .SMAP files created by MakeMKV.
# - The number of channels (stereo, 5.1, 7.1) is now added to the label of the audio streams in the MKV file.
# - Fix: LPCM (WAV) audio tracks were not muxed in the final MKV file.
# - Fix: LPCM (WAV) audio tracks were not converted to AC3 when the Convert to AC3 option was ticked.
# - Updated the Intel MVC decoder library to the latest version (libmfxsw32.dll v5.14.4.28)

As you can see, I have added a new method to detect if the BD is a 3D BD and to find the 3D titles within the 3D BD. The new method is slower (especially if there are many MPLS files in the BD) and it may be less reliable, but it can detect 3D titles in badly authored BDs, such as "Albator corsaire de l'espace" (the French version of "Space Pirate Captain Harlock"), that has no SSIF folder! :eek:

The new detection method should also be able to handle the SSIF files with the SMAP extension created with MakeMKV, without the need to create hard links, and it should therefore be possible to open that backup folders more easily.

The new detection method is never used without your consent. If the program cannot open a BD with the old method or if it detects .SMAP files in the SSIF folder, it will ask you if you want to use the alt method. Use it at your own risk!

This version has also a little improvement and fixes a couple of bugs.

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

mini-moose

3rd June 2014, 14:57

Fix: LPCM (WAV) audio tracks were not converted to AC3 when the Convert to AC3 option was ticked.

Might be a good option to convert to Flac too (eac3to can do flac conversions), since AC3 is lossy. Flac 16bit should be smaller than AC3 and better quality. 24bit is also possible but bigger in size.

r0lZ

3rd June 2014, 18:14

Hum, yes, but who wants FLAC in MKV vidoe files? I have never seen that, and imo most players do not support that format (except perhaps some rare and expensive hardware media players). IMO, converting to AC3 makes sense to regain disc space and, when converting from DTS, for compatibility reasons, but FLAC consumes at least 40% of the original WAV and is not widely supported, and therefore is not really interesting for that purposes. Also, currently, there is an option to convert DTS AND WAV to AC3, and I don't want to multiply the options. My GUI is supposed to convert 3D BDs to the most usual MKV video formats only.

mini-moose

3rd June 2014, 21:02

imo most players do not support that format (except perhaps some rare and expensive hardware media players). IMO, converting to AC3 makes sense to regain disc space and, when converting from DTS, for compatibility reasons, but FLAC consumes at least 40% of the original WAV and is not widely supported

Fair enough, just a suggestion. I only use software players so I wouldn't know about hardware media players (they are too restrictive for my taste). But from what I've seen LPCM to Flac 16bit takes less space than top AC3 bitrate. I don't know what bitrate AC3 is transcoded to with the software. If it's to 192k then of course it will be smaller. However most LPCM audios are very high bitrate, so if I do convert them to AC3, I usually use highest bitrate AC3 too.

r0lZ

3rd June 2014, 22:05

640 Kbps by default. But you can also use the "Convert audio file to AC3" tool to overwrite the AC3 file if you prefer a lower bitrate.

Also, I realize that I have selected 640 Kbps by default because it's usually a DTS 5.1 that is converted to AC3. For a stereo LPCM, that bitrate may be too high. But LPCM audio is rare on 3D BDs, except perhaps for musical films or concerts, and in that case, a good audio quality is important.

Thalyn

5th June 2014, 02:47

So here's a curious one for Slavanap with his ssifSource4.43 plugin: using the appropriate series of commands results in the second half of the the output returning a periodic error.

Basically, in accordance with my tests from a few pages ago I've started using the following to combine my streams into a half over/under result:
Left = SelectEven (SeparateRows (Blur (Left, 0, 1), 2))
Right = SelectOdd (SeparateRows (Blur (Right, 0, 1), 2))
HOU = StackVertical (Left, Right)
NB If you don't use the AVISynth 2.6 Alpha than you'll have to switch out SeparateRows with SeparateFields, and also apply AssumeTFF. The issue still occurs identically when using 2.5.8.

The weird part is that it's not entirely clear what command is causing the problem. It's only by using Blur and StackVertical in tandem that there's an issue, which results in the bottom part of the frame periodically displaying green. Dropping out either of those commands causes it to render perfectly (though obviously not merging them makes for poor 3D playback). The SelectEven/Odd and SeparateRows commands have no influence on the error at all, as best I can tell. What's even more weird is that the error is always on the bottom half of the frame, so even switching around the order of Left and Right in StackVertical still results in the bottom causing the issue - it's not associated with the AVC or MVC stream.

The actual issue seems to stem from how it determines what frame it's showing. If I remove all of my cropping and set the AVC stream to be the bottom it actually flicks up an error saying that it cannot retrieve a given frame because it's expecting the next one with the note indicating that it only supports sequential frame rendering.

The good news is that it's fairly consistent, happening every 30 frames; though it doesn't actually occur on exact multiples of 30. For example, the streams I'm testing now had errors on frame #0 and #1, then it started occurring regularly on #29, #59, #89, #119, #149 and so forth. It also occurs whether the JM decoder or the Intel decoder is in use, regardless of what the source stream is. FWIW, neither DGMVC nor FRIM show the same issue with the same sequence of commands.

Let me know if you need any more info.

*Ed: I do split the frames off into AVC and MVC earlier in the piece by cropping the stream. If I leave the stream unaltered it displays no issue, however it also doesn't use the StackVertical command so I can't really tell whether that's a coincidence or not. Attempting to be horribly inefficient and use two different commands to read the source (one each for the AVC and MVC frames) doesn't work at all - it just stalls with no CPU or HDD usage to speak of, even if I tell it to use two different decoders.

slavanap

5th June 2014, 23:18

Thalyn,
The cause might be that looking forward is forbidden. And the frame cannot be asked twice (here's your bug).
After such a huge frame-related operations, AviSynth clears its cache and asks for the frame again, that probably appears as your error.
You can avoid it by setmemorymax(256), or 512, for example. But big values here can make program run out of memory because its 32-bittness.

I'll fix twice frame acquire a bit later, thanks for the info.

Thalyn

6th June 2014, 08:29

Bumping up the memory allocation to 2048 (figured I'd be a little silly to start with then dial it back until it broke) didn't actually change anything - same issue with the first two frames, then every 30 frames starting from #29. I figured it had to be something to do with a cache flush or similar, but it just seems odd since I'm only actually reading each frame once and then tinkering with it in different buffers. Annoying that there isn't a way to accurately specify a resize kernel, or to split a stream into scanlines and discard every second frame in one step, since I'm sure that doubling the framerate and then halving it again isn't helping the situation.

I look forward to 4.44 (or whatever version it winds up being). I rather like the new results I've been getting (yet to test them on an active display, but they're nice on passive) and there's still at least two movies I can only get to process correctly using your source plugin.

slavanap

6th June 2014, 21:06

New version will be soon.

Btw, recently I'm looking for someone, who can speed up Intel sample_decode.exe decoder. AFAIK, someone has already done that successfully.

Nico8583

6th June 2014, 21:58

Please add a comment to this post : https://software.intel.com/fr-fr/forums/topic/516009
Perhaps Intel will help us if there are many users...

slavanap

7th June 2014, 09:52

New version of ssiSource4 - 4.44: http://sendfile.su/988099
Minor fixes:
* twice current frame acquiring
* crash when launched from 2 different users accounts fix
* swap_view autodetection fix for mplsSource, mplsSource parameters renaming

P.S. I haven't fully tested this version (as always), so please keep this in mind.

Thalyn

8th June 2014, 05:01

Sadly that's a negative on my issue. Same errors in exactly the same places. In case it in any way helps, the exact source I'm using is as follows:

SAVC = Source base stream
SMVC = Source dependant stream
FC = Frame count (manually predetermined)
Swap = False (manually predetermined)
TC, BC, LC and RC = Cropping amounts (manually predetermined)

Source = ssifSource (avc264 = SAVC, mvc264 = SMVC, frame_count = FC, use_ldecod = true, swap_views = Swap)
Left = Source.Crop (LC, TC, -RC, -BC - 1080)
Right = Source.Crop (LC, 1080 + TC, -RC, -BC)
Left = SelectEven (SeparateRows (Blur (Left, 0, 1), 2))
Right = SelectOdd (SeparateRows (Blur (Right, 0, 1), 2))
HOU = StackVertical (Left, Right)
return HOU.Trim (0, FC - 1)
The original script is quite a bit longer, but I've boiled it down to that in order to remove the chances of anything else interfering and the issue still occurs. I'd substitute the values in directly for the variables but that just seems redundant at this point. The error is always on frame #0 and #1, then every 30 frames starting from #29; unless I start playing back and then pause it to skip frame by frame, which changes the offset of the issue but not the period (still every 30 frames just not necessarily starting from #29 anymore).

r0lZ

8th June 2014, 07:14

Have you tried to do the Crop after the SelectEven/Odd?

Something like this:

Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = Left.Crop (LC, TC, -RC, -BC - 1080)
Right = Right.Crop (LC, 1080 + TC, -RC, -BC)
Left = SeparateRows (Blur (Left, 0, 1), 2))
Right = SeparateRows (Blur (Right, 0, 1), 2))

Thalyn

8th June 2014, 13:35

Interesting...

I can't actually use that exact script because Slavanap's plugin provides the frames as either TAB or SBS, not sequential like FRIM or DGMVC (though when I use those, your script is pretty much exactly how I do it). If I apply the Select before I Separate them than I'm going to wind up with the left and right "eyes" one frame out of sync, as well as displaying the same frame twice (once for each set of scanlines).

That having been said, taking that idea and running with produced something that worked:

Source = SeparateRows (Blur (Source, 0, 1), 2)
Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = Left.Crop (LC, TC / 2, -RC, -BC / 2 - 540)
Right = Right.Crop (LC, 540 + TC / 2, -RC, -BC / 2)

While this is theoretically the same (just working with only the Source buffer instead of both Left and Right), this actually works perfectly and gives pixel-identical results to the other method (sans the error) - so long I'm applying at least 1px of vertical cropping. If there isn't any cropping than there will be a half-pixel of bleed at the bottom of the left into the top of the right. If I Crop before I Blur to deal with this bleed than I wind up right back where I started, so this unfortunately isn't a panacea.

I'm gonna try breaking it down to individual commands again to see if it makes any difference. Maybe AVISynth is buggering up the order and messing things around. I'll edit this post if it makes a difference (no edit = no difference).

*ed: I got this far before the error came back:

Left = Source.Crop (LC, TC, -RC, -BC - 1080)
Right = Source.Crop (LC, 1080 + TC, -RC, -BC)
Left = Blur (Left, 0, 1)
Right = Blur (Right, 0, 1)

I started with just the two Crop commands and it worked fine. The instant I put those Blurs in? Bam - error like explained previously. In fact, it's the act of blurring the upper frame that's causing the problem! By "upper" I mean whichever frame comes first in the final StackVertical command, so it isn't specifically the Left or Right (AVC and MVC respectively). If I only apply the Blur to lower frame (whichever it is) than there's no issue, and only if I'm stacking both of the streams (stacking the same stream twice works fine). Even if I extend the script out to include the SeparateRows and then Select it still works just fine so long as I'm not applying the Blur to the upper stream.

Now I'm even more confused!

r0lZ

8th June 2014, 13:46

You apply the blur only along the Y axis, right? And you want to crop the two images to handle them separately, right again? Then you can probably use the SBS mode of Slavanap's decoder, apply the blur on the whole combined views (and it should not affect the borders of the adjacent view), and crop the two views later. You'll end up with the Left and Right clips anyway, and you can stack them vertically, to obtain a final T&B 3D movie if you wish.

Anyway, imo, to avoid the bug, you should read the frames only once, so that the decoder doesn't receive multiple requests for the same frame.

Thalyn

8th June 2014, 13:58

I.... hadn't even considered that. Horizontal input lets me avoid the bleed while using the other command order that works. Solves all the problems in one fell swoop, and a quick test has it working absolutely perfectly.

I didn't actually think I was requesting the same frame more than once anyway. I wanted Source to get the frame, and then worked exclusively from Source - which should mean only one request, despite what I'm doing to it, right? I guess AVISynth thinks otherwise.

Can I curl up into a ball and cry yet? I like things to make sense, and frankly this doesn't. At least it works now...

I've finally got something that works and should neatly fit in with my existing script to handle things like subtitles:

Source = ssifSource (avc264 = SAVC, mvc264 = SMVC, frame_count = FC, use_ldecod = true, swap_views = Swap, horizontal_stack = true)
Source = Blur (Source, 0, 1)
Left = Crop (Source, LC, TC, -RC - 1920, -BC)
Right = Crop (Source, 1920 + LC, TC, -RC, -BC)
Left = SelectEven (SeparateRows (Left, 2))
Right = SelectOdd (SeparateRows (Right, 2))
HOU = StackVertical (Left, Right)
return HOU.Trim (0, FR - 1)
Evidently blurring it before cropping it is the answer, for whatever reason. I don't pretend to understand why since I crop with other plugins first, but since my brain now hurts I'm no longer sure that it matters. It does mean any subtitles I add won't get affected by the blur, but 'eh....

r0lZ

8th June 2014, 15:08

I must admit that I don't understand the problem either. It is very strange, especially that pattern repeated every 30 frames.

When you will have made some more tests, please report if your method with the blur gives better results than the standard method. Thanks in advance.

Thalyn

9th June 2014, 06:37

Well, I've made a bunch of runs so far - 24 titles in all. As I mentioned with my earlier testing on the subject (http://forum.doom9.org/showthread.php?p=1680155#post1680155) it really is very hard to tell, though I do prefer my new approach.

What I can say with absolute certainty is that if you take a 2D stream and split it with the blur, then recombine it as it would appear on an interleaved screen, the results are noticeably better than doing the same with BilinearResize or VerticalReduceBy2. Of course, in that same situation if you don't blur than the results are better still because you're effectively converting from 1080p24 to 1080i48 and back to 1080p24 again.

When you go over to 3D, however, the situation changes. If you don't blur in that situation than it introduces some pretty obvious aliasing. It's still quite watchable and, strictly speaking, does have the "truest" detail retention of them all, but it's just not as good as it could be in playback. Plus if, for whatever reason, you have to watch it back in 2D than it becomes a pretty terrible deinterlaced version of source material that wasn't interlaced to begin with. Comparing the Blur to the Resize, however, isn't so clear-cut in the differences.

Chiefly I need a second set of eyes on it so I can rule out personal bias. I've uploaded 119 seconds (01:49:58.59-01:51:57.59 - I actually asked for 2 minutes from 01:50:00, but 'eh) of The Avengers with both methods if you want to take a look - it's got some high contrast bits, some fast action bits, some slow bits, some small bits, some fine detail, some straight lines, some Scarlett Johansson... hopefully enough to make a decent evaluation. The only difference between the two is the method used to resize the frames for half over/under storage and how x264 subsequently reacted to that change.

BilinearResize (X, Y / 2) (https://mega.co.nz/#!5l1inJAB!Ktg1oLnBitSevB4X9dtte07HUp5Do92mCWtzQ3Q8zWs) (113.2MB)
Select (SeparateRows (Blur (0, 1), 2)) (https://mega.co.nz/#!ho1giYqZ!D_HliCgftIuHKqAc539ZyGDUMZ7F_uOo8F2YTcy4cGE) (117.6MB)

Fair warning: These clips open with an immediate burst of static-like noise from the lead-up, so you might want to dial back the volume before playing them for the sake of your ears and equipment. It's not that loud (there's louder in the clip) but it could be an unwelcome surprise.

r0lZ

9th June 2014, 09:32

Thanks. And is it a noticeable speed difference when encoding with the standard and your methods?

Thalyn

9th June 2014, 10:15

Depends on the stream. That one, for example, was 19.84fps vs 18.93fps in favour of a traditional bilinear resize. The Adventures of Tintin, on the other hand, was 23.41fps vs 23.74fps in favour of the blur. Generally, however, it is the slower option by a small margin.

Overall video bitrate for The Avengers was 3898kbps vs 4056kbps with the bilinear being smaller, and that seems to be a common trend for the 24 I've done so far. Blurring has never been a huge amount larger, but it is always larger (usually within 100-200MB on files between 3GB and 4GB).

r0lZ

9th June 2014, 10:34

Interesting. I don't have a TV compatible with your method, so I can't test it myself, but I appreciate your finding. Unfortunately, it seems too complicated to add your method as an option in BD3D2MK3D, because it is totally different than the methods currently implemented, and I don't know how many peoples would be interested. Anyway, obviously, you don't need an automated tool to do it yourself!

Thalyn

9th June 2014, 10:56

Strange. That should be a stock-standard half over/under video. It's not cropped in any way since the original didn't have any letterboxing to speak of. Though it's possible the AVC settings I've used just aren't compatible (4 keyframes, 6 B-frames, CABAC, etc etc). It should play through pretty much any software player, though, if you've got facilities to connect a PC to your screen.

Otherwise, if you can provide me with some x264 settings that work with your setup I can run some streams through for you to evaluate.

r0lZ

9th June 2014, 11:20

Oh, sorry. I can see your files on my PC without problem, but if I understand correctly your idea, your method should give better results on a 1080p 3D passive screen with row-based separation. When it's not the case, the standard method (based on the resize) should give better results anyway, no?

Thalyn

9th June 2014, 11:43

Ahh. Yeah, theoretically (at least, according to the rumblings in my head) it should yield better results on am passive screen almost every time. The rest of the time it shouldn't look any worse, at least, which is why I'm re-doing all of my stuff without any real concern.

The only real testing field I have is my PC, which is attached to an AOC D2757Ph. I know a guy with a 120Hz PC setup but I haven't had a chance to see him in a while.

Thalyn

10th June 2014, 05:38

Uuuuurgh! Brain!

Even with only applying the Blur once using Slavanap's plugin, it's not right. The AVC and MVC stream are briefly getting out of sync, but there doesn't appear to be any rhyme or reason to it unlike blurring each stream separately. What's even worse is that they appear to be getting out of sync with themselves, too - I'm looking at a frame right now where the AVC and MVC stream have gotten one frame out of sync, but the MVC stream is also "tearing" between two frames (changing frames mid-refresh) towards the top. A slightly later frame is even worse as it appears that the new input to the MVC stream has actually changed frame part way through a scanline!

The only commonality between each incidence is that the MVC frame seems to be the one struggling the most, which would also be the lower frame. There is no common period between the errors, at least as far as frame count is concerned, nor is there solid commonality as to the duration of the issue (I'm seeing anything from 1 to about 4 frames) or even the location of the tearing when it's visible. After the issue it resumes as if nothing has ever happened, but I've seen gaps as small as 3 frames separating problems out to about 27.

The AVC/upper frame looks to be behaving perfectly with no skipped or torn frames, at least.

I don't pretend to understand why, but ssifSource (currently) just isn't compatible with the Blur command, pretty much regardless of when you use it.

*Ed Just for emphasis, I'm not saying there's specifically a problem with ssifSource. I've used it before with great success. It's only when used in tandem with the Blur command that there's a problem, so I'm likely to be the only person it affects in any way, shape or form.

*Ed2: A thought occurs. How difficult would it be to either A: including a frame-sequential option for ssifSource's output, or B: configure it so that, instead of returning a single stream (eg: Source = ssifSource (whatever)), it can return two streams (ssifSource (Left, Right, whatever))? It may not help so if it's difficult or tedious than it's not worth it, but you never know for sure...

r0lZ

10th June 2014, 09:44

Damn, it's really strange!
Have you tried with GDMVCSource and FRIMSource? It may be interesting to know if the same problem occurs also. Or is it a reason to use only or preferably ssifSource?

Thalyn

10th June 2014, 16:02

Both DGMVC and FRIM work just fine and dandy with my script, which is why I'm wondering about the possibility of sequential feedback from ssifSource. I wouldn't have even bothered pursuing it at all if I'd never gotten it to work, after all. The basic script (paraphrased) I use for those is as follows:

Source = plugin (gubbins)
Crop (Source, left, top, right, bottom)
Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = SelectEven (SeparateRows (Blur (Left, 0, 1), 2))
Right = SelectOdd (SeparateRows (Blur (Right, 0, 1), 2))
Return StackVertical (Left, Right)

And, yes, you're seeing correctly - I'm splitting the frames via Select twice in there. Crop first since it's sequential, then I split them to break the sequential into individual AVC/MVC streams. Following that, they're blurred, broken up into scanlines and then half of those are discarded. Subtitles go in between the first Select and the second one so they get blurred as well, plus I can apply an offset to each stream separately.

*ed: The example I posted earlier from The Avengers was made using DGMVCSource, both for BilinearResizing and Blurring. Unless I've lost what's left of my mind, those both work equally well as each other.... don't they?

Problem is, I own two movies that don't work with either of those plugins. Pacific Rim, as expected, and Escape from Planet Earth (which I have still never gotten to work with DGMVC or FRIM). They do, however, work perfectly with ssifSource 4 - Escape regardless of which decoder I use, and Pacific Rim so long as I use the JM decoder. Other than those two I use predominately DGMVC simply in the interest of speed (hardware decoding is hard to beat).

r0lZ

10th June 2014, 16:52

OK, it's only for the possibility to decode Pacific Rim and Escape without the infamous Intel bug that you need ssifSource. I wondered if it was for another reason, related to your method.

BTW, thanks to remind me that Escape from Planet Earth is also a "problematic 3DBD". We tend to forget it and to consider that the Intel decoder bug affects only a single movie, and therefore that it is not really important.

Thalyn

10th June 2014, 17:04

The effect on Escape is a bit hit and miss. I've been able to reproduce it each and every single time using the two other Intel decoders, but Neuron2 (DGMVC) hasn't ever had it happen. I'm not sure whether Videofan3d (FRIM) has managed to reproduce it either, but they always seemed more focussed on the encoding side of things rather than the decoding so I'm really not sure.

Even more interestingly, it works fine in ssifSource 4 through its Intel path. But I believe it uses 1.6 at all times, where the other 2 will use 1.8 in software mode and 1.7 in hardware.

r0lZ

10th June 2014, 17:26

slavanap

10th June 2014, 21:09

Thalyn,
Looks like functions SeparateColumns / SeparateRows were added in AviSynth 2.60. Which version of AviSynth do you use? AviSynth 2.60 Alpha #?
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

P.S. As for me, I use 2.58 (2.5.8.5).

ADD: My bad. Sorry. Twice frame acquiring fix wasn't done properly. Trying to fix it right now. (Tested with 2.6.0.4)

ADD2: Here's the fix (http://forum.doom9.org/showthread.php?p=1683660#post1683660).
Just replace the dll.

PPS. for some reason I've noticed decoding problems with ldecod at secondary ssif file (00005.ssif) in Avatar disc. Be careful using it. The problem I've noticed is that only half of frame changes when next frame is decoded (only in the beginning of the sequence (first 30 frames), not related to SeparateRows). Looks like this (http://postimg.org/image/80clpyrq3/), appears randomly and only in first 2 seconds (tested 10 times), only for ldecod. The bottom part of mvc view is the part of next frame.

Thalyn

12th June 2014, 06:00

So, you are not sure that it's the Intel bug that affects Escape? As far as I know, all versions of the Intel library have the same bug, at least with Pacific Rim. Unfortunately, I don't have the Escape BD to test it myself.

I can't say it with absolute certainty, no. I know I can reproduce it every time with ease, regardless of whether I use FRIM or DGMVC, or what version (until I go far enough back that they stall at the frame which otherwise causes errors), but if memory serves correctly Neuron2 wasn't ever able to reproduce it. I'd put it down to my Haswell except it persists with those plugins using software, but that doesn't discount the possibility that it's Win8 causing it (or at least contributing).

Thalyn,
Looks like functions SeparateColumns / SeparateRows were added in AviSynth 2.60. Which version of AviSynth do you use? AviSynth 2.60 Alpha #?
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

P.S. As for me, I use 2.58 (2.5.8.5).
I'm using 2.60 Alpha 4, but you can get the same result in 2.5.8 release using SeparateFields instead. The only difference there is the requirement to specify AssumeTFF before using SeparateFields, and obviously dropping off the ", 2" parameter. My first instinct was to make sure it worked with the release version in case something stupid was going on with the Alpha.

Testing out the fix now. Will edit this briefly with results.

*Ed: I have good news, bad news and, as always, confusing news.

The good news is that I'm no longer getting the green frames at all. I've tried blurring both before and after splitting, as well as both horizontal and vertical stacking.

The bad news, though, is that I'm observing exactly the same thing you were on Avatar (which is the same basic issue I mentioned earlier when blurring before splitting); only with ldecod as you mention (IM works fine). I've tried stripping out the blur since that caused problems before but it seems that doesn't do anything this time around. Unlike Avatar, though, I'm noticing it sporadically as far in as the 2-minute mark. In case it's relevant, I'm working from raw h.264 streams and not the ssif file.

The confusing part, though, is that while Escape only shows it on the MVC stream, Pacific Rim shows it on both streams. And when I say "both" I don't mean just that the MVC frame is just being distorted as a result of the AVC stream decoding incorrectly, but rather that it's adding additional distortion of its own on top of that. Unfortunately, while I can use the IM path for Escape I can't use it for Pacific Rim.

If it were a videogame I'd suggest enabling V-sync, but I have no idea if ldecod includes that kind of facility - or why it wouldn't have it on by default when it's serving up a stream frame-by-frame. The plot thickens...

slavanap

12th June 2014, 23:43

Nico8583

13th June 2014, 10:09

So if I understand, ldecod can decode properly Pacific Rim ? It uses also Intel Media SDK or is it a standalone filter ?

Thalyn

13th June 2014, 13:22

Thalyn,
My bad again (forgot about thread synchronization objects' initial status; need to stop programming at night..).
ldecod works perfect, it wasn't the cause of that artifact.
http://sendfile.su/990052

@all,
Is there any sample, ldecod can't handle? I've heard "Coraline" may have one. Can anyone confirm?

Had an unexpectedly long day today so I'm only just getting a chance to test it out now. Initial results are promising - very promising. I'll have to do some full runs to be sure but I think you've got a keeper here.

:thanks:

I'll be honest in that I'm not sure if there's anything that ldecod can't do, mostly because it's my "backup" transcoder for when IM fails as hardware IM used to be a lot faster. However, I can start running some tests if you'd like (I've still got another ~36 movies to go in 3D) - both for compatibility testing and to see how the speeds stack up these days.

So if I understand, ldecod can decode properly Pacific Rim ? It uses also Intel Media SDK or is it a standalone filter ?

Last time I tried it (which is before I started messing around with my new frame packing technique), Pacific Rim worked perfectly with ldecod via ssifSource4 - not even a hint of the issue IM decoders experience. I'll be able to let you know tomorrow for certain whether that's still the case.

My understanding is that ldecod is a different filter. I believe it's based on the JM Software SDK (currently v18.6) but Slavanap will know more about it than I do.

r0lZ

13th June 2014, 14:20

Yes, ldecod is the first decoder that has been freely available, long before the Intel SDK has been released. It is terribly slow, but afaik, it has always worked perfectly. I don't know if someone has tested it with Pacific Rim though.

Sharc

13th June 2014, 14:38

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

Sharc

13th June 2014, 15:10

There seems to be a new release of Intel SDK (https://software.intel.com/en-us/forums/topic/516395)

r0lZ

13th June 2014, 15:20

r0lZ

13th June 2014, 15:24

There seems to be a new release of Intel SDK (https://software.intel.com/en-us/forums/topic/516395)
Yes, it is already included in the latest version of BD3D2MK3D:
# v0.37 (June 3, 2014)
[...]
# - Updated the Intel MVC decoder library to the latest version (libmfxsw32.dll v5.14.4.28)
Unfortunately, the latest Intel decoder doesn't fix the Pacific Rim bug.

Thalyn

13th June 2014, 17:46

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

As much as I trust that Videofan3d was indeed able to get the error mentioned in that post, I can't verify it myself. Not only do I not get the error about allocation, but the frames mentioned rendered perfectly. I just double-checked the transcode I did last time with ssifSource 4.4 via the ldecod pathway and saw nothing out of the ordinary.

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.

Interesting to note about the newer SDK, though. I wonder what that might do in tandem with the newer HD/Iris drivers (v15.33.22.3621, released May 21st) for hardware decoding..?

r0lZ

13th June 2014, 18:11

AFAIK, there is nothing new in the MVC decoder part.

Extract from the release notes:

Intel ® Media SDK 2014 R2 introduces API version 1.9. This version is backwards
compatible with the previous API version 1.8.

API version 1.9 introduces the following major features:

Four new fourCC codes for color format were added:
MFX_FOURCC_P010 and MFX_FOURCC_A2RGB10 to support HEVC MAIN10
profile decoding and VPP resize and color conversion in 10-bit format.
MFX_FOURCC_A2RGB10 is specifically required for rendering on a 10 bit-
display. Microsoft* DirectX* equivalent of MFX_FOURCC_P010 format is
currently not supported in Intel display drivers.
MFX_FOURCC_ARGB16 and MFX_FOURCC_R16 to support Intel® Media
SDK Professional Camera Pack product. Please refer to Intel Media
Solutions Portal for more details about this product.

mfxFrameInfo structure was extended with controls for bit depth and shift
which defines values alignment.
VPP composition alpha blending support.
At the moment of this release this feature is supported only by Intel ® Media
SDK for Linux* Servers product.
AVC skip frame control which forces skipped frame encoding.
At the moment of this release this feature is supported only by hardware
implementations of Intel Media SDK Library coming with Intel ® Iris TM and HD
Graphics Driver for Microsoft Windows* 7/8/8.1 on platforms listed below in
System Requirements section.
AVC slice size limitation control.
At the moment of this release this feature is not supported by any
implementation of Intel Media SDK Library.
New mfxExtAVCRefLists extended buffer which allows application to manage
reference lists.
New plugin GUIDs definitions were added to mfxplugin.h:
MFX_PLUGINID_VP8D_HW and MFX_PLUGINID_HEVCD_HW: for hardware
accelerated HEVC and VP8* decoder plugins which will be distributed
as default plugins with graphics driver along with hardware
implementation of Intel ® Media SDK library. These components are not
available in existing platforms and will be added in future.
MFX_PLUGINID_CAMERA_HW: for Intel ® Media SDK Professional Camera
Pack.

Additionally, dispatcher source code was updated with capabilities of default plugin
loading, fixes for handling plugin version vs. library version during plugin loading and
for compilation under MinGW* environment.

Please note that all the new APIs listed above are not supported by software
implementation of Intel Media SDK Library, with exceptions for VPP resize in P010
format and VPP color conversions P010->A2RGB10 and P010->NV12.

In a particular platform specific hardware implementation of Intel Media SDK Library
some of the features may also be unsupported. Make sure to call Query functions to
check the actual support.

I don't know if there is a more detailed release notes file somewhere, but it is not included in the pack.

Guest

13th June 2014, 18:36

Thanks for that. Nothing in there to justify doing anything with my source filters. :(

r0lZ

13th June 2014, 22:50

I agree. I have just updated the Intel DLL, and your Source filter works as expected, without any visible modification.

Thalyn

14th June 2014, 05:17

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.
Just following up on this: ssifSource 4.44c (the 3rd hotfix - not sure what Slavanap calls it internally) using the ldecod path worked just fine. No errors in the first 200 frames, no sign of either of the two well-documented IM errors and sound sync persists until at least the last possible point to check it.

Speed is fairly pedestrian compared to IM, but may prove to be a necessary evil on occasion. PR, for example, processed at 11.47fps overall, while Escape managed a slightly better 12.93fps. None of my IM-sourced transcodes have gone even close to that slow so far - high teens is about the lowest I see from it, and it's normally closer to realtime.

However, I cannot pin that speed down entirely on the use of ldecod. Since I'm not using a pre-combined stream it's possible the act of piping it has an adverse effect on speed, plus the dependence on the external MVCCombine executable of unknown optimisation.

Sadly, however, I can only confirm the speculations with regards to the new IM dlls. Minor fixes like what we need are rarely documented properly but I've been unable to tell any difference between the results of the older and newer dlls, whether using hardware or software.

slavanap

14th June 2014, 20:47

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

Just tested (http://sendfile.su/990659) this source with ssifSource4 Intel & ldecode,
Intel returned 211 frames, ldecode -- 234 frames. Where's the decoding errors?

Had an unexpectedly long day today so I'm only just getting a chance to test it out now. Initial results are promising - very promising. I'll have to do some full runs to be sure but I think you've got a keeper here.
Thank you for kind words! :)

I believe it's based on the JM Software SDK (currently v18.6) but Slavanap will know more about it than I do.
I've just compiled the source from here (http://iphome.hhi.de/suehring/tml/download/) with minor changes (about 10 lines of code) to speed up a decoding a bit (that's all I can without understanding the whole source code) and one bugfix because of what ldecod might crash with 'access violation' error.

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.
Nope, there's the latest JM18.6 version in the package.

Just following up on this: ssifSource 4.44c (the 3rd hotfix - not sure what Slavanap calls it internally) using the ldecod path worked just fine. No errors in the first 200 frames, no sign of either of the two well-documented IM errors and sound sync persists until at least the last possible point to check it.

Speed is fairly pedestrian compared to IM, but may prove to be a necessary evil on occasion. PR, for example, processed at 11.47fps overall, while Escape managed a slightly better 12.93fps. None of my IM-sourced transcodes have gone even close to that slow so far - high teens is about the lowest I see from it, and it's normally closer to realtime.

However, I cannot pin that speed down entirely on the use of ldecod. Since I'm not using a pre-combined stream it's possible the act of piping it has an adverse effect on speed, plus the dependence on the external MVCCombine executable of unknown optimisation.

Intel decoder is slow in the ssifSource4...(whatever) package because it is just a compiled binary from Intel Media SDK samples. It HAS NOT been optimized in any sense (looks like some student wrote it). Both decoders Intel & ldecod MAY be optimized a far more, but I haven't enough free time to read and understand their code entirely. Pipes mechanism is fast enough to support realtime playback, but the decoders code mostly use only single CPU core (and, of course, it doesn't use the GPU). That's why they are a bottleneck here.

r0lZ

14th June 2014, 21:19

How did you the Intel test? With ssifsource4 w/o hardware acceleration? The result seems bug-free.
For the number of frames, I don't know. Have you tried to examine the input clip with MediaInfo?

slavanap

14th June 2014, 21:51

Just fixed ldecod to handle sequence from Ice Age 4 properly (Intel handled it well already, but ldecod failed with "max_dec_frame_buffering larger than MaxDpbSize" error message).
http://sendfile.su/990671.
Of course it's experimental. Any videos (with same level_idc = 41) may fail now.

(let it be another ssifSource4 patch 4.44d)

slavanap

15th June 2014, 08:13

How did you the Intel test? With ssifsource4 w/o hardware acceleration? The result seems bug-free.
For the number of frames, I don't know. Have you tried to examine the input clip with MediaInfo?

Yes, with ssifSource4, Intel decoder without hardware acceleration and with "-d3d" option. Unfortunately, I have a version of MediaInfo without top menu, and it doesn't show the framecount. AVC source is about 9 sec. long - that's all I know.

r0lZ

15th June 2014, 09:40

If you demux it with tsMuxeR, it will tell you the exact number of frames.

r0lZ

18th June 2014, 09:42

# v0.38 (June 18, 2014)
# - Added Tools -> Verify 3D-planes compatibility to show info about the undefined Depth values in the 3D-planes for a particular subtitle stream.
# - Fix: Tools -> Convert Subtitles to 3D (with 3D-Plane) bug when verifying the output file extension.
# - Fix: Added vcomp100.dll (from the ImageMagick package), needed on some systems to convert the subtitles to 3D.
# - Added Tools -> MkvMerge GUI to open MMG.exe easily from BD3D2MK3D.
# - Updated MkvMerge to the latest version (and added MMG.exe in the toolset folder)

Mainly a bug fix release, but there is also a new function that you can use if you need to convert a subtitle to 3D and you don't know what 3D-plane to use. The new function checks if all 3D-plane files from a specific directory have valid depth values for all frames during which the subtitles of the specified subtitle file are displayed. For best results, you should select the 3D-plane with the lowest number of undefined depth values. (Of course, if the subtitle file comes from the BD itself, you should select the 3D-plane associated with it, except if that 3D-plane has been obviously badly authored.)

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

Privateer5000

18th June 2014, 17:38

@r0lZ

wrong Download-Link

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

r0lZ

18th June 2014, 17:47

Damn, it's not the first time! :-(
Link fixed. Thanks!

slavanap

19th June 2014, 12:55

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

Well tsMuxer reports about 238 frames. ldecod: 234, Intel: 211.
Decoding results are here (http://sendfile.su/990659). I haven't noticed any artifacts reported in this (http://forum.doom9.org/showthread.php?p=1666387#post1666387) post.

Looks like ldecod can decode anything for me right now.
Does anyone have difficult video sources to prove that?

r0lZ

22nd June 2014, 20:03

# v0.39 (June 22, 2014)
# - New option to hardcode the PGS (BD SUP) subtitles to the video with SupTitle.
# - Fix: Bug when converting subtitles with an original width of 1920 pixels to 3D.
# - Added a warning when BDSup2Sub++ is selected in the Settings menu.
# - Several little bugs fixed.

I have noticed problems with strange subtitles from bad BDs such as "Amphibious 3D". The width of the subtitle is always 1920, and therefore it cannot be moved along the X axis to convert it to 3D. I have added a workaround: the transparent background of the subtitle is now cropped when necessary. But I'm still wondering how the BD players are supposed to display that subtitles in 3D. Is it allowed to use negative X values? Anyway, v0.39 can now handle them correctly.

But when I have analysed that subtitle problem, I have noticed that BDSup2Sub++ has a very big bug. When it imports a XML/PNG subtitle file with a fully transparent border around the subtitle, it crops the useless part of the background, and it is supposed to modify the position in X and Y of the subtitle accordingly. BDSup2Sub.jar does that correctly, but BDSup2Sup++ fails miserably, and creates crazy, extremely high X and Y values. Therefore, I highly recommend to use only the java version of BDSup2Sub! Since the ++ version was the default in the old versions of DB3D2MK3D, the users of the old versions should change that setting in the Settings menu. (Now, the java version is the default except when the program detects that java is not installed, and a warning is displayed when the user changes it to use the ++ version.) You have to install Java 32-bit on your machine also. Sorry for that.

I have also improved the way the subtitles are hardcoded on the video. Now, it is possible to hardcode the high quality PGS (.SUP) stream with the SupTitle avisynth plugin (http://forum.doom9.org/showthread.php?t=148167), rather than the VobSub (IDX/SUB) file with DirectVobSub. Thanks to Zachs for his permission to distribute his SupTitle plugin with BD3D3MK3D!

As usual, you can download the latest version of BD3D2MK3D here: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

I repeat:
Please use only the java version of BDSup2Sub!
(Change the BDSup2Sub setting in the Settings menu and install java 32-bit if necessary.)

Sharc

25th June 2014, 07:33

sef

25th June 2014, 10:47

I just finished encode Pacific Rim in sbs mode, and I have no artifacts. I used FRIMDeсode.exe and sample_encode.exe (build from source (Video Encoding Sample 5.0.337.78585))..

http://i63.fastpic.ru/big/2014/0626/de/eac545317bc5b8136d94249da1553ade.jpg

http://i64.fastpic.ru/big/2014/0626/78/b2d2105d74fb698cd858b81cb8ba2a78.jpg

MediaInfo:

General
Unique ID : 186770297968183920652343608449373776154 (0x8C82A6A52D61E0298F455D5A676F291A)
Complete name : C:\Users\Sef\Desktop\Pacific Rim.mkv
Format : Matroska
Format version : Version 2
File size : 21.8 GiB
Duration : 2h 11mn
Overall bit rate mode : Constant
Overall bit rate : 23.8 Mbps
Encoded date : UTC 2014-06-25 09:56:10
Writing application : mkvmerge v7.0.0 ('Where We Going') 32bit built on Jun 9 2014 15:08:34
Writing library : libebml v1.3.0 + libmatroska v1.4.1
DURATION : 02:11:16.911000000
NUMBER_OF_FRAMES : 188857
NUMBER_OF_BYTES : 23394039926
_STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 32bit built on Jun 9 2014 15:08:34
_STATISTICS_WRITING_DATE_UTC : 2014-06-25 09:56:10
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 11mn
Bit rate mode : Constant
Bit rate : 24.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.483
Stream size : 21.4 GiB (98%)
Default : Yes
Forced : No

Later, I'll try to use avisynth filters (FRIMSource, DGMVCSource (with Pacific Rim))..

Nico8583

25th June 2014, 11:41

Did anyone try THOR - The Dark Kingdom 3D?
This seems to be another case - like PacificRim - where Intel Decoder fails badly, e.g. the scene between 00:28:00:000 .... 00:29:00:000.
I will do more test when I find some time.
Where have you seen artifacts ? Could you post a screen capture ?
I don't see any artifacts between 00:28:00 and 00:29:00 but perhaps I have not seen...

Sharc

25th June 2014, 17:18

Where have you seen artifacts ? Could you post a screen capture ?
I don't see any artifacts between 00:28:00 and 00:29:00 but perhaps I have not seen...
It's only this single frame:

Nico8583

25th June 2014, 21:22

No problem for me with this frame and DGMVCSource.

Thalyn

26th June 2014, 12:20

Afraid I'm with Nico on this one. Just checked my Thor TDW transcode - if I'm right, the frame you're showing is somewhere during 0:28:44, and I saw no problems. I checked further than that, naturally, but still didn't find anything. Again, though, that was using DGMVCSource.

Your findings are curious, though, Sef. If it works outside of AVISynth, than what the heck is happening inside...?

Sharc

26th June 2014, 18:53

Nico, Thalyn:
Thanks guys for checking. Looks like a bad rip in my case. I'll rip it again and report back.

Edit:
The problem was with the disc. I returned it to the shop and got a replacement which is fine now.

sef

26th June 2014, 20:18

..If it works outside of AVISynth, than what the heck is happening inside...?

And who knows.. :( (Maybe it takes place during the transition between layers on Blue Ray disc?)..

frank

26th June 2014, 21:05

Hello r0lZ,
nice to see you here. It's been a long time that we worked on PgcEdit... :D
Now I'm a 3D-Fan, especially for the passive, polarized system (3D-TAB).
Your BD3D2MK3D is a very good tool, and I wish you could make your own thread for it. This thread is large and too general.

You can reduce a lot of memory and time without demuxing the huge video-streams from BD.
I modified _ENCODE_3D_MOVIE.avs using FRIMSource():

FRIMSource("mvc", "G:\BDMV\STREAM\00000.m2ts", "G:\BDMV\STREAM\00001.m2ts", num_frames = 159021, cache = 2, ts=true)

It workes very well.

What do you think about extending BD3D2MK3D to the 3rd option: Blu-ray 3D encoding with FRIMencode() to BD or MKV3D.
Now MakeMKV can generate stereo MKVs (mkv standard compliant) from BD3D and Stereoscopic Player plays it well.
The development goes ahead...

Nico8583

26th June 2014, 21:16

Just a little thing : with FRIMSource, how do you do with multiple M2TS stream (like Disney) ?

Guest

26th June 2014, 21:25

You should be able to do copy /b in a DOS window if nothing else.

Nico8583

26th June 2014, 22:29

I don't think it's so easy :-/ (I believe I've read something about it) and IMHO there is no interest to create a single M2TS with copy instead of demux it, no ?

r0lZ

27th June 2014, 07:19

Hi Frank!

There are several drawbacks if we decide to use the M2TS without demuxing.

First, afaik, as noted by Nico, there is no way to process a MPLS file, and therefore no way to process the titles made of several parts. OK, there are probably some methods that could work, like the one suggested by Neuron2, but the point is to save some time and disc space, so joining the files is not a good idea imo. It should be possible to process each M2TS file independently, with several FRIMSource commands, but the previous versions of BD3D2MK3D used that trick with ssifSource, and we know that it was very difficult to start the encoding due to timeout problems when avisynth initializes all ssifSource commands at the same time. I guess we'll have the same problem with FRIMSource.

It is also difficult and slow to encode directly from a physical blu-ray disc, because the BD players are slow and noisy. The disc can also become very hot if it has to spin in the drive during hours. OK, some peoples encode from a mounted ISO, but I can't exclude the fact that many peoples use the original BD decoded on the fly by AnyDVD HD.

Also, I need to demux the audio and subtitle streams anyway (to convert them when necessary) and I need to count the number of frames during the demux process, so the demux phase cannot be completely avoided.

If you want to convert the subtitles to 3D, BD3D2MK3D needs to extract the 3D-planes from the MVC stream, and currently it can do that only if the MVC stream has been previously demuxed.

I prefer also to copy all necessary files in one directory, because the user can launch the encode at any time, without having to be sure that the BD is still in the drive or the ISO is still mounted.

Only FRIMSource can decode the M2TS files directly, and currently I have a little preference for DGMVCSource. (I have had a problem that I have never reported here with FRIMSource and a specific BD. It was unable to decode or serve the last frames of the movie and therefore the avisynth script was stopped waiting indefinitely for FRIMSource to finish its job. DGMVCSource doesn't have that problem.)

Also, currently, I don't know how to know for sure what MVC MPLS corresponds to the AVC MPLS. To determine what MPLS is probably the dependent view, I use the file sizes. The size of the AVC MPLS + the size of the MVC MPLS must be equal to the size of the SSIF. That simple trick works well most if the times, but I cannot exclude the fact that it is not impossible to have several MPLS files that have exactly the same size, and therefore I will not be able to determine for sure which one must be used.

Would it be useful to add an option to use the direct method but if that method is used only when FRIMSource is selected and not DGMVCSource, and when the movie is made of a single file, and when the user has not selected any subtitle stream or when the option to convert it to 3D is not used, and when the program can determine what MPLS file contains the MVC stream? If all these conditions are met, I should be able to use your method. The demux process will have to be done anyway, but it will probably be somewhat faster because there is much less data to write to HDD. I can add that option if you wish, but honestly I think it's just another option that very few peoples will use and that will make the GUI even more complicated.

I agree that I should start a new thread for BD3D2MK3D. I did not want to do it before because the program was still somewhat unstable, and the info about the 3D conversion was centralised in this thread, but now, with DGMVCSource and FRIMSource, we have a very stable method and imo my program is mature enough to have its own thread. I'll create it when a new version will be ready...

r0lZ

27th June 2014, 07:31

What do you think about extending BD3D2MK3D to the 3rd option: Blu-ray 3D encoding with FRIMencode() to BD or MKV3D.
Now MakeMKV can generate stereo MKVs (mkv standard compliant) from BD3D and Stereoscopic Player plays it well.
The development goes ahead...
Well, I don't think I'll do that. The point of my program is to convert a 3D BD to SBS or T&B, and you are free to burn the resulting 3D MKV on a BD or DVD to play it with your BD player if you wish. If you want to copy a BD 3D to a BD 3D, you should use a BD copier or BD Rebuilder.

I will think about the possibility to encode to MK3D with FRIMencode, but afaik currently there is only very limited support for that format (except stereoscopic player) and therefore don't expect that soon. When enough 3D TVs and BD players will support that format, I will probably add that option...

frank

27th June 2014, 15:45

Thank you for your very detailed explanation. You've convinced me. mpls and subs operations need MVC.
And in that special case where demuxing isn't needed I can easy modify the script.
Uh, it's time to buy a new disk...

I wait with joy on your new BD3D2MK3D thread. :)

Thalyn

27th June 2014, 16:48

And who knows.. :( (Maybe it takes place during the transition between layers on Blue Ray disc?)..
I've always worked from files on my harddrive - plus I've tried a few different extraction methods (tsMuxer, eac3to, MakeMKV, etc). It's possible the layer transition still has some kind of residual effect on the data (a "layer change here!" flag that the AVISynth plugins don't like, for example), and both issues present in kinda the right place to be as a result of a layer change, but it's definitely weird.

Though that does remind me... I should grab a new nightly of Handbrake and try their QuickSync path again on it. If you use QSV encoding you can also use QSV decoding, instead of just DXVA, which I've used in the past to give the same error on just the AVC stream. That was a fairly early QSV implementation I tried last time, though, so maybe they've been able to solve it.

slavanap

28th June 2014, 03:08

First, afaik, as noted by Nico, there is no way to process a MPLS file, and therefore no way to process the titles made of several parts. OK, there are probably some methods that could work, like the one suggested by Neuron2, but the point is to save some time and disc space, so joining the files is not a good idea imo. It should be possible to process each M2TS file independently, with several FRIMSource commands, but the previous versions of BD3D2MK3D used that trick with ssifSource, and we know that it was very difficult to start the encoding due to timeout problems when avisynth initializes all ssifSource commands at the same time. I guess we'll have the same problem with FRIMSource.

Have you tried mplsSource function from the latest ssifSource4 plugin? It can glue all ssif parts without going out of memory.
Nevertheless, I admit, ssifSource4 is slow enough itself and audio processing need to be done separately, but I'm going to fix these issues.

r0lZ

28th June 2014, 05:53

Yes, I know that your tool can join the parts, but BD3D2MK3D uses DGMVCSource or FRIMSource, and not ssifSource. (I may add it later if it's necessary to process "difficult" BDs like Pacific Rim, but currently, its syntax and usage is too different from the two other methods to be easily integrated. I don't want to multiply the different methods in the same GUI.)

And I think the problem with the previous versions was not related to the memory, but to timeout issues. When a script starts, all Source commands must be executed, even if they are chained together to source different parts of a long clip, because the script has to know the total number of frames and it must verify the compatibility of the different parts (and it must probably do other things as well). Since these commands require some time to initialize themselves, when the MPLS has hundreds of SSIF parts, the script takes to long to start, and an error occurs. Maybe it's also related to the memory, I don't know, but IMO fixing memory problems may not be sufficient. Anyway, I wish you good luck with the current developments of ssifSource4. Thanks for your continuous efforts.

frencher

30th June 2014, 21:37

L'Extravagant voyage du jeune et prodigieux T.S. Spivet (perpetual movement) (http://www.allocine.fr/video/player_gen_cmedia=19537596&cfilm=199842.html)
La 3D relief vue par Jean-Pierre Jeunet (http://www.allocine.fr/personne/fichepersonne-2123/interviews/?cmedia=19538441)

r0lZ

30th June 2014, 21:52

Why do you post these links?

BTW, I like very much the films by Jean-Pierre Jeunet, but T.S. Spivet is not particularly good, perhaps because it's an American film, and he has not been free to do what he wants really. However, his conception of the 3D is the best I've seen in a movie. Nicely done and very original.

frencher

30th June 2014, 23:04

r0lZ it's just a really movie shot in 3D and can be used for comparison with 3D fake ex: World War Z
How did you get the 3D effect in this film?

r0lZ

1st July 2014, 08:43

Ah, OK.

As I said, I like the 3D in that film. It is much more intelligent than in most (all?) other 3D films. For example, when T.S. Spivet imagines a new invention, the engine appears as an independent object in 3D, in front of the screen. It's exactly that kind of idea that I like in all films by Jeunet (except in Alien 4, another minor US film), and he has nicely adapted his world to the 3D. I like also very much the fact that Jeunet is a perfectionist, as in all his films, and he has shot the movie with the quality of the 3D in mind. IMO, it's the best 3D movie so far, perhaps with Hugo Cabret by Martin Scorsese. (I like that one for the marvellous scenes in the big clock, really spectacular in 3D.)

I don't like much the US blockbusters like Pacific Rim or Hansel & Gretel, shot with boxing gloves, without any imagination, and obviously made only to make money. The 3D is mainly fake (conversion), except in the scenes with a lot of computer graphics. In that kind of films, the 3D is mainly a commercial argument. And that works! I have watched that films in 3D, even if I don't like them! ;-)

And of course, I don't like the conversions like what they did with Jurassic Park or Titanic. They are not bad films, but they have not been shot in 3D, and the post-process to convert them to 3D cannot be completely satisfactory.

In fact, my real interest for the 3D comes from the animation. I love animation, and I have worked on some animated movies and TV series in computer graphics in the past (before the 3D fashion). Of course, in computer animation like the Pixar movies, all difficulties related to the 3D cameras are inexistent, and the result is marvellous. There are so many 3D animated movies that I love that I can't quote them all.

Note: For the English peoples here, the name of the movie by Jeunet is, in English, The Young and Prodigious T.S. Spivet (http://www.imdb.com/title/tt1981107/). It's his second US film, after Alien 4. IMO, Jeunet is much more creative when he has the freedom of a French production than in the US environment, where producers are real censors. Despite being a minor film, T.S. Spivet is a good example of what should be a film in 3D.

frank

1st July 2014, 12:01

Oh, Hitchcock's Dial M for Murder 1954 3D, a masterpiece for such an old movie.
---

In latest BD3D2MK3D v0.39 you cannot select BDSup2Sub.jar anymore.:scared:
One option is greyed out. If you change the .ini then you can work with Java but the creation of subs fails.

> "" -Xmx256m -jar "C:\\Users\\Chef\\BD3D2MK3D\\toolset\\BDSup2Sub.jar"
"C:\Users\Chef\Videos\movie 3D\00000_mpls\00000.track_4608.Ger.sup"
-o "C:/Users/Chef/Videos/movie 3D/00000_mpls/00000.track_4608.Ger_forced.3D_2D/temp_2D.xml"
--palette-mode keep --minimum-time 1 --convert-fps 24p,24p
*** BDSup2Sub open error: couldn't execute "": no such file or directory
BD3D2MK3D console shows:
"C:\\Windows\\System32\\java.exe"
That's wrong.

Old v0.38 works.

Win7 x64, Java 1.7 b60 32bit

r0lZ

1st July 2014, 14:01

I agree for the Hitch, but the BD 3D is terrible! The quality of the picture is horrible. I prefer the 2D version with a crisp picture.

I will have a look for the Java bug. Normally, the program tries to determine the java path automatically, but it may fail if you are running a 64-bit Windows. The program requires the 32-bit version of java. I suppose it's the problem, because system32, despite its name, holds only 64-bit programs and DLLs. The 32-bit version should be in SYSWOW64 or in "Program Files (x86)".

Can you open the console (from the File menu) and type (case sensitive):

JavaVersion false true

It should reply with a dialog, and print the path of your java.exe in the console. I guess it will find nothing, because only the 32-bit version of Java is installed.

It's strange if it works with the v0.38. Are you sure you haven't uninstalled the 32-bit version? Anyway, I will have a look.

Thanks for the bug report.

frank

1st July 2014, 14:34

BD3D2MK3D v0.39 console shows indeed
C:\Windows\System32\java.exe
but that is a fake.
The v0.38 console shows the same wrong path.

The java.exe (x86) actually lies in
Program Files (x86)\Java\jre7\bin and in SysWOW64.

Maybe there is a Registry problem. I have deinstalled Java x64 some time ago.
But v0.38 works, then there must be a path problem.

r0lZ

1st July 2014, 15:59

Since BD3D2MK3D is a 32-bit app, it sees the 32-bit system files in system32, although the real path is SYSWOW64. The 64-bit programs, on the other hand, see the 64-bit system files in system32, and the 32-bit files in SYSWOW64, as they are really. So, BD3D2MK3D displays the correct path, from his point of view. (It doesn't see java.exe in Program Files (x86) probably because that directory is not in the system path.) To see the right paths, you have to use a 32-bit program (such as cmd.exe from the SYSWOW64 directory). Same thing for the registry editor. If you use regedit.exe, you'll see the registry for the 64-bit programs, irrelevant for BD3D2MK3D. That's horribly complex, but he, it's Microsoft!

In the config file, there are two settings related to BDSup2Sub.jar:

set ::config(useBDS2Sjava) 1
set ::config(javapath) {C:\Windows\System32\java.exe}

With that settings, it works perfectly on my Win7 x64 with both versions of java installed.

When BD3D2MK3D starts, it checks the values of your config file, and if the javapath doesn't exist, it tries to find it with the DOS command "where java" (executed in a 32-bit shell). If the command returns nothing, it tries to use simply "java.exe" (without any path). Finally, it executes the javapath command with the argument -version. If that command cannot be executed, it assumes that java is not properly installed, and it disables the option to select BDSup2Sub.jar in the settings menu.
IMO, that logic should work, but perhaps there is something special on your system that prevents the java -version command to run.

I will compare the current code with the code of v0.38. Maybe I'll understand what's wrong...