Free H.264 MVC 3D Encoder

[frank]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.

That issue talked a guy to the Intel dev forum in January. Guess what they answered... Nothing!!

The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.

The question:
How can we set the bitrate of the two views separately, according to a profile?
The professional encoders (Rovi, Encore) make it in this way.

Without that option FRIMencode /Media SDK makes no sense.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.

[Sharc]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.
Where did you see this? In all my encodes the dependent stream was about 80% of the basic one, which is not terribly efficient but at least the saving is about 20%...25%.
The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.
There is no such rule or law. The ratio depends on the encoder and the video itself.
The question:
How can we set the bitrate of the two views separately, according to a profile?
AFAIK there is no such setting for the free Intel/FRIM encoder.
The professional encoders (Rovi, Encore) make it in this way.
Without that option FRIMencode /Media SDK makes no sense.
Easy; just buy a professional encoder in this case.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.
The decision remains with you :)

[HWK]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.

That issue talked a guy to the Intel dev forum in January. Guess what they answered... Nothing!!

The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.

The question:
How can we set the bitrate of the two views separately, according to a profile?
The professional encoders (Rovi, Encore) make it in this way.

Without that option FRIMencode /Media SDK makes no sense.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.

Yes, I am aware of it. What really is happening is bitrate is equally divided between views with very little variance. In fact I am convinced reduce size is caused by absence of I frames. Since dependent view still contain P and B frames.

Although dependent view require 50 less bitrate but this is not the case 100% of time, it usually change based on scene complexity and and depth info present. However with that said 90% total size of mvc stream will be 50% of avc stream.

CCE and Rovi will change bitrate scene by scene ranging from 30% to 70% change between avc and mvc stream. Example if you are encoding with 10Mbps encoder may assign anywhere between 3 to 7 Mbps to avc and remaining to mvc or other way around, again it all depends on scene and complexity of source.

[superleo]

Apologize in advance since this question is off topic a bit, but I've been researching the question and I have seen it mentioned in several different places but have not found a definite answer or how to fix it.

I'm working on a 3D Bluray Demo Disc, comprised of scenes from different BDs. My intent is to author the disc in scenarist. When I demuxed the clips and try to import them into scenarist I'm getting an error message stating that the base stream and the dependent stream have different number of frames. This is indeed the case. If I remember someone has discover this and wanted to add some empty frames to make them the same while someone different suggested just to remove some frames. The question is anyone ever found out how to fix the frames so they have the same number on both streams?

[HWK]

Ok, here we go. In order to fix it you need to decode two streams altogether so they not dependent on each other and more important time base and run time is same. Once that is done you need to run through mvc encoder and it will fix it.

Once all is done then you can import into program of your choice.

[frank]

@sharc
Where did you see this?
Look with Mediainfo into professional 3D Blu-rays (corresponding streams), then you can see the video bitrates and max values that the encoder has used. All dependent bitrates on 3D Blu-rays are much lower (I have seen 0.3x - 0.6x). The encoder uses separate processes for main and dependent stream, and the bitrates must be set correctly for both processes. MediaSDK equals the bitrates and that is certainly an error as well as the decoder bug in Pacific Rim. INTEL should fix the SDK.
FRIMencode/MediaSDK usually sets the bitrates (target!) to 12500 for both streams. The 80% difference with your FRIMencodes represents the absence of I-frames.

[colinhunt]

No new development in the past 2 months? Shame, that.

[alexxdls]

Can I use VapourSynth script instead AviSynth one at input?

[videofan3d]

Can I use VapourSynth script instead AviSynth one at input?

Try it and let us know ;)

[alexxdls]

Here results come
d:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1

ERROR: Cannot open input avi-file F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_
51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

d:\TOOLS\MyDCPConverter>Tools\vspipe TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K
_TCF_20140417_DWA_IOP-3D_BD3D.vpy - | Tools\FRIMEncode -sbs 2 -i - -viewoutput -
o::mvc F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-
3D.avc F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-
3D.mvc -w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1
Script evaluation failed:
File reading exception:
[Errno 2] No such file or directory: 'TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2
K_TCF_20140417_DWA_IOP-3D_BD3D.vpy'
FRIM Encoder version 1.22 (build: Feb 2 2014)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (d:\TOOLS\MyDCPConverter\Tools\libmfxsw64.dll)
Media SDK version 1.8
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 24.000
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 1 (quality)

Processing started
Frame number: 0
Processing finished in 0.00 secondsd:\TOOLS\MyDCPConverter>Tools\vspipe.exe F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_
RU-00_51_2K_TCF_20140417_DWA_IOP-3D_IOP-3D_BD3D.vpy - -info
Width: 3840
Height: 1080
Frames: 72
FPS: 24/1
Format Name: YUV420P8
Color Family: YUV
Bits: 8
SubSampling W: 1
SubSampling H: 1

[videofan3d]

Here results come
d:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1

ERROR: Cannot open input avi-file F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_
51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.



I have no personal experience with VapourSynth, so I cannot comment whether it can even work or not.
From principle: if the VapourSynth substitutes AVI, and can be opened using VFW functions of Windows, then it could work.
(This is the way how Asisynth works.)

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.
Can this VapourSynth script be opened using Windows Media Player? If yes, then FRIM Encoder could (possibly) open it as well.
Maybe some tuning via ffdshow will be needed (32-bit or 64-bit respectively)

[alexxdls]

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.
Can this VapourSynth script be opened using Windows Media Player? FRIM is x64 and VS x86 because of some issues with a plugin.
And yes, the script is openned with WMP freely.
I'll do some checks and report back

[alexxdls]

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.Yeap. That was a solution. x86 encoder version works flawlessly with x86 VapourSynth scriptd:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1
FRIM Encoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (d:\TOOLS\MyDCPConverter\Tools\libmfxsw32.dll)
Media SDK version 1.8
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 24.000
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 1 (quality)

Processing started
Frame number: 72
Processing finished in 17.04 seconds

[SquallMX]

Does FRIM support the Haswell Advanced Options like Look-Ahead?

It seems to be a great option for improving quality on complex scenes.

[videofan3d]

Does FRIM support the Haswell Advanced Options like Look-Ahead?

It seems to be a great option for improving quality on complex scenes.

Yes.

You can check all options: FRIMEncode -help

However, keep on mind that Look-Ahead is not HRD (Hypothetical Reference Decoder) compliant method - per Intel documentation.

[bebolan]

I wonder my cpu i7 920 is supported by FRIM?

[damorsoft]

Due to an disc cleanup error I deleted my earlier version of the SDK (2013) I had downloaded earlier this year. I have written a routine to compress a DL 3d movie to a bdr25, it was working great. It did not create a proper 3d copy using the SDK 2014. I did manage to find a copy of SDK 2013 R2 (media SDK 1.7) that does seem to be working OK again.
Was this something I could have done wrong or has there been some subtle changes with 2014??

[DMagic1]

No update to support the newer drivers?

[DMagic1]

Driver version 15.36.7.64.3960 seems to have fixed some pixel issues with decoding that some experienced at times with other software.
Could support be added for this version with Frim?

[videofan3d]

Driver version 15.36.7.64.3960 seems to have fixed some pixel issues with decoding that some experienced at times with other software.
Could support be added for this version with Frim?

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

[DMagic1]

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

I mean frim fails with all the latest driver versions using decode with Rebuilder.

[damorsoft]

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

Intel 2014 ran fine with FRIM decode/encode it is just the resulting 3D iso file wasn't. The picture did indeed look like 3d but the TV did not recognize it as 3D. When I went back to the older version on INTEL the 3D was perfect.. Something is not quite right.

Thanks

[DMagic1]

Intel 2014 ran fine with FRIM decode/encode it is just the resulting 3D iso file wasn't. The picture did indeed look like 3d but the TV did not recognize it as 3D. When I went back to the older version on INTEL the 3D was perfect.. Something is not quite right.

Thanks

Sorry what version is "Intel 2014"?

[blatantsubtext]

I'm trying to extract the two 3D views from an MVC elementary stream into two separate yuv files and I can't seem to get FRIMDecode to produce anything. It runs for awhile, then crashes. I used MakeMKV to get the stream off the BD, then mkvextract to pull just the .264 file from the MKV.

If I run FRIMDecode (32-bit), the program runs for about 20-30 mins, then Windows reports a "This program has stopped working" dialogue box, and it closes.

If I run FRIMDecode (64-bit), the program runs for about 20-30 mins and I get this error:
E:\MVC>FRIMDecode -i::mvc Input.h264 -o Output_L.yuv Output_R.yuv

ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (114)


ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (785)


ERROR: Cannot start decoding process.

I don't have an Intel GPU, so this should be a software decode. I have tried running both with and without the -sw flag, and it makes no difference. Any thoughts or guidance would be much appreciated.

*EDIT* One last note, the Output_L.yuv and Output_R.yuv files never get made, so I'm really unsure what FRIM is doing for the 20-30 mins it runs.

[pistacho]

I used MakeMKV to get the stream off the BD, then mkvextract to pull just the .264 file from the MKV.


mvkextract is NOT MVC 3D compatible and do you not need to create intermediate MKV. Just use eac3to or TsMuxeR to extract AVC/MVC streams from BD.

[damorsoft]

Sorry what version is "Intel 2014"?

I am using Intel Media SDK64bit 4.13.6.21, not sure of the 2014 version but it is still available from INTEL.

Just did Maleficent and was a great copy.

[blatantsubtext]

mvkextract is NOT MVC 3D compatible and do you not need to create intermediate MKV. Just use eac3to or TsMuxeR to extract AVC/MVC streams from BD.

Ahh, I would have thought mkvextract would not have cared anything about the stream itself and would have simply dumped its data to a file. TsMuxer did the trick, though. Thanks!

[blatantsubtext]

So I did some tests and it turns out that you CAN use mkvextract to get the MVC stream out of a MakeMKV-created MKV file:

mkvextract -f tracks "input.mkv" 0:output_mvc.264 --fullraw

I'm unsure about needing to use the -f flag, but this definitely produces a single H.264 bitstream file that FRIMDecode can take as input.

While this does add one more step and one more intermediate file, I personally think this is better than the AnyDVD + TsMuxer method, if only that MakeMKV is about US$50 cheaper than AnyDVD HD (regular price €79=~US$98).

[Nico8583]

Hi,
Do you plan to update your FRIM with latest Intel SDK ?
The latest version seems to solve problems with Pacific Rim and Dragon Gate movies (tested with pistacho software).
Thanks !

[videofan3d]

Hi,
Do you plan to update your FRIM with latest Intel SDK ?
The latest version seems to solve problems with Pacific Rim and Dragon Gate movies (tested with pistacho software).
Thanks !


Hi,

so far I didn't have a time to explore the latest Intel Media SDK. But I plan to do it in the future and possibly bring additional bitrate control methods (e.g. LA HRD).

Anyway, I presume that Intel keeps backward compatibility, so you can try to replace libmfxsw32.dll with the latest one, and everything should/could work (with some fixed bugs, of course :) ).
Please try and report back to other users...

[frank]

My tests showed that libmfxsw32.dll later than 4/2014 doesn't work properly on Intel's 2nd gen cpu, Sandy Bridge, gfx3000!
Latest graphics drivers for this cpu/chipset are from 4/2014.:mad:

And that was the time where FRIM was developed.

[r0lZ]

Yes, unfortunately, it appears that the version you have used works fine in most cases, but fails with Dragon Gate and Pacific Rim. Changing only the Intel DLL results (on my machine without hardware acceleration) in completely bad conversions. All frames of all movies are pixellized and never decoded properly. Obviously, something has changed in the latest Intel lib and is not backward compatible. According to tests I did with frank, it seems that the problem is hardware dependent, even when you use the software decoder!

Donald has a new version of his DGMVCSource decoder, that I will test right now. Perhaps he has found the solution. Anyway, frank, Nico or me will let you know if a good solution is found...

[Sharc]

I tested Donalds new DGMVCsoure (SW only) with Pacific Rim. The glitch is gone!
(I can't test the HW option with my PC).

[r0lZ]

Yes, it's confirmed. The latest versions of the Intel SDK and libs solve the problem. However, the latest lib is not backward compatible.

As Donald said, FRIM will need to be rebuilt with INDE 2015 Update 1. Then, FRIMSource will work fine with the libmfxsw32.dll v6.14.11.28 (28/11/2014). It's the intel lib distributed with DGMVCSource, and currently incompatible with FRIMSource. Therefore, I need a recompiled version of your DLL, to include it in BD3D2MK3D. As far as I know, there is no need to modify your code. Can you do that?

Thanks in advance! :thanks:

[videofan3d]

Yes, it's confirmed. The latest versions of the Intel SDK and libs solve the problem. However, the latest lib is not backward compatible.

As Donald said, FRIM will need to be rebuilt with INDE 2015 Update 1. Then, FRIMSource will work fine with the libmfxsw32.dll v6.14.11.28 (28/11/2014). It's the intel lib distributed with DGMVCSource, and currently incompatible with FRIMSource. Therefore, I need a recompiled version of your DLL, to include it in BD3D2MK3D. As far as I know, there is no need to modify your code. Can you do that?

Thanks in advance! :thanks:

Unfortunately, it is not only about recompilation with INDE 2015 Update 1.
There are few incompatibilities which I need to investigate and treat in the source code (and overcome some newly introduced bugs in libmfxhw32.dll :-( )

I will look at this deeper next week and then provide new version for thorough testing.

[r0lZ]

I'm interested to know what are those newly introduced bugs in libmfxhw32.dll ?

[Pat357]

I'm trying to let FRIMencode to read from STDIN, but I get nothing but errors or 0 bytes files as output.264
Reading fom .AVS & AVI seems to work just fine for me.

To rule out a lot of other things, this creates a nice output :
FRIMEncode -avi -i 2k_ffms.avs -o::h264 2k_ffms.h264 -icq 22 -u 1

But this does not :
avs2yuv -raw 2K_ffms.avs - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

It creates a an emty output file (0 bytes)

and this s what I get :

>> avs2yuv -raw 2K_ffms.avs - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080
FRIM Encoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE (2) - D3D9 (C:\Program\Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version 1.11
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 ICQ
quality 22
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)

Processing started
2K_ffms.avs: 1920x1080, 60060/1001 fps, 500 frames
Frame number: 0
Processing finished in 0.08 seconds


I've tried to let avs2yuv output a raw stream (-raw switch) but that also did not work.

The idea behind reading from STDIN is to be also able to feed VapourSynth .VPY scripts to the encoder using VSPIPE.

To be honest, I don't know how to use named pipes ; the most output from common tools is like AVS2YUV and VSPIPE is STDOUT with an option to deliver raw or yuv4mpeg.
The latter (yuv4mpeg) is a great option because it sends also all video properties like resolution and framerate.

[jdobbs]

Not sure if this is your problem -- but I think you're supposed to use the "-o" parameter in the command line:

avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

[Pat357]

Not sure if this is your problem -- but I think you're supposed to use the "-o" parameter in the command line:

avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

Thanks for your input !
Unfortunatelly this didn't resolve the problem.
Here is what I get now :
(after also adding the -f 60 parameter & put AssumeFPS(60) in avs-script.

>avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 "2k_ffms_stdin_test.h264" -icq 22 -u 1 -w 1920 -h 1080 -f 60
FRIM Encoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE (2) - D3D9 (C:\Program\Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version 1.11
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 60.000
Bitrate control ICQ
quality 22
GOP structure:
GOP length 60
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 1 (quality)

Processing started
2K_ffms.avs: 1920x1080, 60 fps, 1000 frames
Frame number: 0
Processing finished in 0.07 seconds
error: wrote only 3087595 of 3110400 bytes
>

[videofan3d]

Thanks for your input !
Unfortunatelly this didn't resolve the problem.
Here is what I get now :
(after also adding the -f 60 parameter & put AssumeFPS(60) in avs-script.


Please check the input side (avs2yuv or avs script itself).

I just tested piped commands:

set SRC=f:\BD\BDMV\STREAM\00011.m2ts
set DST=c:\_testing\DST.h264

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1

And all worked pretty well. :-)

[videofan3d]

I'm interested to know what are those newly introduced bugs in libmfxhw32.dll ?

E.g.:

FRIMEncode uses (till version 1.23) hardcoded setting for H.264 options AdaptiveI=on and AdaptiveB=on. These settings are supposed to allow SDK encoder to change B&P -> I and B -> P frames according to actual situation in the input scene being encoded, i.e. not exactly to follow predefined requested GOP structure. (for details please see Intel Media SDK documentation)

However, I realized, that libmfxhw32.dll from Intel Driver version 15.36.14.64.4080 fails and does not accept AdaptiveI=on nor AdaptiveB=on.
Fortunately -sw (i.e. libmfxsw32.dll) works as expected.
(It took me quite time to trace it and find what is happening there; it looked like mystery at the first time).

Hence I need to tweak these setting in FRIMEncode.

(... and I'm sure there few more new bugs ;-) )

[Pat357]

Please check the input side (avs2yuv or avs script itself).

I just tested piped commands:

set SRC=f:\BD\BDMV\STREAM\00011.m2ts
set DST=c:\_testing\DST.h264

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1

And all worked pretty well. :-)
That's odd...but can you tell me the format of the stream between the decoder and the encoder ?
It's obvoiusly RAW uncompressed video, but what format/color-space ? YV12, NV12 or something else ?
My .AVS script is OK since it works when using :

FRIMEncode -avi -i 2k_ffms.avs -o::h264 "2k_ffms.h264 -u 1 -f 60

This produces a nice encoded .264 that also plays fine in any player.
This should rule out all possible HW-issues/setup-issues and most environemt parameters as being a problem.

However the encode fails if I try :
avs2yuv -raw 2k_ffms.avs -o - | FRIMEncode -i - -o::h264 "2k_ffms_stdin.h264" -u 1 -f 60 -w 1920 -h 1080
The problem seems to be one of the following :
-There is a bug in my cmd-line or syntax.
-AVS2YUV has a bug or is not compatible with your encoder because the RAW uncompressed format is not what the encoder expects/accepts.
I've also tried VSPIPE (part of VapourSynth and I got exactly the same error.)
- I really don't know.

Can you please try it the same way I did (using avs2yuv/Avisynth) on your system just to rule out any problem wih this approach ?

My AVS script is :

LoadPlugin("c:\plugs\FFMS2.DLL")
Import("c:\plugs\FFMS2.AVSI")
FFVideoSource("test_1080p.mkv", colorspace="YV12")
AssumeFPS(60)
It plays fine is any player like MPC-HC, Mplayer, FFplay,...

What could be the reason, you think, why the first method for encoding *does* work, while the other (using AVS2YUV) does not ?
I'm using the same Avisynth script.

For the first method, FFDShow is some needed, because whitout it it does not work.
The second (invoving AVS2YUV) , FFDShow is not involved, so maybe this could be the reason ?
Do you maybe use FFDShow for the color-space convertion from YUV420 to NV12 needed for the Intel HW encoder ?


PS.

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1
I just tested your decoder-encoder example on my system and it works indeed perfect.
The encoder accepts what the decoder produces, that's for sure.
This brings me back to wheter the encoder accepts "normal" (by AVS2YUV) produced RAW YV12 /I420 video.
I suspect the problem lies there somewhere.

[videofan3d]

....

For the first method, FFDShow is some needed, because whitout it it does not work.
The second (invoving AVS2YUV) , FFDShow is not involved, so maybe this could be the reason ?
Do you maybe use FFDShow for the color-space convertion from YUV420 to NV12 needed for the Intel HW encoder ?

I don't know nor have AVS2YUV.
But it may be the right point: while FRIMEncode -avi -i input.avs involves ffdshow, using stdin doesn't !

Input format via stdout-stdin has to be YV12, so make sure that AVS2YUV sends data to stdout in this format.
Optionally it could be also NV12, then try FRIMEncode -nv12 but I didn't test it (having no input source in NV12)

[r0lZ]

E.g.:

FRIMEncode uses (till version 1.23) hardcoded setting for H.264 options AdaptiveI=on and AdaptiveB=on. These settings are supposed to allow SDK encoder to change B&P -> I and B -> P frames according to actual situation in the input scene being encoded, i.e. not exactly to follow predefined requested GOP structure. (for details please see Intel Media SDK documentation)

However, I realized, that libmfxhw32.dll from Intel Driver version 15.36.14.64.4080 fails and does not accept AdaptiveI=on nor AdaptiveB=on.
Fortunately -sw (i.e. libmfxsw32.dll) works as expected.
(It took me quite time to trace it and find what is happening there; it looked like mystery at the first time).

Hence I need to tweak these setting in FRIMEncode.

(... and I'm sure there few more new bugs ;-) )
Wow, it's Chinese for me. What are the visible symptoms of these bugs? Are they responsible of AVC or MVC decoding glitches?

If I understand correctly, those bugs are present only in the hardware drivers, and the software decoder should be safe. Is it correct?

Sorry to ask you that, but I would like to know if I can trust the latest version of the decoder, in sw, hw and "auto" modes. If hw is not safe, I can at least set sw as the default setting for BD3D2MK3D. Unfortunately, I can't test the hw mode myself, because I have an old processor w/o graphics.

Anyway, thanks for trying to adapt your decoder to the newest version. Unfortunately, it seems that Intel is unable to release a bug free version. When they fix a bug, they introduce another one!

[videofan3d]

Wow, it's Chinese for me. What are the visible symptoms of these bugs? Are they responsible of AVC or MVC decoding glitches?

If I understand correctly, those bugs are present only in the hardware drivers, and the software decoder should be safe. Is it correct?

Sorry to ask you that, but I would like to know if I can trust the latest version of the decoder, in sw, hw and "auto" modes. If hw is not safe, I can at least set sw as the default setting for BD3D2MK3D. Unfortunately, I can't test the hw mode myself, because I have an old processor w/o graphics.

Anyway, thanks for trying to adapt your decoder to the newest version. Unfortunately, it seems that Intel is unable to release a bug free version. When they fix a bug, they introduce another one!

The symptom is, that FRIMEncode/FRIMTranscode version 1.23 (and lower) with Intel driver 15.36.14.64.4080 doesn't work at all. It fails
ERROR: Cannot initiate Intel Media Encoder - invalid parameters.

Full stop.:-D

-sw is fortunately not impacted.

I will overcome it in version 1.24 (to be released soon - I hope)

Re: "bug free version"
There is no such thing like bug free SW! It is only a dream :-D
Each and every SW has bugs. More complex SW = more new bugs.
It is only about approach of the vendor to be able to fix them.

Golden rule of programming: "If it already works, don't touch it anymore!!!" :-D

[r0lZ]

OK, thanks!

And of course I agree that a complex program cannot be fully bug free. But Intel is very irritating, because they should fix the bugs that have been reported, without trying to add new features immediately. Then, when everything works as expected, new features can be added, and the users happy with the old version can stick with it. At least, a version is usable. But that seems impossible to obtain from the guys at Intel.

[videofan3d]

FRIM version 1.24 released.

Compiled with Intel Media SDK - INDE 2015 Update 1

Few new features (=parameters) added:
-lahrd bitRate depth ... new encoding mode LA HRD-compliant
-dar w:h ... set output display aspect ratio, e.g. 4:3, 16:9 (FRIM Encode only)
-gopfile filename ... GOP-structure file (=requested I-frames), e.g.: (FRIM Encode only)

Please read FRIM_release_notes.txt for more details.

(Kindly asking audience of this forum for further testing :) ... )

[r0lZ]

Thanks! I'll test FRIMSource right now...

[Sharc]

Thanks videofan.
I will do some tests as well.

[r0lZ]

I did 2 tests with FRIMSource, and everything is OK so far. But I don't have a CPU with the hardware acceleration, so my tests are limited. Anyway, for me, it's OK, and I'll distribute this version of FRIMSource with the next release of BD3D2MK3D (to be released soon).

Sorry, but I haven't tested FRIMEncode and FRIMDecode.