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

[damia]

hai atak...for version 1.18.3 2pass before this version i only get 10-11chucks.. now for new version around 93chucks??? how to i change back to normal?? i mean this.. http://imgur.com/YuUWAoL

[Atak_Snajpera]

It seems like maybe a better way to do it than the old 2-pass method. But the quality still suffers greatly.

I encoded a blu-ray clip with regular 2-pass and with ripbot new distributed 2-pass method.
Everything other than the 2-pass method is identical: preset slow, --bitrate 3000, all x264 settings the same:

http://screenshotcomparison.com/comparison/132840

Try again but this time with 600s chunk size.

[slalom]

yes you can but it does not make sense now. Smaller chunk is better for work distribution (Less server idle time). Also you lose less time if you decide to restart encoding after abort.
All those are true, OK!

[mini-moose]

Try again but this time with 600s chunk size.
Was going to do it now, but some reason RB won't start properly now, not sure what's up.

It starts and sits in task bar but I can't bring it forward.

[Atak_Snajpera]

Maybe you messed up something in ripbot264.ini ?

[mini-moose]

Maybe you broke something in ripbot264.ini ?

Don't think I have. Might have something to do with NV driver update I did earlier that hanged at the end and didn't officially completed...not exactly sure, will reboot perhaps.

[mini-moose]

It's working now after reboot. Might be related to job2_EncodingClient.meta being open in notepad++?. I think it was cause N++ restarted with it loaded there.

Anyway, I'm not sure how well the 600s will be effective on this test cause the clip is only 4mins long :) I'll look into it tomorrow.

[Atak_Snajpera]

Well I thought you were encoding full movie...

[mini-moose]

Well I thought you were encoding full movie...

I did say a clip :) It was just to try out and see how it look and I didn't feel like doing a whole movie for that.

[Atak_Snajpera]

So maybe try with 120s chunk then.

[mini-moose]

So maybe try with 120s chunk then.

Meanwhile I just did the 4mins in one chunk to see how how it turns out using crf 23 1st pass (first pass without defined bitrate).

There is a noticeable difference even without breaking the video into chunks:

http://screenshotcomparison.com/comparison/132941

Maybe simply upscaling the bitrate for 2nd pass isn't that good?
I noticed the first pass bitrate results are considerably smaller 2nd pass target, and I used a relatively low bitrate for 2nd pass (first passes were around 1000, 2nd pass was 3000).

I'm not a big expert, but the stats file seem to include all sorts of stuff that maybe isn't just bitrate related:

cpbdur:2 q:26.11 aq:21.71 tex:273375 mv:20072 misc:1193 imb:534 pmb:2811 smb:175 d:s ref:0

[Atak_Snajpera]

Meanwhile I just did the 4mins in one chunk to see how how it turns out using crf 23 1st pass (first pass without defined bitrate).

There is a noticeable difference even without breaking the video into chunks:

http://screenshotcomparison.com/comparison/132941

Maybe simply upscaling the bitrate for 2nd pass isn't that good?
I noticed the first pass bitrate results are considerably smaller 2nd pass target, and I used a relatively low bitrate for 2nd pass (first passes were around 1000, 2nd pass was 3000).

I'm not a big expert, but the stats file seem to include all sorts of stuff that maybe isn't just bitrate related:

cpbdur:2 q:26.11 aq:21.71 tex:273375 mv:20072 misc:1193 imb:534 pmb:2811 smb:175 d:s ref:0

I really do not see any problem here! It is 100% normal that frames are not 100% the same. What is important is overall complexity of frame. Looking at your screenshots I really can't say whether frame A has more details than B or vice versa. I only see different pattern of the film grain. You must be a super human to notice this subtle difference in motion ;)

[mini-moose]

Looking at your screenshots I really can't say whether frame A has more details than B or vice versa. I only see different pattern of the film grain. You must be a super human to notice this subtle difference in motion ;)

I can see quite a difference in detail (especially in #3), but yeah, if you watch in motion and from a viewing distance, it's unlikely to be as apparent.

It was mostly to demonstrate that cq first pass doesn't give the same reference as real first pass does. Remember this is not split first pass. It was a lot worse when I used 60 seconds chunks.

[Atak_Snajpera]

I can see quite a difference in detail (especially in #3), but yeah, if you watch in motion and from a viewing distance, it's unlikely to be as apparent.

It was mostly to demonstrate that cq first pass doesn't give the same reference as real first pass does. Remember this is not split first pass. It was a lot worse when I used 60 seconds chunks.

I've noticed the same drops in quality in my 10 min "Drive" sample.
It turns out that default CRF 23 is not accurate enough to estimate chunk's complexity. CRF value increased to 16 seems to be much more accurate.

Screenshot from chunk 6
Normal mode -> http://i.cubeupload.com/hM3KmT.png
DE crf 23 -> http://i.cubeupload.com/uJqdy8.png
DE crf 16 -> http://i.cubeupload.com/1yJNyf.png

And here is explanation why some chunks have poor quality.
Bitrate Distribution for chunks with CRF 23
http://i.cubeupload.com/2G922C.png

Bitrate Distribution for chunks with CRF 16
http://i.cubeupload.com/w1zl7G.png

No wonder that chunk 6 has such poor quality if it only gets 0.66 of target bitrate instead of ~1. Also first and last chunk wastes a lot of bitrate budget because when I was comparing those two sections I had not seen any obvious differences in quality.

Try this patch
http://www.mediafire.com/download/grd9kfgm3e5k5m1/DE_patch_for_1.18.3.7z

[mini-moose]

I've noticed the same drops in quality in my 10 min "Drive" sample.
It turns out that default CRF 23 is not accurate enough to estimate chunk's complexity. CRF value increased to 16 seems to be much more accurate.

Screeshots look a lot better now.

Did you try any crf values in between too or went straight to 16?

I'll give it a try too. Thanks.

[Atak_Snajpera]

16 seems to be a good value
http://i.cubeupload.com/AgWJYG.png

[Atak_Snajpera]

After further investigation I've noticed that even with higher crf value there are still cases where quality of the frame drops. I guess that .stat file generated using CQ mode is not always compatible in second pass so I decided to restore previous old method with 10 min chunks with constant bitrate for each chunk.

Please re-download again 1.18.3 if you use DE mode with 2-pass. Sorry for this mess. I should have tested this method a little bit more...

[slalom]

So the only change is the 10 min chunks?
What if we use 5 minutes?

Is it safe?

[Atak_Snajpera]

yes if you can accept less optimal bitrate distribution.

[soneca]

I can not create AVCHD discs because Ripbot264 is stopping at the end of the first pass in this latest version. This is happening in my two pc.

http://s20.postimg.org/eyxbiftsd/RIPBOT.png

Edit: I test using another source but this source has been converted without problems in the CQ mode.

[soneca]

Another source is the same, stopping at the end of the first pass.

[essential]

I searched first but this is such a long thread it may have been answered but I can't find it. Anyway, how do you use a DTS track in the new versions of Ripbot? Just started doing some encoding again and I remember a couple years ago if I did COPY STREAM I'd get the actual DTS track in my mkv. Now, no matter what I do, loading the MT2S, or muxing the DTS track out and loading it separately, it's converted to FLAC ("converting DTS-MA to FLAC"), and that seems like the highest audio I can get.

Am I missing something, how do you get an untouched DTS track in the encode?

[hoju3508]

@essential, if your source audio is DTS-HD MA, then chose "core" instead of "flac".

[hoju3508]

Another source is the same, stopping at the end of the first pass.

No problems here with creating AVCHD with v1.18.2 - no DE, 2-pass.

Are you having issues with v.1.18.3?

[essential]

@essential, if your source audio is DTS-HD MA, then chose "core" instead of "flac".

I'll have to try again from the MT2S but when I load the individually muxed .264 and the .dts (which was how I always did it in the past) I hit the "..." next to audio, select the .dts and the file is automatically converted, I'm not given an option to change anything, or pick CORE. Can you only get DTS if using a MT2S now?

Edit:
DTS/Core selection worked when loading in the MT2S, but doesn't work when loading in the .DTS file directly, that is converted to FLAC automatically, not sure why, but thanks, I'll just work from the MT2S.

Also, has AC3 640 been removed? The highest AC3 stream selectable now (MT2S or .dts) seems to be 256?

[mini-moose]

After further investigation I've noticed that even with higher crf value there are still cases where quality of the frame drops. I guess that .stat file generated using CQ mode is not always compatible in second pass so I decided to restore previous old method with 10 min chunks with constant bitrate for each chunk.


Did you try the new method but with pre-defined bitrate on first pass instead of CQ?

[Atak_Snajpera]

ABR in first pass is not very accurate in estimating chunk's complexity. I tried that before using cq mode.

http://i.cubeupload.com/GMVLE8.png

@soneca
When first pass hangs run process explorer and do screenshot. I need to see what processes started by ripbot264.exe are still running.

[soneca]

No problems here with creating AVCHD with v1.18.2 - no DE, 2-pass.

Are you having issues with v.1.18.3?

No problems with 1.18.2, only with the 1.18.3 version using 2 pass.

[soneca]

@Atak

http://s20.postimg.org/5i7ibt9xp/processos.png
http://s20.postimg.org/y6kgf1c3x/processos1.png

[Atak_Snajpera]

Run manually job6_EncodeAudio1.cmd and show me what you get.

[soneca]

I run job6_EncodeAudio1 but nothing happens, I can only run the job6_EncodeAudio2.

http://s20.postimg.org/nz1x2mpvx/job6.png

[Atak_Snajpera]

ok. Now show me content of job6_AUDIO1.avs file and job6_AUDIO2.avs

[soneca]

#MT


#VideoSource

video=BlankClip(length=166549, width=1920, height=1080, fps=23,976, pixel_type="YV12", channels=0)

#Deinterlace



#Decimate



#Crop



#Resize
video=Spline36Resize(video,1280,720).Sharpen(0.0)


#Colors



#Denoise




#Subtitles



#AudioSource
Import("E:\Temp\RipBot264temp\job6\job6_a1.avs")


#Triming



#AVSameLength



#ColorSpace

______________________________________________________

#MT


#VideoSource

video=BlankClip(length=166549, width=1920, height=1080, fps=23,976, pixel_type="YV12", channels=0)

#Deinterlace



#Decimate



#Crop



#Resize
video=Spline36Resize(video,1280,720).Sharpen(0.0)


#Colors



#Denoise




#Subtitles



#AudioSource
Import("E:\Temp\RipBot264temp\job6\job6_a2.avs")


#Triming



#AVSameLength



#ColorSpace

[Atak_Snajpera]

And also job6_a1.avs and job6_a2.avs please.

[soneca]

#AudioSource
LoadPlugin("C:\Programas\RipBot264v1.18.3\tools\AviSynth plugins\NicAudio\NicAudio.dll")
audio=NicAC3Source("E:\Temp\RipBot264temp\job6\audio_1_English.ac3")
audio=ResampleAudio(audio,48000)
#DownMix
Import("C:\Programas\RipBot264v1.18.3\Tools\AviSynth plugins\Scripts\DownMixAudio.avs")


#Delay
audio=DelayAudio(audio,0)


#Tempo



#Normalize



#AudioDub
audio=ConvertAudioTo16bit(audio)
AudioDub(video,audio)

_____________________________________________________________________________________________________

#AudioSource
LoadPlugin("C:\Programas\RipBot264v1.18.3\tools\AviSynth plugins\NicAudio\NicAudio.dll")
audio=NicAC3Source("E:\Temp\RipBot264temp\job6\audio_2_Portuguese.ac3")

#DownMix



#Delay
audio=DelayAudio(audio,0)


#Tempo



#Normalize



#AudioDub
audio=ConvertAudioTo16bit(audio)
AudioDub(video,audio)

[sneaker_ger]

video=BlankClip(length=166549, width=1920, height=1080, fps=23,976, pixel_type="YV12", channels=0)
[...]
video=BlankClip(length=166549, width=1920, height=1080, fps=23,976, pixel_type="YV12", channels=0)
Does comma work for fps decimal on some systems? Usually you need a dot.

[Atak_Snajpera]

Good eye sneaker_ger I haven't noticed that wrong decimal symbol.

Soneca try this http://www.mediafire.com/download/0ndbxwwnys9/RipBot264.exe

[soneca]

Ok, now running in a few minutes I report.

I had the impression the first pass not have reached their full frames, but went to the second pass smoothly.

[soneca]

Working properly, thank you!

[hoju3508]

Also, has AC3 640 been removed? The highest AC3 stream selectable now (MT2S or .dts) seems to be 256?

Haven't tried v1.18.3, but v1.18.2 has 640k.

[Atak_Snajpera]

Most likely he has 2.0 audio. Higher bitrates are only available for 5.1.

[slalom]

Haven't tried v1.18.3, but v1.18.2 has 640k.
v1.18.3 also has 640k

[agressiv]

I was wondering why "Please Wait... Gathering Information..." Takes so long after the audio is extracted from an MKV.

Turns out if AviSynth MT mode is on, this can take 25 minutes. With it off, it takes 2 minutes.

-------

Source MKV file has a single DTS-HD audio track, which is 4GB. My Temp directory is on a RAID-0 set. Movie is 2 hours 30 minutes, hence the rather large file.

I opened up Sysinternals' Process Monitor. avs2avi.exe is chewing all I/O on the disk, and nothing else is using that drive. It's currently reading at the rates of 40-50 MBytes/sec.

avs2avi.exe scans the *entire* 4GB 1_audio_English.dts file from start to finish (it's very clear in procmon)

D:\RipBot\Tools\avs2avi\avs2avi.exe E:\Temp\RipBot264temp\job1\getinfo.avs -c null -o n

Each iteration takes about 2.5 minutes. It goes through this at least 10 times - I had to clear my process monitor buffer because it was taking so long.

The first two times, avs2avi.exe has the same PID. The remaining times are a different, but unique PID.

This whole process took 25 minutes.

Surely there must be a more efficient way of simply gathering information on an audio file?

I did more testing from the command line. This is AviSynth MT causing this. Turn MT off (comment out SetMTmode(3,0) and SetMTmode(2)), and it only does 2 iterations instead of 10.

Perhaps some tweaking in the getinfo.avs can be done for those of us who use AviSynth MT?

[Vereor]

Hi Atak_Snajpera

I seem to have run into a little problem with v1.18.3
When using distributed encoding CRF with the source file being x265, the avs chunks being created have the local file path to the original source file instead of the \RipBot264temp\\job1\video.mkv network share, so the remote servers fails with 'could not open the input file'

I can work around this by selecting the source file through network share on the host machine, just thought I would let you know.

[Atak_Snajpera]

I'm unable to reproduce this problem.

http://i.cubeupload.com/5qKN6c.png

[Vereor]

I'm unable to reproduce this problem.

I am able to reproduce this problem.
But as said, I can work around...

http://i.cubeupload.com/MnK4PI.png

[Atak_Snajpera]

Vereor
This should help
http://www.mediafire.com/download/xy66s7t686az95g/EncodingClient.exe

[Vereor]

Vereor
This should help
http://www.mediafire.com/download/xy66s7t686az95g/EncodingClient.exe

Yes, the new EncodingClient.exe has fixed the problem. Thanks Atak_Snajpera

Also due to your distributed encoding I have a nice little cluster of 10x i7-4770s that makes my x265 encoding a 1/10th of the pain it could have been. So thanks heaps for everything in general too!!

[guest]

Have a strange IP address problem when trying to use DE.

I have recently setup a Windows 10 TP system, and Ripbot works fine, however, I was trying to connect to Windows 8.1 PC using DE, and that PC has an IP Address of 192.168.0.4, and the Windows 10 PC has 192.168.0.3, but when the DE Server windows come up, (on the W10 PC) they show an IP Address of 192.55.233.2:xxxx, so as a result, the 2nd PC won't connect, and "help".

So how does an IP address of 192.168.0.3, be interpreted as 192.55.233.2, in Ripbot ??

Encoder.ini has correct address'.

Any suggestions, anyone ???? :)

[Atak_Snajpera]

ipconfig /all and show us what you have there.

What ip is associated by your router? Do you have more than one network card?