Free H.264 MVC 3D Encoder

[videofan3d]

Exactly.
I want do something like this:

I will thing about it :)

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?

[videofan3d]

v1.11 named pipe still does not work here. Now I get the error:
Error: Unknown codec

Unknown codec - you have likely wrong command line, some hyphen "-" is missing, or you have there extra space.

[tymoxa]

Good news we already have decoder which can do it for you and yes you can use X.264 encoder with it.
You are referencing to DirectShow MVC Source.dll? It's not an option to me.

[tymoxa]

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?
We already have pure_L.h264. I want pure_R.h264.

[HWK]

You are referencing to DirectShow MVC Source.dll? It's not an option to me.

May I know why, if that is ok with you?

[Eseninzhiv]

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

is it possible to add the conversion directly from the file SSIF?

[Sharc]

@videofan3d
I confirm that separate input files and named pipe now work perfectly with v1.11:

FRIMDecode.exe mvc -i base.264 -i dependent.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O

:thanks:

[tymoxa]

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

That's odd. In my tests both methods give me the same size of .yuv's.

[Sharc]

Does this mean I can feed it demuxed h264 files directly from a 3DBD?
Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools, like:
FRIMDecode.exe mvc -i 00049.track_4113.264 -i 00050.track_4114.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 8000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O(I included resizing to 1280x720 in the example)
=> You will get re-encoded base *.avc and dependent *.mvc streams.
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[videofan3d]

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed


This is strange - for investigation I need to simulate it.
How did get the original combined file and related separated files? Please describe me process in order to reproduce it.

[Eseninzhiv]

demux SSIF via tsMuxeR 2.1.6
1. MVC combined, use the utility http://forum.doom9.org/showthread.php?p=1628058#post1628058 files are the same
2. MVC separate, demux SSIF via tsMuxeR 2.1.6 http://i.imgur.com/haAbf6b.png

if demux with eac3to playlist, all right, files are the same
eac3to probably adds at the end of an empty frame
eac3to v3.24
command line: "F:\3D\H.264 MVC 3D Decoder\eac3to v3.24\eac3to.exe" "J:\BDMV\PLAYLIST\00250.mpls" 01: l.h264 02: r.h264
------------------------------------------------------------------------------
M2TS, 2 video tracks, 3 audio tracks, 3 subtitle tracks, 0:01:41, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/AVC (right eye), 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: AC3, Russian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), French
7: Subtitle (PGS), Dutch
8: Subtitle (PGS), Russian
[v02] Extracting video track number 2...
[v01] Extracting video track number 1...
[v02] Creating file "r.h264"...
[v01] Creating file "l.h264"...
Video track 1 contains 2419 frames.
Video track 2 contains 2420 frames.
eac3to processing took 4 seconds.
Done.

[videofan3d]

Post was geared towards videofan3d :p

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

[HWK]

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

Ok I will try again and see what happens.

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.

[Cedvano]

Works fine for me.
Thank you very much videofan3D.

[Sharc]

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.
Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

Edit:
Oooops! It runs for some time (few thousand frames), then FRIMencode crashes with the error
M_Alloc; error allocing 4552128
Doing more tests .....

Edit2:
Encoding a 2 hours movie with named pipes worked flawlessly and was reasonably fast.
Interesting that the original had a file size ratio dependent/base = 0.304 (which is exceptionally low, more typical ratios seem to be around 0.5), while after encoding with FRIMenocde this ratio became 0.83.

[HWK]

Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

That would be helpful, Although I own mainconcept mvc encoder but I want to help improve this as well.

In the mean time I would also try using ssif file decoder as well which doesn't rely on directshowmvcsource to decode file.

[colinhunt]

Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso
Awesome answer, thank you Sharc!

[Cedvano]

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.


Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with eac3to
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[frencher]

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

@videofan3d

1 minute is too short for view from AVS problem
I have upload full video demo and log report with 266804 total frames (AVC/MVC from "MVCcombined.264")
Download:
FRIMDecode YUV FRIMEncode - VS - From AVS Script.rar (http://ul.to/k4q11xt8)
Watch FRIMDecode YUV FRIMEncode - VS - From AVS Script.mkv (include into package) before explore folder and report :logfile:

Low CPU Usage for recode, it's possible to add CPU optimisation ? x264x64 use 100% of my CPU (i7 3930k)
http://i42.tinypic.com/4j6kjk.png

Thanks for your bigest works ;)

[Sharc]

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.
Strange; should perhaps be reported to physic.
What is the consequence of the 1 frame difference? Does the encoding fail?

[Cedvano]

Strange; should perhaps be reported to physic.
What is the consequence of the 1 frame difference? Does the encoding fail?

No fail in encoding, but black screen with the TsMuxeR ISO.

[Sharc]

No fail in encoding, but black screen with the TsMuxeR ISO.
I haven't seen this happening in my tests yet.... :confused:

[videofan3d]

demux SSIF via tsMuxeR 2.1.6
1. MVC combined, use the utility http://forum.doom9.org/showthread.php?p=1628058#post1628058 files are the same
2. MVC separate, demux SSIF via tsMuxeR 2.1.6 http://i.imgur.com/haAbf6b.png

if demux with eac3to playlist, all right, files are the same
eac3to probably adds at the end of an empty frame

I also realized this symptom on one .ssif file.
(Not sure if problem is in .ssif itself, or in combining AVC+MVC, or in FRIM Decoder).
This I need to investigate...

[videofan3d]

@videofan3d

1 minute is too short for view from AVS problem
I have upload full video demo and log report with 266804 total frames (AVC/MVC from "MVCcombined.264")
Download:
FRIMDecode YUV FRIMEncode - VS - From AVS Script.rar (http://ul.to/k4q11xt8)
Watch FRIMDecode YUV FRIMEncode - VS - From AVS Script.mkv (include into package) before explore folder and report :logfile:


Friends,

I have looked to your issue with DirectShowMVCSource.dll in debugging mode.
And very clearly - problem is in DirectShowMVCSource itself.

Let me shortly describe you how FRIM Encoder works.

FRIM Encoder opens and read avi file using VWF (Video For Windows) API - which is standard part of Windows from version 3.x.
Avisynth script "input.avs" behaves like regular AVI and is for FRIM Encoder fully transparent.

Once FRIM Encoder opens succesfully avs-script (~avi-file), it reads it frame by frame, and undelaying Avisynth driver does all operations described in the script on background (it is its responsibility).

Now specifically:

@HWK:
In you case, when FRIM Encoder tries to open ENCODE_3D_MOVIE.avs, this operation fails because Avisynth cannot initialize CoreAVCDecoder.dll.
It is probably because you are running process from another directory.

When I put everything into one directory and ran it within this directory, all worked.
Once I moved FRIMEncode.exe into another, or started batch file from outside this directory, underlaying Avisynth could not
initialize CoreAVCDecoder.dll and opening failed - consequently FRIM Encoder reported "Cannot read YUV420 frame". Setting PATH properly could help.

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.

Library DirectShowMVCSource.dll is not official part of Windows, neither provided by any HW vendor.
I don't know who is author of DirectShowMVCSource.dll and how does he support it.
In the associated readme.txt he himself admits, that
"... this as an hack to the original DirectShowSource source code with possible bugs, maybe memory leaks... "
So, I recommend to approach author to investigate and fix...

[HWK]

Friends,

I have looked to your issue with DirectShowMVCSource.dll in debugging mode.
And very clearly - problem is in DirectShowMVCSource itself.

Let me shortly describe you how FRIM Encoder works.

FRIM Encoder opens and read avi file using VWF (Video For Windows) API - which is standard part of Windows from version 3.x.
Avisynth script "input.avs" behaves like regular AVI and is for FRIM Encoder fully transparent.

Once FRIM Encoder opens succesfully avs-script (~avi-file), it reads it frame by frame, and undelaying Avisynth driver does all operations described in the script on background (it is its responsibility).

Now specifically:

@HWK:
In you case, when FRIM Encoder tries to open ENCODE_3D_MOVIE.avs, this operation fails because Avisynth cannot initialize CoreAVCDecoder.dll.
It is probably because you are running process from another directory.

I think this is related to Frim application and it causes problem with this program only. I use virtualdub and other application and it works fine and can figure out number of frames with no problem.

Also calling application must be inside magic path, which is "STEREOPLAYER.exe" folder in this case.

When I put everything into one directory and ran it within this directory, all worked.
Once I moved FRIMEncode.exe into another, or started batch file from outside this directory, underlaying Avisynth could not
initialize CoreAVCDecoder.dll and opening failed - consequently FRIM Encoder reported "Cannot read YUV420 frame". Setting PATH properly could help.

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.

Surprise it doesn't I have used players and encoders with SSIFSource3 and it works. Even X.264 encoder work with it and MPC-HC works for me as well.

Library DirectShowMVCSource.dll is not official part of Windows, neither provided by any HW vendor.
I don't know who is author of DirectShowMVCSource.dll and how does he support it.
In the associated readme.txt he himself admits, that
"... this as an hack to the original DirectShowSource source code with possible bugs, maybe memory leaks... "
So, I recommend to approach author to investigate and fix...

Original author is Peter Wimmer, however asking him to fix it is not an option. BTW he did update coreavcdecode.dll, however doing so prevent other program from using it. This version is last one which allows other application to call it as long "stereoplayer.exe" is in path of calling application.

[Sharc]

Just in case someone wants to ceck / improve DirectShowMVCSource.dll, here the download link (http://www.share-online.biz/dl/I3CQBCDMI5)including the source.

[videofan3d]

I think this is related to Frim application and it causes problem with this program only. I use virtualdub and other application and it works fine and can figure out number of frames with no problem.

Also calling application must be inside magic path, which is "STEREOPLAYER.exe" folder in this case.


Re. "VirtualDub and other applications" - each application starts within some environment (you as a user define this environment) and in this environment it needs to find all required components. Directly and also indirectly. This is how operating systems works.
Please give to FRIM Encoder such environment, that it can find all necessary components, in this case indirectly.

Next version of FRIM will have an option to display some error messages reported by AviSynth, this will allow you to see what is wrong in the underlaying avisynth script.

[videofan3d]

Original author is Peter Wimmer, however asking him to fix it is not an option. BTW he did update coreavcdecode.dll, however doing so prevent other program from using it. This version is last one which allows other application to call it as long "stereoplayer.exe" is in path of calling application.

Don't take me wrong :)

Please accept an axiom: Each and every program has bugs.

And in our particular case we are processing whole long chain of components

- source data
- avisynth script (=its functions written by whoever)
- avisynth driver
- Windows drivers (VFW, DirectShow)
- FRIM Encoder
- Intel Media SDK
- and user him/ser-self !

Each part HAS some bugs, some of them can be overcome in other part, some need to be fixed on proper place.

Number of bugs decrease by time and by support of vendor - but it never drops to zero :)
So never presume some applications to be bug-free.
Our SW world is too complex.

Just for fun: Oracle published statistics which shows that in average there is one bug on every 10 lines of code! (but it is another discussion belonging to different thread :D )

[Sharc]

Environment which works here:
- Put the FRIM package into a Directory, e.g. FRIM
- Create a subdirectory under FRIM with Name stereoplayer.exe which contains the corresponding files plus a copy of FRIMEncode.exe

Script directshowMVC.avs (in the FRIM Directory):
LoadPlugin("c:\..your path ...\FRIM\stereoplayer.exe\DirectShowMVCSource.dll")
V2=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF")
V1=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF",decodeleft=true)
StackHorizontal(V1,V2)
ConvertToYV12().AssumeFPS(24000,1001)
Command (in the FRIM Directory):
"C:\...your path....\FRIM\stereoplayer.exe\FRIMEncode.exe" mvc -avi -sbs 2 -i directshowMVC.avs -viewoutput -o Base.avc -o Dependent.mvc -w 1920 -h 1080 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
(Watch the quotation marks "....")

But as I wrote before FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

[videofan3d]

FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

Could you provide me with full description of reported error?
Meaning: how EXACTLY does this error display? There was probably some info in which file/line of code it happened...
I need to simulate it first...

[Sharc]

Could you provide me with full description of reported error?
Meaning: how EXACTLY does this error display? There was probably some info in which file/line of code it happened...
I need to simulate it first...
This error message is actually all I get from the cmd console.

However, from the Windows log there is an indication that divX.dll is responsible. Translated from German:

Name of the faulty application: FRIMEncode.exe, Version: 0.0.0.0, Time stamp: 0x527b8642
Name of the faulty module: DivX.dll, Version: 6.9.2.26, Time stamp: 0x4b7ee5fa
Exception code: 0xc0000005
Error offset: 0x00118a05
ID of the faulty process: 0x15cc
Start time of the faulty application: 0x01cedd26bf27d9c1
Path of the faulty application: C:\Program Files Video\FRIM\stereoplayer.exe\FRIMEncode.exe
Path of the faulty module: C:\Windows\system32\DivX.dll

Why gets DivX.dll involved at all?

Update 1:
I uninstalled DivX, now everything seems to work as expected ..... no crash ..... continuing testing .....
(I had DivX on my system for trying their HEVC/h265 encoder)

Update 2:
Now I run into another problem: No crash, but after some 1000 frames the dependent output file silently stops to grow, and only the base view continues encoding/growing.
No error message, it happens silently.

I guess I stick to the named pipe variant which worked flawlessly for the entire 2:25 hours movie.

Update 3:
Amazing. After a couple of new attempts with the directshowMVCSource variant I am now at frame 100'000 without a problem..... a miracle or a mystery????

[nunub]

any gui for this encoder will be most welcome to test.

[HWK]

Don't take me wrong :)

Please accept an axiom: Each and every program has bugs.

And in our particular case we are processing whole long chain of components

- source data
- avisynth script (=its functions written by whoever)
- avisynth driver
- Windows drivers (VFW, DirectShow)
- FRIM Encoder
- Intel Media SDK
- and user him/ser-self !

Each part HAS some bugs, some of them can be overcome in other part, some need to be fixed on proper place.

Number of bugs decrease by time and by support of vendor - but it never drops to zero :)
So never presume some applications to be bug-free.
Our SW world is too complex.

Just for fun: Oracle published statistics which shows that in average there is one bug on every 10 lines of code! (but it is another discussion belonging to different thread :D )

I am not taking you wrong at all. In fact I fully support you in first place since you bold enough to at least compile encoder and I know it will have bugs.

[HWK]

Environment which works here:
- Put the FRIM package into a Directory, e.g. FRIM
- Create a subdirectory under FRIM with Name stereoplayer.exe which contains the corresponding files plus a copy of FRIMEncode.exe

Script directshowMVC.avs (in the FRIM Directory):
LoadPlugin("c:\..your path ...\FRIM\stereoplayer.exe\DirectShowMVCSource.dll")
V2=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF")
V1=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF",decodeleft=true)
StackHorizontal(V1,V2)
ConvertToYV12().AssumeFPS(24000,1001)
Command (in the FRIM Directory):
"C:\...your path....\FRIM\stereoplayer.exe\FRIMEncode.exe" mvc -avi -sbs 2 -i directshowMVC.avs -viewoutput -o Base.avc -o Dependent.mvc -w 1920 -h 1080 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
(Watch the quotation marks "....")

But as I wrote before FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

I will give this method a try and see how it goes.

[colinhunt]

Any chance I could use the Intel HD 4000 GPU of the i7-3770K to run encodes?

[videofan3d]

Any chance I could use the Intel HD 4000 GPU of the i7-3770K to run encodes?

In theory yes: option -hw

But you need to have proper HW library libmfxhw32.dll (which might be even HW dependent, I don't know).
I cannot test it cause I have nVidia GPU, not Intel GPU...

[colinhunt]

In theory yes: option -hw
But you need to have proper HW library libmfxhw32.dll (which might be even HW dependent, I don't know).
I cannot test it cause I have nVidia GPU, not Intel GPU...
Well, that didn't work:

ERROR: Cannot initialize Intel Media SDK session.
ERROR: Cannot start encoding process.

The dll is probably HW dependent, like you said. Any ideas where I could pick up the correct one?

update: Downloaded the latest drivers from Intel's website and installed them. They created a "Media SDK" directory under Program Files (i.e. 64bit), inside which I found a newer version of the dll (actually two, 32bit and 64bit dlls). Replaced the dll in FRIM directory with the new one, added -hw to both decoder and encoder options -- and it works. Both decoding and encoding are now running on HD4000.

I've got quality set to "-u 3" and the system did 1000 frames of decode/encode in 100 seconds.

[frencher]

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

SsifSource3 have same black screen as DirectShowMVCSource with FRIMEncode (mplayer, x264, avstoavi, avstoyuv return corect right Stream), There would he no opportunity to fix the problem with the source code of avstoyuv ?

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.
virtualdub not works with preview.avs for me - Works with magic path sorry
If possible, If you could take a look :p

Thank

[colinhunt]

Ehh, I thought I was being clever by trying to run 2 encodes simultaneously. Decode/encode on HW uses less than 50% CPU so I thought I'll run another encode on the side, on software only. Turns out that can't be done: piping throws up an error message.

[Cedvano]

Where I can find SSifsource3, please.

Thanks

[Sharc]

Where I can find SSifsource3, please.

Thanks
Here, author is slavanap:

http://forum.doom9.org/showpost.php?p=1630916&postcount=1353

and check for possibly newer posts by slavanap in the same thread.

Edit:
The file seems to have been withdrawn ..... Not sure if the .dll is still maintained. You may want to PM the author slavanap.
ssifsource2 can be found in frencher's MVC Player free package, or in the Tools folder of rOIz's BD3D2MK3D.

[videofan3d]

Ehh, I thought I was being clever by trying to run 2 encodes simultaneously. Decode/encode on HW uses less than 50% CPU so I thought I'll run another encode on the side, on software only. Turns out that can't be done: piping throws up an error message.

Pipename is like filename, i.e. it must be unique on your computer :-)

Try to set different pipename for each session...

[colinhunt]

Pipename is like filename, i.e. it must be unique on your computer :-)
Try to set different pipename for each session...
I did, didn't help.

.bat file:
start FRIMDecode.exe mvc -i left.264 -i right.mvc -o \\.\pipe\XMAS.yuv | FRIMEncode.exe mvc -i \\.\pipe\XMAS_L.yuv -i \\.\pipe\XMAS_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr 34000 40000 -u 1 -profile high -level 4.1 -gop 24 4 0 O

result:
Return on error: error code -15, .\src\pipeline_encode.cpp 1174
Return on error: error code -15, .\src\pipeline_encode.cpp 1102
ERROR: Cannot start encoding process.

Currently running pipe is named simply "TMP".

[colinhunt]

This is kinda interesting: according to Intel's documentation, Look-ahead Bitrate Control (option -labrc instead of -vbr) requires a 4th generation Intel GPU, such as the HD4200 on some Haswell CPUs. I'm running a i7-3770K Ivy Bridge with a HD4000 on it, but the currently running job reports:

Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control LA
bitrate 24000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 1 (quality)

So it appears to be running in Look-ahead mode, exactly as the job was configured for. It'll be interesting to see what comes out the other end once the job completes.

[Cedvano]

Here, author is slavanap:

http://forum.doom9.org/showpost.php?p=1630916&postcount=1353

and check for possibly newer posts by slavanap in the same thread.

Edit:
The file seems to have been withdrawn ..... Not sure if the .dll is still maintained. You may want to PM the author slavanap.
ssifsource2 can be found in frencher's MVC Player free package, or in the Tools folder of rOIz's BD3D2MK3D.

Thank you, I try with Ssifsource2.

I don't understand, after Encoding with FRIMEncode, the number of frames between the 2 files is different.
Someone have the same problem ?

[videofan3d]

I did, didn't help.

.bat file:
start FRIMDecode.exe mvc -i left.264 -i right.mvc -o \\.\pipe\XMAS.yuv | FRIMEncode.exe mvc -i \\.\pipe\XMAS_L.yuv -i \\.\pipe\XMAS_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr 34000 40000 -u 1 -profile high -level 4.1 -gop 24 4 0 O

result:
Return on error: error code -15, .\src\pipeline_encode.cpp 1174
Return on error: error code -15, .\src\pipeline_encode.cpp 1102
ERROR: Cannot start encoding process.

Currently running pipe is named simply "TMP".

This error code -15 means that Media core function MFXVideoENCODE_Init() cannot initialize some parameters.

I ran two sessions (in two cmd.exe) in parallel in -sw mode. Successfully!
So maybe there is some restriction of -hw mode...

[Cedvano]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file

Can you correct FRIMDecode for the first soluce ?

Thanks

[videofan3d]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file

Can you correct FRIMDecode for the first soluce ?

Thanks

Could you give examples of a 3D-movies when it happens?
I need to reproduce it.

[Cedvano]

If you got The Lion King BD3D, you can test with 278 or 234 SSIF.
I upload 240 and share the link.

[colinhunt]

FYI, HD4000 hardware decode + hardware encode + Look-ahead bitrate control = GARBAGE.