Free H.264 MVC 3D Encoder [Archive] - Page 7

colinhunt

23rd November 2013, 14:59

FRIMTranscode GUI 1.04 (https://drive.google.com/file/d/0BxjaFf3cdexVV0NXSE14Sko5WHM/edit?usp=sharing)
version 1.04
- Add SSIF and MPLS support
- Include tsMuxer by Roman/Physic
Cedvano, one thing I believe the GUI should absolutely have: a built-in file size/bitrate calculator! It would be extremely useful to see immediately how large the resulting output file will be when encoded at the average bitrate user entered.

Wrt v1.04: Bitrates, shouldn't "min" be "avg"?

Cedvano

23rd November 2013, 15:03

Cedvano, one thing I believe the GUI should absolutely have: a built-in file size/bitrate calculator! It would be extremely useful to see immediately how large the resulting output file will be when encoded at the average bitrate user entered.

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).

For a small video, the size is good.

If someone have a good bitrate calcul, I take it.

Sharc

23rd November 2013, 15:10

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).

For a small video, the size is good.

If someone have a good bitrate calcul, I take it.
There is one available in the MeGUI Tools.

colinhunt

23rd November 2013, 15:13

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).
Others may disagree, but for my use it doesn't have to be 100% accurate. In fact, it's only good if the output is smaller than the estimate, because there are overheads to think of in muxing and in burning to disc.

Sharc

23rd November 2013, 15:19

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.

colinhunt

23rd November 2013, 15:22

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.
I suppose that's exactly why that calculator does not account for containers :)

Sharc

23rd November 2013, 15:28

You have the choice:
http://www.videohelp.com/tools/sections/bitrate-calculators

I recall that AVCHDcalculator was one of the better ones....

Cedvano

23rd November 2013, 15:34

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.

I use this one, I integrate it.

After some tests, I modify it later.

Cedvano

24th November 2013, 12:52

Hi guys,

Here the new release (with new name)

http://forum.doom9.org/showthread.php?t=169801

colinhunt

24th November 2013, 15:51

Hi guys,

Here the new release (with new name)

http://forum.doom9.org/showthread.php?t=169801
Thanks! I'll give it a try when the current transcoding is finished.

colinhunt

25th November 2013, 00:41

Had my first glitchy encode using Transcoder (v1.16). Demuxed source into avc + mvc with tsmuxer v2.2.3, ran Transcoder via cedvano's GUI. Output file appears to be OK and I can mux it into ISO using original playlist with tsmuxer, but mounting & playing the ISO results in movie freezing at the 19 minute mark. While the movie runtime looks normal, rest of the movie from 19 minutes onwards is a freeze frame without audio. Tested on Stereoscopic Player and a couple of PowerDVDs.

Sharc

25th November 2013, 00:44

Had my first glitchy encode using Transcoder (v1.16). Output files appear to be OK and I can mux them into a ISO with tsmuxer, but mounting & playing the ISO results in movie freezing at the 19 minute mark. Tested on Stereoscopic Player and a couple of PowerDVDs.
Hear hear..... ;)
Try with Pipes.

colinhunt

25th November 2013, 00:48

Hear hear..... ;)
Try with Pipes.
Yeah, I'm now testing cedvano's new GUI which allows the use of FRIMEncoder & pipes.

nunub

25th November 2013, 12:01

@cedvano
I m using 64bit windows 8 pro and i m getting error as such can't open command files.

Cedvano

25th November 2013, 12:57

@cedvano
I m using 64bit windows 8 pro and i m getting error as such can't open command files.

For encoding or demux ?

videofan3d

25th November 2013, 13:20

I started some tests with -hw coding.

@colinhunt
I didn't realize any problems with decoding:

FRIMDecode mvc -i test.h264 -o test_hw.yuv -hw
and
FRIMDecode mvc -i test.h264 -o test_sw.yuv

test.h264 was sample of Full HD-MVC-3D video (~80 seconds)

Both of them gave me byte-identical test_hw_L.yuv and test_sw_L.yuv . (and the same for R-eye).
Which I expect to be...

(Running on i7 Haswell - Intel Graphics 4600, Win8/64)

colinhunt

25th November 2013, 14:09

@colinhunt
I didn't realize any problems with decoding (Running on i7 Haswell - Intel Graphics 4600, Win8/64)
OK, let's do some comparison and debugging. Firstly, my systems are running Win7/64. Secondly, my latest CPU is i7-3770K, an Ivy Bridge CPU, with Intel Graphics HD4000. Thirdly, I never tested decoding like that, i.e outputting to a .yuv file. All my tests were done by piping directly from Decoder to Encoder, then dropping the output into tsmuxer and muxing into an .ISO file. There's a lot of difference in our respective test environments and methods, in other words.

Can you check what versions of libmfxhw32.dll and libmfxhw64.dll you have? Mine are 4.13.7.5; Digital signature timestamp is 5.7.2013.

colinhunt

25th November 2013, 16:26

videofan3d, this may have been asked earlier, but.... will FRIMEncode ever support 2-pass encoding?

videofan3d

25th November 2013, 18:52

videofan3d, this may have been asked earlier, but.... will FRIMEncode ever support 2-pass encoding?

Once Intel provides support for it :)

In my opinion - two pass is not necessary.
It can help only better to estimate total output file size, and thus provide bitrate control method "fit into size".

However, if you are interested in encoding quality, then every single pass encoder can do the job. MPEG compression is based on GOP, so if encoder can fit and process whole GOP, then it is - at least in theory - able to set all parameters for high-quality encoding.

colinhunt

25th November 2013, 19:13

In my opinion - two pass is not necessary.
It can help only better to estimate total output file size, and thus provide bitrate control method "fit into size".
I was under the impression that 2-pass also results in better, more efficient distribution of the available bit budget?

HWK

25th November 2013, 19:16

videofan3d, do you think it would be possible add support for creating I frame. Let say I want to insert I frame for chapters. I can specify 00:01:01:01, 00:04:02:08, 00:08:05:06 ....

HWK

25th November 2013, 19:18

I was under the impression that 2-pass also results in better, more efficient distribution of the available bit budget?

It does, since encoder know before hand how to best distribute bits throughout video.

videofan3d

25th November 2013, 19:20

videofan3d, do you think it would be possible add support for creating I frame. Let say I want to insert I frame for chapters. I can specify 00:01:01:01, 00:04:02:08, 00:08:05:06 ....

This I need to check - I guess that Intel provides some support for GOP manipulation .... patience, please :)

HWK

25th November 2013, 19:25

This I need to check - I guess that Intel provides some support for GOP manipulation .... patience, please :)

Thanks, Jdobbs wanted this feature as well for his program.

videofan3d

25th November 2013, 19:27

Can you check what versions of libmfxhw32.dll and libmfxhw64.dll you have? Mine are 4.13.7.5; Digital signature timestamp is 5.7.2013.

My libmfxhw32.dll is 4.13.9.19 (dig. signature 19.9.2013), libmfxhw64.dll the same.

I conducted some further performance tests:

Machine: Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM:

Real Full HD 3D video ~80 seconds (1942 frames x 2 (for 3D)):

Decoding to regular yuv-file:

sw-decoding on regular HDD 271.33 s
hw-decoding on regular HDD 240.41 s
(i.e. not so much difference)

sw-decoding on SSD drive 74.79 s
hw-decoding on SSD drive 22.42 s (!)
(i.e. this is great)

This shows that bottleneck is disk access, decoding process itself is faster, and even much faster in -hw mode.

To separate decoding from disk access, I also ran the same decoding test with writing output to nul-device ( \\.\nul ),
i.e. eliminating disk write completely:

sw-decoding to nul-device 70.94 s
hw-decoding to nul-device 9.31 s

Fantastic! - Hardware decoding itself is almost 8x faster !!!
All the rest is thrown by disk access.
Use of pipes will probably lie somewhere between SSD and null-device.

Remember: uncompressed 3D YUV-video represents 2x3 MB per frame!, this is really huge volume of data to be written to disk.

This shows (together with proven identity of output file)that hardware decoding should be used if possible.

Could somebody conclude similar test and confirm these results? :)

(I'm looking forward to test also encoding performance - later this week)

colinhunt

25th November 2013, 19:45

My libmfxhw32.dll is 4.13.9.19 (dig. signature 19.9.2013), libmfxhw64.dll the same.
Good; can you tell me where I can download these newer versions?

videofan3d

25th November 2013, 19:49

Good; can you tell me where I can download these newer versions?

I think you need to run some "Intel video driver update" of whatever similar on your PC.
There is a lot of files in "c:\Program Files\Intel\Media SDK" which are related and hardware dependent.

colinhunt

25th November 2013, 19:58

I think you need to run some "Intel video driver update" of whatever similar on your PC.
There is a lot of files in "c:\Program Files\Intel\Media SDK" which are related and hardware dependent.
Downloaded the latest 32bit HD4600 drivers from Intel, and inside the .zip there's an even newer libmfxhw32.dll: v4.13.10.3, dated 3.10.2013.

No libmfxsw32.dll, however.

videofan3d

25th November 2013, 20:14

Downloaded the latest 32bit HD4600 drivers from Intel, and inside the .zip there's an even newer libmfxhw32.dll: v4.13.10.3, dated 3.10.2013.

No libmfxsw32.dll, however.

libmfxsw32.dll is in FRIM Installation package :)

colinhunt

25th November 2013, 20:15

libmfxsw32.dll is in FRIM Installation package :)
I know ;) I was only looking for a newer one.

videofan3d

25th November 2013, 23:40

@Cedvano:

Just a little heads up for GUI:
Next version FRIM 1.18 will contain few new/changed features:

FRIM "all" 1.18
- processing info message now reports correct number of processed frames (for "mvc" NOT(!) multiplied by 2 anymore)
- added parameter "-start firstFrame" (for processing), together with "-length" allows decode/encode portions of the video stream
optionally, SMPTE format is allowed: -start 00:01:25:14 -length 00:00:05:07
- unified option naming: -sw or -hw, -d3d, -d3d11
- running platform is now detected automatically, i.e. "software mode" (using libmfxsw32.dll) is not a default anymore!
To force "software mode" you MUST specify "-sw" option

FRIM Encoder 1.18
FRIM Decoder 1.18
- option "-b" removed, use "-cbr" instead
- changed of syntax of "-i" and "-o" (to be unified with FRIM Transcoder)
e.g.:
FRIMDecode -i::mvc input_base.avc input_dependent.mvc -o output_L.yuv output_R.yuv
FRIMEncode -i input_L.yuv input_R.yuv -o::mvc output_base.avc output_dependent.mvc -viewoutput -vbr 24000 40000

(previous syntax still remains valid, but this new one is preferred)

FRIM 1.18 will be released in second half of this week - stay tuned ;)...

Cedvano

26th November 2013, 10:01

@videofan3d
Ok, thanks for your information. I'm waiting this next version for change mine.
Great job !

trevorjharris

26th November 2013, 10:27

Please can you fix the avs problem.

videofan3d

26th November 2013, 10:42

Please can you fix the avs problem.

Please specify what is the problem?
(I didn't face any further issues with Avisynth)

I need to reproduce it first...

trevorjharris

26th November 2013, 16:38

Using very simple avs file

AVISource("e:\video\FRIM\old warden-lp.avi")
converttoyv12()

E:\video\frim>frimencode h264 -avi -i l.avs -viewoutput -o l.h264 -vbr 28000 40000 -u 7 -w 1920 -h 1080
FRIM Encoder version 1.16 (build: Nov 21 2013)
- based on Intel(R) Media SDK

ERROR: Cannot get YUV420 frame from input avi-file l.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

Using latest avisynth 2.6. I have also tried sbs video.

videofan3d

26th November 2013, 18:23

Using very simple avs file

AVISource("e:\video\FRIM\old warden-lp.avi")
converttoyv12()

Using latest avisynth 2.6. I have also tried sbs video.

It is some problem with Video for Windows API on your machine, VFW doesn't provide frames in proper format (or at all).

Two questions:
1. Can you open and play the same avs file using standard Windows Media Player? And/or with MPC-HC ?

2. Do you have installed necessary codecs, e.g. "K-Lite Codec Pack" ?

trevorjharris

26th November 2013, 20:20

Sharc

26th November 2013, 20:38

videofan3d

26th November 2013, 20:47

My "windows media player" does not support avs. However the avi file does play in windows media server. The avs file does work with virtualdub. The file is encoded with cineform and all the codecs are installed. The issue of not recognising YUV420 was mentioned in previous posts.

This is the problem - you have to make sure that avs is available for VFW. Usually, when an old Windows Media Player is able to play the avs, then it works.
Try also suggestion from Sharc.

FRIM is reading frames via VFW AVI-API, and requests final YUV420 stream. The original source is hidden behind this API and VFW/Windows/installed codecs are responsible for proper transformation.

videofan3d

26th November 2013, 21:27

Hi,

FRIM 1.18 is available for download.
(Key info in previous post - please read Release notes!)

Sharc

26th November 2013, 21:47

Thanks!

trevorjharris

27th November 2013, 01:04

Thankyou Sharc and Videofan3d

Check your ffdshow Settings:
VFW-Configuration/Decoder/Codecs => RAW Video =>all supported

I reinstalled ffdshow and set as above. Please can you tell me why this is important. I didn't think fddshow was used.

I have found that the avs file will not play if the converttoyv12 is included. If I remove it it does play but also says it does not recognize avs file.

So there does seem be be something wrong with converttoyv12.

Sharc

27th November 2013, 08:13

Thankyou Sharc and Videofan3d

I reinstalled ffdshow and set as above. Please can you tell me why this is important. I didn't think fddshow was used.

The answer is quite simple:
- When I don't enable it for VFW I get exactly your error messages.
- When I set it to "all supported" it works just fine.

Make sure that you press the 'Accept' button before OK in the ffdshow GUI. Pressing OK only is not effective.

You may also want to try with DirectShowSource("....") in your script instead of AVISource.

trevorjharris

27th November 2013, 17:20

I have definitly set "all supported" for RAW ffdshow. I tried direct show but that did work in virtualdub but not in wmp. I have uninstalled avisynth and reinstalled ( version 18 September 2013 2.6.0.4). I have also tried an avi file compressed with Lagarith YV12 and that does not work either. I am using windows 7 64bit.

HWK

27th November 2013, 18:16

I have also tried an avi file compressed with Lagarith YV12 and that does not work either. I am using windows 7 64bit.

I am using Lagarith as well with avi file and it works for me through Avisynth. You do know by default file compressed with lagarith won't work in avisynth. Also I am using windows 7 64 Ultimate as well.

More info from you would help.

Sharc

27th November 2013, 18:41

@trevorjharris
Do you have codec packs installed? Filter merit changed?
Maybe you run Codec Tweak Tool and check for broken filters.

When your *.avs plays in any other player (like vdub, mpc, mpc-hc) except wmp then you should not get error messages with FRIMencode, even though your script may not play in wmp. Don't worry about wmp.