Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph

[r0lZ]

The source code of an old version of tsMuxeR could be available here (http://www.videohelp.com/tools/tsMuxeR). (It's the GUI, but apparently, it contains also the code of the main exe.) See comments #3 to #1.

[Sharc]

Could perhaps TsRemux (http://forum.doom9.org/showthread.php?p=999234#post999234) by dmz be used?
Source Code is here (https://github.com/antiochus/tsremux).

[frencher]

With v0.3a
I have w7 x64 with 8Gb of RAM
eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 | MVCCombine.exe -p -o test.h264

AnnexBReader-Thread started: \\.\pipe\left.h264
PipeMode: Pipe connecting Loop started
Pipe (\\.\pipe\left.h264) created and waiting
AnnexBReader-Thread started: \\.\pipe\right.h264
PipeMode: Pipe connecting Loop started
Pipe (\\.\pipe\right.h264) created and waiting
Pipe (\\.\pipe\right.h264) connected
Pipe (\\.\pipe\left.h264) connected
Frame 18345 written (100,00%) - 0:01:53 - 0:00:00
Left Queue EOF: 1
\\.\pipe\left.h264: FreePool pop/push: 57730/60724
\\.\pipe\left.h264: Queue pop/push: 57729/57729
Frame 18423 written (100,00%) - 0:02:54 - 0:00:00
Right Queue EOF: 1
\\.\pipe\right.h264: FreePool pop/push: 57924/60921
\\.\pipe\right.h264: Queue pop/push: 57923/57923
Frame 18486 written (100,00%) - 0:03:54 - 0:00:00

done, cleaning up
Writing the destination file failed.Aborted at file position 3256877056.Pipe-Rea
d returned with BROKEN_PIPE, this means EOF...


eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: .\left.h264 3: .\right.h264

M2TS, 2 video tracks, 4 audio tracks, 7 subtitle tracks, 1:33:44, 24p /1.001
1: Chapters, 18 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
5: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: AC3, Spanish, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
7: AC3, Portuguese, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
8: Subtitle (PGS), English
9: Subtitle (PGS), French
10: Subtitle (PGS), Spanish
11: Subtitle (PGS), Portuguese
12: Subtitle (PGS), French
13: Subtitle (PGS), Spanish
14: Subtitle (PGS), Portuguese
v02 Extracting video track number 2...
v03 Extracting video track number 3...
v03 Creating file ".\right.h264"...
v02 Creating file ".\left.h264"...
Video track 2 contains 134853 frames.
Video track 3 contains 134853 frames.
eac3to processing took 4 minutes, 53 seconds.
Done.

[r0lZ]

You should not pie the two processes in the same command. You should launch MVCCombine in a command prompt window, and then eac3to in another window. Works fine here (Win8 x64, 4GB RAM).

[Sparktank]

Sorry, but it's really hard to follow this thread since it's taking after an older, outdated topic.

Would it be possible for frencher to start his own thread with updates and updated links in the first post?
And possibly host Neisklar's combinemvc progress? ot get Neisklar to start a new thread as well for combinemvc progress/links?

Would be easier to catch the updates. ie, a static link to bookmark or otherwise use as a reference link for others to show and talk about.
Sorry, just get cross-eyed (no 3D pun intended) trying to go through to see what's been going on in here lately.

Liking the progress and looking forward to trying some things out.

[r0lZ]

I agree that this thread is confusing. It started as a guide, but now it holds the discussions about several tools. IMO, that's not really bad, as long as it is used mainly by programmers, as we are working together on the same project, atthough the GUIs are different.
IMO, we should indeed create new threads for the end-user tools like MVC Player Free and BD3D2MK3D. But it doesn't make sense to make a new thread just for MVCCombine, for example, as it is not really useful for an end-user. It should be integrated within a GUI, and it's what we discuss here.
I think I'll create a new thread for BD3D2MK3D when I'll release the next version. In the meantime, the discussion about MVCCombine and the avisynth 3D plugins will probably continue here.

[Neisklar]

In the meantime, the discussion about MVCCombine and the avisynth 3D plugins will probably continue here.

Yep;-)

So try this one:
http://www.share-online.biz/download.php?id=B7V8DRLMT4M

Please start it with with debug output (-v): MVCCombine.exe -p -v -o <outfilename>

The pipenames are hardcoded as in the last version.
The handling of normal files should be reverted to the behavior of V0.1.
Memory usage is only half a Gig

could you please have a look during testing at the 'P' and 'Q'-Values
Frame: 752 [L: 8 P: 500 - Q: 0] | [R: 8 P: 493 - Q: 6]
I'm especially interested if some machines get the P value somewhat down (if not i could decrease the memory usage)

Thanks

[frencher]

Same
http://i33.tinypic.com/2ag3lhx.png

[Neisklar]

Same

Thas the old Version, maybe i have uploaded the wrong one (without arguments it should state V0.4)

I will have a look and edit this post


(BTW: The EOF: 1 Error means normally the amount of buffers were to small)



Edit:
I'v uploaded the correct one (the exe is from today)

[frencher]

Thas the old Version, maybe i have uploaded the wrong one (without arguments it should state V0.4)

I will have a look and edit this post


(BTW: The EOF: 1 Error means normally the amount of buffers were to small)



Edit:
I'v uploaded the correct one (the exe is from today) ;)

Yes v0.3
MVCCombine.exe V0.3
-l <left> -r <right> -o <out>
-ml to get multiline progress
-p use pipes (Alpha)
-v Debug output
-qs <size> Queuesize (Try to set to 4000 or 5000 when process hangs)

[frencher]

v0.3
eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 | MVCCombine.exe -qs 500 -p -o test.h264

http://i37.tinypic.com/alsuwp.png

[Neisklar]

frencher could you please redownload from
http://www.share-online.biz/download.php?id=B7V8DRLMT4M
I'm sure thats the V0.4 Version.

[frencher]

v0.4b ~1% of CPU i7 3930k and eac3to ~2%

L:\CombineMVC v0.4b>eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: \\.\pipe\left.h264
3: \\.\pipe\right.h264 | MVCCombine.exe -p -o test.h264
\\.\pipe\left.h264: TPipeSucker Thread started
\\.\pipe\left.h264: Pipe created and waiting for connection
\\.\pipe\right.h264: TPipeSucker Thread started
\\.\pipe\right.h264: Pipe created and waiting for connection
\\.\pipe\right.h264: Pipe connected
\\.\pipe\left.h264: Pipe connected
Frame 134789 written (100,00%) - 0:22:23 - 0:00:00
\\.\pipe\left.h264: Read ok, need new loop, new readsum: 72978 dwRead: 72978
\\.\pipe\right.h264: Read ok, need new loop, new readsum: 434851 dwRead: 434851
\\.\pipe\left.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\left.h264: FillBuffer errored with data, mostly its the last buffer
\\.\pipe\right.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\right.h264: FillBuffer errored with data, mostly its the last buffer
\\.\pipe\left.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\left.h264: FillBuffer errored with zero data, mostly its only EOF
AnnexB getChunk returned nil
Left Stream end
\\.\pipe\right.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\right.h264: FillBuffer errored with zero data, mostly its only EOF
AnnexB getChunk returned nil
Right Stream end
Frame 134853 written (100,00%) - 0:22:23 - 0:00:00

done, cleaning up
\\.\pipe\left.h264: TPipeSucker Thread ended
\\.\pipe\right.h264: TPipeSucker Thread ended
END

Very Nice UpDate
I will test with a corrupt stream to see what happens;)
I will be happy to discover the support. MKV (AVC / MVC) in a future update

[Neisklar]

v0.4b ~1% of CPU i7 3930k and eac3to ~2%

MVCCombine.exe -p -o test.h264

Thanks the run looks good, the low CPU results from waiting on the data in the pipe threads.

Could you please run with -v as additional switch in the command of MVCCombine. During the run please have a look at the output, especially the two 'P' values. I would like to know if your machine gets them down significantly ;-)

Edit2: For anyone interested: Q is the amount of currently read but not processed 512KB Buffers from the Pipe. Means if that value mostly zero the pipe OR The process at the other end of the pipe is the slowing factor.

Thank you

Edit:
I will be happy to discover the support. MKV (AVC / MVC) in a future update
The outputted .h264 should already be muxable in mkvtoolnix. Let's wait till your xstreamer3 arrives, and test it:)

[frencher]

Thanks the run looks good, the low CPU results from waiting on the data in the pipe threads.

Could you please run with -v as additional switch in the command of MVCCombine. During the run please have a look at the output, especially the two 'P' values. I would like to know if your machine gets them down significantly ;-)

Edit2: For anyone interested: Q is the amount of currently read but not processed 512KB Buffers from the Pipe. Means if that value mostly zero the pipe OR The process at the other end of the pipe is the slowing factor.

Thank you

Edit:

The outputted .h264 should already be muxable in mkvtoolnix. Let's wait till your xstreamer3 arrives, and test it:)

This format of mkv (avc/mvc) and playable with stereo player (http://ul.to/ryijbyaw)

With actual MVCCombine not playable
http://i37.tinypic.com/2eoaeq9.png

v0.4b with -v switch ~20 minutes ~1% of CPU
L:\CombineMVC v0.4b>eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: \\.\pipe\left.h264
3: \\.\pipe\right.h264 | MVCCombine.exe -v -p -o test.h264
\\.\pipe\left.h264: TPipeSucker Thread started
\\.\pipe\left.h264: Pipe created and waiting for connection
\\.\pipe\right.h264: TPipeSucker Thread started
\\.\pipe\right.h264: Pipe created and waiting for connection
\\.\pipe\right.h264: Pipe connected
\\.\pipe\left.h264: Pipe connected
Frame: 134797 [L: 3 P: 499 - Q: 1] | [R: 3 P: 500 - Q: 0]
\\.\pipe\left.h264: Read ok, need new loop, new readsum: 72978 dwRead: 72978
\\.\pipe\right.h264: Read ok, need new loop, new readsum: 434851 dwRead: 434851
\\.\pipe\left.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\left.h264: FillBuffer errored with data, mostly its the last buffer
\\.\pipe\right.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\right.h264: FillBuffer errored with data, mostly its the last buffer
Frame: 134852 [L: 3 P: 500 - Q: 0] | [R: 3 P: 500 - Q: 0]
\\.\pipe\left.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\left.h264: FillBuffer errored with zero data, mostly its only EOF
AnnexB getChunk returned nil
Left Stream end
\\.\pipe\right.h264: Read returned BROKEN_PIPE, this means EOF...
\\.\pipe\right.h264: FillBuffer errored with zero data, mostly its only EOF
AnnexB getChunk returned nil
Right Stream end
Frame: 134853 [L: 2 P: 499 - Q: 0] | [R: 2 P: 499 - Q: 0]

done, cleaning up
\\.\pipe\left.h264: TPipeSucker Thread ended
\\.\pipe\right.h264: TPipeSucker Thread ended
END

[Neisklar]

v0.4b with -v switch ~20 minutes ~1% of CPU

Thank you.

Did you had an eye on the values of P during the run?

[r0lZ]

I did a test with v0.4beta and a long movie (181762 frames), but without the -qs option. Everything went fine, but slowly.
The full debug log is here (http://download.videohelp.com/r0lZ/tmp/MVCCombine.log.7z).

Do you need other tests?

[EDIT] I've just relaunched the same test, but this time with -qs 4000. It seems to work, and I don't notice differences in the log. I may stop it before it ends...
The command is:

MVCCombine04b.exe -v -p -ml -qs 4000 -o test.h264 | tee.exe MVCCombine.log


I suppose that it is slow (partially) because it outputs one line per frame, and that these numerous lines are printed in the DOS window, and piped via tee.exe to a log file. It will probably be more rapid without -v and the | tee. Right?

[Neisklar]

I did a test with v0.4beta and a long movie (181762 frames), but without the -qs option. Everything went fine, but slowly.
The full debug log is here (http://download.videohelp.com/r0lZ/tmp/MVCCombine.log.7z).

Do you need other tests?

Should be enough. Thank you.
I think 0.4 is much much more stable.
-qs is not needed in 0.4, as of that buffering is a completly different thing. (Almost all of the new Code from V0.2 and V0.3 was thrown out.)

Here is an V0.5:
http://www.share-online.biz/download.php?id=P7W9PRLMW2
@frencher: use as additional commandline param '-ano', and you should hopefully get the output from your sample.

Edit:
Looking at the log, eac3to or the pipe is the limiting thing. And i can decrease the buffer size, so the memory consumtion will be maybe only 100 Megs

Edit2: Yes without -v it will only output 2 lines per second, but the limiting factor is still the piping and eac3to. (Just do a run of eac3to writing these two files directly to disc, and compare the times)

[r0lZ]

OK, thanks. I'll test v0.5 tomorrow. I have a fiesta tonight...

Just to clarify. Currently, it is possible to abort a conversion with BD3D2MK3D. But I do it the hard way, by killing the running exe. Can I do the same thing with MVCCombine? I suppose the pipes will stay open, right? Or is it sufficient to kill eac3to, and MVCCombine will detect that the pipes are broken?

Edit2: Yes without -v it will only output 2 lines per second, but the limiting factor is still the piping and eac3to. (Just do a run of eac3to writing these two files directly to disc, and compare the times)
OK, I'll check it. But imo eac3to should be even slower, as it has to write to 2 different files at the same time. Hard discs do not like that.

[Neisklar]

OK, thanks. I'll test v0.5 tomorrow. I have a fiesta tonight...

Just to clarify. Currently, it is possible to abort a conversion with BD3D2MK3D. But I do it the hard way, by killing the running exe. Can I do the same thing with MVCCombine? I suppose the pipes will stay open, right? Or is it sufficient to kill eac3to, and MVCCombine will detect that the pipes are broken?


V0.5 only adds the -ano (AlternateNALUOrdering) and some bugfixes for none-pipe mode.

Yes, when eac3to is killed happens exactly the same as if eac3to arrived at the end and 'closed' the files/pipes. MVCCombine gets a BROKEN_PIPE (which usually only means EndOfPipe). Besides that in both versions an interupt handler is defined, so it will react on Ctrl+C or other stuff.

Edit: BTW: If i hadn't hardcoded the pipe names, you could even do it between two different machines;-)

[frencher]

thank you.

Did you had an eye on the values of p during the run?

p ~480

[r0lZ]

Edit: BTW: If i hadn't hardcoded the pipe names, you could even do it between two different machines;-)
One additional reason to not hardcode them. :-)

[frencher]

Here is an V0.5:
http://www.share-online.biz/download.php?id=P7W9PRLMW2
@frencher: use as additional commandline param '-ano', and you should hopefully get the output from your sample

The problem is that if demuxes my sample (http://ul.to/ryijbyaw) and that the remuxe it is not readable with stereo player.
Is this possible with the '-ano' to a mkv container output?

Example:
eac3to.exe P:\BDMV\PLAYLIST\00100.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 | MVCCombine.exe -ano -p -o test.mkv

I it hard to translate into English because sometimes what I mean is not what I write and am sorry

[Neisklar]

The problem is that if demuxes my sample (http://ul.to/ryijbyaw) and that the remuxe it is not readable with stereo player.
Is this possible with the '-ano' to a mkv container output?


Just so that i don't get it wrong:
The Sample you provided is created with MakeMKV and is playable?

But you can just give it a try.
Do a combine with -ano (and for comparison even without) and take the resulting .h264 and use mkvtoolnix to mux it into an mkv container.

[frencher]

Just so that i don't get it wrong:
The Sample you provided is created with MakeMKV and is playable?

But you can just give it a try.
Do a combine with -ano (and for comparison even without) and take the resulting .h264 and use mkvtoolnix to mux it into an mkv container.

Yes created with MakeMKV.

This is what I meant in my last message, i'm sorry i forgot to mention.
The result .h264 with mkvtoolnix into an mkv container doesn't works.
MakeMKV does not use the format matroska standard and it takes this format to make it readable "Stereo player"

[Nico8583]

Nobody has found a MVC encoder ? :D

[arrgh]

...yes, that seems to be the problem:
MakeMKV creates 3D-MKVs which SP plays ok.
But if you remux the mkv-videostream from this file (with other audio- or subtitle-streams) to a new mkv-file, then SP does not recognize/playback it anymore as a 3D.

But I think that should be a simple metadata-problem, or does mkvtoolnix repack the video.mkv Stream?

[r0lZ]

Neisklar, I did some speed tests. Unfortunately, MVCCombine using pipes is MUCH slower than eac3to alone.

For example, to demux the AVC and MVC streams of my short demo clip with eac3to alone, this command takes 7 or 8 seconds to complete:

eac3to.exe G:\BDMV\PLAYLIST\01000.mpls 2: left.h264 3: right.h264 -progressnumbers

But when MVCCombine is piped, it uses 27 seconds to complete:

eac3to.exe G:\BDMV\PLAYLIST\01000.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 -progressnumbers | MVCCombine.exe -p -ml -o test.h

(The command above uses | to launch the 2 commands approx at the same time, but I did several other tests with the two commands launched in different command prompt windows, with similar results.)

It seems that establishing and waiting for the named pipes uses 1 or 2 seconds, but even with that overhead subtracted, the duration of the process is still 3 to 4 times slower than with eac3to alone. I don't understand why. Any idea to improve that?

Note that the MVCCombine command to combine the 2 files from HDD takes only approx 6 seconds. So, using files on hard disc instead of the pipes for the whole process takes 13 or 14 seconds. More than 2 times more rapid than using the pipes, supposed to speed the process up.

[frencher]

Small pack with CMD of MakeMKV (http://ul.to/tphq3gko) (How works it...)

[Neisklar]

...yes, that seems to be the problem:
MakeMKV creates 3D-MKVs which SP plays ok.
But if you remux the mkv-videostream from this file (with other audio- or subtitle-streams) to a new mkv-file, then SP does not recognize/playback it anymore as a 3D.

But I think that should be a simple metadata-problem, or does mkvtoolnix repack the video.mkv Stream?

Ok now i understand the problem:

It's not the h.264 stream, its the way it's packed into a mkv container.

So when you (re)mux it with mkvtoolnix (mmg.exe)
So as a guess: Did you set/check the 3D Flag in the options of the h.264 Track?

[r0lZ]

Here is a new version of BD3D2MK3D. It is not an important update. I have added a tool to demux and combine the AVC & MVC video streams with MVCCombine v0.5beta. As explained above, it is very slow, but it works. (Because that part is still in beta phase and very experimental, I have decided to releast this version here. I'll start a new thread when I'll get a more stable version to offer.)

Note that the main method to convert a movie to SBS or T&B has not been modified. It still uses the method of the old releases. MVCCombine.exe is currently used only with Tool -> MVCCombine. It should be easy, however, to modify the AVS script to use the combined.h264 streams as input. Edit the AVS script before launching the encoding. The modifications to do are documented.


# v0.17 (April 26, 2013)
# - BD Compatible bug: --fake-interlaced is now added only when the framerate is 25 or 29.976.
# - Added a warning when the user opens BD files copied to hard disc instead of a real BD disc or mounted ISO.
# - Added File -> Mount disc image (Available under Windows 8 or greater only)
# - Added Tools -> MVCCombine to combine the AVC & MVC streams of the current MPLS or external AVC/MVC files to h264 or M2TS.
# - Added Help -> MVCCombine Version
# - Removed Tools -> CombineMVC, and CombineMVC.exe from the toolset directory.
# - Added level 4.2 in the list of h264 levels. (It is necessary to encode at 48fps).


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

[vanden]

...yes, that seems to be the problem:
MakeMKV creates 3D-MKVs which SP plays ok.
But if you remux the mkv-videostream from this file (with other audio- or subtitle-streams) to a new mkv-file, then SP does not recognize/playback it anymore as a 3D.

But I think that should be a simple metadata-problem, or does mkvtoolnix repack the video.mkv Stream?
This strange because I have create AVC/MVC combined stream with MakeMKV. Remux this stream with mkvmerge (and add audio track) : it's playable with Stereoscopic Player.

And with the first version of MVCCombine, it's possible to convert the row stream, to be playable with Stereoscopic Player :
1. create a combined AVC/MVC raw stream with CombineMVC.
2. Mux this stream with MKVtoolnix.
3. open this mkv file with MakeMKV.
4. Record the file.

[arrgh]

So as a guess: Did you set/check the 3D Flag in the options of the h.264 Track?
Thank you, this motivated me to try again to edit the headers with mkvmergeGUI to : "video stereomodus = 13"
now the remuxed file works in SP!

(I thought I have tried this already! Maybe I've done something wrong the first time?!)
4. Record the file

I think this step sets the flags right...that seems to be something similar to "remux"...

Edit : strange thing is, that if I open the "original" MakeMKV-file with mkvmergeGUI it does not show any settings under "stereomode" for the videostream (it is blank)...
once patched as stereomode "13", Icaros does not show the cover anymore for the "patched" remuxed file ...
and MPC-BE doesn't seem to be able to play-back it (in 2D)
but once you have played it for a few secs in SP, it creates a SP-library entry...after this one can delete the stereomodus entry from the mkv...SP still is able to play it in 3D but in addition Icaros is showing again the cover and MPC-BE plays it back in 2D...
so its is all about taging...
MakeMKV, SP and mkvtoolnix must come together to define a standard how to handle these things.... ;-)

[frencher]

Works with "MVCCombine v0.5b" without -ano option and ready to play with "stereo player" if remux with "MakeMKV"
Package of tests here (http://ul.to/8auf5228)
The objective would be to avoid MakeMKV which is an extra step and not free
http://i44.tinypic.com/10i6s6c.png

Nobody has found a MVC encoder ? :D
Idea to submit to developers as x264 (http://x264.nl)

[Nico8583]

Idea to submit to developers as x264 (http://x264.nl)

Yes, project was started 2 years ago but not finalized...

[jdobbs]

Not sure if this matters at this point, but I thought I'd just post a note for those who have had ssifSource2() add duplicated frames at the end of a stream. It also applies to DirectshowMVCSource() when it seems to freeze at 99% during encode. I guess for a playlist that is made of a single SSIF it's no big deal -- but it causes sync issues when you are encoding/combining multiple SSIF files.

It appears to be a buffering/EOF issue, and that's why it goes away when you combine the files using "copy /b". So I did a little testing, and it also seems to be corrected if you write some zeroed packets to the end of the file, encode, and then truncate the SSIF back to its original length. Not sure how many empty packets you are required to write, but 100 seems to do the trick. You also need to put the framecount into the DirectshowMVCSource() & ssifsource2() AVISYNTH entries, but that's pretty easy to determine by using the PlayItem IN and OUT times (to get the length) in the MPLS file and the frame rate. Of course this isn't a good strategy if you are reading directly from BD -- as you can't write to it without copying it first.

Like I said, nothing dramatic, but it might help somewhere along the line.

[r0lZ]

Thanks for the useful info, jdobbs. Perhaps I'll implement your trick in BD3D2MK3D, but MVCCombine should also fix that issue, and might be simpler to use (and it should work with a disc). Great discovery anyway. :-)

[jdobbs]

Thanks for the useful info, jdobbs. Perhaps I'll implement your trick in BD3D2MK3D, but MVCCombine should also fix that issue, and might be simpler to use (and it should work with a disc). Great discovery anyway. :-)I just ran into one that 100 packets didn't work... I'll increase it to 1000 and see what happens, that's what I was using for most of the testing.

It matters for BD-RB, because I'd have to make some major changes for 3D support of I need to combine before encoding. Anyway, just experimenting.

[Edit] That one worked with 1000 packets. I'll keep testing...

[jdobbs]

Not sure if this matters at this point, but I thought I'd just post a note for those who have had ssifSource2() add duplicated frames at the end of a stream. It also applies to DirectshowMVCSource() when it seems to freeze at 99% during encode. I guess for a playlist that is made of a single SSIF it's no big deal -- but it causes sync issues when you are encoding/combining multiple SSIF files.

It appears to be a buffering/EOF issue, and that's why it goes away when you combine the files using "copy /b". So I did a little testing, and it also seems to be corrected if you write some zeroed packets to the end of the file, encode, and then truncate the SSIF back to its original length. Not sure how many empty packets you are required to write, but 100 seems to do the trick. You also need to put the framecount into the DirectshowMVCSource() & ssifsource2() AVISYNTH entries, but that's pretty easy to determine by using the PlayItem IN and OUT times (to get the length) in the MPLS file and the frame rate. Of course this isn't a good strategy if you are reading directly from BD -- as you can't write to it without copying it first.

Like I said, nothing dramatic, but it might help somewhere along the line.Ignore this... as seems to be the case with most things using these DLLs, it only works "most of the time" -- I found a file that adds the duplicate frames no matter how much I append to it. I'll keep looking at it to see what I else I can find.

[Edit] It does appear to work 100% of the time, however, if instead of null packets, I add a few blank frames. So now I just append a file called FILLER.SSIF (that contains a few blank frames) to the file instead of zeroes.

[frencher]

Ok now i understand the problem:

It's not the h.264 stream, its the way it's packed into a mkv container.

So when you (re)mux it with mkvtoolnix (mmg.exe)
So as a guess: Did you set/check the 3D Flag in the options of the h.264 Track?

It is true that sometimes i find it hard to understand me.
But I believe that arrgh just refer us to the solution ;)

[Neisklar]

Nobody has found a MVC encoder ? :D
Have a look at the Intel Media SDK:
http://software.intel.com/en-us/vcsource/tools/media-sdk. There is a MVC Encoder DirectShow filter included, as well as sample code and compiled working sample encoders (needs YUV input)

Neisklar, I did some speed tests. Unfortunately, MVCCombine using pipes is MUCH slower than eac3to alone.

I will later quickl put together a little tool to test the plain pipe speed, without the combine, buffering und threadsychronization overhead.

Thank you, this motivated me to try again to edit the headers with mkvmergeGUI to : "video stereomodus = 13"
now the remuxed file works in SP!

Works with "MVCCombine v0.5b" without -ano option and ready to play with "stereo player" if remux with "MakeMKV"
Package of tests here (http://ul.to/8auf5228)

I think we need to binary compare / binary diff a MakeMKV remuxed file with a mkvtoolnix remuxed file, to see the differences.

Not sure if this matters at this point, but I thought I'd just post a note for those who have had ssifSource2() add duplicated frames at the end of a stream. It also applies to DirectshowMVCSource() when it seems to freeze at 99% during encode.

Thats a thing all filters based on the DirectShowSource Filter-Code from Avisynth inherites. AFAIK when a certain timout is reached during the DirectShow Filtet run then the last successfull frame is given back.

[Neisklar]

I did some minor modifications to the executable, removed one silly sleep command, and added an option (-nt) to completly disabled any sleeping and waiting calls in the pipethreads.

http://www.share-online.biz/download.php?id=3VL201MMANJ

Looking at my tests, this version should even be without the -nt option around as fast as an eac3to run alone, may need at the start some more CPU, but thats only for 1-5 seconds or so.
With -nt both pipe reading threads are running without any sleep or throttling, so they will eat up 2 CPU cores at maximum, even if they mostly won't do anything. But for this you get the fasted pipereading speed as possible. Now the limiting factor will hopefully be the harddisk.

If you do your own test, please run it with -v and have a look at the 'P' values. If we still can't get them significantly down, i can decrease the memory usage

[r0lZ]

Thanks. I'll test it as soon as possible, but currently I have a big problem in my house: the boiler is broken and I have to buy and install a new one rapidly, so I don't have much time for other things.

What is the "ideal" value of the P value?

[Nico8583]

Have a look at the Intel Media SDK:
http://software.intel.com/en-us/vcsource/tools/media-sdk. There is a MVC Encoder DirectShow filter included, as well as sample code and compiled working sample encoders (needs YUV input)
Have you tried this sample ? Intel's server seems to be out of service, I'll try later...

[frencher]

I did some minor modifications to the executable, removed one silly sleep command, and added an option (-nt) to completly disabled any sleeping and waiting calls in the pipethreads.

http://www.share-online.biz/download.php?id=3VL201MMANJ

Looking at my tests, this version should even be without the -nt option around as fast as an eac3to run alone, may need at the start some more CPU, but thats only for 1-5 seconds or so.
With -nt both pipe reading threads are running without any sleep or throttling, so they will eat up 2 CPU cores at maximum, even if they mostly won't do anything. But for this you get the fasted pipereading speed as possible. Now the limiting factor will hopefully be the harddisk.

If you do your own test, please run it with -v and have a look at the 'P' values. If we still can't get them significantly down, i can decrease the memory usage

Jeeeeeeeeezzzzzzzzzzz impressive speed :)
my CMD line is:
eac3to\eac3to.exe Z:\BDMV\PLAYLIST\00001.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 | MVCCombine.exe -nt -v -p -o Out-Combined-MVC.h264
Crash with -v option
MVCCombine.exe V0.6
EAccessViolation: Zugriffsverletzung bei Adresse 004B07C4 in Modul 'MVCCombine.exe'. Lesen von Adresse 00000044

[Neisklar]

What is the "ideal" value of the P value?

P is the amount of free buffers in the pool (500 pieces), high values means the pipe is slower than the processing, if P is getting down it means the pipe is faster than the processing, in which case the huge amount of buffers has a benefit. But if the pipe is almost always slower, than there is no need to 'waste' 500MB of RAM

Have you tried this sample ? Intel's server seems to be out of service, I'll try later...

Yes, i tried it a while ago. i used the already precompiled encoder and decoder samples. they worked good but need YUV. But since there also sample code, you could build your own one, or use a direct show graph.

Jeeeeeeeeezzzzzzzzzzz impressive speed :)
my CMD line is:
eac3to\eac3to.exe Z:\BDMV\PLAYLIST\00001.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264 | MVCCombine.exe -nt -v -p -o Out-Combined-MVC.h264
Crash with -v option
MVCCombine.exe V0.6
EAccessViolation: Zugriffsverletzung bei Adresse 004B07C4 in Modul 'MVCCombine.exe'. Lesen von Adresse 00000044

I will look into the crash and try to fix it.
Edit: when did that crash happen?



Another (for me important) Off-Topic question:

Does anyone has access to the exetools forum? Please PM me.

[r0lZ]

Just did some rapid tests with my little demo BD.

The extraction alone with eac3to takes 7.5 seconds.
The combine alone (not using pipes) takes 6.3 ''.
The total with the disc only method takes therefore around 14''

With -p (no -nt), the eac3to|MVCCombine process took 10.1''
With -p and -nt, it took 10'' (but also 2 times around 11.5'', probably due to other things running on my PC.)
I haven't noticed a big difference in CPU usage.

With -p, -nt and -v, I got P = 494 and 490 (for L & R) at the beginning of the process.
L-P gradually decreased to 218, where I saw the BROKEN PIPE messages (after frame 1857). After that messages, it stays at 217 up to the last frame (4897)
Similarly, R-P decreased to 358 at BROKEN PIPE, and was then constant at 357.

I got similar values without the -nt parameter:
498 & 490 at the beginning, 310 & 404 at BROKEN PIPE and 309 & 405 after.

There is a slight difference. With -nt, all BROKEN PIPE messages were issued in one shot, after frame 1857. Without -nt, the first message appears after frame 2772, then the other messages were inserted from time to time up to frame 2800.

Of course, a test with such a short movie is not really reliable (as the HDD buffers help much more than with big files), but I don't have enough time to do long tests right now.

Anyway, very good job! The speed is now better than the method with temp files on disc (and, of course, it requires less disc space). :-)

Little suggestion: Could you add a prefix (for example "MVCC: ") to all lines output to stdout during the processing (except the progress and -v messages)? When MVCCombine is piped with eac3to, the final log is a mix of the output of both programs, and a prefix will help the humans to differentiate what program has printed what.

[Nico8583]

I have tried Intel SDK 2013, "sample_decode" works to convert H264 file created by MVCCombine to YUV420 and "sample_encode" works to convert YUV420 to MVC but space color is not good (Intel SDK 2013 uses NV12 with final file instead of YUV420). I think it needs to be recompiled with few modifications...

[frencher]

I will look into the crash and try to fix it.
Edit: when did that crash happen ?
Directly from demuxed left.h264 & right.h264 files With this cdmline
MVCCombine.exe -l "left.h264" -r "right.h264" -v -nt -o .\Out-Combined-MVC.h264

[jdobbs]

When you talk about the left and right h.264 streams, are they actually fully playable independent streams -- or is this just the two PIDs for the primary AVC video and the MVC extensions that have been demuxed from the original SSIF file(s)?