Free H.264 MVC 3D Encoder

[HWK]

I'd guess some time in the next few days. I hate to be vague, but I don't know what I might run into. The new TSMUXER version helped by fixing the "PES len" error. But I also had to adjust in several places because the "mplsfile=" parameter is deprecated now. That means I have to start running through all the battery of test sources again.

I understand, no pressure by any means. Also I can run some test to speed up if you want.

3D and 2D both available at your disposal and different encoders are available as well.

[damorsoft]

Playing with a gui for frim et al.

I have succeeded in running frim in myprocess but can not read the output.
have tried standard error and output I would like to show the frame# progress in my GUI.
eg. does not work

While (myProcess.HasExited = False)
Application.DoEvents()
Dim aLine As String = myProcess.StandardOutput.ReadLine
If (Not String.IsNullOrEmpty(aline)) Then
Label16.Text = aline ' & " % complete "
End If
End While

Thanks.

[Nico8583]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !

[jdobbs]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !That would be REALLY nice. It would eliminate the need for HAALI and FFDSHOW from BD Rebuilder. The whole need for DirectshowSource() is a constant issue (especially when other software installs overwrites thing or changes system defaults).

[videofan3d]

That would be REALLY nice. It would eliminate the need for HAALI and FFDSHOW from BD Rebuilder. The whole need for DirectshowSource() is a constant issue (especially when other software installs overwrites thing or changes system defaults).

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.

But Avisynth simulates AVI, which is in principle quite opposite.

[Sharc]

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.
.....
This might be one of the reasons why piping of FRIMDecoder into x.264 seems not to work (at least I have not been successful)
Piping works with ffmpeg though.

[jdobbs]

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.

But Avisynth simulates AVI, which is in principle quite opposite.There are other AVISYNTH decoders that don't support seeking. But you obviously know this software better than I do, so I'll assume it's a lost cause.

[frencher]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !

Very nice idea for full free MVC players ;) :goodpost:

[nunub]

@frencher
How it is that we are unable to download ur free mvc player although u r changing versions but i for one would not be able to download it.

[HWK]

@frencher
How it is that we are unable to download ur free mvc player although u r changing versions but i for one would not be able to download it.

I can download fine, can you explain error message or something similar to describe what you are experiencing.

[frencher]

Thanks for download test HWK ;)
nunub it's good ?

[nunub]

@frencher
I m experiencing difficulty from ur download site as ur page seems to me blank and even if i m trying to download it from frd it is showing as to no string attached.

[HWK]

@frencher
I m experiencing difficulty from ur download site as ur page seems to me blank and even if i m trying to download it from frd it is showing as to no string attached.

Try this link instead and see if it works, I have included MVC Player Free v0.0.2.6.rar & uNicAudio.dll + Source Code.rar

https://drive.google.com/file/d/0B2c8pQSAQa3qc0RUZG4tYkFZMWc/edit?usp=sharing

There are two rar file under one main rar file.

[nunub]

Try this link instead and see if it works, I have included MVC Player Free v0.0.2.6.rar & uNicAudio.dll + Source Code.rar

https://drive.google.com/file/d/0B2c8pQSAQa3qc0RUZG4tYkFZMWc/edit?usp=sharing

There are two rar file under one main rar file.

thanks for that link and on my 64bit win8 with 3dm2ts file it is unable to playback.

[frencher]

thanks for that link and on my 64bit win8 with 3dm2ts file it is unable to playback.


Continue this thread > Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph (http://forum.doom9.org/showthread.php?p=1602605#post1602605)

Have you see my tutorial in my signature

[Thalyn]

Videofan3D: Is there any chance you could re-work the FRIMDecoder into an AVISynth plugin?

There's been a few issues cropping up with more recent rendered titles (DreamWorks and Disney/Pixar) that seem to be solved by FRIM, but there's no easy way to work it into AVISynth at present without a very large intermediate file.

[Sharc]

@Thalyn:
Sure, but see posts #403 .... 407.

[Thalyn]

Wow... I'm 2 and 0 for reading posts and forgetting their existence entirely within weeks. I'd quit while I'm ahead but, well, I can't even say that I'm ahead of anything.

Even without the seeking ability it would still be useful; so long as it's actually possible. I'm pretty sure H264StereoSource can't actually seek and it was remarkably useful (up until better tools became available).

[colinhunt]

OK guys, I'm running a slight fever and feeling kinda lazy... so can someone tell me if it's possible to use FRIM to create a proper (although lower on resolution) 3D Blu-ray from a Side-by-Side 3D video, and how?

[Sharc]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?

If so, the workflow would likely be:
1) Demux the .m2ts (e.g. with tsMuxeR or eac3to)
2) Create a script 'input.avs' to resize the Video to 3840x1080
3) Encode with FRIMEncode
4) Remux encoded videostreams and Audio with tsMuxeR to a Blu-ray ISO.

Example for 3) cmd:

FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc base.avc dependent.mvc -w 1920 -h 1080 -l 6 -cpbsize 3750 -vbr 8000 15000 -u 4 -profile high -level 4.1 -gop 24 4 0 O -PicTimingSEI off -EndOfSequence off

(it's too late to try it here in detail now ....)

[HWK]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?

Shouldn't it be 3840x1080 instead.

[Sharc]

Shouldn't it be 3840x1080 instead.
Yes, as a source for FRIMEncode.
SBS sources are however often 2x half horizontal resolution. These must be resized to (2x1920x1080) for FRIM in order to work. FRIMEncode output will then become 1920x1080 for Base and Dependent view.
(I edited my last post).

[colinhunt]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?
It's a HDTV 3D broadcast, a Half-SBS, i.e. both views forced into a regular 1920x1080 frame by squeezing the views horizontally. In short, yes :)

So I need to stretch it into a Full-SBS 3840x1080 first, then feed it into FRIM encoder... right? I'm not much of an Avisynth scripter, unfortunately.

[Sharc]

It's a HDTV 3D broadcast, a Half-SBS, i.e. both views forced into a regular 1920x1080 frame by squeezing the views horizontally. In short, yes :)

So I need to stretch it into a Full-SBS 3840x1080 first, then feed it into FRIM encoder... right? I'm not much of an Avisynth scripter, unfortunately.

Save this code as text file named "input.avs" and use the FRIMEncode command as suggested in my previous post:

DirectShowSource("C:\.......\your_source.m2ts")
spline16resize(3840,1080)
converttoyv12()

[colinhunt]

Save this code as text file named "input.avs" and use the FRIMEncode command as suggested in my previous post:

DirectShowSource("C:\.......\your_source.m2ts")
spline16resize(3840,1080)
converttoyv12()
Brilliant. Thank you ever so much!

Whoops. On closer inspection (I blame the fever) I see the original is 1440x1080 and 29.97fps. Dammit.

Indexed the file with DGIndex and came up with an .avs like this:

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("video.d2v")
Load_Stdcall_Plugin("yadif.dll")
Yadif(order=0)
ConvertFPS(23.976)
Spline16resize(3840,1080)
ConvertToYV12()

Running first test now.

u: Encode finished OK, but tsmuxer 2.6.7 could not create a readable ISO. Went back to 2.3.2 and all's fine... except skintones are messed up. Everyone has blue skin. Whaaa..?

[frencher]

There are other AVISYNTH decoders that don't support seeking. But you obviously know this software better than I do, so I'll assume it's a lost cause.

However someone has already done
http://forum.doom9.org/showthread.php?p=1658935&posted=1#post1658935
http://i41.tinypic.com/2rc2zbt.png

[jdobbs]

However someone has already done
http://forum.doom9.org/showthread.php?p=1658935&posted=1#post1658935
http://i41.tinypic.com/2rc2zbt.pngHmmm, that's interesting. Where is it available for download?

[frencher]

Hmmm, that's interesting. Where is it available for download?

From BDtoAVCHD install folder

[Nico8583]

You can find informations in 3D topic : http://forum.doom9.org/showthread.php?t=155246&page=88
MVCsource.dll is free to use but not to redistribute, you can see this point with the author (pistacho) ;)

[Cedvano]

I would like to encode directly a SSIF file, but with DirectShowMVCSource or SsifSource2, I've always an error.
Access violation for DirectShowMVC and another with Ssifsource
It's work fine with X264.
I use BD3D2MK3D scripts.
Someone have a solution ?
Thanks in advance.

[nunub]

I would like to encode directly a SSIF file, but with DirectShowMVCSource or SsifSource2, I've always an error.
Access violation for DirectShowMVC and another with Ssifsource
It's work fine with X264.
I use BD3D2MK3D scripts.
Someone have a solution ?
Thanks in advance.
what happen to that prestigious project of urs for frim encoder gui. The site has disappeared.

[Cedvano]

what happen to that prestigious project of urs for frim encoder gui. The site has disappeared.

I work on a complete software, but I would like to simplify this and encode without demuxing. Working directly with SSIF save time.
It's the reason of my question.

I add SBS->MVC and other options.

[nunub]

I work on a complete software, but I would like to simplify this and encode without demuxing. Working directly with SSIF save time.
It's the reason of my question.

I add SBS->MVC and other options.

Very great to hear from u at least u responded and i hope u complete that and also dont forget HOU also. I found the quality of intel mvc greater and also the speed.

[Cedvano]

Very great to hear from u at least u responded and i hope u complete that and also dont forget HOU also. I found the quality of intel mvc greater and also the speed.

Yes, it's a great encoder !

[colinhunt]

I add SBS->MVC and other options.
Ooh, that's a very welcome feature. Looking forward to the new software!

[jdobbs]

@videofan3d

Can you tell me what kind of security token you are creating when you set up the named pipe in FRIMDecode? I keep getting an "Access Denied" error when I try to open the named pipe from another app.

[Added] Is there any way FRIMDecode can be modified to allow output to stdout so it can be used with X264? If so, then I don't need an answer to the above question (it was just a CLI app that would input from the named pipe and output to stdout).

[videofan3d]

@videofan3d

Can you tell me what kind of security token you are creating when you set up the named pipe in FRIMDecode? I keep getting an "Access Denied" error when I try to open the named pipe from another app.

[Added] Is there any way FRIMDecode can be modified to allow output to stdout so it can be used with X264? If so, then I don't need an answer to the above question (it was just a CLI app that would input from the named pipe and output to stdout).

Technically: named pipe server is created using standard CreateNamedPipe() with security attributes NULL, i.e. named pipe gets a default security descriptor - see CreateNamedPipe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx). So security is purely derived from operating system.

stdout is not suitable for binary transfer in Windows environment since it is textual and translates \n to \r\n. :(

x264 seems not suitable for pipe processing, I observed it does not read input in purely sequential way but is seeks also backward, which in principle disallow using pipes...
(also two-pass encoding is out of the game when using pipes).
However, ffmpeg can read named pipe from FRIMDecode - this was already mentioned in this thread

[videofan3d]

FRIM 1.19 with minor updates is available:

FRIM Encoder with new optional parameters:
-rf numRefFrame .... parameter number of ref. frames
-ResetRefList on|off .... parameter for reset ref. frames
-goplog filename .... added report for actually created GOP structure

+ some minor fixes and internal code changes.

Also utilities bincopy.exe and pipecopy.exe added to distribution pack - see documentation.

[jdobbs]

Technically: named pipe server is created using standard CreateNamedPipe() with security attributes NULL, i.e. named pipe gets a default security descriptor - see CreateNamedPipe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx). So security is purely derived from operating system.

stdout is not suitable for binary transfer in Windows environment since it is textual and translates \n to \r\n. :(

x264 seems not suitable for pipe processing, I observed it does not read input in purely sequential way but is seeks also backward, which in principle disallow using pipes...
(also two-pass encoding is out of the game when using pipes).
However, ffmpeg can read named pipe from FRIMDecode - this was already mentioned in this threadI've tested X264 with sequential input through stdout/stdin using avs2yuv and it works fine.

Thanks for the new version. :)

[videofan3d]

I've tested X264 with sequential input through stdout/stdin using avs2yuv and it works fine.


I don't know details how x264 does work but neither myself nor other people here succeeded to use FRIMDecode as source for x264 - unfortunately.

avs2yuv probably translates AVS (i.e. AVI) to flat yuv, right?
This might be a key, because AVI container is "seekable"!
i.e. you can seek to the beginning.
I assume that x264 opens data-source, read some header or portion of data for preliminary analysis, then close it. and in the second round it re-open the source again and read it from beginning to the end.

But pipe is from its principle unidirectional channel, once it is closed, it is its end-of-life.
FRIMDecode uses pure pipe on its output, and there is no way to get a signal for re-opening the pipe.

Regarding stdout/stdin - I would be very careful when using it for binary data transfer.
Simple test:

char sss[] = "abcd\nefgh\n1234";
fwrite(sss, strlen (sss), 1, stdout);

will produce output (when redirected to file) with 16 bytes!
Each \n is converted to \r\n.
If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)

[jdobbs]

I don't know details how x264 does work but neither myself nor other people here succeeded to use FRIMDecode as source for x264 - unfortunately.

avs2yuv probably translates AVS (i.e. AVI) to flat yuv, right?
This might be a key, because AVI container is "seekable"!
i.e. you can seek to the beginning.
I assume that x264 opens data-source, read some header or portion of data for preliminary analysis, then close it. and in the second round it re-open the source again and read it from beginning to the end.

But pipe is from its principle unidirectional channel, once it is closed, it is its end-of-life.
FRIMDecode uses pure pipe on its output, and there is no way to get a signal for re-opening the pipe.

Regarding stdout/stdin - I would be very careful when using it for binary data transfer.
Simple test:

char sss[] = "abcd\nefgh\n1234";
fwrite(sss, strlen (sss), 1, stdout);

will produce output (when redirected to file) with 16 bytes!
Each \n is converted to \r\n.
If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)It's up to you, and you know FRIMDecode a lot better than I do... but people use stdin/stdout with binary data all the time. I've encoded entire movies feeding video through stdout/stdin using X264. It can't be seeking backward, because that method wouldn't allow it. As another example, in BD-RB I use stdin/stdout pipes between LAME and AFTEN for MP3 to AC3 encoding. I do the same using WAVI and AFTEN for reencoding .WAV to AC3. This is all done in a Windows environment. A lot of the open source CLI packages allow for input from stdin and output to stdout (usually using "-" as the file indicator for the command line).

[MasterNobody]

If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)
There is simple way to make this standard streams binary in Windows:
#ifdef _WIN32
_setmode( _fileno( stdin ), _O_BINARY );
_setmode( _fileno( stdout ), _O_BINARY );
_setmode( _fileno( stderr ), _O_BINARY );
#endif
And that is pretty standard way so I don't see any problems with using it.

P.S. As for problem with x264 and named pipes. It was problem with double fopen/fclose because stat() function didn't worked with named pipes and so we couldn't find out if specified path is pipe or regular file (and default is regular file). This patch (http://privatepaste.com/e79989bceb) should fix it.

[jdobbs]

@videofan3d

Including an option for using stdout would certainly make encoding of SBS and O/U versions of 3D encodes via X264 easier. Your choice, but I'd certainly appreciate it. Currently I'm relying on end users having a commercial package installed so DirectshowMVCSource() can be used.

Also I find FRIMDecode to be a lot more dependable for MVC decodes. In my experience it works perfectly.

[videofan3d]

There is simple way to make this standard streams binary in Windows:
#ifdef _WIN32
_setmode( _fileno( stdin ), _O_BINARY );
_setmode( _fileno( stdout ), _O_BINARY );
_setmode( _fileno( stderr ), _O_BINARY );
#endif
And that is pretty standard way so I don't see any problems with using it.



Good point - thanks ;) :)

[videofan3d]

@videofan3d

Including an option for using stdout would certainly make encoding of SBS and O/U versions of 3D encodes via X264 easier. Your choice, but I'd certainly appreciate it. Currently I'm relying on end users having a commercial package installed so DirectshowMVCSource() can be used.

Also I find FRIMDecode to be a lot more dependable for MVC decodes. In my experience it works perfectly.

I'll consider it (with input from MasterNobody) :) ;) ...

[jdobbs]

I'll consider it (with input from MasterNobody) :) ;) ...Cool. :)

[Cedvano]

How the wall option work ? Have you got an exemple ?

[Sparktank]

Hi guys,

Here the new release (with new name)

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

The site has disappeared.

I work on a complete software

Whoever's maintaining the VideoHelp.com page should edit the other section where it says you can download the GUI, as the link is non-existent.

http://www.videohelp.com/tools/FRIM
(scroll down for "other downloads" to get the GUI...

More information and other downloads:
Download Transcoder GUI for FRIMTranscode and FRIMEncode here.

^leads to http://forum.doom9.org/showthread.php?t=169801 which doesn't exist.

Cedvano, you should update your previous posts for clarity. (whichever have a link to a non-existent thread/page)

FRIMTranscode GUI 1.04 (https://drive.google.com/file/d/0BxjaFf3cdexVV0NXSE14Sko5WHM/edit?usp=sharing)

I have no idea if that's your latest release before your makeover of the software.
Should people download that or should everyone avoid downloading that and wait for the complete version?

That post should be edited for clarity, as well.

[Cedvano]

http://img4.hostingpics.net/thumbs/mini_2373153dvonvert.png (http://www.hostingpics.net/viewer.php?id=2373153dvonvert.png)

Here the next release of FRIMTrancode GUI
I change the name by .::3D Encode::..

I make some changes and put the next FRIM 1.19

I don't forget but I have a [BEEP] work. ;-)

Thanks for your patience.

Edit: It's in French, but it's in English too.

[colinhunt]

Here the next release of FRIMTrancode GUI
Looking forward to it.