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

jumpjack

2nd April 2013, 11:14

I get this error:
Evaluate: System Exception - Access Violation on line 6

First lines of file:
LoadPlugin ("E:\documenti\Downloads\MVC Player Free v0.0.1.3\MVCtoAVI.exe\DirectShowMVCSource.dll")
LoadPlugin ("E:\documenti\Downloads\MVC Player Free v0.0.1.3\MVCtoAVI.exe\DirectShowSource.dll")

# Start AVS for Selected Tracks

Video1 = DirectShowMVCSource("D:\BDMV\STREAM\SSIF\00342.ssif",timeout=2000000,stf=13)
Audio1 = DirectShowSource ("D:\BDMV\STREAM\00342.m2ts",audio=TRUE,video=FALSE)
Video2 = DirectShowMVCSource("D:\BDMV\STREAM\SSIF\00344.ssif",timeout=2000000,stf=13)
Audio2 = DirectShowSource ("D:\BDMV\STREAM\00344.m2ts",audio=TRUE,video=FALSE)

(which one is considered 6th one?)

Tested on MenInBlack-III.
This error appears when operating on BD.
Operating on folder structure created on hard disk by MakeMKV results in nothing happening upon pressing PLAY button.

frencher

2nd April 2013, 13:13

jumpjack

2nd April 2013, 13:17

"DirectShowMVCSource.dll" not works with MakeMKV File
Have you tried this ?
http://i47.tinypic.com/343qd21.png
yes, but no luck.

Could the "access violation" be related to being reading directly from BD? Maybe the program attempts writing something to the folder where it reads data from, which is of course readonly.

r0lZ

2nd April 2013, 14:10

If your disc is an original, it is probably encrypted. You have to decrypt it on HDD first, or use AnyDVD HD to decrypt it on the fly.

frencher

2nd April 2013, 19:02

If your disc is an original, it is probably encrypted. You have to decrypt it on HDD first, or use AnyDVD HD to decrypt it on the fly.

From my original MIB III in 3D with AnyDVD HD
http://i47.tinypic.com/ddexcz.png

odyssey

11th April 2013, 09:07

BD3D2MK3D is great, but I have some problems with it.

1: Seems like eac3to is reporting an incorrect number of frames (very low - usually around 5000 frames, but a seemingly random number). This happens with all 3D blurays. Problem is the same when I try to manually extract the audio, where I only get 5-10 minutes.

2: SSIFSource2 fails to encode with x264 properly, when --preset slow is used. It gives a lot of "duplicate frame added"-errors, and the right-eye output stutters a lot.

I'm running it on XP x86 SP3. All encodes made as HOU (didn't try any other). I can't be the only one with these problems?

r0lZ: Would be nice if you could choose which method (at least SSIF or DirectShowMVCSource) should be enabled, in the GUI :)

Besides any possible failures, are there any reason to choose one method over another in terms of quality?

r0lZ

11th April 2013, 09:57

1: Seems like eac3to is reporting an incorrect number of frames (very low - usually around 5000 frames, but a seemingly random number). This happens with all 3D blurays. Problem is the same when I try to manually extract the audio, where I only get 5-10 minutes.Very strange problem. I have never seen that. Usually, the number of frames reported by eac3to is off by 1, but is it almost correct. I can only suggest to try to update eac3to, and verify with the command line or one of its GUIs if it fails again, or if it's a bug in BD3D2MK3D.

2: SSIFSource2 fails to encode with x264 properly, when --preset slow is used. It gives a lot of "duplicate frame added"-errors, and the right-eye output stutters a lot.Again something new for me. I have already noticed once a missing or duplicated frame in one of the views (causing a slight left/right desync), but I have never notices numerous additional frames. Anyway, I doubt --preset slow could be the cause, as x264 should encode what it receives, regardless of the preset.

r0lZ: Would be nice if you could choose which method (at least SSIF or DirectShowMVCSource) should be enabled, in the GUI :)
Menu Settings -> Use ssifsource2 for SBS/T&B

Besides any possible failures, are there any reason to choose one method over another in terms of quality?Normally no. Both should produce correctly decoded frames. The main limitation with ssifsource2 is that it can encode only in SBS or Top/Bottom, but it seems to crash less with MPLS containing many SSIF parts, and it's why BD3D2MK3D offers to use it anyway for SBS or T&B if it's the case.

odyssey

11th April 2013, 10:07

I can only suggest to try to update eac3to, and verify with the command line or one of its GUIs if it fails again, or if it's a bug in BD3D2MK3D.
I'm already on 3.27 and as I mentioned, I have the same problem when I extract the audio, so I can say for sure that it's not a problem with BD3D2MK3D. I just posted in this thread, as it seems to be a problem with 3D disks only.

Again something new for me. I have already noticed once a missing or duplicated frame in one of the views (causing a slight left/right desync), but I have never notices numerous additional frames. Anyway, I doubt --preset slow could be the cause, as x264 should encode what it receives, regardless of the preset.

I would think that too, but it's quite obvious. The first pass is fine, and when it goes on to pass 2 it triggers throughout. When you think about it, it makes sense - preset slow uses more reference frames, so it has to look way beyond what it usually does, and maybe SSIFSource can't handle that properly. Could be related to the same problem, that you can't search with the plugin.

Would be great if you could test it. I may also try to do another install with Windows 7 to see if that makes a difference.

r0lZ

11th April 2013, 10:51

The first pass is fine, and when it goes on to pass 2 it triggers throughout. When you think about it, it makes sense - preset slow uses more reference frames, so it has to look way beyond what it usually does, and maybe SSIFSource can't handle that properly. Could be related to the same problem, that you can't search with the plugin.Indeed, that might be the cause of the proble. Usually, I encode in CRF mode, medium or slow preset, and have never noticed that problem. I'll try a slow 2-pass encode...

I may also try to do another install with Windows 7 to see if that makes a difference.
Currently, what OS do you have? (I have W8 x64, and an old partition with W7 x64.)

Nico8583

11th April 2013, 11:11

I had the same problem of duplicated frames, it was because frames number was wrong...

24673583

11th April 2013, 11:13

BD3D2MK3D，I use BD compatible.
But encoded .264 is 1920*1080i/23.976 (not BDspec)

odyssey

11th April 2013, 11:13

I had the same problem of duplicated frames, it was because frames number was wrong...
I used the number of frames as reported by DirectShowMVCSource for SSIFSource2 and got the error. Is there another way to determine the correct number of frames?

r0lZ

11th April 2013, 11:26

Try xport.exe. (It is included in the toolset of BD3D2AVS, but not with BD3D2MK3D. If you need it, you can download it here (http://download.videohelp.com/r0lZ/tmp/xport.7z).)

The CLI syntax to check the number of frames only is:
xport.exe -phs "path\to\file.m2ts" 1 1 1
Note that you must use the corresponding M2TS file. It doesn't work with MPLS or SSIF. If there are several parts in the MPLS, you have to check the number of frames of all M2TS files, and add them together.

r0lZ

11th April 2013, 11:30

BD3D2MK3D，I use BD compatible.
But encoded .264 is 1920*1080i/23.976 (not BDspec)Can you check what's wrong in the command line? (You can find it in the log.)
I have added that "BD compatible" option at the request of a user, but I don't know exactly what options must be added. It's not simple. Currently, the option --fake-interlaced is included, as it seems mandatory, but I may be wrong.

24673583

11th April 2013, 13:13

Can you check what's wrong in the command line? (You can find it in the log.)
I have added that "BD compatible" option at the request of a user, but I don't know exactly what options must be added. It's not simple. Currently, the option --fake-interlaced is included, as it seems mandatory, but I may be wrong.

now,I have added the command line in the option "--fake -interlaced"

x264 command:
"D:\Soft\BD3D2MK3D\toolset\stereoplayer.exe\x264.exe" ^
--bitrate 25000 --pass 1 --stats "00003_m2ts.stats" --preset medium ^
--bluray-compat --profile high --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4 ^
--open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709 --b-pyramid strict --fake-interlaced --aud ^
--output "00003_m2ts.264" "_ENCODE_3D_MOVIE.avs"
"D:\Soft\BD3D2MK3D\toolset\stereoplayer.exe\x264.exe" ^
--bitrate 25000 --pass 2 --stats "00003_m2ts.stats" --preset medium ^
--bluray-compat --profile high --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4 ^
--open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709 --b-pyramid strict --fake-interlaced --aud ^
--output "00003_m2ts.264" "_ENCODE_3D_MOVIE.avs"

but The result of coding is no change (1920*1080i/23.976)

Sharc

11th April 2013, 18:25

now,I have added the command line in the option "--fake -interlaced"
but The result of coding is no change (1920*1080i/23.976)
Strange. 1080i/23.976 is indeed not BD compliant. The command line looks ok without --fake interlaced.
--fake-interlaced is only needed when you encode progressive although the blu-ray standard requires that the particular resolution/framerate should be interlaced. These are quite exceptional cases.

What are the resolution and framerate of your source?
From where do you get the info that it has been encoded as interlaced (1080i)?

frencher

11th April 2013, 21:33

I used the number of frames as reported by DirectShowMVCSource for SSIFSource2 and got the error. Is there another way to determine the correct number of frames?

Hi odyssey,

What name of your Bluray 3D and files used (.ssif)

frencher

11th April 2013, 21:53

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

Extract and run directly MVC Player Free.exe or play associated file with MVC Player Free.exe
# Major fix: For correct Left, Right, SBS & UO for preview and output (Press LOAD button before... fix in progress)
# Added: Left mouse clic directly to playlist select & deselct only one (m2ts+ssif)
# Added: Right mouse clic to playlist select & deselct all (m2ts+ssif)
# Some fixes
http://i45.tinypic.com/zikidh.png

24673583

12th April 2013, 09:36

Strange. 1080i/23.976 is indeed not BD compliant. The command line looks ok without --fake interlaced.
--fake-interlaced is only needed when you encode progressive although the blu-ray standard requires that the particular resolution/framerate should be interlaced. These are quite exceptional cases.

What are the resolution and framerate of your source?
From where do you get the info that it has been encoded as interlaced (1080i)?

from 3d blu ray disc(1080p/23.976)

drap to TSMuxGui，the .264 is 1080i.

frencher

13th April 2013, 09:58

from 3d blu ray disc(1080p/23.976)

drap to TSMuxGui，the .264 is 1080i.

VC-1 or h264 ?

24673583

15th April 2013, 13:31

VC-1 or h264 ?

i use BD3D2MK3D encoding h264

r0lZ

15th April 2013, 13:48

Strange. 1080i/23.976 is indeed not BD compliant. The command line looks ok without --fake interlaced.
--fake-interlaced is only needed when you encode progressive although the blu-ray standard requires that the particular resolution/framerate should be interlaced. These are quite exceptional cases.
I don't understand. If the BD-specs require interlaced, an interlaced input should be encoded as it, and a progressive input should be encoded with --fake-interlaced. In all cases, the output should be interlaced (real or fake). Right?

Also, I suppose that --fake-interlaced doesn't hurt if the input is already interlaced. That option should do nothing in that case. But I may be wrong.

Any pointer will be appreciated.

Sharc

15th April 2013, 20:51

If the BD-specs require interlaced, an interlaced input should be encoded as it, and a progressive input should be encoded with --fake-interlaced.
Yes.
--fake-interlaced just fools the playback device by pretending (=fake) that the progressive video is interlaced.
Also, I suppose that --fake-interlaced doesn't hurt if the input is already interlaced. That option should do nothing in that case. But I may be wrong.
When the input (source) is interlaced it should be encoded with --tff. Not sure if the superfluous --fake-interlace will hurt in this case (probably not).
Any pointer will be appreciated.
A comprehensive overview about the legal blu-ray formats is given in this sticky. (http://forum.doom9.org/showthread.php?p=1399419#post1399419)

r0lZ

15th April 2013, 22:25

OK, thanks. So, it seems that only the frame rates at 25 and 29,97 fps must be interlaced. All other frame rates (regardless of the image resolution) must be encoded in progressive mode. In that other frame rates, I should simply remove the --fake-interlaced option from the command line and everything should be OK.

now,I have added the command line in the option "--fake -interlaced" [...] but The result of coding is no change (1920*1080i/23.976)
That's right. It's because the --fake-interlaced option is added anyway when the BD compatible option is ticked. My fault! (If you add it manually, it is not added twice in the command, because BD3D2MK3D detects that it is already present.)

I'll fix that problem in the next version. In the meantime, you can edit the batch file with the x264 command to manually remove that option. Sorry, you'll have to encode again. If you do it, please confirm that your stream is BD compliant.

Sharc

15th April 2013, 23:28

OK, thanks. So, it seems that only the frame rates at 25 and 29,97 fps must be interlaced.
Correct. If such sources are interlaced they should be encoded using --tff; if you know they are progressive you may use --fake-interlaced instead.
All other frame rates (regardless of the image resolution) must be encoded in progressive mode.
Correct. Caution however when downsizing 25 or 29.97 fps 1080i interlaced sources to 720p: You would need to deinterlace (bob, doubling the framerate), downsize and encode as progressive.

r0lZ

16th April 2013, 06:28

Thanks for the confirmation.
Caution however when downsizing 25 or 29.97 fps 1080i interlaced sources to 720p: You would need to deinterlace (bob, doubling the framerate), downsize and encode as progressive.
Luckily, when encoding a 3D BD source, we can probably safely assume that the input video is always progressive (and usually at 23.976 fps).

24673583

16th April 2013, 09:02

OK, thanks. So, it seems that only the frame rates at 25 and 29,97 fps must be interlaced. All other frame rates (regardless of the image resolution) must be encoded in progressive mode. In that other frame rates, I should simply remove the --fake-interlaced option from the command line and everything should be OK.

That's right. It's because the --fake-interlaced option is added anyway when the BD compatible option is ticked. My fault! (If you add it manually, it is not added twice in the command, because BD3D2MK3D detects that it is already present.)

I'll fix that problem in the next version. In the meantime, you can edit the batch file with the x264 command to manually remove that option. Sorry, you'll have to encode again. If you do it, please confirm that your stream is BD compliant.

Thank you.
I believe that the next version, we will get a better experience
Thanks again！

Neisklar

17th April 2013, 15:46

Hi folks,

only a short post, having to much work for to few hours.

Here is an CLI Version of MVCCombine:
http://www.share-online.biz/download.php?id=5HN7MELMCJW

This version is waaayyyyy faster than the old one (did an combine in 20minutes, and the limiting factor was the external harddrive i used).
Stupid me had an 8 MB Buffer allocated and deallocated in an average movie around 100.000 times instead of simply reusing, which slowed all down like hell.

Have fun and sorry for being making me so sparse

frencher

19th April 2013, 06:00

r0lZ

20th April 2013, 13:29

Here is an CLI Version of MVCCombine:
http://www.share-online.biz/download.php?id=5HN7MELMCJW
Thanks! It works very well, and indeed it is fast! :-)

But I have a request. Could you add an option to output the progress messages one line at a time, instead of using BS characters to erase the previous line? Currently, it is very difficult to parse the output from a GUI. (For whatever reason, Tcl misses sometimes a character, and therefore it is not possible to simply read 86 characters at a time.)

I would also like to know if it issues warnings or error messages when something goes wrong, and if it does it to stdout or stderr. And is the return code non-zero in case of error?

Also, do you plan to implement named pipes? It's the only thing that is still necessary to automate the direct conversion from an unencrypted BD to a M2TS file directly. That would be very nice for BD3D2MK3D.

Thanks in advance.

frencher

20th April 2013, 23:21

Also, do you plan to implement named pipes?

I tried but it does not reach use pipes work either for me.

Is it possible to export in the same format as "MakeMKV" because it seems that some media player coming to MVC Format (.mkv & .iso) with hdmi 1.4 :)
This box is HERE (http://www.01net.com/fiche-produit/fiche-technique-12324/disques-durs-multimedias-xtreamer-sidewinder-3)
Same for "Power DVD" & "Stereoscopic Player"

Nice speed and good works Neisklar ;)

Neisklar

22nd April 2013, 14:16

But I have a request. Could you add an option to output the progress messages one line at a time

Yes, but that need some time, since i'm currently at trying to implement multithreading (needed for pipes) and didn't save the old code, since it was working.

I would also like to know if it issues warnings or error messages when something goes wrong, and if it does it to stdout or stderr. And is the return code non-zero in case of error?

No there is nothing i did implement. If the App crashed there maybe some returncode from the runtime, but not from the app.

Also, do you plan to implement named pipes?

Yes, it's in the working, but difficult. First i need to go multithreading, and seperate and more importantly buffer the reading of the two streams. I had something hacked together but it's not working, some researching it's an error in the framework, so i need to do some more coding myself and multithreading coding without the proper libs is hell.

Is it possible to export in the same format as "MakeMKV

Yeah it's possible, but are your sure it's needed?
The difference between MakeMKV and my combiner ist only the order of the NALUs from the two streams, MakeMKV simply outputs for one frame first ALL NALUs from the left eye, then all from the right eye. I instead for one frame group some NALUs together depending on the type. If i remember correctly thats also what i had read somewhere a long time ago. But doing different NALU-orders shouldn't a big problem.

So my next goal is to get each stream-reader as seperate thread, with read-ahead and buffering, then piping should hopefully not be such a hassle.

r0lZ

22nd April 2013, 14:52

Thanks. BTW, I've also tried to implement the pipes using Tcl. With an additional library, I can create the pipes, and I have been able to get simple DOS commands such as echo and type working from 2 different command prompt windows, using the pipe established by a Tcl script. But currently, I can't get eac3to and MVCCombine to work together. eac3to prints that it opens the second pipe (used for the MVC stream), but then it stops, and MVCCombine doesn't seem to receive its output. Not sure why. Perhaps it's because they have to communicate 2 files. Anyway, I guess that stuff will be much easier to implement if MVCCombine supports the pipes internally, at least for me! ;-)

I've also added a GUI to launch MVCCombine in BD3D2MK3D. It can process 2 files already saved on HDD, or the GUI can also demux them from the BD, then launch MVCCombine. There is also an option to convert the combined stream to M2TS with tsMuxeR. That works fine, but it's slow due to the numerous large temp files that must be written to HDD.

Also, currently, due to the way the progress messages are written, I can't display the eta and other information, but I've managed to get the percentage of the progress, and that's sufficient to update the progress bar. Note that tsMuxeR handles its progress messages very well. It uses BS characters like you when the output is a console window, but it prints individual lines (with CR/LF) when its output has been redirected to a file. Not sure how it detects that, but that's very handy. Anyway, a new MVCCombine option to specify that we want plain lines should be sufficient.

Neisklar

22nd April 2013, 15:00

Thanks. BTW, I've also tried to implement the pipes using Tcl. With an additional library, I can create the pipes, and I have been able to get simple DOS commands such as echo and type working from 2 different command prompt windows, using the pipe established by a Tcl script. But currently, I can't get eac3to and MVCCombine to work together. eac3to prints that it opens the second pipe (used for the MVC stream), but then it stops, and MVCCombine doesn't seem to receive its output. Not sure why. Perhaps it's because they have to communicate 2 files. Anyway, I guess that stuff will be much easier to implement if MVCCombine supports the pipes internally, at least for me! ;-)

Try to use 2 eac3to instances, one for each stream. Then it maybe work.
(Thats why the (multithreaded) buffering stuff is needed. With one instance eac3to writes both streams in parallel, it may be that the MVCCombine needs some data from stream 2, which eac3to hasn't written yet to the pipe. But in the same time eac3to has written so much data to pipe 1 that it's full. So it stops outputting stuff till pipe 1 has some space, but the combiner waits for data on pipe 2)

r0lZ

22nd April 2013, 15:14

Yes, it's what I suspected. I'll try with 2 instances of eac3to. Thanks for the tip!

Neisklar

22nd April 2013, 20:50

I uploaded a first multithreaded version:
http://www.share-online.biz/download.php?id=WHVG9OLMBD

Changes:
* reader and parser for each stream in seperate thread
* progress-output only every 0,5 seconds
* output should be more logging friendly, if that is not enough there is an '-ml' param

Please don't overwrite you old version, just i case this one produces garbage. I would like two know if this ones working correctly (eg comparing an md5 hasah of an combined.h264 of the previous version with a hash of the output of this version) Also i would like to know, if there are some speed benefits on multiprocessor CPUs.
I'm also not sure id there are any memory leaks or so, also the threading stuff may deadlock, so the exe needs to be killed. (Also there are some internal timeouts set to really long values)

Next step: Trying the pipe stuff;-)

frencher

22nd April 2013, 22:06

Thanks Neisklar.

Yeah it's possible, but are your sure it's needed?
The difference between MakeMKV and my combiner ist only the order of the NALUs from the two streams, MakeMKV simply outputs for one frame first ALL NALUs from the left eye, then all from the right eye. I instead for one frame group some NALUs together depending on the type. If i remember correctly thats also what i had read somewhere a long time ago. But doing different NALU-orders shouldn't a big problem.
I'm really interested because i shop afterwards the magic HD box mkv (AVC/MVC) (http://www.01net.com/fiche-produit/fiche-technique-12324/disques-durs-multimedias-xtreamer-sidewinder-3)

eac3to return
Video track 1 contains 139268 frames
Video track 2 contains 139268 frames

With corrupted left & right video track on i7 3930k and 2 HDD SATA 3 ;)
v0.1
F:\MVCCombine.exe -l "left.h264" -r "right.h264" -o "L:\Out.h264"
Frame 139269 written (100,00%) - 0:06:37 - 0:00:00
done, cleaning up
v0.2
F:\MVCCombine.exe -l "left.h264" -r "right.h264" -o "L:\Out.h264"
AnnexBReader-Thread started: left.h264
AnnexBReader-Thread started: right.h264
Frame 34397 written (24,82%) - 0:01:34 - 0:04:44
AnnexBReader-Thread ended: right.h264
Frame 34584 written (24,95%) - 0:01:34 - 0:04:44
Debug: Terminated and Pushed=Popped
Right Queue EOF: 3
Frame 138968 written (69,66%) - 0:03:48 - 0:01:39
will terminate: left eye.h264
AnnexBReader-Thread ended: left.h264
Debug: Terminated and Pushed=Popped
Left Queue EOF: 3
Frame 139272 written (69,71%) - 0:03:48 - 0:01:39

done, cleaning up
END
Runtime error 217 at 0042102A

r0lZ

22nd April 2013, 22:47

Thanks Neisklar. I did a quick test with a very short demo clip, and the output is exactly identical than with v0.1.
I can't compare the speed, but the process took approx 10 seconds with both programs.
I'll check the progress output and -ml tomorrow.
* progress-output only every 0,5 secondsGood idea! It's something I wanted to suggest. :-)

frencher

23rd April 2013, 01:04

eac3to return
Video track 1 contains 134853 frames
Video track 2 contains 134853 frames

With clean left & right video track on i7 3930k and 2 HDD SATA 3 ;)
v0.1 CPU ~4%
F:\MVCCombine.exe -l "left.h264" -r "right.h264" -o "L:\Out.h264"
Frame 134853 written (100,00%) - 0:03:57 - 0:00:00
done, cleaning up

v0.2 CPU ~6%
F:\MVCCombine.exe -l "left.h264" -r "right.h264" -o "L:\Out.h264"
AnnexBReader-Thread started: left.h264
AnnexBReader-Thread started: right.h264
Frame 134456 written (99,76%) - 0:04:11 - 0:00:01
will terminate: right.h264
AnnexBReader-Thread ended: right.h264
Frame 134730 written (99,96%) - 0:04:12 - 0:00:00
will terminate: left.h264
AnnexBReader-Thread ended: left.h264
Debug: Terminated and Pushed=Popped
Left Queue EOF: 3
Debug: Terminated and Pushed=Popped
Right Queue EOF: 3
Frame 134853 written (100,00%) - 0:04:12 - 0:00:00

done, cleaning up
END

r0lZ

23rd April 2013, 09:44

Yesterday, I did 2 tests only, and from my GUI. Both versions worked apparently at approx the same speed. But today I did several tests from CLI, and I must say that v0.2 is much slower. With v0.1, the clip is combined in 7 seconds, and it takes 14 or 15 seconds with v0.2.

Also, v0.2 has crashed one time (with exactly the same input and output files than with my other tests). The crash occurred at the END of the processing, when "END" is already printed to stdout. Here is the Windows error info:

Problem signature:
Problem Event Name: APPCRASH
Application Name: MVCCombine.exe
Application Version: 0.0.0.0
Application Timestamp: 5175923b
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.2.9200.16451
Fault Module Timestamp: 50988950
Exception Code: 0eedfade
Exception Offset: 00014b32
OS Version: 6.2.9200.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 4094
Additional Information 2: 4094f881f329e48ad5dfccb7d7c90af5
Additional Information 3: a39e
Additional Information 4: a39e30719cfd568b24926134fa32031a

When I've closed the dialog, I've seen this in the command prompt window:

Runtime error 217 at 0042102A

I don't understand why it crashed only once.

Also, I notice that the file size is only 837 KB for v0.1 and 5104 KB for v0.2. Is it because v0.2 has the debug information? That might explain the slow speed.

frencher

23rd April 2013, 12:36

Also, I notice that the file size is only 837 KB for v0.1 and 5104 KB for v0.2. Is it because v0.2 has the debug information? That might explain the slow speed.

I think v0.2 uses a code snippet of v0.0 (GUI)

r0lZ

23rd April 2013, 13:10

I did a new test with a real movie (from my GUI), but it crashed two times with the same error code, at approx 60% of the process: Runtime error 217 at 0042102A

Also, I've noticed that it consumes much memory. Before the crash, it was eating 301MB. That seems a bit too much, but I'm not sure. Anyway, my PC was not out of memory when it crashed.

I'm doing currently the same test, but from the command line, to see if that makes a difference.

[EDIT]
Same problem from command line:

[...]
Frame 140401 written (61.11%) - 0:06:09 - 0:03:55
will terminate: D:\BD3D2MK3D_projects\BD3D-demo\test_AVC_TEMP.h264
AnnexBReader-Thread ended: D:\BD3D2MK3D_projects\BD3D-demo\test_AVC_TEMP.h264
Debug: Terminated and Pushed=Popped
Left Queue EOF: 3
Frame 140835 written (61.28%) - 0:06:09 - 0:03:53

done, cleaning up
END
[Windows APPCRASH dialog appears here]
Runtime error 217 at 0042102A

[EDIT2]
Confirmed with another BD. Exactly the same problem, at 65% of the progress.

Neisklar

23rd April 2013, 16:13

Thanks for all the test, multithreaded programming is at least for me difficult.

I don't understand why it crashed only once.

Thats typical with bugs in multithreaded code. Sometimes it happens, sometimes not, and finding the bug is really hard due to different timing issues.

Also, I notice that the file size is only 837 KB for v0.1 and 5104 KB for v0.2. Is it because v0.2 has the debug information? That might explain the slow speed.

I used much more stuff from the Framework delphi provides so thats the size, beside the debug mode. The debug mode shouldn't be so a big speed impact.
Its more the syncronization between the threads, waiting for each other and so on.

I have an halfway working pipe thing reading, which is even before alpha, that's even slower currently.

The crash occurred at the END of the processing, when "END" is already printed to stdout.

Something in the cleanup got wrong, i think because the reader threads were already terminated.

it was eating 301MB. That seems a bit too much, but I'm not sure.
Thats right, for (hopefully) speedoptimation i create a large number on bigger buffers already on startup (pure combined buffer size is 250 MB, add to that some object overhead)

The Piping-Alpha currently needs at least 1,5 GB (G!) for Avanger3D to not hang (6000 NALU objects with 256kB Buffer, which are most of the time only filled with 2-5%. The old GUI-Version was slow because it allocated and deallocated these objects all the time. I think, speed is more important than memory usage, i could at least expect 2Gigs to use)
Edit2:
if i use 2 eac3to processes for each stream in the Piping-Alpha, i come along with around 1000 Objects as buffer, it would even work with 500 i think. eac3to outputs not really the data in parallel when doing dualstreaming extracting, its more like, some KB left, some KB right, and so on.

AnnexBReader-Thread ended:

This line should only occur at the end. Due to multithreading and buffering not exactly after 100%, shortly before.
r0lZ, if you look at the successful run from frencher, you see it shortly before the end, thats where it should be, if not there is something wrong. An ended Thread (with a "will terminate" line shortly before) normally means that the end of the source file was reached, but then the percentage done should be much higher, since it is calculated from the bytes already read from both files, and the sum of the filesize of both files.

Edit: Just to get sure: The old single threaded V0.1 works correctly with the input files?

------------
Edit3:

Just for testing, or having fun
http://www.share-online.biz/download.php?id=RQWNSPLMWAS
Piping halfway working (needs default 1,5GB RAM) :)
MVCCombine.exe -p -o combined.h264
If it hangs halfway, add an -qs 4000 or -qs 5000 (needs even more RAM)

Start the combiner, then start eac3to in the following way:
eac3to.exe X: 1) 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264

r0lZ

23rd April 2013, 18:48

Edit: Just to get sure: The old single threaded V0.1 works correctly with the input files?
I haven't tried with v0.1. I'll do it now...

Just for testing, or having fun
http://www.share-online.biz/download.php?id=RQWNSPLMWAS
Piping halfway working (needs default 1,5GB RAM) :)

If it hangs halfway, add an -qs 4000 or -qs 5000 (needs even more RAM)

Start the combiner, then start eac3to in the following way:
Thanks. If I understand correctly, the inputs pipe names are hardcoded to \\.\pipe\left.h264 and \\.\pipe\right.h264. Right?

Will you also add the possibility to output to a pipe? That's useful to produce the M2TS in one shot.

r0lZ

23rd April 2013, 19:30

I haven't tried with v0.1. I'll do it now...Done. It worked without problem.

r0lZ

23rd April 2013, 19:36

MVCCombine03a.exe -p -qs 5000 -o test.h264
AnnexBReader-Thread started: \\.\pipe\left.h264
PipeMode: Pipe connecting Loop started
Pipe (\\.\pipe\left.h264) created and waiting
EAccessViolation: Zugriffsverletzung bei Adresse 004AF57B in Modul 'MVCCombine03a.exe'. Lesen von Adresse 00000004

:(
[EDIT] It seems that that error happens only when -qs 5000 or -qs 4000 is specified. Without -qs parameter, the program seems to work. Currently combining. It uses currently 1505 MB RAM.

The progress message is something like this:

Frame 9322 written (100.00%) - 0:01:49 - 0:00:00

I suppose MVCCombine cannot compute the % and eta because it doesn't know the number of frames. Right?
If it's the case, could you add an option to specify it (just to update the progress message correctly; it should not stop when the number of frames is reached).

Neisklar

23rd April 2013, 19:42

I haven't tried with v0.1. I'll do it now...

Thanks. If I understand correctly, the inputs pipe names are hardcoded to \\.\pipe\left.h264 and \\.\pipe\right.h264. Right?

Will you also add the possibility to output to a pipe? That's useful to produce the M2TS in one shot.

Yes, it's just a quick try so hardcoding, i may add an option to overwrite it. And pipe output is on the todo, and luckyly thats really easy, no threading needed. But i will only work if the final executable will not try to seek, only opening and reading is supported.

There are in the moment some conceptual mistakes in the combiner and the pipe reading, i need to redesign all the threads and the task of each thread.

If we can get our hands on some m2ts muxer code, i could also directly implement it.

r0lZ

23rd April 2013, 20:59

I can confirm that v0.3alpha works, as long as -qs is not specified:

MVCCombine03a.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 127696 written (100.00%) - 0:24:37 - 0:00:00
Pipe Read OK: 232 read: 235391
Pipe-Read returned with BROKEN_PIPE, this means EOF...
will terminate: \\.\pipe\right.h264
AnnexBReader-Thread ended: \\.\pipe\right.h264
Pipe Read OK: 232 read: 30730
Frame 127769 written (100.00%) - 0:24:37 - 0:00:00
Frame 127769 written (100.00%) - 0:24:37 - 0:00:00
Pipe-Read returned with BROKEN_PIPE, this means EOF...
will terminate: \\.\pipe\left.h264
AnnexBReader-Thread ended: \\.\pipe\left.h264
Debug: Terminated and Pushed=Popped
Left Queue EOF: 3
\\.\pipe\left.h264: FreePool pop/push: 1040198/1043197
\\.\pipe\left.h264: Queue pop/push: 1040197/1040197
Debug: Terminated and Pushed=Popped
Right Queue EOF: 3
\\.\pipe\right.h264: FreePool pop/push: 1046130/1049129
\\.\pipe\right.h264: Queue pop/push: 1046129/1046129
Frame 127801 written (100.00%) - 0:24:37 - 0:00:00

done, cleaning up
END

eac3to.exe G:\BDMV\PLAYLIST\00000.mpls 2: \\.\pipe\left.h264 3: \\.\pipe\right.h264
M2TS, 2 video tracks, 4 audio tracks, 4 subtitle tracks, 1:28:50, 24p /1.001
1: Chapters, 24 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: DTS, French, 5.1 channels, 1509kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
7: AC3, Modern Greek, 5.1 channels, 640kbps, 48kHz
8: Subtitle (PGS), English
9: Subtitle (PGS), Modern Greek
10: Subtitle (PGS), Romanian
11: Subtitle (PGS), Swedish
v02 Extracting video track number 2...
v03 Extracting video track number 3...
v03 Creating file "\\.\pipe\right.h264"...
v02 Creating file "\\.\pipe\left.h264"...
Video track 2 contains 127800 frames.
Video track 3 contains 127800 frames.
eac3to processing took 24 minutes, 19 seconds.
Done.

Yes, it's just a quick try so hardcoding, i may add an option to overwrite it.
That's necessary imo. With the hardcoded names, you cannot run several instances at the same time. (Not sure it's useful, but people will certainly do it!)

And pipe output is on the todo, and luckyly thats really easy, no threading needed. But i will only work if the final executable will not try to seek, only opening and reading is supported.
Not sure tsMuxeR needs to seek. I haven't tried yet.

If we can get our hands on some m2ts muxer code, i could also directly implement it.
Yes, that would be nice. I'm not sure, but IIRC, the source code of tsMuxeR has been available, but it has been removed. Perhaps it is still possible to obtain it somewhere.

I have another little suggestion. Could you count the frames starting at 0? Most video tools do that. Not really important, but more consistent.