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

[r0lZ]

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)

[slavanap]

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]

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]

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]

..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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[Thalyn]

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]

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

[slavanap]

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]

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!

[allanlee]

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]

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.

[allanlee]

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]

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 ?

[r0lZ]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[r0lZ]

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

[sef]

..ssif fragment?

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

[frencher]

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]

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?