Free H.264 MVC 3D Encoder

[Eseninzhiv]

Pattern_3D-TAB.prproj, Thank you, all ok!

try my files
inserted in the project from the camcorder file .MP4 (Side by Side)
try to get avc, mvc
put these parameters for the encoder
-viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O -EndOfSequence off

http://iceimg.com/VQ56vm70/1-thumb.jpg (http://iceimg.com/VQ56vm70/1) http://iceimg.com/YfHvoo1i/2-thumb.jpg (http://iceimg.com/YfHvoo1i/2)

I receive an error
please tell me, what parameters needed?

and if perhaps, please make presets in the following versions

[videofan3d]

Pattern_3D-TAB.prproj, Thank you, all ok!

try my files
inserted in the project from the camcorder file .MP4 (Side by Side)
try to get avc, mvc
put these parameters for the encoder


http://iceimg.com/VQ56vm70/1-thumb.jpg (http://iceimg.com/VQ56vm70/1) http://iceimg.com/YfHvoo1i/2-thumb.jpg (http://iceimg.com/YfHvoo1i/2)

I receive an error
please tell me, what parameters needed?

and if perhaps, please make presets in the following versions

Few comments:

FRIMEncoder for 3D expects 2x HD (=not squeezed by 2!), either top-above-below or side-by-side.

So, if you have video already squeezed side-by-side from consumer camcorder, you need to spread it by 2 in Premiere (to resolution 3840 (!) x 1080 - still in side-by-side) = you need to define proper Custom parameters of the Sequence in Premiere, and apply some spreading filter to the video itself.

Output filename, resolution and framerate is taken from Premiere, no need to set it in Codec options.

Codec options should be only aditional parameters, e.g.:
-viewoutput -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O -EndOfSequence off

[videofan3d]

FRIM package 1.22
Support reading transport stream .ts/.mts/.m2ts directly

FRIM Decoder / FRIM Transcoder
- optional parameter -ts added
example:
FRIMDecode -ts -i::h264 input.m2ts -o output.yuv

FRIM Source for Avisynth
- optional parameter ts=false/true (default is false) added
example:
FRIMSource(codec="h264", filename="input.m2ts", ts=true, cache=24, num_frames=300)

example for Panasonic 3D-Z10000 (with audio):

FILE3D="Z10000.m2ts"
V=FRIMSource(codec="mvc", filename=FILE3D, filename_dep=FILE3D, ts=true, layout="sbs", cache=24, num_frames=300)
A=DirectShowSource(FILE3D).KillVideo()
AudioDub(V,A)

[Cedvano]

Oh, great ! Thank you very much.
SSIF work or not ?

[videofan3d]

Oh, great ! Thank you very much.
SSIF work or not ?

SSIF likely not (= never tested), but for each SSIF you have two regular .m2ts files which will work.

[Cedvano]

Work only for 2D (like M2ts) but not for 3D.

[videofan3d]

Work only for 2D (like M2ts) but not for 3D.

I don't like this SSIF - it is virtual fake.
I already expressed my opinion about SSIF here (http://forum.doom9.org/showthread.php?p=1662997#post1662997).

On the contrary, those two real m2ts files associated with virtual SSIF have very clear and natural meaning:
base.m2ts serves for 2D - as standard, keeping bitrate for 2D compatibility, playable on every HW/SW media player.
dependent.m2ts ads only 3D information, multiplexed into standard TS-container, and playable together with base.m2ts on 3D compatible media players.

[Cedvano]

Like this that's work fine. Thank you very much for your work !

[Sharc]

I don't like this SSIF - it is virtual fake.
I already expressed my opinion about SSIF here (http://forum.doom9.org/showthread.php?p=1662997#post1662997).

On the contrary, those two real m2ts files associated with virtual SSIF have very clear and natural meaning:
base.m2ts serves for 2D - as standard, keeping bitrate for 2D compatibility, playable on every HW/SW media player.
dependent.m2ts ads only 3D information, multiplexed into standard TS-container, and playable together with base.m2ts on 3D compatible media players.
Agree, with the sidenote that .ssif can be just convenient as it links the associated pair of base & dependent .m2ts.
These are often in sequence like 0002.m2ts / 0003.m2ts and easy to identify. But sometimes the pair(s) are "wildly" numbered which makes their identification a bit more difficult -- especially in the case of multi-segmented structures.
Thanks for the update :)

[jdobbs]

SSIF likely not (= never tested), but for each SSIF you have two regular .m2ts files which will work.From a video perspective the SSIF is just an M2TS with a different name. In fact you can rename it to .M2TS and play it in 2D with Media Player Classic. The two M2TS files are just interleaved. I think the only difference is the MVC stream uses a different PID.

With that said, it really doesn't matter. As long as you can read from the two M2TS files it should be fine. Thanks for the new feature!

[jdobbs]

Ran this command, and it froze after 825 frames:
"c:\CLI\FRIMDecode.exe" -i::mvc "P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00000.M2TS"
"P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00001.M2TS" -o \\.\pipe\bdrb.yuv -sw | "C:\CLI\FRIMEncode.exe"
mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\WORKING7\WORKFILES\VID_00000.AVS.264"
-o "D:\WORKING7\WORKFILES\VID_00000.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 6 -cpbsize 1625 -profile high
-level 4.0 -vbr 15000 15000 -gop 24 4 0 S -maxdpb 4

[nunub]

Like this that's work fine. Thank you very much for your work !

Gear up now for the ultimate gui.

[videofan3d]

Ran this command, and it froze after 825 frames:
"c:\CLI\FRIMDecode.exe" -i::mvc "P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00000.M2TS"
"P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00001.M2TS" -o \\.\pipe\bdrb.yuv -sw | "C:\CLI\FRIMEncode.exe"
mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\WORKING7\WORKFILES\VID_00000.AVS.264"
-o "D:\WORKING7\WORKFILES\VID_00000.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 6 -cpbsize 1625 -profile high
-level 4.0 -vbr 15000 15000 -gop 24 4 0 S -maxdpb 4

Didn't you forget
FRIMDecode.exe -ts -i::mvc ...
?

[jdobbs]

Didn't you forget
FRIMDecode.exe -ts -i::mvc ...
? Hmmm... I guess I missed that. Thanks!

[Eseninzhiv]

Great ! Thank you very much
works fine
FRIMDecode -ts -i::mvc -i 00000.m2ts -i 00001.m2ts -o output_L.yuv -o output_R.yuv

[jdobbs]

@videofan3d

Any idea what the error below could be? I get it when I try to run two instances of FRIMEncode against a source. It takes a while, but fails at the same point in each try. It also fails on every source I've tried, but at different points. The same files encode fine if I only use one instance of FRIMEncode.

Frame number: 16140
ERROR: unknown error (-1), src\pipeline_encode.cpp (1086)


ERROR: unknown error (-1), src\pipeline_encode.cpp (1282)


ERROR: the previous asynchrous operation is in execution (1), src\main_frim_encode.cpp (128)

[videofan3d]

@videofan3d

Any idea what the error below could be? I get it when I try to run two instances of FRIMEncode against a source. It takes a while, but fails at the same point in each try. It also fails on every source I've tried, but at different points. The same files encode fine if I only use one instance of FRIMEncode.

Frame number: 16140
ERROR: unknown error (-1), src\pipeline_encode.cpp (1086)


ERROR: unknown error (-1), src\pipeline_encode.cpp (1282)


ERROR: the previous asynchrous operation is in execution (1), src\main_frim_encode.cpp (128)

Hi,

Are you running on Intel i5/i7 CPU ? (or with some new Intel Graphics)? More precisely, are you using "autodetect" or -hw option?

Please try to switch to -sw.

[jdobbs]

Hi,

Are you running on Intel i5/i7 CPU ? (or with some new Intel Graphics)? More precisely, are you using "autodetect" or -hw option?

Please try to switch to -sw.I am running on an AMD CPU, and am running with -sw forced already.

[sef]

http://i57.fastpic.ru/big/2014/0207/59/4a79a16bbcc841c3668dd3296f86c059.jpg

http://i33.fastpic.ru/big/2014/0207/5d/ac9ecb263137212d74354ffd0a77b95d.jpg

What am I doing wrong??

[videofan3d]

I am running on an AMD CPU, and am running with -sw forced already.

Please send exact command which you are running + running conditions, I will try to simulate it.

[videofan3d]

http://i57.fastpic.ru/big/2014/0207/59/4a79a16bbcc841c3668dd3296f86c059.jpg

http://i33.fastpic.ru/big/2014/0207/5d/ac9ecb263137212d74354ffd0a77b95d.jpg

What am I doing wrong??

This is strange, this is how it should be used.
I ran your command without any issues

c:\Prj\IntelMedia\_bin\Win32\Release\FRIMDecode -i::mvc SRC_L.h264 SRC_R.h264 -sbs -o - | c:\Prj\IntelMedia\_bin\Win32\Release\FRIMEncode -sbs 2 -i - -o::mvc Z.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000
FRIM Encoder version 1.22 (build: Feb 2 2014)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfx
hw32.dll)
Media SDK version 1.7
Memory type System

Input format YUV420

Output video AVC
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 VBR
avg,maximum 28000,40000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 4 (balanced)

Processing started
Frame number: 276
Processing finished in 3.43 seconds

Please try it with FRIMEncode -sw (or maybe also for FRIMDecode)
(I faced some issues when running in -hw mode, HW acceleration depends on driver version)

[sef]

Please try it with FRIMEncode -sw (or maybe also for FRIMDecode)

Problem solved, had to manually set the path to Intel Media SDK(2014).. Only -sw, with FRIMDecode and FRIMEncode simultaneously..
P.S. What is your video card?(HD 4000).. And, why -hw not working at all, with first example..

[videofan3d]

Problem solved, had to manually set the path to Intel Media SDK(2014).. Only -sw, with FRIMDecode and FRIMEncode..
P.S. What is your video card?(HD 4000).. And, why -hw not working at all, with first example..

(I use Haswell CPU i7 4770K with integrated GPU HD 4600)

I noticed that there are sometimes some limitations (or bugs?) when using -hw mode.
In -hw mode Intel Media uses graphic driver and calls GPU accelerated routines. They are "bloody-faster", on decoding 8x(!), but with some limits.

I can only guess:
In -sw mode each process allocates resources (memory, thread pool, etc.) in regular PC memory, so there are almost no limitations.
But in -hw mode each process can use/share resources on the GPU - which are not endless, and probably depend on specific given GPU. Once exhausted (for example when running more processes/threads), each additional process fails. And number of available resources probably depends on specific GPU family.

My experience is to play with -hw and -sw, and try to find proper combination.

[sef]

And number of available resources probably depends on specific GPU family.


That's what I was expecting:), thanks for the detailed explanation, soon I will replace hardware..

[jdobbs]

Please send exact command which you are running + running conditions, I will try to simulate it.The goal of running multiple instances is to speed up encoding. I've noticed that only a little over half of the available CPU usage was being used when doing a single instance encode. The multiple instances gives me about a 30% increase in encoding speed. But, as I said, only one of the instances will complete, and the other will get the error I posted (http://forum.doom9.org/showthread.php?p=1666619#post1666619). In the example here I am accepting a half-SBS source and reencoding to full MVC using FRIMEncode (to create a 3D BD disc). Frame serving is being provided by DGDecNV so I can get frame-accurate seeking. The two AVISYNTH scripts:#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-91203)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(91203,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Here are the command lines being used:"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.1.264"
"D:\WORKING8\WORKFILES\VID_00000.1.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.2.264"
"D:\WORKING8\WORKFILES\VID_00000.2.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4One of the two instances will end with the error I posted every time. If the source changes, the frame at which it fails changes -- but it has happened on every source I've tried. Unfortunately it can be several thousand frames into the encode, so repeating the issue always takes a lot of time.

If I do a single file with the same settings etc... it will complete with no issues.

It's not something critical -- as a single encode always works. The purpose of the experiment is just to save time when encoding.

[Edit] Note also, that either of the two specific command lines above will complete successfully if run as a single instance -- but one will fail if run concurrently.

[videofan3d]

That's what I was expecting:), thanks for the detailed explanation, soon I will replace hardware..

I just noticed that your HW system reports Media SDK Version 1.4 while on my side 1.7.
Maybe try also upgrade video driver - Intel HW library used to be part of it, and I realized it really matters what version you have.

[videofan3d]

The goal of running multiple instances is to speed up encoding. I've noticed that only a little over half of the available CPU usage was being used when doing a single instance encode. The multiple instances gives me about a 30% increase in encoding speed. But, as I said, only one of the instances will complete, and the other will get the error I posted (http://forum.doom9.org/showthread.php?p=1666619#post1666619). In the example here I am accepting a half-SBS source and reencoding to full MVC using FRIMEncode (to create a 3D BD disc). Frame serving is being provided by DGDecNV so I can get frame-accurate seeking. The two AVISYNTH scripts:#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-91203)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(91203,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Here are the command lines being used:"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.1.264"
"D:\WORKING8\WORKFILES\VID_00000.1.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.2.264"
"D:\WORKING8\WORKFILES\VID_00000.2.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4One of the two instances will end with the error I posted every time. If the source changes, the frame at which it fails changes -- but it has happened on every source I've tried. Unfortunately it can be several thousand frames into the encode, so repeating the issue always takes a lot of time.

If I do a single file with the same settings etc... it will complete with no issues.

It's not something critical -- as a single encode always works. The purpose of the experiment is just to save time when encoding.

[Edit] Note also, that either of the two specific command lines above will complete successfully if run as a single instance -- but one will fail if run concurrently.

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...

[sef]

Intel HW library used to be part of it..

I know, but unfortunately, for my card(HD 3000) already installed the latest drivers..:(

[jdobbs]

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.

[HWK]

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...

I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.

I have Nvidia card and dgdecnv, if you want jdobbs I can run test as well and see if it is related specific configuration.

[jdobbs]

I have Nvidia card and dgdecnv, if you want jdobbs I can run test as well and see if it is related specific configuration.I'll send you a test version of BD-RB that does multiple instances. That way you can run a job and see what happens.

[jdobbs]

I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.Yeah, it choked with DirectshowSource() also.

[HWK]

Not sure, if this is any help or not. I finish encoding world war z with multiple instance of FRIMEncode (x2) and it finished without a problem, will do Pacific Rim next with two instance and balance setting in FRIM.

(Around 60% done)
http://i58.tinypic.com/255o20y.jpg

(100% done)
http://i62.tinypic.com/4ujw51.jpg

First Instance
FRIMDecode.exe -ts -i::mvc "E:\BD_RB\WORKFILES\00800.M2TS" "E:\BD_RB\WORKFILES\00800.M2TS" -o \\.\pipe\_L1.yuv -o \\.\pipe\_R1.yuv | FrimEncode.exe -i \\.\pipe\_L1.yuv -i \\.\pipe\_R1.yuv -viewoutput -o::mvc "E:\WORLD_WAR_Z_Part1.264" -o "E:\WORLD_WAR_Z_Part1.mvc" -w 1920 -h 1080 -f 23.976 -u 7 -cpbsize 3750 -profile high -level 4.1 -vbr 30000 60000 -gop 24 4 0 S -maxdpb 4
pause

Second Instance
FRIMDecode.exe -ts -i::mvc "E:\BD_RB\WORKFILES\00810.M2TS" "E:\BD_RB\WORKFILES\00810.M2TS" -o \\.\pipe\_L2.yuv -o \\.\pipe\_R2.yuv | FrimEncode.exe -i \\.\pipe\_L2.yuv -i \\.\pipe\_R2.yuv -viewoutput -o::mvc "E:\WORLD_WAR_Z_Part2.264" -o "E:\WORLD_WAR_Z_Part2.mvc" -w 1920 -h 1080 -f 23.976 -u 7 -cpbsize 3750 -profile high -level 4.1 -vbr 30000 60000 -gop 24 4 0 S -maxdpb 4
pause

I split movie into two files 00800.m2ts and 00810.m2ts file and ran two instance simultaneous.

[videofan3d]

Yeah, it choked with DirectshowSource() also.

I tried to reproduce it .... with mixed results :scared: ...

VID.1.avs:

L=DirectShowSource("VIDEO.m2ts").Trim(0,-60000)
StackHorizontal(L,L)


VID.2.avs:

L=DirectShowSource("VIDEO.m2ts").Trim(60000, 0)
StackHorizontal(L,L)


Both inputs were artifically made 2*1920 to simulate 3D SBS input.
Input video was ~130000 frames long.

Encode 1

FRIMEncode.exe -avi -sbs 2 -sw -i VID.1.avs -viewoutput -o::mvc VID.1.h264 VID.1.mvc -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 23376 35000 -gop 24 4 0 S -maxdpb 4


Encode 2

FRIMEncode.exe -avi -sbs 2 -sw -i VID.2.avs -viewoutput -o::mvc VID.2.h264 VID.2.mvc (...same params..)


i.e. I tried to set similar conditions as you have.
Running on i7 Haswell.

And my results:

When I run in -sw encoding mode, I faced the same (rather stochastic) failure on one process.

When I run in -hw encoding mode, both finished correctly!

As you commented, it is very time consuming to reproduce it.

.... at this moment I can only add it will be very difficult to investigate the root cause - in order even to try to fix it :( ...)

[jdobbs]

Did you get a significant speed-up with -hw set? Just wondering... I'm just going to disable multiple instance processing for FRIM in BD-RB, I think it's too unpredictable as to when it will or will not fail. While it was failing on every job before, I've since had a couple shorter jobs that completed successfully. The probability is that the issue is in the library somewhere anyway -- and that would have to be fixed by Intel anyway.

I think it's a lot more likely to happen when BD-RB starts the process and has to make frequent checks for process completion -- although I don't know why that would impact it. But even then it goes through thousands of frames (and a few hours) before it finally trips.

Thanks for the look.

[HWK]

Jdobbs, so you are dropping the idea of multi-process for time being. I manage to do something which is shown in post # 533 not sure if it is any good.

I am gone try later today with method similar to yours for dgdecnv.

[jdobbs]

Jdobbs, so you are dropping the idea of multi-process for time being. I manage to do something which is shown in post # 533 not sure if it is any good.

I am gone try later today with method similar to yours for dgdecnv. I'm not sure whether I'll drop it completely. I don't have a system that would support -hw -- so I'm not sure whether is has any issues at all. I would think, though, that -hw might be where it might benefit the most.

I may just leave it in and use an undocumented hidden option to enable it. Unfortunately when it happens, the encode process never ends and BD-RB just keeps waiting. Eventually you have hit the "Abort" button. Unless you have "show_encoder=1" set in the config file, you don't even know why it's hung.

[HWK]

I'm not sure whether I'll drop it completely. I don't have a system that would support -hw -- so I'm not sure whether is has any issues at all. I would think, though, that -hw might be where it might benefit the most.

I'll probably just leave it in and use a hidden option (with warning) to enable it.

Hmm, I use software option and used two instance of frimdecode & frimencode and it worked without problem, three work as well but it slows down encoding with little or no benefit.

At least there is light at end of tunnel :D Anyways, like I said I will use script posted by you and see if it works at all for information purposes, if it works fine and if not good with me.

[jdobbs]

Hmm, I use software option and used two instance of frimdecode 7 frimencode and it worked without problem, three work as well but it slows down encoding with little or no benefit.

At least there is light at end of tunnel :D Anyways, like I said I will use script posted by you and see if it works at all for information purposes, if it works fine and if not good with me.Oh, I'm confident you'll get it if you repeat my method. I get it every time on a long job. But sometimes it may be 50,000+ frames before it happens. On other jobs it may happen at 8,000. I also noticed you're using FRIMDecode in your test. I'm using AVISYNTH and the -avi option, which might make a difference. In my test version of BD-RB it is currently only enabled when converting SBS to MVC.

I see the same speed effect on my system when trying to run more than 2 instances. But that makes sense when there's no available processor bandwidth available. I would expect it to do better with -hw set.

[HWK]

Oh, I'm confident you'll get it. I get it every time on a long job. But sometimes it may be 50,000+ frames before it happens. On other jobs it may happen at 8,000.

Fair enough, but it doesn't hurt to try. On a side note I was reading Neuron2 has intention to develop plugin which mvc decode without need NVidia and is frame accurate or at least that is what I understand. Let me search for the link and will post it here, if I find it.

http://forum.doom9.org/showthread.php?p=1667083#post1667083

[jdobbs]

Removed link -- realized I had some bad test-code still in it.

Ok. If you have BD Rebuilder installed and you want to test download this executable (http://www.jdobbs.net/Freeware/bdrb.exe) and replace BDRB.EXE. Then set FRIM_SBS_PROCESSES=2 (for two instances) and set SHOW_ENCODER=1. Then import a SBS source and run it. It will eventually error out.

I saw Neuron2's post.

[videofan3d]

Did you get a significant speed-up with -hw set? Just wondering...

Some time ago I measured FRIMDecode on -hw|sw - see here (http://forum.doom9.org/showthread.php?p=1655287#post1655287).

Encoding with -hw is visibly faster than -sw.
But also resulting H.264 files are different - in size and content (I'm not evaluating visual difference since it is matter of personal preference if even possible to recognize).
Intel also confirmed that algorithms in SW and HW libraries slighly differ.

(Unlike decoding - YUV file from the same source H.264 is identical for both FRIMDecode -hw and -sw)

[jdobbs]

Some time ago I measured FRIMDecode on -hw|sw - see here (http://forum.doom9.org/showthread.php?p=1655287#post1655287).

Encoding with -hw is visibly faster than -sw.
But also resulting H.264 files are different - in size and content (I'm not evaluating visual difference since it is matter of personal preference if even possible to recognize).
Intel also confirmed that algorithms in SW and HW libraries slighly differ.

(Unlike decoding - YUV file from the same source H.264 is identical for both FRIMDecode -hw and -sw)I assumed hw was faster, I was more interested in how much faster it would be with multiple instances, since I would assume it uses less CPU time than sw.

[HWK]

Removed link -- realized I had some bad test-code still in it.

Ok. If you have BD Rebuilder installed and you want to test download this executable (http://www.jdobbs.net/Freeware/bdrb.exe) and replace BDRB.EXE. Then set FRIM_SW_PROCESSES=2 (for two instances) and set SHOW_ENCODER=1. Then import a SBS source and run it. It will eventually error out.

I saw Neuron2's post.

Thank you, will try later today. Also do you know specs of GPU you are using for frame serving.

[jdobbs]

Thank you, will try later today. Also do you know specs of GPU you are using for frame serving. It happens on both an AMD Radeon 6530D (using DirectshowSource) and an Nvidia GeForce GT520 (using either DirectshowSource or DGDecNV). They are on two different computers.

[jdobbs]

It happens on both an AMD Radeon 6530D (using DirectshowSource) and an Nvidia GeForce GT520 (using either DirectshowSource or DGDecNV). They are on two different computers.The job I tried today went over 78,000 frames before it hit the error.

[HWK]

I am currently doing Pacific Rim and see what happens. Just want to know why BD-RB use mkvmerge in the beginning when importing. I am using m2ts file with h.264 codec.

[jdobbs]

I am currently doing Pacific Rim and see what happens. Just want to know why BD-RB use mkvmerge in the beginning when importing. I am using m2ts file with h.264 codec.It converts all non-mkv sources to mkv when it imports in order to simplify processing.

[HWK]

It converts all non-mkv sources to mkv when it imports in order to simplify processing.

Aha, I see thanks for information. I would be much better off if I knew what I am up against. I am using lossless source and it is slow 2:11:16 length translate to 163GB of file and it is taking it's time.

[HWK]

Jdobbs, does "MULTIPROCESS" need to be in hidden option for this method to work? I tired with instructions and it run in only one instance.

I am doing again by adding multiprocess to options.