RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[blacksapprow]

@LigH this one is from fraunhoffer and not related with network. Follow the link above, (I have mistyped as x266, but of course this is H.266....)

Meanwhile not only H.266 codec, latest Magix Vegas Pro 18 bring Colorization to films. I don't know is that possible for Ripbot to include. It needs fixing with bar adjustments, but at mobile phones, this is done automatically & immediately with chromatix application. Maybe that way, can be a future add on for ripbot, I hope!

[LigH]

Well, hold your horses then ... Fraunhofer created the VVC codec, yes. But it is only a reference encoder so far. Made to create correct output. Not made to be usably performant. Before using this codec for serious work, you will have to wait for optimized implementations. It doesn't make sense to wait weeks for a conversion of a movie.

[colinhunt]

Hey Atak_Snajpera, I finally took the time to give RipBot264 a shot, and I'm loving it. I actually got goosebumps seeing 1080p video being encoded in hevc at 160 fps Thanks for creating this awesome software.

One question (or feature request): does/can RipBot support image sequences, as in thousands of PNG/TIF files? Googling didn't give me an answer.

edit: did a bit more googling and stumbled on ImageSource() in an .avs script. Let's see what happens...

[yuryna]

@Atak_Snajpera
Any news about 3 pass support?

Now a question,
how do you choose the breaking point of chunks to distribute among all the client?

It's randomly chosen (i don't think so),
it just mathematically chosen (Total frames / some formula)
fixed number (the chunk is always N frames)?

I think it would be nice to make the chunks lenght basing on "scene change detection".

In this way the distributed chunks would be much more compression/optimized by the x264 which will not find itself in a "scene change" situation with only 5 frames to encode (because the remaining frames of the same scene have been distributed to other client).

The final compression would be more safe and optimized thanks to distribution of key frames (and all that follow) inside the same scene.

What do you think about it?

[Atak_Snajpera]

I think it would be nice to make the chunks lenght basing on "scene change detection".

That would only create HUGE bottleneck because you would have to analyze whole movie before starting encoding. My workaround is to start chunk at key-frame detected in source file (hence chunks have irregular number of frames). Not perfect but still better than starting chunk at some "random" frame.

[yuryna]

start chunk at key-frame detected in source file

Wise solution.

For the bottlenek you could make it just a selectable option,

in order to satisfy the deep-quality-researcher too (who don't mind encoding time (like myself? eheh )).

I think it would be a good compromise (the "choice" is always a good added-value).

[blacksapprow]

@LigH

Don't worry, H.266 can't come so quick, and we are upgrading our systems generally within 5 years. But, if a film size shortens %50, I may love it. Because hard drives are really expensive. 2 piece of 10GB hard drive, equals to a good graphics card. This one will provide only 1 piece of 10GB in a way. Encoding took 6,5 times but playing only needs 1,5 times processing power. For me, this is not bad....

[LigH]

Did you mean 10 TB?

[slalom]

@Atak

there is a problem when downloading a poster

[userx]

Hello!

Not sure what happens here:
In DE mode chunks always restart after 100%.
I recently got an update to W10 2004 but i temporary disabled DE mode. Latest nvidia driver is installed.

439|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.2:1000 -> [98.3%] 1462/1488 frames, 126.43 fps, 2888.16 kbps, eta 0:00:00;CHUNK=1;CPU=92;RAM=58;DECODER=23;ENCODER=43;OTHER=26;ENCODING_PRIORITY=low;
440|CLIENT -> SERVER| OK
441|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
442|CLIENT <- SERVER| OK
443|CLIENT <- SERVER| ENCODING_FINISHED
444|CLIENT -> SERVER| OK
445|CLIENT -> SERVER| GET_ENCODING_SUMMARY
446|CLIENT <- SERVER| OK
447|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.1.2:1000 -> ERROR;CHUNK=1;CPU=92;RAM=55;DECODER=0;ENCODER=0;OTHER=92;ENCODING_PRIORITY=low;
448|CLIENT -> SERVER| OK
449|CLIENT -> SERVER| STANDBY
450|CLIENT <- SERVER| OK
451|CLIENT <- SERVER| SERVER_IDLE
452|CLIENT -> SERVER| OK
453|CLIENT -> SERVER| ENCODE_CHUNK_1=\\PC\RipBot264temp\job1\Chunks\1.cmd

I noticed I have to switch the OPENCL device to NONE to use the DE mode.

0.0 Device name      : GeForce GTX 970 
    Hardware version : OpenCL 1.2 CUDA 
    Software version : 452.06 
    OpenCL C version : OpenCL C 1.2  
    Compute units    : 13 

1.0 Device name      : Intel(R) HD Graphics 4600 
    Hardware version : OpenCL 1.2  
    Software version : 20.19.15.4835 
    OpenCL C version : OpenCL C 1.2  
    Compute units    : 20

Some time ago, i had the same problem with my AMD Radeon 7700 but it seems Capeverde is not well supported or something else. Now i'm not able to use my Nvidia card.
Does anybody have an idea what happens?

[HehoChef]

Quicky Question: In the Distributed Encoding Client, what does the little number below the "server picture" mean?
For some servers it's rock solid, for some others its bouncing around rapidly.

[Atak_Snajpera]

Communication delay in ms. (Number of ms elapsed from sending command to reciving confirmation [OK] from server)

[Slogra]

KNLMeansCL does not seem to work on my AMD VEGA 64. Am i doing something wrong? I get a very dark image when i set mono noise to 2 or higher.
When i set it to 0 or adapter there is a normal image, but i wonder if denoise works at all with these settings.

What other GPU denoise filter do you recommend for an AMD GPU? i'm willing to add it manually to the avisynth script.

I used to use fft3dgpu in the past with avisynth 32bit (?), but i don't think there is a 64bit version.

I've done some conversions with MDegrain2. I really like the result but it is too CPU intensive.


EDIT: however KNLMeansCL does work if i change the resolution of the video from 1920x1080 to 1916x1080 or any other resulotion! So something strange is going on. I would really like to keep the original 1920x1080 resolution.
And to be honest i don't like the result of the KNLMeansCL filter. Especially with animated stuff there seems to be some "color bleeding". So i'm still looking for another GPU denoise filter.

[LigH]

But that's certainly not the fault of RipBot264, being just a user interface to control distributed encoding via AviSynth scripts. The reason will rather be between the ATI graphic driver and the KNLMeansCL AviSynth plugin.

[Slogra]

Agreed. Maybe i should've posted my question in a different topic.

But maybe other ripbot264 users have seen this issue before and have a solution.

[LigH]

I'd recommend the KNLMeansCL development thread instead. This plugin will not be used in RipBot264 only, but possibly in other tools as well, or even manually.

Indeed, the keyword "vega" appears a few times in there.

[Pauly Dunne]

Originally Posted by Slogra

KNLMeansCL does not seem to work on my AMD VEGA 64. Am i doing something wrong? I get a very dark image when i set mono noise to 2 or higher.
When i set it to 0 or adapter there is a normal image, but i wonder if denoise works at all with these settings.

What other GPU denoise filter do you recommend for an AMD GPU? i'm willing to add it manually to the avisynth script.

I used to use fft3dgpu in the past with avisynth 32bit (?), but i don't think there is a 64bit version.

I've done some conversions with MDegrain2. I really like the result but it is too CPU intensive.


EDIT: however KNLMeansCL does work if i change the resolution of the video from 1920x1080 to 1916x1080 or any other resulotion! So something strange is going on. I would really like to keep the original 1920x1080 resolution.
And to be honest i don't like the result of the KNLMeansCL filter. Especially with animated stuff there seems to be some "color bleeding". So i'm still looking for another GPU denoise filter.

I don't quite understand why you're complaining about your graphics card not working with KNLMeansCL, when you don't like the result anyway..

If you like the result when using MDGrain2, maybe you need to upgrade your CPU...are you using distributed encoding ??

Maybe a custom filter, that uses both !!

Sometimes you've just gotta do, what ya gotta do...

[Slogra]

I was able to get knlmeanscl working using a workaround by adding a border before denoising and removing the border after denoising (see knlmeanscl thread).

I'm planning to encode many videos, so I tested the 2 denoise filters and settings with one video first.

Resolution: 1920x1080
Encoder: x.265
Audio: 320kbps 5.1 aac

File size:
Original 2900MB
unfiltered 720MB
mdgrain2 457MB
knlmeanscl mono noise 1 537MB
knlmeanscl mono noise 2 524MB

Encoding speed:
Knlmeanscl 24fps
Mdegrain2 12fps

So Knlmeanscl is much faster.
But mdgrain2 looks a bit nicer imho.
Unfortunately I don't have numbers of the power consumption. I read about power consumption of my cpu and gpu. The 8700K cpu should draw about 90watts with full load.
I don't know the load of the Vega during denoising. I guess it is close to full load, which should be around 300watts.
So if these numbers are correct then mdegrain2 is more power efficient in my setup.

I probably will go for Mdegrain2, although it will take twice as long.
The image is better, the file size smaller and total power consumption is probably lower.


Sorry, if all this belongs in another thread .

[Pauly Dunne]

Well, I can't believe it, a long awaited Auto Update has appeared...

Welcome to RipBot264 v1.26.0, everybody

Some interesting additions, and updates

Thanks, Atak


edit:- having said that, I think there is a problem with MPC.zip...

[ERROR] D:\RipBot264v1.25.1\updates\mpc.zip is corrupted. CRC32 mismatch. Expected value was 79A3D553 but got 1638972A

There weren't any significant files in the MPC.zip...

[jlpsvk]

Originally Posted by Pauly Dunne

Well, I can't believe it, a long awaited Auto Update has appeared...

changelog????