Free H.264 MVC 3D Encoder

[nunub]

@Cedvano
Still waiting for ur frim encoder gui. I hope it will be ready sooner.

[Cedvano]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks

[HWK]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks

Ouch, hopefully you will recover soon and will be back in full force.

[jdobbs]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks I hope everything is alright. Take your time and get better.

[nunub]

@Cedvano
Thanks for responding and i would like to clear u all that cedvano is working in a hospital and this is just a research and a hobby kind side work for him.

[trevorjharris]

Tried your premiere pro application with -viewoutput -vbr 28000 40000 as options. This produces 3 files a .h264, .avc, .mvc. Is there a way of producing just 3 files.

[HWK]

Tried your premiere pro application with -viewoutput -vbr 28000 40000 as options. This produces 3 files a .h264, .avc, .mvc. Is there a way of producing just 3 files.

Can you elaborate on your question or what do you want to find out?

[nerdfactormax]

I hate to pollute this thread with what could be a complete noob question, but here goes:

I'm trying to render direct from Premiere Pro CC -> Debugmode Frameserver -> avisynth -> FRIMEncode but I get an error "Cannot open input avi-file input.avs"
I've tried to copy the example (6) in the FRIMEncode_readme as close as possible.

In the frameserver I have tried RGB24 and YUY2
My batch file is:
FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc output_base.avc output_dependent.mvc -vbr 28000 40000 -u 1
My input.avs is:
AVISource(“full_filename_shown_in_frameserver.avi”)
ConvertToYV12()

The batch file and input.avs are both in the same directory as the frimencode.exe

Incidentally (and maybe related), the frameserver seems to run fine the first time, but after that Premiere wont open the export window until you remove the frameserver plugin.

Could it be an issue of mixing 32/64bit within the chain? I believe Premiere is 64 bit but the rest of the path is 32.

[videofan3d]

I hate to pollute this thread with what could be a complete noob question, but here goes:

I'm trying to render direct from Premiere Pro CC -> Debugmode Frameserver -> avisynth -> FRIMEncode but I get an error "Cannot open input avi-file input.avs"
I've tried to copy the example (6) in the FRIMEncode_readme as close as possible.

In the frameserver I have tried RGB24 and YUY2
My batch file is:
FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc output_base.avc output_dependent.mvc -vbr 28000 40000 -u 1
My input.avs is:
AVISource(“full_filename_shown_in_frameserver.avi”)
ConvertToYV12()

The batch file and input.avs are both in the same directory as the frimencode.exe

Incidentally (and maybe related), the frameserver seems to run fine the first time, but after that Premiere wont open the export window until you remove the frameserver plugin.

Could it be an issue of mixing 32/64bit within the chain? I believe Premiere is 64 bit but the rest of the path is 32.

Hi, process you have described is in principle correct, and it should work.
Premiere and Debugmode plugin are 64-bit, Avisynth and FRIMEncode are 32 - but those are separate processes interfacing on file level, so there is no conflict.

Please check if you have correct setting of ffdshow for AVI processing - it was described somewhere above in this thread:
1. Start ffdshow (usually from Start Menu/All Programs)
2. Select “VFW Configuration”
3. On the “Decoder” tab, scroll down to "Raw Video"
4. Select "All Supported"

i.e. if you are able to encode any YUV 4:2:0 avs file.


Btw. did you also try direct FRIMExport.prm plugin with Adobe CC? (I could test it only with CS6)

[nerdfactormax]

Hi, process you have described is in principle correct, and it should work.
Premiere and Debugmode plugin are 64-bit, Avisynth and FRIMEncode are 32 - but those are separate processes interfacing on file level, so there is no conflict.

Please check if you have correct setting of ffdshow for AVI processing - it was described somewhere above in this thread:
1. Start ffdshow (usually from Start Menu/All Programs)
2. Select “VFW Configuration”
3. On the “Decoder” tab, scroll down to "Raw Video"
4. Select "All Supported"

i.e. if you are able to encode any YUV 4:2:0 avs file.


Btw. did you also try direct FRIMExport.prm plugin with Adobe CC? (I could test it only with CS6)

I don't think I ffdshow installed, now I do.

I just tried the FRIMExport.prm with Adobe CC and got
ERROR: Cannot initialize Intel Media SDK Session
ERROR: Cannot start encoding process.
these lines also appear on subsequent attempts
ERROR: Cannot create output file blah:\blah\blah.avc
ERROR: Cannot start encoding process.
ERROR: Cannot create output file blah:\blah\blah2.avc
ERROR: Cannot start encoding process.

It seems multiple attempts remember past attempted filenames (and failed attempts create empty files which can't be deleted while premiere is open)

I would like to attempt a less convoluted tool-chain to start with, but I'm not sure how to render YUV straight out of Premiere. I've had a look at all the options of the different export types and come to the conclusion that I'm out of my depth.

I retried the original method with ffdshow now setup, but had the same result (cannot open avi-file input.avs).

I'll search the internet for a sample yuv file to play with.

[videofan3d]

I just tried the FRIMExport.prm with Adobe CC and got
ERROR: Cannot initialize Intel Media SDK Session
ERROR: Cannot start encoding process.
these lines also appear on subsequent attempts
ERROR: Cannot create output file blah:\blah\blah.avc
ERROR: Cannot start encoding process.
ERROR: Cannot create output file blah:\blah\blah2.avc
ERROR: Cannot start encoding process.

It seems multiple attempts remember past attempted filenames (and failed attempts create empty files which can't be deleted while premiere is open)


It seems that FRIMExport.prm cannot find libmfxsw64.dll library!

Please note that FRIMExport is 64-bit DLL for Adobe, thus it requires also 64-bit Intel Media core libraries.
You need to have either libmfxsw64.dll (-sw mode, part of FRIM 64-bit distribution pack) or libmfxhw64.dll (part of Intel graphic driver) in your %PATH%.

FRIMExport should eliminate any interim chain, it produces directly elementary h264 or mpeg2 stream, suitable for multipexing with audio (tsMuxer 3D)

[nerdfactormax]

It seems I had the 64bit FRIMEncode. Trying with the 32bit version I get
ERROR: Cannot get YUV420 frame from input avi-file input.avs
I tried the frameserver with RGB24 and YUY2

[videofan3d]

It seems I had the 64bit FRIMEncode. Trying with the 32bit version I get
ERROR: Cannot get YUV420 frame from input avi-file input.avs
I tried the frameserver with RGB24 and YUY2

Then this message clearly identifies incorrect setting of ffdshow filters. Try to play with its setting (as mentioned above) - at the end you will find proper combination :-)

Remark:
frameserver RGB24 or YUV2 has impact only to interface between Premiere and Debugmode.
But once you have command ConvertToYV12() in your AVS script (which is necessary), then output is converted to the needed format YUV4:2:0.
And then ffdshow will do the work for passing data into Video For Windows (VFW) API for FRIMEncode.

[videofan3d]

...
I'll search the internet for a sample yuv file to play with.

You can create your own YUV420.AVI.
Take short sample of input.h264 file and use example (3) from FRIMDEcode_readme.pdf:

FRIMDecode -i::h264 input.h264 -o \\.\pipe\yuvpipe

and then in another separate command-session:

ffmpeg -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\yuvpipe -vcodec copy -y output.avi

will create an AVI-file with uncompressed YUV 4:2:0 video.

(assuming you have installed ffmpeg, of course :) )

[nerdfactormax]

To whoever made FRIMEncode and to whoever made tsMuxer:
THANKYOU THANKYOU THANKYOU.
I've spent the last year editing a 3D concert video. At the start of the journey, I wasn't expecting to be able to easily author a proper 3D Bluray so discovering this forum has been awesome.

Being able to render from original source, through after effects, into premiere pro and export to the 3D encoded file without any intermediate rendering is AMAZING.

My problem now is that everything was done at 25fps (zero budget, had to borrow cameras for the shoot) and it seems that 25fps is not a bluray standard :(
My choices seem to be 24p or 50i.
Thats probably a question for a different forum, but I thought I'd drop by and express my gratitude.

[titlis]

@nerdfactormax

you can make blu-ray compliant 25p stream with either x264's --fake-interlaced parameter or simply encode 25p as 50i, psf
or I believe 2:2 pulldown option could also do that

[nunub]

@nerdfactormax

you can make blu-ray compliant 25p stream with either x264's --fake-interlaced parameter or simply encode 25p as 50i, psf
or I believe 2:2 pulldown option could also do that

He is talking about 3D bluray compliancy not normal bluray.

[nunub]

@videofan3d
I think the parameters for premiere pro export of frim encoder is showing error. Can u please detail me where to put that libmfxsw64.dll into the right path. As i m using AMD quad core machine.

[videofan3d]

@videofan3d
I think the parameters for premiere pro export of frim encoder is showing error. Can u please detail me where to put that libmfxsw64.dll into the right path. As i m using AMD quad core machine.

You can place it anywhere you want, just make sure that this directory is defined in PATH variable :)

My own setup:

"c:\Program Files\Intel\Media SDK 2014 for Clients\bin\win32\libmfxsw32.dll"
"c:\Program Files\Intel\Media SDK 2014 for Clients\bin\x64\libmfxsw64.dll"

and
PATH=...;C:\Program Files\Intel\Media SDK 2014 for Clients\bin\x64;C:\Program Files\Intel\Media SDK 2014 for Clients\bin\win32;...

Remark info:
During a week I'm going to release also FRIMImport.dll for Premiere CS6 which will allow importing .MTS files from 3D-camcorders (specifically my beloved Panasonic Z10000) directly to Adobe Premiere.
This will allow (together with FRIMExport.dll) rendering Bluray-3D without any time-or-space-or-quality consuming re-encoding via some intermediate format.

[nunub]

@videofan3d
Thanks for ur info i will look into it and will see what is the outcome. And also would request ur kindself in ur frimimport kindly decode sbs or ou files inside premiere pro also as it will kill those tedious job of enlarging those frames or atleast a preset for it. And is there any problem using adobe 7.2.1 with frim.
Thanks once again for ur very and most important work for all the 3d community.

[nerdfactormax]

So I slowed my video down to 23.976fps and it still looks and sound great. I can render to mvc-3d straight out of premiere for shorter sections, but when I tried to render the whole video (70mins), it crashed about halfway with:
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)

I use tsMuxerGUI to combine the .h264 with the .wav and generate an iso. That creates a proper 3d bluray and all is well. Is there a way I can generate a file that I can import into encore which it wont try to retranscode (and destroy the 3d on the way)? I would like to be able to create menu/chapters etc.

[colinhunt]

Is there a way I can generate a file that I can import into encore which it wont try to retranscode (and destroy the 3d on the way)? I would like to be able to create menu/chapters etc.
Not possible, as far as I know. It's a limitation of Encore. You need other, more expensive software to author BD3Ds with menus.

[videofan3d]

... but when I tried to render the whole video (70mins), it crashed about halfway with:
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)



Frankly, I have never rendered such long video - all my videos are shorter, up to 20 minutes.
(nowadays is "time of youtube" when users are used to watch up to 1 minute, everything longer is considered old-fashioned and boring :D :D :D )

Now seriously: I personally didn't face this issue so far.
Unknown error (-1) is reported by core Intel Media library, and line 1086 indicates it is when allocating internal memory during thread synchronization.
Similar error was reported some time ago, when people here tried to run two instances of FRIMEncode in parallel.
I have no solution for it... :(

[Guest]

Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.

At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. Please report the results.

[nerdfactormax]

Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.

At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. Please report the results.
Thanks, I'll try that tonight.
I notice that the rendered file has 0 size until it is finished. Does that mean that it's trying to keep everything in RAM? That could pose a problem when I want to render an entire Bluray at high quality and I only have 16gig of ram.

[videofan3d]

I notice that the rendered file has 0 size until it is finished. Does that mean that it's trying to keep everything in RAM? That could pose a problem when I want to render an entire Bluray at high quality and I only have 16gig of ram.

No, this is just a consequence that file is opened for a long time and not "flushed". Operating system then doesn't present its exact size.
No worry about this phenomenon :)

[videofan3d]

Hi,

FRIM version 1.23 is released.

Changes:
all modules - code refactoring (removal of dependency on legacy stdout/stderr, optimized CPU utilization)

FRIM Encode, FRIM Transcode
- new encoding modes
-lavbr bitRate depth (.... renamed from -labrc)
-avbr bitRate accuracy convergence
-icq quality
-laicq quality depth

FRIMSource.dll
- fixed identification of interlaced sources
- parameter reload=false|true (default true)
- parameter num_frames=0 ... zero as num_frames will imply automatic length calculation, works only for TS-container !

FRIMExport.prm
- manual setting of MVC-3D TAB vs. SBS layout added
- viewoutput creates only two files .avc and .mvc

FRIMImport.prm
- new module, importer to Adobe Premiere Pro (CS6), see FRIMPremiere_readme.pdf for description

Please read more in release notes.

[colinhunt]

Well, it's been a while since I last used FRIMTranscode or FRIMEncoder, so it could well be I'm out of touch... but when I ran the latest FRIMTranscode, I got this:

frimtranscode -i::mvc base.avc dependent.mvc -o::mvc output.h264 -vbr 34000 48000 -u 3

FRIM Transcoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

ERROR: unknown error (-1), src\pipeline_transcode.cpp (1321)
ERROR: unknown error (-1), src\pipeline_transcode.cpp (1693)

Encoding rig: Windows 7 64-bit, i7-3770K and 16GB of RAM, operated via Remote Desktop.

[videofan3d]

Well, it's been a while since I last used FRIMTranscode or FRIMEncoder, so it could well be I'm out of touch... but when I ran the latest FRIMTranscode, I got this:

frimtranscode -i::mvc base.avc dependent.mvc -o::mvc output.h264 -vbr 34000 48000 -u 3

FRIM Transcoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

ERROR: unknown error (-1), src\pipeline_transcode.cpp (1321)
ERROR: unknown error (-1), src\pipeline_transcode.cpp (1693)

Encoding rig: Windows 7 64-bit, i7-3770K and 16GB of RAM, operated via Remote Desktop.


error line 1321 points to surface memory allocation error in core Intel Media libraries.

Try to run it in -sw mode, or install newer Intel driver.

Neuron2 pointed out above:
"Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.
At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. "

Btw.: this driver 3496 contains SDK API ver 1.8 - where new ICQ mode is available.

[colinhunt]

Try to run it in -sw mode, or install newer Intel driver.
I had actually installed the 3496 drivers only minutes earlier. I'll try -sw mode next.

[worknstiff]

I have an i7-2600k and have been trying to get BD_Rebuilder to use FRIMEncoder with it. I was hoping you have had better luck than I have. Did the latest intel driver help or should I just break down and buy the latest i7 and hope it will work with FRIME?

[colinhunt]

I have an i7-2600k and have been trying to get BD_Rebuilder to use FRIMEncoder with it. I was hoping you have had better luck than I have. Did the latest intel driver help or should I just break down and buy the latest i7 and hope it will work with FRIME?
Nah, it's been playing silly buggers, crashing all too often. I've just installed the one release older drivers to see if that makes a difference.

[colinhunt]

@ videofan3d, do you know how well or poorly FRIMEncoder scales in multi-cpu systems? I replaced the Xeon CPUs in my old encoding rig with newer Xeons (X5660), and got a total of 12 cores and 24 threads. That looks great on paper, but I'm now running the new BD-RB (47.03), doing a full 3D backup using software decode/encode - and CPU usage hovers around 30-35% only. BD-RB reports FRIMEncoder is pushing only 5 fps.

So I'm wondering where to start looking for a bottleneck. Could it be that FRIMEncoder is unable to take full advantage of all the cores/threads on a dual-Xeon setup? Or should I be looking for a bottleneck elsewhere?

[videofan3d]

@ videofan3d, do you know how well or poorly FRIMEncoder scales in multi-cpu systems? I replaced the Xeon CPUs in my old encoding rig with newer Xeons (X5660), and got a total of 12 cores and 24 threads. That looks great on paper, but I'm now running the new BD-RB (47.03), doing a full 3D backup using software decode/encode - and CPU usage hovers around 30-35% only. BD-RB reports FRIMEncoder is pushing only 5 fps.

So I'm wondering where to start looking for a bottleneck. Could it be that FRIMEncoder is unable to take full advantage of all the cores/threads on a dual-Xeon setup? Or should I be looking for a bottleneck elsewhere?

Hi,

I personally use Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM, so I cannot comment on XEON. For this you can try to search on Intel Media SDK forum (http://software.intel.com/en-us/forums/intel-media-sdk?page=1).

And I also didn't do any deep performance tests on encoding-decoding schema, specifically not related to multithreading (which is implemented internally in core Intel Media libraries)

Few months ago I did performance and quality test for decoding on i7 (it is described somewhere before in this thread) which showed me that -hw and -sw decoding provides identical YUV output but -hw is significantly faster.

For encoding, I only realized that -wh and -sw produces slightly different results which points to the fact that HW-library uses different algorithm than SW-library (this was also confirmed by Intel support).

And obviously: HW encoding is faster than SW, but it may share/occupy some more GPU resources and thus HW decoding-encoding chain can exhaust them.
I personally use -hw for decoding and -sw for encoding portion of processing chain.

[colinhunt]

I personally use Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM, so I cannot comment on XEON.
In order to figure out what's going on, I ran another instance of BD-RB while the first one was still encoding MVC in software at 30-35% CPU utilization. I also set up the 2nd BD-RB in such a way that it was using super-slow, super high-quality settings for x264.

After 2 hours of two BD-RBs running simultaneously, the one encoding MVC had dropped from 5 to 4 fps. The second BD-RB is running x264 pass 2/2 at 7.25 fps. That's pretty much the encoding speed I got from a dual-Xeon E5520 during pass 2/2 when set for the same super high-quality settings.

All this looks to me like FRIMEncoder, or the Intel SDK it's based on, is not optimized for multithreading and/or multi-CPU. I'm not a programmer so I might be totally incorrect about this, however :)

[jdobbs]

In order to figure out what's going on, I ran another instance of BD-RB while the first one was still encoding MVC in software at 30-35% CPU utilization. I also set up the 2nd BD-RB in such a way that it was using super-slow, super high-quality settings for x264.

After 2 hours of two BD-RBs running simultaneously, the one encoding MVC had dropped from 5 to 4 fps. The second BD-RB is running x264 pass 2/2 at 7.25 fps. That's pretty much the encoding speed I got from a dual-Xeon E5520 during pass 2/2 when set for the same super high-quality settings.

All this looks to me like FRIMEncoder, or the Intel SDK it's based on, is not optimized for multithreading and/or multi-CPU. I'm not a programmer so I might be totally incorrect about this, however :)Be careful. If you look back through the thread you'll see that running multiple instances of FRIMEncode can cause a crash. I tried adding multiple instances to speed up encoding and had to give up the idea.

[colinhunt]

Be careful. If you look back through the thread you'll see that running multiple instances of FRIMEncode can cause a crash. I tried adding multiple instances to speed up encoding and had to give up the idea.
That's good to know, thanks. My test above was running a single instance of FRIMe and a single instance of x264, however.

[Shylock]

Hi,

Using Frim through BDRB with Intel I7 4770k and hardware setting, both for decoding and encoding, No errors reported but the resulting stream is heavily corrupted and unwatchable, as if the disc was not ripped correctly.
The same with 3 different discs.
If switching to software encoding, everything is OK.
I'm using the last 3496 beta drivers. Have someone experienced the same issue ?

[Hajnal]

hi

using frimencoder and scenarist error:
Error : ERROR: The MVC scalable nesting SEI message(offset_metadata) is not contain first view component in decoding order of GOP. AU No = 0
D:\temp\WORKFILES\VID_00000.AVS.mvc

command: "D:\TEMP\WORKFILES\VID_00000.AVS.mvc" -laicq 1 -d3d11 -hw -rf 4 -w 1920 -h 1080 -f 23.976 -u 1 -cpbsize 3743 -l 6 -profile high -level 4.1 -vbr 32331 34826 -gop 24 4 0 O -maxdpb 4

-gop 24 4 0 O - other setting?

[acsphere]

Hi,

Using FRIMDecoder version 1.23 (build: Mar 19 2014), and get the following near the very end of the decoding:

ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)

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



More details:

FRIMDecode.exe -i::mvc track.264 track.mvc -o \\.\nul \\.\pipe\rightyuvpipe


Media SDK impl SOFTWARE (libmfxsw64.dll)
Media SDK version 1.8
Memory type System

Input video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,0,0
Frame rate 23.976

Output format YUV420


The original video has the following information from tsMuxeR:

Track ID: 4114
Stream type: MVC
Stream ID: V_MPEG4/ISO/MVC
Stream info: H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976 3d-pg-planes: 32
Stream lang:

Track ID: 4113
Stream type: H.264
Stream ID: V_MPEG4/ISO/AVC
Stream info: Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
Stream lang:

[...]

File #00000 name=[...]\BDMV\STREAM\SSIF\[...].ssif
Duration: 00:00:00.824
Base view: left-eye
start-time: [...]
Marks: 00:00:00.000

File #00001 name=[...]\BDMV\STREAM\SSIF\[...].ssif
Duration: 01:40:01.259
Base view: left-eye
start-time: [...]
Marks: 00:06:04.769 [...]


Any ideas?

thanks!

[videofan3d]

Hi,

Using FRIMDecoder version 1.23 (build: Mar 19 2014), and get the following near the very end of the decoding:

ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)

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



More details:

FRIMDecode.exe -i::mvc track.264 track.mvc -o \\.\nul \\.\pipe\rightyuvpipe


Media SDK impl SOFTWARE (libmfxsw64.dll)
Media SDK version 1.8
Memory type System




Error "undefined behavior (-16)" is returned from some core-function in libmfxsw64.dll library.

Interesting and strange.
I have never faced any "undefined" error during decoding process.
(It happens usually during encoding, and especially in HW mode, as reported by few users here, while SW mode is more stable.)

Try to use 32-bit version.
Or maybe try to use older libmfxswNN.dll from previous release, which is older and has API version 1.7

[colinhunt]

videofan3d, I sure hope you haven't stopped working on this fantastic encoder...?

[videofan3d]

videofan3d, I sure hope you haven't stopped working on this fantastic encoder...?

:)

Is there anything specific what needs to be improved? :D

[colinhunt]

:)

Is there anything specific what needs to be improved? :D
Well-ll, since you asked... :D

Version 1.23 keeps crashing when used with BD-Rebuilder 0.47.06. For a moment I thought that simply rebooting after every successful encode solved the problem, but no, FE crashes at random points during the encoding regardless. Most encoding jobs finish OK eventually if I restart the job again and again... but I'm trying to backup Tinker Bell 3D now, and have already restarted it at least 10 times. There's no logic as to when FE crashes; it can happen at 3%, 24%, 76%... it's just totally random.

The encoding rig is not overclocked and it's running cool. I'm doing hardware decode/encode, and I can see CPU load stays below 30% during encoding.


Dammit, there it goes again. This time it got to 90.84%, then FE crashed. "FRIMEncode.exe has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."

I've tried driver versions 3412, 3496 and the 3574 beta. Yesterday I found and installed even newer drivers, v3621, that are originally for Intel NUC but they support a wide range of 2nd, 3rd and 4th generation Intel CPUs.

This random crashing has affected all versions listed above.

[videofan3d]

Well-ll, since you asked... :D

Version 1.23 keeps crashing when used with BD-Rebuilder 0.47.06.
....
I've tried driver versions 3412, 3496 and the 3574 beta. Yesterday I found and installed even newer drivers, v3621, that are originally for Intel NUC but they support a wide range of 2nd, 3rd and 4th generation Intel CPUs.

This random crashing has affected all versions listed above.

Is there any message in the log, stdout/stderr which I could analyze?
If this issue is coming from FRIM wrapper itself then I can fix it - I only need to get identified where it happens.
If it is something in libmfxswNN.dll / libmfxhwNN.dll then likely not - it will be rather in Intel's hands.

Please check also whether combination HW decoding + SW encoding is more stable. (I know it is slower, but in my view stability pays more in this case... )

Remark: I personally use FRIM only for encoding my own 3D videos, not for shrinking Blu-rays :)

[colinhunt]

Is there any message in the log, stdout/stderr which I could analyze?
If this issue is coming from FRIM wrapper itself then I can fix it - I only need to get identified where it happens.
If it is something in libmfxswNN.dll / libmfxhwNN.dll then likely not - it will be rather in Intel's hands.
I'll have to get back to you on those.

In the meanwhile, I have an interesting data point for you. That Tinker Bell 3D I tried to re-encode, the one I gave up on after 12 re-starts? Well, I went back to driver version 3412, rebooted the rig, ran the encode again... and it finished without crashing the first time. Howeverrrrr... the next title I tried to encode crashed almost immediately, and so did the next 4 re-starts. So, it almost looks like a simple reboot is not enough; I need to install drivers and reboot, and following that the next encode job finishes without problems.

Weeeeeird....

Please check also whether combination HW decoding + SW encoding is more stable. (I know it is slower, but in my view stability pays more in this case... )
It's a difference between 35 minutes and 9 hours for me, so I'll do what I can to enable the 35 minute option :)

[videofan3d]

I'll have to get back to you on those.

In the meanwhile, I have an interesting data point for you. That Tinker Bell 3D I tried to re-encode, the one I gave up on after 12 re-starts? Well, I went back to driver version 3412, rebooted the rig, ran the encode again... and it finished without crashing the first time. Howeverrrrr... the next title I tried to encode crashed almost immediately, and so did the next 4 re-starts. So, it almost looks like a simple reboot is not enough; I need to install drivers and reboot, and following that the next encode job finishes without problems.

Weeeeeird....



It looks like some memory leak somewhere in core system, which "appear" accidentally, or even infrequently.... :(
It won't be easy to identify it. And if it is really in core libraries - then I'll have no chance to influence it.

Please tell me, which BD3D titles are impacted the most?
(I don't have this Tinker Bell 3D available in our Blockbuster video-library)
I'll try to get some of them and simulate it....

[colinhunt]

Please tell me, which BD3D titles are impacted the most?
After maybe two dozen encodes and countless restarts in the past week, I'd say the issue is not limited to certain titles, nor do some titles crash FE more than others. It's just... random. Like I mentioned, Tinker Bell crashed FE 12 times before I installed earlier drivers and rebooted, after which it finished encoding on the first attempt - but I'm pretty sure the same thing could have happened with any other 3D title. I had to restart Universal Soldier several times, same with Loser (a German post-conversion) and right now I'm trying to encode Battle Royale (Japanese post-conversion); already had to restart encoding at least 5 times.

I sooooo wish I had more precise and helpful information to give to you :(

//

Hold on. BD-RB does not output error logs for any FRIM crashes... but the next time encoding crashes, I'll shut down BD-RB and will run the same encoding.bat in a command line window. When that crashes, I should have some error information for you.

[colinhunt]

Here you go!

Media SDK impl HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.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 24149,45000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 2
Processing started
Frame number: 6225Frame number: 4905
ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)


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

What if I replaced that libmfxhw32.dll from a newer set of drivers...?

Hmm... why do I remember a parameter, something like -async, which I used successfully with a much earlier version of FRIMDecode/Encode?

[colinhunt]

I replaced the DLL from the latest set of drivers, and for a while it looked like that solved the problem. But then:

Media SDK impl HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version 1.10
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 24149,45000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 2
Processing started
Frame number: 70885Frame number: 68215
ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)


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