Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
10th November 2013, 12:52 | #141 | Link |
Registered User
Join Date: May 2006
Posts: 3,997
|
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. Last edited by Sharc; 10th November 2013 at 13:32. |
10th November 2013, 13:56 | #142 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
Try to set different pipename for each session... |
|
10th November 2013, 13:58 | #143 | Link | |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Quote:
.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". Last edited by colinhunt; 10th November 2013 at 14:02. |
|
10th November 2013, 14:08 | #144 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
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:
Code:
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) |
10th November 2013, 14:18 | #145 | Link | |
Registered User
Join Date: Jul 2009
Posts: 244
|
Quote:
I don't understand, after Encoding with FRIMEncode, the number of frames between the 2 files is different. Someone have the same problem ? Last edited by Cedvano; 10th November 2013 at 14:40. |
|
10th November 2013, 14:47 | #146 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
I ran two sessions (in two cmd.exe) in parallel in -sw mode. Successfully! So maybe there is some restriction of -hw mode... |
|
10th November 2013, 18:21 | #147 | Link |
Registered User
Join Date: Jul 2009
Posts: 244
|
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 |
10th November 2013, 19:44 | #148 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
I need to reproduce it. |
|
10th November 2013, 21:08 | #151 | Link |
Registered User
Join Date: Jul 2009
Posts: 244
|
Here the link : 00278.ssif
|
10th November 2013, 22:31 | #152 | Link | ||
Registered User
Join Date: Oct 2006
Location: Kyiv, Ukraine
Posts: 117
|
Quote:
Try this line: Quote:
|
||
11th November 2013, 17:32 | #154 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
Next release FRIM 1.15 will be available on ~Thursday |
|
12th November 2013, 00:08 | #157 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
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.
|
12th November 2013, 00:29 | #158 | Link | |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Quote:
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. |
|
12th November 2013, 23:15 | #160 | Link |
Registered User
Join Date: Sep 2013
Location: Czech Republic
Posts: 321
|
Frim 1.15
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 |
Tags |
encoders, mvc |
|
|