Free H.264 MVC 3D Encoder

[Sharc]

Originally Posted by Cedvano

Where I can find SSifsource3, please.

Thanks

Here, author is slavanap:

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

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

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

[videofan3d]

Originally Posted by colinhunt

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

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

Try to set different pipename for each session...

[colinhunt]

Originally Posted by videofan3d

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

I did, didn't help.

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

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

Currently running pipe is named simply "TMP".

[colinhunt]

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

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

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

[Cedvano]

Originally Posted by Sharc

Here, author is slavanap:

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

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

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

Thank you, I try with Ssifsource2.

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

[videofan3d]

Originally Posted by colinhunt

I did, didn't help.

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

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

Currently running pipe is named simply "TMP".

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

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

[Cedvano]

videofan3d

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

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

Can you correct FRIMDecode for the first soluce ?

Thanks

[videofan3d]

Originally Posted by Cedvano

videofan3d

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

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

Can you correct FRIMDecode for the first soluce ?

Thanks

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

[Cedvano]

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

[colinhunt]

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

[Cedvano]

Here the link : 00278.ssif

[tymoxa]

Originally Posted by Cedvano

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

It's OK for me with this scheme and your sample:


Try this line:

FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o output.avc -o output.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

[Cedvano]

With this line, I've the same problem.

Have you compare the YUV files.

It's not all the ssif, I wait for more tests.

[videofan3d]

Originally Posted by Cedvano

videofan3d

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

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file - both L- and R-yuv are of the same length

Can you correct FRIMDecode for the first soluce ?

Thanks

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

[Cedvano]

Originally Posted by videofan3d

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

Yes, great ! Thanks.

[videofan3d]

Originally Posted by colinhunt

HD4000 hardware decode + hardware encode .

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
@colinhunt: Could you conclude such test?

[colinhunt]

Originally Posted by videofan3d

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
Could you conclude such test?

I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

[videofan3d]

Originally Posted by colinhunt

I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

This is interesting - and strange.
Decoding is much simpler than encoding, and I'd expect to get the same results, the same YUV file for both -sw and -hw, byte to byte identical!
(Btw, I compared Intel Media SW decoder output with JM H.264/AVC Reference Decoder from http://iphome.hhi.de/suehring/tml/, and they are really 100% identical - that's good)

For encoding - in theory - if GPU is given the same parameters as CPU, it should be also identical.
But I can imagine that GPU routines have different implementation than corresponding C-routines in SW mode. Which will lead to different DCT encoding and resulting .h264 videofile will be different (but visually it should be similar).

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode.

[colinhunt]

Originally Posted by videofan3d

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode.

I will, once I've cleared my current workload. It'll be a few days.

[videofan3d]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC