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

View Full Version : Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

slavanap

30th May 2013, 23:33

Can you upload the two exes or give the link to download the previous ssifsource package? I'm not sure I have the correct versions of the exes.

Here it is. The first ssifSource package:
http://sendfile.su/548123

I know. I hate DVDFab's h264 encoder, but the other things it does can be useful.
I installed and used it only to test if its MVC decoding engine has the same bug than CoreAVCDecoder (and also to test if a badly authored Ice Age 3 3DBD could be the culprit). Since DVDFab can correctly decode the MVC stream, I can only deduce that there is a bug in CoreAVCDecoder. However, there must be something strange or new in the Ice Age 3 BD, as all encodings of other 3DBDs I did were successful.

And if you play that with PowerDVD? Or PM me the link to the source, I'll test it.

Slavanap: Given your newest build a bit of a run, but I'll be damned if I can get the auto-detection to work properly. I'm not sure whether it's just not working right with branched movies but I've had all sorts of results from around 100 frames less than there should be to almost 200 more. Not to mention it takes a lot longer to suss it out than DirectShowSource (not the MVC variant) does - many minutes against a second at most, even with only a single source file. This has subsequently limited my testing also of branched sources.
Thaky you for testing. It looks like there is no way to make CoveAVC return correct timings then. I'll make a solution when ssifSource extracts framecount from referenced .m2ts file with DSS2 in new version of ssifSource.
I've now done four titles with this version, including one that froze on the previous release. All have completed successfully and I've seen no issues. I haven't tried the automatic framecounts at all, since I get that information easily from the MPLS. In fact, this release has worked so well that I'm considering using it (replacing DirectshowMVCSource) in the next BD Rebuilder release. I need to do more testing, though.

Thanks.
Thank you for testing!

I'm not using autodetect, so I'm positive the framecounts are correct. I'm not sure why it is going out-of-sync.

I wonder if its possible that the cut points don't necessarily fall on a frame boundary (e.g. the main view of a frame may be in one SSIF and the dependent view in the following)? I noticed that sync was also an issue with DirectshowMVCSource() before I started combining the multiple SSIF files prior to encoding.

@slavanap

Is there a way to simply read the multiple files sequentially as if they were one unit as opposed to specifying a framecount for each file independently?

I actually did it in ssifSource3. If the frames requested sequentially in foreign software, then it requested sequentially in ssifSource2 and ssif files loading/unloading procedure happens only at borders. Could your encoder request frames not sequentially?
Anyway I'll double check it asap. And, because of precise frame detection do not work, there is some code to delete.

As for Intel Decoder solution, I have thoughts about it, just need time to figure out how that decoder works.

jdobbs

31st May 2013, 00:43

I actually did it in ssifSource3. If the frames requested sequentially in foreign software, then it requested sequentially in ssifSource2 and ssif files loading/unloading procedure happens only at borders. Could your encoder request frames not sequentially?
Anyway I'll double check it asap. And, because of precise frame detection do not work, there is some code to delete.Hmm.. I've been using two ssifSource3() statements in an AVISYNTH script to pull in left/right individually. I may try simply pulling them in together horizontally stacked and see if that corrects the sync issues.

slavanap

31st May 2013, 01:51

Hmm.. I've been using two ssifSource3() statements in an AVISYNTH script to pull in left/right individually. I may try simply pulling them in together horizontally stacked and see if that corrects the sync issues.
If this does not solve the issue, then please give me an example to debug it.
http://sendfile.su/819355
I've deleted the seeking solution based on frame timings. Now directshow does all the seeking work.

jdobbs

31st May 2013, 02:30

If this does not solve the issue, then please give me an example to debug it.
http://sendfile.su/819355
I've deleted the seeking solution based on frame timings. Now directshow does all the seeking work.The source I've been using the most in testing is "Toy Story 3D", but I had the same issue with almost every multipart disc.

I'll do the testing tomorrow and let you know how it works out.

r0lZ

31st May 2013, 06:51

Here it is. The first ssifSource package:
http://sendfile.su/548123Thanks!

And if you play that with PowerDVD? Or PM me the link to the source, I'll test it.I don't have (and don't want) PowerDVD.
Anyway, I'm pretty sure now that that specific Ice Age 3 3DBD has a bug in the MVC stream (and perhaps also in some subtitle streams, as you can see here (http://forum.doom9.org/showthread.php?p=1630830#post1630830)).
See your PMs.

As for Intel Decoder solution, I have thoughts about it, just need time to figure out how that decoder works.Very good news! Thanks.

minhjirachi

31st May 2013, 11:14

I have a problem when mount convert the right.h264 to .avi. I open the right.avi, the screen is green from the beginning to the end.

If I mux the right.h264 to .mkv file. The mkv says: "Command line used:

"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" --output-charset UTF-8 --identify-for-mmg "D:\Temp\right.h264"

Output:

Error: File D:\Temp\right.h264 has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly."

So how to fix this problem?

Thank you,

r0lZ

31st May 2013, 11:40

Welcome to Doom9, minhjirachi.

How did you get or encode that right.h264 file? Did you simply demux it? Usually, the right eye view is the MVC stream (dependent view), and it cannot be rendered without the AVC stream (base view). So, you have to either use the left.h264 file, or encode the right.h264 file directly from the 3DBD. It is not sufficient to demux it.

You can encode the MVC stream with DB3D2MK3D. Select the "Monoscopic 2D: Right only" option in the last tab. But IMO, you should encode the left view. It's much more simple, and rapid. And you can mux it directly to MKV (with the audio, subtitles and chapter points) without re-encoding if you double-click the _MUX_2D.cmd file at the end of the DB3D2MK3D process. You can't do that with the right view.

r0lZ

31st May 2013, 12:01

This version contains mainly several workarounds for bugs in third party exes. It fixes also the problem of the inverted left/right views with some BDs.

# v0.18 (March 5, 2013)
# - When encoding with x264 64-bit, 100 frames are now added in the AVS script but not encoded, to avoid x264 crashes in 2-pass mode.
# - When encoding with x264 64-bit, -frames N is now added in the avs2yuv command, to avoid the "wrote only" x264 error message.
# - Removed the contSPS ("Continually insert SPS/PPS") option when muxing the combined.h264 stream to M2TS with tsMuxeR, becauses it causes crashes with some DBs.
# v0.19 (May 30, 2013)
# - Workaround for the inverted left/right views eac3to bug with some 3D titles.
# - Workaround for a BDSup2Sub++ bug when converting SUP with fades to 3D SUBs.
# - The left and right streams are nor correctly handled, thanks to jdobbs.

This version doesn't use the new ssifsource3 command yet. But I have updated the ssifsource2.dll file to the latest ssifsource3 beta. It should work (in ssifsource2 mode), but I haven't tested it.

I'm waiting for a stable version of ssifsource3 to use it in my code. It should fix the problem of the DirectShow timeout with MPLS made of several SSIF files. This version of BD3D2MK3D (v0.19) is therefore probably the last one that will use ssifsource2. Grab it if you want to keep the ssifsource2 support.

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

minhjirachi

31st May 2013, 13:07

minhjirachi

31st May 2013, 15:11

Wolfy59

31st May 2013, 16:09

Hi all. Is it possible to have a little programme that only return which view was the main view and which view is the dependent view just by scanning the 3d bd.
Thanks for all

frencher

31st May 2013, 17:09

As for Intel Decoder solution, I have thoughts about it, just need time to figure out how that decoder works.

It is true that the work would be much easier and am delighted for your interest in the Intel MVC decoding :rolleyes:
Very good news slavanap ;)

minhjirachi

31st May 2013, 18:54

This version contains mainly several workarounds for bugs in third party exes. It fixes also the problem of the inverted left/right views with some BDs.

This version doesn't use the new ssifsource3 command yet. But I have updated the ssifsource2.dll file to the latest ssifsource3 beta. It should work (in ssifsource2 mode), but I haven't tested it.

I'm waiting for a stable version of ssifsource3 to use it in my code. It should fix the problem of the DirectShow timeout with MPLS made of several SSIF files. This version of BD3D2MK3D (v0.19) is therefore probably the last one that will use ssifsource2. Grab it if you want to keep the ssifsource2 support.

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

I don't know why I use your tool. The file .264 is too small (2GB). I don't know because its type or something. I use the clownbd, the file .h264 is very big. It about 8GB. Is it normal? Or is it change the bitrate of the movie?

r0lZ

31st May 2013, 20:55

You're welcome. :-)

minhjirachi

1st June 2013, 02:21

You're welcome. :-)

Can you tell me why it have a different size? Because I want to take the .264 file and mux it to .mkv with the original file size.

r0lZ

1st June 2013, 08:37

Hi all. Is it possible to have a little programme that only return which view was the main view and which view is the dependent view just by scanning the 3d bd.
Thanks for all
BD3D2MK3D v0.19 does it. When you load the BD, it removes the "(left eye)" and "(right eye)" strings from the eac3to output (as they are wrong), but as soon as you click "Get Streams Info" or you go to tab 2, you'll see them again, and they are correct.

Note also that you can find in which M2TS file(s) the AVC and MVC streams are stored with the menu "Tools -> Find dependent-view (MVC) file(s)".

r0lZ

1st June 2013, 08:59

Can you tell me why it have a different size? Because I want to take the .264 file and mux it to .mkv with the original file size.
Oops, sorry, I haven't seen your last replies.

I've explained that the 2nd video stream (usually the right view) is a MVC stream. A 3D BD is made of 2 views. One of the two views (usually the left view) is encoded in h264 "normally". It's the "base view", encoded in AVC (Advanced Video Codec). It's a "standalone" video stream. You can simply extract it from the BD and put it in a MKV container without having to re-encode it, and most players will be able to play it.

In the other hand, the other stream (usually the right view) is the "dependent view", encoded in MVC (Multi-view Video Codec). It contains only the differences between the left and right views. Since it doesn't contain the complete information but just the changes in the right image in comparison to the left image, it can be much more compressed than the AVC view. But that means also that it is totally impossible to play it without the AVC stream. Therefore, it doesn't make sense to store the MVC view only in a MKV (or AVI) container, as no player will be able to play it. If you want to make a video with the MVC stream only, you MUST re-encode it. It's what BD3D2MK3D does when you select "Monoscopic 2D: Dependent view only" as the Stereoscopy mode. The final file size depends of the x264 encoding parameters.

So, either you really want to put the unmodified MVC stream in an AVI container, and it's totally useless as it's not playable, or you must re-encode it from the right AND left views, and the file size will certainly be different than the original MVC stream.

minhjirachi

1st June 2013, 11:02

Oops, sorry, I haven't seen your last replies.

I've explained that the 2nd video stream (usually the right view) is a MVC stream. A 3D BD is made of 2 views. One of the two views (usually the left view) is encoded in h264 "normally". It's the "base view", encoded in AVC (Advanced Video Codec). It's a "standalone" video stream. You can simply extract it from the BD and put it in a MKV container without having to re-encode it, and most players will be able to play it.

In the other hand, the other stream (usually the right view) is the "dependent view", encoded in MVC (Multi-view Video Codec). It contains only the differences between the left and right views. Since it doesn't contain the complete information but just the changes in the right image in comparison to the left image, it can be much more compressed than the AVC view. But that means also that it is totally impossible to play it without the AVC stream. Therefore, it doesn't make sense to store the MVC view only in a MKV (or AVI) container, as no player will be able to play it. If you want to make a video with the MVC stream only, you MUST re-encode it. It's what BD3D2MK3D does when you select "Monoscopic 2D: Dependent view only" as the Stereoscopy mode. The final file size depends of the x264 encoding parameters.

So, either you really want to put the unmodified MVC stream in an AVI container, and it's totally useless as it's not playable, or you must re-encode it from the right AND left views, and the file size will certainly be different than the original MVC stream.

Thank you so much!

Wolfy59

1st June 2013, 12:35

BD3D2MK3D v0.19 does it. When you load the BD, it removes the "(left eye)" and "(right eye)" strings from the eac3to output (as they are wrong), but as soon as you click "Get Streams Info" or you go to tab 2, you'll see them again, and they are correct.

Note also that you can find in which M2TS file(s) the AVC and MVC streams are stored with the menu "Tools -> Find dependent-view (MVC) file(s)".

Thanks i will try with the next bd3d i will Buy

jdobbs

1st June 2013, 16:26

Unfortunately it appears that most of the multi-part output that I've done with ssifsource3() appears to be losing or adding frames and the left/right pictures are falling out of sync. Is anyone else experiencing this? It appears it may be happening at the points where the multiple segments are joined -- but I'm not sure yet.@slavanap

I kept having issues with right/left sync with ssifsource3 and multipart sources. So I decided to fall back to DirectshowMVCSource() -- only to find that it was also now out of sync (after many successful runs). So I started looking at other changes to the process, which included the updated CoreAVCDecoder.dll.

On my last job I switched back to v2.1.0.1 of the coreavcdecoder.dll (from v3.0.0.2) -- and now the output (from ssifsource3) is in-sync.

It's pretty hard to say definitively that the issue was in the newer DLL after running only one job -- but it certainly is a coincidence that after several out-of-sync jobs the first one I ran with the older DLL is suddenly back in sync.

More to come with further testing.

r0lZ

1st June 2013, 18:10

I post my original message to let you know (and because I've typed it), but I've found the problem. See at the end of this post.

I did an small encode with ssifsource3() (with the "old" CoreAVCDec), but unfortunately, it failed completely. The movie is made of only one SSIF part. Its duration is about 0:03:24. I have given the number of frames in the command line: 4898.

The first second of the video contains the beginning of the original video, but there are many duplicates, sometimes in the left (AVC) view, sometimes in the right view. The 4th image of the right view is already wrong. But the 5th image seems correct. Then, the 2 views are almost always out of sync, with duplicates in either the left or right view every 2 or 3 images.

Then, during the next second of video, I can see some frames apparently picked randomly from the remaining part of the original video. It seems that the encoder did seeks to pick one image approximately every 200 images. After that second, a black frame (probably the last frame of the original video) is repeated up to the end of the video.

There is something I don't understand at all. When I preview the AVS script with AvsPMod, the playback is perfectly correct! (Of course, AvsPMod is in the "magic path".) But when I encode it, the result is terrible. I wonder why!

Here is the script I've used:

LoadPlugin("D:\Tools\BD3D2MK3D\toolset\stereoplayer.exe\SsifSource2.dll")
SsifSource3("Z:\BDMV\STREAM\SSIF\00000.ssif;4898", avc_view = true, mvc_view = true, horizontal_stack = true, swap_views = 0)
AssumeFPS("ntsc_film")
BilinearResize(1920, 1080)

I have also tried to replace the number of frames with 0. Same problem. And again, it works fine in AvsPMod!

I have tried also ssifsource2(), and it seems to work correctly, even when doing seeks in AvsPMod. That's great. :-)

[EDIT] OK, the problem is caused by the fact that I was encoding with avs2yuv and x264_x64. Unfortunately, ssifsource3() is (currently) totally incompatible with avs2yuv. Pity, but it's not so bad. The test I did with x264 32-bit worked perfectly. I'm still wondering why ssifsource2() works in 64-bit mode, but not ssifsource3(). Both can do seeks now, and I have supposed that the problem was due to the new seek support, but apparently, it's not the case.

frencher

2nd June 2013, 00:17

I have made smal tool for extract chapters from mpls to tsMuxer & mkvmergeGUI compiled in x86 & x64 for extrem speed

Chapters Extractor by Web Free Software (http://ul.to/okjux9rb)

"Chapters Extractor x86.exe" -i "F:\BDMV\PLAYLIST\00800.mpls" -o ".\Out"
or
"Chapters Extractor x64.exe" -i "F:\BDMV\PLAYLIST\00800.mpls" -o ".\Out"

Out_MKVmerge.txt
CHAPTER01=00:00:00.000
CHAPTER01NAME=
CHAPTER02=00:07:22.817
CHAPTER02NAME=
CHAPTER03=00:14:31.996
CHAPTER03NAME=
CHAPTER04=00:22:22.967
CHAPTER04NAME=
CHAPTER05=00:31:52.619
CHAPTER05NAME=
CHAPTER06=00:40:13.661
CHAPTER06NAME=
CHAPTER07=00:45:14.295
CHAPTER07NAME=
CHAPTER08=00:52:43.494
CHAPTER08NAME=
CHAPTER09=01:00:40.846
CHAPTER09NAME=
CHAPTER10=01:06:41.122
CHAPTER10NAME=

Out_tsMuxeR.txt
00:00:00.000
00:07:22.817
00:14:31.996
00:22:22.967
00:31:52.619
00:40:13.661
00:45:14.295
00:52:43.494
01:00:40.846
01:06:41.122

jdobbs

2nd June 2013, 03:58

@slavanap

I kept having issues with right/left sync with ssifsource3 and multipart sources. So I decided to fall back to DirectshowMVCSource() -- only to find that it was also now out of sync (after many successful runs). So I started looking at other changes to the process, which included the updated CoreAVCDecoder.dll.

On my last job I switched back to v2.1.0.1 of the coreavcdecoder.dll (from v3.0.0.2) -- and now the output (from ssifsource3) is in-sync.

It's pretty hard to say definitively that the issue was in the newer DLL after running only one job -- but it certainly is a coincidence that after several out-of-sync jobs the first one I ran with the older DLL is suddenly back in sync.

More to come with further testing.Well scratch this. I've just run another job (on the same source) that is out of sync. So coincidence it is.

This is frustrating.

minhjirachi

2nd June 2013, 04:01

Anyone know how to demux the menu of the 3D Bluray Disc? Has any software can do this job?

Wolfy59

2nd June 2013, 07:39

r0lZ

2nd June 2013, 08:35

Well scratch this. I've just run another job (on the same source) that is out of sync. So coincidence it is.

This is frustrating.
I can confirm that sync problem with ssifsource3() and any version of CoreAVCDec.

r0lZ

2nd June 2013, 08:41

Hi all, I used BD3D2MK3D to have two Mkv with the base view and the dep view (thanks to r0lz For his work).
Now when I click to get stream info, it seems to be the right eye that is the base view.
I want to know if now that i have the two streams may i change the order to encoding (right eye become the left eye and the left eye become the right eye) ?
Just to have a BD3D with left eye for base
Thanks and sorry for my poor english
You can use the Intel SDK to re-encode the two h264 streams (in any order) to AVC/MVC combined stream. But you'll lose quality. And I don't know how to rebuild the M2TS, SSIF and MPLS streams, and the BD structure, from the new combined stream.
IMO, you should keep the original BD as it is. As we know (thanks to jdobbs), the Right/Left views order is perfectly legit.

Wolfy59

2nd June 2013, 08:49

As we know (thanks to jdobbs), the Right/Left views order is perfectly legit.

Ok But must i have to change the view order to my 3D tv Manually or it s automatic ?
And May it be possible to add a batch processing to your BD3D2MK3D.
With it, it will be possible to create a batch with the 2 separate view before i m going to sleep :-).
Thanks

r0lZ

2nd June 2013, 09:19

If you play the original 3DBD with a good BD player, the order should be switched automatically. It's the responsibility of the BD player to send the images in the correct order to the TV (or to give the correct information with the streams, I don't know exactly).

If you play a 3D SBS or T&B file created by BD3D2MK3D, the TV should be able to select the left/right views automatically too, as the correct information is in the MKV header, but unfortunately, many TVs ignore that information. Anyway, the latest version of BD3D2MK3D (v0.19) restores the right order automatically, so if you have selected, for example, "SBS, left first", the left view will be first, even if the left/right views order is inverted in the original BD.

I don't know what you are doing with the 2 separate views. If you compose them to recreate a new 3DBD, you should compose them in the right order, or set the left/right order flag correctly in your 3DBD authoring software.

I don't have plans to implement batch processing with BD3D2MK3D, but it's easy to do manually. Just create the two projects. (Be sure to rename the output directory after having generated the project for the first view, as otherwise it will be overwritten by the second project.) Then, create a batch file to launch the 2 "_ENCODE.cmd" commands. You MUST CD to the directory containing the project before! For example, this batch should work:

CD /d "D:\BD3D2MK3D_projects\MyBD\00000_m2ts_AVC"
cmd /c _ENCODE.cmd
CD /d "D:\BD3D2MK3D_projects\MyBD\00000_m2ts"
cmd /c _ENCODE.cmd

In the first project, you must delete or rename the _POSTPROCESS.cmd file, as otherwise, the batch will stop after the first encoding (or shut the PC down if you have selected that option in the GUI).

I haven't tested that method, but it should work. If it doesn't work, try to replace the two "_ENCODE.cmd" commands with "cmd /c _ENCODE.cmd". [EDIT] You MUST do it.

Wolfy59

2nd June 2013, 09:39

If you play the original 3DBD with a good BD player, the order should be switched automatically. It's the responsibility of the BD player to send the images in the correct order to the TV (or to give the correct information with the streams, I don't know exactly).

If you play a 3D SBS or T&B file created by BD3D2MK3D, the TV should be able to select the left/right views automatically too, as the correct information is in the MKV header, but unfortunately, many TVs ignore that information. Anyway, the latest version of BD3D2MK3D (v0.19) restores the right order automatically, so if you have selected, for example, "SBS, left first", the left view will be first, even if the left/right views order is inverted in the original BD.

I don't know what you are doing with the 2 separate views. If you compose them to recreate a new 3DBD, you should compose them in the right order, or set the left/right order flag correctly in your 3DBD authoring software.

I don't have plans to implement batch processing with BD3D2MK3D, but it's easy to do manually. Just create the two projects. (Be sure to rename the output directory after having generated the project for the first view, as otherwise it will be overwritten by the second project.) Then, create a batch file to launch the 2 "_ENCODE.cmd" commands. You MUST CD to the directory containing the project before! For example, this batch should work:

CD /d "D:\BD3D2MK3D_projects\MyBD\00000_m2ts_AVC"
_ENCODE.cmd
CD /d "D:\BD3D2MK3D_projects\MyBD\00000_m2ts"
_ENCODE.cmd

In the first project, you must delete or rename the _POSTPROCESS.cmd file, as otherwise, the batch will stop after the first encoding (or shut the PC down if you have selected that option in the GUI).
I haven't tested that method, but it should work. If it doesn't work, try to replace the two "_ENCODE.cmd" commands with "cmd /c _ENCODE.cmd".

Thanks for your answers and your help:D

r0lZ

2nd June 2013, 10:35

You're welcome.

I've just tested the method (with just "_ENCODE.cmd"), and it doesn't work. You HAVE to use "cmd /c _ENCODE.cmd" in your batch file. (I have modified the code in my previous post accordingly.)

Be sure to mount your ISO(s) before launching the command, of course! Also, if you want to encode 2 projects from different BDs, you must mount the two ISOs. In that case, the drive letter of the second mounted ISO can be different than the original drive letter (when you have created the project) and you may have to change it in the AVS script.

Also, I forgot to say that if you don't need the MKV file, you can also delete or rename the _MUX_3D.cmd file(s), or you can untick the "Mux to MKV" option in the BD3D2MK3D GUI. When that file is not present, the _ENVODE.cmd batch stops when the encoding to h264 is finished.

Also, you don't need to demux the audio and subtitle streams in both projects. You can do it just in one project, and untick all streams in the other project. The generation of the second project will be much more rapid.

Sharc

2nd June 2013, 11:01

BD3D2MK3D:
I made a combined.m2ts from a BD MVC source (ssif).
- 2D and 3D Playback with Stereoscopic Player 2.0.6 fail (black picture with CPU at 50%)
- 2D (base view) playback with MPC-HC works, and playback is smooth

Now using the temporary _combined_TEMP.h264:
- 2D playback with Stereoscopic Player works with stroboscopic effect (jitter rather than smooth playback)
- 3D playback with Stereoscopic Player works with some jitter, but 3D effect (depth) is poor compared to watching the original with the same settings of the Stereoscopic Player.

I just thought to report this back.

r0lZ

2nd June 2013, 17:57

BD3D2MK3D:
BD3D2MK3D is only a GUI for MVCCombine.exe, and doesn't do anything special.
I don't know why Stereoscopic Player fails, but I use the Combined.m2ts file only for converting it to SBS when there are too many SSIF files in the MPLS, and DirectShowMVCSource or ssifsource2 fail. For that conversion, the combined m2ts has always worked fine.

Sharc

2nd June 2013, 18:57

BD3D2MK3D is only a GUI for MVCCombine.exe, and doesn't do anything special.
I don't know why Stereoscopic Player fails, but I use the Combined.m2ts file only for converting it to SBS when there are too many SSIF files in the MPLS, and DirectShowMVCSource or ssifsource2 fail. For that conversion, the combined m2ts has always worked fine.
Understood, no problem; thanks again for BD3D2MK3D :)

Wolfy59

3rd June 2013, 07:58

r0lZ

3rd June 2013, 08:38

Wow, that's fast!
BTW, I wonder if you really need to re-encode the AVC stream. You can just grab it from the BD. (Use _MUX_2D.cmd to mux it to MKV, or tick the Demux the AVC stream option in tab 2, or use eac3to manually). However, I don't know if it is necessary to encode the 2 views in a similar way. That depends probably of what you are doing with them.

Wolfy59

3rd June 2013, 15:16

r0lZ

3rd June 2013, 17:48

So, you will re-encode them anyway, and it is much more rapid to demux and re-encode the original AVC stream directly. (And you'll need less disc space.)

Wolfy59

4th June 2013, 06:58

So, you will re-encode them anyway, and it is much more rapid to demux and re-encode the original AVC stream directly. (And you'll need less disc space.)

Yes I can, but I don't know if there is a lost in quality in the final project. I saw somewhere that the dependent view must have half base view bitrate. And in this project the dependent bitrate is lower than the half base bitrate.
How can i calculate that ?
Base View 31 Go
Dep View 10 Go

r0lZ

4th June 2013, 07:32

I'm not sure I understand your question. To rebuild a 3DBD, you must re-encode both streams at the same time with a MVC encoder. You cannot encode the base view (for example with x264) and then the dep view and lower the bit rate for the dep view. I don't know many MVC encoders (in fact, I've just tested once the Intel encoder of the SDK), and with that encoder, you cannot specify the bitrate of the 2 streams independently. The "bitrate gain" in the dep view in comparison to the left view is determined by the encoder itself and the amount of difference in the two views. It might be true that the dep view bitrate is usually about half the bitrate of the base view, but IMO, it's only a coincidence.

BTW, the Intel SDK has exactly what you need to re-create the AVC/MVC streams for your BD25. Extract the original streams to a combined.h264 file with eac3to and MVCCombine (or with the GUI integrated in BD3D2MK3D), then re-encode that combined.h264 file to another combined h264 file with the sample_multi_transcode exe from the SDK. I'm not sure it's a good encoder, but it works, and you don't need to encode the original streams to two huge lossless streams first.

sample_multi_transcode_x64.exe -i::mvc OrigMVCCombined.h264 -o::mvc TargetMVCCombined.h264 -w 1920 -h 1080 -f 23.976 -b 12000 -u 1
As you can see, you can only specify a global bitrate for the 2 streams.

Wolfy59

4th June 2013, 08:36

I'm not sure I understand your question. To rebuild a 3DBD, you must re-encode both streams at the same time with a MVC encoder. You cannot encode the base view (for example with x264) and then the dep view and lower the bit rate for the dep view. I don't know many MVC encoders (in fact, I've just tested once the Intel encoder of the SDK), and with that encoder, you cannot specify the bitrate of the 2 streams independently. The "bitrate gain" in the dep view in comparison to the left view is determined by the encoder itself and the amount of difference in the two views. It might be true that the dep view bitrate is usually about half the bitrate of the base view, but IMO, it's only a coincidence.

BTW, the Intel SDK has exactly what you need to re-create the AVC/MVC streams for your BD25. Extract the original streams to a combined.h264 file with eac3to and MVCCombine (or with the GUI integrated in BD3D2MK3D), then re-encode that combined.h264 file to another combined h264 file with the sample_multi_transcode exe from the SDK. I'm not sure it's a good encoder, but it works, and you don't need to encode the original streams to two huge lossless streams first.
As you can see, you can only specify a global bitrate for the 2 streams.

I use totalcode pro to encode the mvc and the d.mvc view and i can fix an average bitrate for each view but I don't know if using a half bitrate for the dep view is necessary or if I can use lower bitrate.
All movies I did seems good but Increase the avc bitrate by using a lower mvc bitrate is a good solution to have better 3D BD25.

Thanks for your help and you work

Sharc

4th June 2013, 21:50

Intel SDK Multi_Transcode exits with:
Return on error: error code -16, .\src\pipeline_transcode.ccp 719

Any idea what could be wrong?

r0lZ

4th June 2013, 22:17

I got that error too with a combined file, and when I try to render the file with the -r option. I don't know why.

slavanap

5th June 2013, 09:54

Next version of ssifSource lib: http://sendfile.su/821817
* precise seeking removed, now default directshow seeking function does all the work (not frame precise),
* default swap_views value set to 0 (AVC=left, MVC=right),
* mkv files that contains 2 views (mkv files is made by MakeMKV software and perfertly plays in Stereoscopic player) support added. Requires MatroskaSplitter.dll from Stereoscopic player.

@jdobbs, r0lZ
If the sync problem appears in that lib, too, please let me know.
The one difference in process when you extract base view in one AVS-file and dependent view in the other AVS-file is that ssifSource lib doesn't request dependent view from CoreAVC when it isn't necessary (for only base view extraction; to make extraction process faster). So maybe the problem is in that. To force 2 view extraction anytime you can just select 2 views to be extracted and then crop the one you need.

[EDIT] OK, the problem is caused by the fact that I was encoding with avs2yuv and x264_x64. Unfortunately, ssifsource3() is (currently) totally incompatible with avs2yuv. Pity, but it's not so bad. The test I did with x264 32-bit worked perfectly. I'm still wondering why ssifsource2() works in 64-bit mode, but not ssifsource3(). Both can do seeks now, and I have supposed that the problem was due to the new seek support, but apparently, it's not the case.

What do you mean? You mean I need to compile ssifSource2 for x64 architecture? I can do that actually.
Or you mean, that ssifSource2 function works and ssifSource3 function does not work in the same dll? That's really strange to me. ssifSouce3 actually uses ssifSource2, that's why there are both of them in the same library.

r0lZ

5th June 2013, 12:09

What do you mean? You mean I need to compile ssifSource2 for x64 architecture? I can do that actually.No. It might be a good thing to have an x64 version later, for the guys who use Avisynth 64-bit, but it's not really necessary.

Currently, it is possible to encode an AVS script (running with Avisynth 32-bit) with x264_x64.exe if you read the AVS script with avs2yuv.exe and you pipe its output to x264_x64.exe, like this:

"avs2yuv.exe" "script.avs" -o - | "x264_x64.exe" [options] -demuxer y4m --stdin y4m -

Since avs2yuv.exe is a 32-bit app, it can launch the 32-bit avisynth.dll. It decodes the script as uncompressed YUV to stdout, and its output is piped to x264 64-bit. That way, the decoding process (avisynth + avs2yuv) is slow but reliable, and the encoding process takes advantage of the 64-bit architecture of most recent PCs.

Or you mean, that ssifSource2 function works and ssifSource3 function does not work in the same dll? That's really strange to me. ssifSouce3 actually uses ssifSource2, that's why there are both of them in the same library.No, both methods work when the whole process is made in 32-bit. When the avisynth 32-bit dll is called directly by x264.exe (32-bit), there is no problem (except the missing or additional frames, but it's another problem).

But the output is completely wrong when using the avs2yuv + x264_x64 method described above. I don't know why, and I will try again with other BDs, just to confirm, when I'll have some free time. Anyway, your new beta doesn't do the seeks the same way than before, and I suppose the problem will be fixed. I'll let you know...

jdobbs

5th June 2013, 13:27

If the sync problem appears in that lib, too, please let me know.
The one difference in process when you extract base view in one AVS-file and dependent view in the other AVS-file is that ssifSource lib doesn't request dependent view from CoreAVC when it isn't necessary (for only base view extraction; to make extraction process faster). So maybe the problem is in that. To force 2 view extraction anytime you can just select 2 views to be extracted and then crop the one you need. I tried the two view extraction with cropping -- same issue. Actually I'm not sure whether the issue is sssifsource3 or the newest CoreAVCDecoder release. I started having issues with DirectshowMVCSource as well, and it went away when I reverted the decoder to v2.1.0.1 and reripped the source. Unfortunately, though, the ssifsource3 issue seems to have remained.

I'll try again with your new release.

frencher

5th June 2013, 17:46

Next version of ssifSource lib: http://sendfile.su/821817
* precise seeking removed, now default directshow seeking function does all the work (not frame precise),
* default swap_views value set to 0 (AVC=left, MVC=right),
* mkv files that contains 2 views (mkv files is made by MakeMKV software and perfertly plays in Stereoscopic player) support added. Requires MatroskaSplitter.dll from Stereoscopic player.

@jdobbs, r0lZ
If the sync problem appears in that lib, too, please let me know.
The one difference in process when you extract base view in one AVS-file and dependent view in the other AVS-file is that ssifSource lib doesn't request dependent view from CoreAVC when it isn't necessary (for only base view extraction; to make extraction process faster). So maybe the problem is in that. To force 2 view extraction anytime you can just select 2 views to be extracted and then crop the one you need.

What do you mean? You mean I need to compile ssifSource2 for x64 architecture? I can do that actually.
Or you mean, that ssifSource2 function works and ssifSource3 function does not work in the same dll? That's really strange to me. ssifSouce3 actually uses ssifSource2, that's why there are both of them in the same library.

Hello slavanap,

Very very good news, for I am interested in against a x64
I will test soon ;)

PS: It's possible to add audio support with uNicAudio.dll + Source Code.rar (http://ul.to/6k1bhp8m) for playback ?

Thank you

frencher

6th June 2013, 00:23

"MVC Player Free v0.0.1.6" In my signature... :rolleyes:

Old version "MVC Player Free v0.0.1.5" (http://ul.to/7n6gdbvh)

Extract and run directly MVC Player Free.exe or play associated file with MVC Player Free.exe
# Major fix: Long path with "MVC Player Free.exe" now working
# Added: Experimental support of mkv and seek is now fixed with 3D (ssif, m2ts and mkv only) thanks you slavanap for ssifSource2.dll ;)
# Some fixes
Temporary: Don't use eac3to infos

r0lZ

6th June 2013, 10:34

@Slavanap:
But the output is completely wrong when using the avs2yuv + x264_x64 method described above.
Well, I have tried again with the previous beta, and this time, I have had exactly the same result with ssifsource3() than with ssifsource2(). There are still additional or missing frames from time to time, but encoding with x264 32-bit or with avs2yuv and x264_x64 work the same way. I don't understand why, as nothing has changed since my last tests. I remember I've previewed the movie and I did several seeks with AvsPMod before launching the encoding, but that should have no impact. Anyay, consider this problem as solved. If I can reproduce it, I'll let you know.

I did also some tests with the latest beta. Unfortunately, the sync problem persists, but again I don't understand it.

When I preview the AVS script with AvsPMod, all frames are in sync, so everything seems perfect.

But when I encode the movie with avs2yuv and x264_x64, there are 2 additional frames in the MVC stream at the very beginning of the video. (It seems that no dupes are added later, but I'm not sure).

Then I did another test with x264 32-bit, and I've seen a lot of "Duplicate frame added" warnings. I've decided to start again but this time I've added "> x264.log" to the command to capture the error messages. Strangely, there were no warning any more, in the command prompt window or in the log. There are NO additional frames at the beginning any more. :-)
Here is the content of the log:

ssifSource3: adding file Z:\BDMV\STREAM\SSIF\00000.ssif with 0 frames to sequences list. Have to load flag is TRUE

ssifSource2: framecount autodetect mode on. looking for 'Z:\BDMV\STREAM\SSIF\..\00000.M2TS' file...
ssifSource2: DSS2 function does not exists. Please add DSS2 plugin (avss.dll) to Avisynth plugins to make this feature work.
ssifSource2: framecount directshow value is 4898

Is the DSS2 function really necessary? It seems that ssifsource3() works as expected without it. Note also that I have installed the Haali MatroskaSplitter, and it contains the avss.dll file, but it is located in "C:\Program Files (x86)\Haali\MatroskaSplitter". Is it sufficient to move or copy it to the avisynth plugins directory?

Then, I've tried again to encode with x264 32-bit without the redirection to the log file. It tooks a very long time to start the encoding, and again I see the error messages. Here are a few of them:

"D:\NoInstall\BD3D2MK3D\toolset\stereoplayer.exe\x264.exe" --crf 23 --preset medium --profile high --level 4.1 ^
--keyint 96 --output "00000_m2ts.264" "_ENCODE_3D_MOVIE.avs"

ssifSource3: adding file Z:\BDMV\STREAM\SSIF\00000.ssif with 0 frames to sequences list. Have to load flag is TRUE

ssifSource2: framecount autodetect mode on. looking for 'Z:\BDMV\STREAM\SSIF\..\00000.M2TS' file...
ssifSource2: DSS2 function does not exists. Please add DSS2 plugin (avss.dll) to Avisynth plugins to make this feature work.
ssifSource2: framecount directshow value is 4898
avs [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 4.1

ssifSource2: Decoding frame timeout reached!!! Frame # 3 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 4 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 5 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 6 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 10 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 11 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 12 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 15 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 15 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 16 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 17 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 19 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 20 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 21 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 21 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 22 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 23 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 25 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 27 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 28 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 30 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 30 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 32 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 32 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 36 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 43 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 43 duplicate added (debug: g03937998 m03937830 s03937998)

ssifSource2: End of graph. Frame # 45 duplicate added (debug: g03937830 m03937830 s03937998)
[0.0%] 2/4898 frames, 0.03 fps, 310.54 kb/s, eta 47:39:35
ssifSource2: End of graph. Frame # 53 duplicate added (debug: g03937830 m03937830 s03937998)

ssifSource2: End of graph. Frame # 53 duplicate added (debug: g03937998 m03937830 s03937998)

[...]

I had to stop the command to be able to copy/paste the messages here, so I've started the command again (without any modification), and this time, there are again no error messages, but there is a missing frame at the beginning of the MVC view. How is it possible that exactly the same command launched in exactly the same conditions can give different results? I'm puzzled.

I did all tests with the number of frames set to 0 in the AVS script. If you want tests with the correct number of frames, please let me know.

I will check again later, with the avss.dll correctly installed...

r0lZ

6th June 2013, 16:23

I did a lot of new ssifsource3() tests, with and without the avss.dll, and with and without the number of frames in the ssifsource3() command. All tests have been made with a single SSIF file.

Apparently, right after a reboot, ssifsource3() works perfectly. There is no left/right sync problem, no timeout and no "duplicate added" error messages. But if you launch the same encoding again, the timeout and "duplicate added" error happen. Same thing if you reboot, launch AvsPMod (even without previewing the video), quit it, and then encode the script. If you reboot again, the script can be encoded successfully again. Obviously, there is something wrong when avisynth is initialised for the second time. I don't know if it is possible to "reset" avisynth before starting the script, but I've tried to edit my Win8 registry to automatically unload the DLLs that are not used any more (http://www.freetutorialssubmit.com/speed-up-windows-7-by-forcing-it-to-unload-unused-dlls-and-delete-cached-ones/1786). Unfortunately, that doesn't solve the problem.

Note that the presence or absence of avss.dll in the avisynth's plugins folder doesn't change anything (except that the warnings about DSS2 is not shown when the dll is present.

I have also tested an encode of several times the same SSIF file, with this command: SsifSource3("Z:\BDMV\STREAM\SSIF\00000.ssif;48;Z:\BDMV\STREAM\SSIF\00000.ssif;48;Z:\BDMV\STREAM\SSIF\00000.ssif;1000", avc_view = true, mvc_view = true, horizontal_stack = true, swap_views = 0). Unfortunately, that doesn't work either, even after a reboot. I have tried to encode it 4 times, and each time, at least one of the 3 parts produced the "duplicate added" errors. Even the first part can produce the error after a reboot.

It should be noted that AvsPMod has absolutely no problems with the script with a single SSIF. So, IMO, it uses a method to initialize the script correctly. But it hangs also with scritps with several SSIF files in the same command.

Slavanap, I hope you have now enough info to find and fix that irritating bug. Unfortunately, I can't help on this point. To reproduce it, encode a few frames of any 3D movie, and then launch the same encoding command again. Most of the times (but not always), it will fail (and you'll see the progress % of x264 only after the timeout of 1 minute).

I did most tests with x264 32-bit, but I've tried also several times the method using avs2yuv and x264_x64. The bugs described above are happening also with that encoding method, but I have also discovered another problem. The current beta of ssifsource2.dll prints its messages to stdout. That's fine when using the 32-bit encoding method, but not when using the 64-bit one. When the message is issued, avs2yuv echoes it probably to stdout normally, but since the YUV decoded video is also sent to stdout, the messages are mixed with the video stream, and x264_x64 receives strange frames with garbage that it cannot encode properly. That means that it is never possible to encode correctly a script using ssifsource3 in 64-bit mode. There is almost always a totally bugged frame near the beginning of the video, followed by a left/right sync problem of at least 3 or 4 frames. (The rest of the encoding seems normal, but of course the sync problem persists.)

I suppose that this bug can easily be fixed by printing all messages to stderr instead of stdout. Slavanap, can you fix it?

Thanks.