Free H.264 MVC 3D Encoder

[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.

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!

[videofan3d]

Originally Posted by 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!

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]

Originally Posted by 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

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]

Originally Posted by Pat357

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]

Originally Posted by r0lZ

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]

Originally Posted by videofan3d

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.

Originally Posted by videofan3d

 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]

Originally Posted by Pat357

....

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]

Originally Posted by videofan3d

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]

Originally Posted by r0lZ

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.