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

[Juha]

I have a Blu-Ray that is - according to Mediainfo - progressive but still it says "Top field first" which is typical term on interlaced video. Which is it really?

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 1 h 59 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Top Field First
Compression mode : Lossy

RipBot allows to de-interlace this video (normally it doesn't allow to do so if it's a progressive video). Should I do it even if Mediainfo says it's progressive?

[LigH]

"Scan order" is only interesting if "Scan type" is "Interlaced". But both are not relevant to decide whether to use a deinterlacer or not, you really have to check if there is a temporal progress from one field to another in a frame. MediaInfo cannot check that. It can only report how the video encoder was set up.

HDConvertToX has a check for the video content. It encodes a tiny piece of the video once in TFF, once in BFF interlaced mode, compares the statistics and calculates a probability which scan type and order may be most efficient. Still, there are better ways to check that, but also more elaborate (e.g. looking at a Bob result field by field with your own eyes).

[rlev11]

I have a Blu-Ray that is - according to Mediainfo - progressive but still it says "Top field first" which is typical term on interlaced video. Which is it really?

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 1 h 59 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Top Field First
Compression mode : Lossy

RipBot allows to de-interlace this video (normally it doesn't allow to do so if it's a progressive video). Should I do it even if Mediainfo says it's progressive?

What I would do is use the built in media player that will open the video when you click "preview script" in the avisynth filters window.

Load the video and then do not set any deinterlacing, then hit preview script. Once media player opens, slide to a point where there is some fast motion, then use CTRL-Right Arrow which will go frame by frame. look for any interlacing lines or stutters (same frame repeats itself). This should let you know if it is interlaced or not, or doing some sort of 3:2 pull down like DVD's used to do (doubtful, but maybe possible??). It does seem strange that a BR disk would be interlaced, but I guess anything is possible

If it does not show any interlacing lines, I would just encode it as usual and figure the TFF listed is just some sort of false positive glitch.
If it does show lines, you can choose the deinterlace TFF and repeat the test and see if that clears them up.

[Juha]

Thanks, I did carefully check the video for areas with movement and with CTRL + RIGHT Arrow. I think it's defenitely interlaced.

https://images2.imgbox.com/89/55/y9R5xeFw_o.png
https://images2.imgbox.com/b6/32/n0feQUCm_o.png
https://images2.imgbox.com/18/8b/06qNvjmi_o.png

Not the first Blu-Ray I see that has interlaced content though they are clear minority. Usually if Blu-Ray source has 25 fps, the picture is also interlaced (my experience). Truly progressive Blu-Rays have been 23.976.

[LigH]

Do not rely on single frames. There are multiple reasons for combing, and not all of them should be treated with "Deinterlacing". Between Film (24000/1001 fps) and NTSC (30000/1001 fps) there might be Telecine instead. And between Film and PAL (25.0 fps) there might be a blended norm conversion, and de-blending is a lot more elaborate than just de-interlacing. You will need some experience to judge the progress over at least half a dozen frames.

It is complicated. To learn more, see: exotic interlacing (https://forum.doom9.org/showthread.php?t=176104) (German original by scharfis_brain, translated by StainlessS).

[rlev11]

So I have been holding off posting this until I had some time to fully test what was going on.
Ever since the update which I think was back in June that put the EncodingClient.exe to version 1.19.0 I have had an intermittent issue where in the middle of an encode the distributed encoding client window would just close itself. The servers would continue to encode the chunk they were working on, and then everything would stop. Only thing to do would be go into task manager and close everything Ripbot related and start the process over. As said, it would be very intermittent, sometimes could do dozen or so encodes in a row before it happened, or could happen sooner even on the first job I tried in a session. Could not track down any specific scenarios where it would or would not happen.

So I waited until the last update of 1.27.4 to see if anything changed and it did not. I also tried 2 different computers as the clients and still got the same issue.

So my next step was just copying back encodingclient.exe from a previous version, in my case 1.18.3 and turning off auto updates so it did not get the newest encodingclient version of 1.19.0. I left everything else at its latest versions as part of 1.27.4, just using an older encodingclient. It's now been a couple of weeks running this way and I have done more than enough encodes without any issues that I can feel fairly confident that 1.19.0 has some sort of a bug in it causing the shutdowns.

Not sure if there is anything I can do to troubleshoot exactly why there is this issue with 1.19.0. would be willing to try anything if I get some guidance on what to do.

[slalom]

Poster download is broken again

[stryker412]

I ran two batch season encodes last night. Today I started on seasons 3 and 4. As soon as the job is prepared it "completes" within 2 seconds. I'm using the same settings so I'm not sure what's going on. I'm using the latest version 1.27.3.

https://imgur.com/a/NQNkeQq

[Atak_Snajpera]

check log. (right click on job and then SHOW LOG)

[stryker412]

Error: The file 'C:\Temp\RipBot264temp\job1\video.265' could not be opened for reading: open file error.

[LigH]

To discover the reason for the aborted encode, you will have to look at much more than the last line only...

[Daringbaaz]

check log. (right click on job and then SHOW LOG)

Are there any further developments and updates on RipBot264 available? Nowadays, all CPUs have multiple Cores, and we can't utilize them properly for single-file encoding.

I want to give it a try again to Ripbot264 for Distributed Encoding options. Please provide a download link to the latest version and change logs..

Thanks

[bar72]

I'd just like to say, nice work Atak_Snajpera. Been using ripbot for just over a year now and the DE has saved me a ton of time with the pile of BDs I'm backing up to my media server.

I've just got an old i7-7700k where I run the client and I run server on 2 x desktops with i7-4790s, all with 16GB RAM. Anyone with older CPUs, best settings are programs defaults with my setup:

/priority normal /restart-if-no-progress /avisynth-prefetch-threads 4 /x264-threads 4 /x265-threads 4 and "use multiple processing threads" set to 4 and setting any scripts to SetMemoryMax(8192).

SMDegrain took me ages to get running right but got there eventually, thanks to everyone in this thread.

Getting on great with Dogway's Example script on the SMD page of: Video=SMDegrain(video,tr=2,thSAD=180,prefilter=2,contrasharp=30,refinemotion=true,chroma=false,plane=0).

I'm still using MDegrain2 with some Blurays though as results are per movie specific.

[stryker412]

To discover the reason for the aborted encode, you will have to look at much more than the last line only...

My Ripbot updated to 1.27.4 finally and now it works again. So I have no idea what was wrong.

[rlev11]

Are there any further developments and updates on RipBot264 available? Nowadays, all CPUs have multiple Cores, and we can't utilize them properly for single-file encoding.

I want to give it a try again to Ripbot264 for Distributed Encoding options. Please provide a download link to the latest version and change logs..

Thanks

Setup properly using distributed encoding I can assure you Ripbot can use all of your cpu cores and threads to their fullest.
Running all the computers in my inventory, each of my encodes are currently using 200 physical cpu cores and 364 threads. Even running only 1 encoding server per PC, watching task manager, the cpu's are all going full bore near 100% usage.

[LigH]

My Ripbot updated to 1.27.4 finally and now it works again. So I have no idea what was wrong.

I would guess the reason might have been the command line syntax change (explicit "--input") we discussed in the last several pages of this thread.

[00-00]

I'm having a problem when trying to encode a BluRay with 7.1 DTS-MA, once everything is demuxed & prepared opening the preview window, the audio goes out of synch with the video. It's fine at the beginning but drifts out of sync during later parts of the preview.

I've tried encoding it anyway but the audio drifts out of synch in the resulting file too. I can add a delay, but it still drifts out. I've tried 3 completely separate sources all with the same problem. Other encodes are going on fine btw.

I'd appreciate any ideas!

[slalom]

Check fps display in program vs movie fps

[00-00]

Check fps display in program vs movie fps

Mediainfo reports: 23.976 (24000/1001) & RipBot also shows 23.976.

However! I just loaded it into RipBot again, (the 2nd time with this source) and, at least according to the preview window, everything seems to be in synch throughout. I'll re-encode tonight and see if the actual encode is also in synch.

Just as an FYI it's an obfuscated playlist, (definitely the correct one btw!) so I don't know if that has any bearing, but never had his happened previously with similar encodes..? Anyway, I'll re-encode & report back.


UPDATE: It was only in synch in the preview window with the audio profile at it's default setting: 7.1 FFMPEG FLAC ??? kbps [vbr] As soon as I change it to 7.1 Copy Stream it goes out of sync, even if i switch it back to default profile...

[rlev11]

Just out of curiosity, I would mux out the audio file from the original using mkvtoolnix which will save it as a .mka file. Then add that newly created file to the outputted file that ran through ripbot. I would be curious to see how the audio syncs up doing it that way. So essentially using the video part from ripbot, and the audio part from the original.

[00-00]

Just out of curiosity, I would mux out the audio file from the original using mkvtoolnix which will save it as a .mka file. Then add that newly created file to the outputted file that ran through ripbot. I would be curious to see how the audio syncs up doing it that way. So essentially using the video part from ripbot, and the audio part from the original.

Well that was strange - it worked! I tried extracting the audio separately and remuxing it afterwards previously with no luck, but doing it this way worked! I've never tried doing it this way before though, through mkvtoolnix, as I usually use tsmuxer if I have to demux a track.

So thank you for that, much appreciated!

[stryker412]

What is everyone's personal CRF preference for 1080p?

[LigH]

I wish this question would mean anything so I could answer...

[microchip8]

What is everyone's personal CRF preference for 1080p?

x264: CRF 21

x265-10bit SDR: CRF 23
x265-10bit HDR: CRF 18

[stryker412]

x264: CRF 21

x265-10bit SDR: CRF 23
x265-10bit HDR: CRF 18

Not an argument, just curious. Why 23 vs the default of 20?

[microchip8]

Not an argument, just curious. Why 23 vs the default of 20?

20 was chosen at the beginning, when they added presets, and hasn't changed. At that time, x265 wasn't very good still so it needed more bitrate. Now, x265 is "good enough(tm)" and 23 is optimal CRF for me wrt quality/file size trade-off

[LigH]

There may be different factors to select your preferred CRF.

But the video resolution should hardly be one.

[stryker412]

20 was chosen at the beginning, when they added presets, and hasn't changed. At that time, x265 wasn't very good still so it needed more bitrate. Now, x265 is "good enough(tm)" and 23 is optimal CRF for me wrt quality/file size trade-off

Gotcha, thank you.

[Boulder]

There may be different factors to select your preferred CRF.

But the video resolution should hardly be one.

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

[rlev11]

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

So what exactly does having the --hdr10-opt (or even the --hdr10) in the x265 command line do. I have been running for the longest time with just the default ma10 profile in ripbot that just has
--profile main10 --output-depth 10
in it. It appears to me when encoding hdr, that even with the default setting, that the bt2020 parameters for hdr are being passed in the encode.

[Boulder]

So what exactly does having the --hdr10-opt (or even the --hdr10) in the x265 command line do. I have been running for the longest time with just the default ma10 profile in ripbot that just has
--profile main10 --output-depth 10
in it. It appears to me when encoding hdr, that even with the default setting, that the bt2020 parameters for hdr are being passed in the encode.

--hdr10-opt will offset QPs based on the luma level of the frame so it will allocate bits better considering the characteristics of HDR sources being different from SDR ones.

You can use MediaInfo to see which parameters have been used on the video.

[valnar]

Hey everyone. My Google Fu is failing me.

Is there a tutorial on Batch mode? My episode files have a DTS-HD track and I assumed with the defaults based on this pic, it would copy the stream over. Instead it's converting it to FLAC. How can I adjust that?

18748

In case the pic doesn't come through, it's the default batch window of

Audio 1:
DEFAULT
English
1_audio

7.1|COPY STREAM
5.1|COPY STREAM
2.0|COPY STREAM
5.1|FFMPEG AC3|640 kpbs
2.0|FFMPEG AC3|256 kbps

[slalom]

That's a lot of pages back...

try this

https://i.ibb.co/LkThFqS/Screenshot-2024-11-04-190203.jpg (https://ibb.co/LkThFqS)

[activoice]

Before encoding a video I strip out any subs I don't want leaving just the English Subtitles, and English Forced Subtitles. I make sure that the forced subtitle has the Forced value set to YES

When the Forced Subtitles are de-muxed they end up in the corresponding Job folder with a file name like this (so far so good)

1_subtitles_English_DEFAULT_FORCED.srt

But after encoding has been completed by Ripbot and the output is remuxed that subtitle still ends up with the Forced value set to NO, I need to open the output file in MKVToolnix change the flag to Yes and Remux it.

When I look at Profile setting under preferred forced subtitles, it says FORCED and has examples of English|Forced.SSA as the filename to be used.

But I don't control the filename that the subtitle is output as. Does that mean I should be entering this file name in that field for it to retain the forced flag?

1_subtitles_English_DEFAULT_FORCED.srt in that box?

Or if that's not it, how do I retain the Forced value without having to remux after the encode?

[Atak_Snajpera]

Is 1_subtitles_English_DEFAULT_FORCED.srt automatically selected in SUBTITLES section after demuxing?
I think the problem is that 1_subtitles_English_DEFAULT_FORCED.srt was originally muxed with two flags DEFAULT and FORCED. In that case RipBot treats that file as DEFAULT.

[activoice]

Is 1_subtitles_English_DEFAULT_FORCED.srt automatically selected in SUBTITLES section after demuxing?
I think the problem is that 1_subtitles_English_DEFAULT_FORCED.srt was originally muxed with two flags DEFAULT and FORCED. In that case RipBot treats that file as DEFAULT.

Usually if you have a Forced Subtitle it's also the first subtitle and is often set to Default YES and Forced YES.

I did a test just now where I set Default to NO and Forced to YES, but Ripbot still did not set it to forced automatically in the job.

I also tried adding both English_DEFAULT_FORCED and DEFAULT_FORCED to the preferred forced subtitle box and that didn't do anything either.

It seems the only workarounds are to either Edit the job to manually select the subtitle I want forced. Or to edit the output with MKVToolnix, set the flag to YES and Remux.

[hardkhora]

Has anyone been able to get RipBot to work with Linux via WINE?
I know a Virtual Machine (VM) option exists but would take more resources... and I'm trying to de-windows my life, but it is soo hard :(
I saw some interest from a few users (TDS, apol847, dv8r, BLKMGK, Ryushin, and mparade)

Or is there something for Linux that does distributed encoding like RipBot?

[Atak_Snajpera]

Usually if you have a Forced Subtitle it's also the first subtitle and is often set to Default YES and Forced YES.

I did a test just now where I set Default to NO and Forced to YES, but Ripbot still did not set it to forced automatically in the job.

I also tried adding both English_DEFAULT_FORCED and DEFAULT_FORCED to the preferred forced subtitle box and that didn't do anything either.

It seems the only workarounds are to either Edit the job to manually select the subtitle I want forced. Or to edit the output with MKVToolnix, set the flag to YES and Remux.

It is a bug. I will fix that soon.

[activoice]

It is a bug. I will fix that soon.

Thanks

[rlev11]

With bigger resolutions, you might get away with a slightly higher CRF as the possible artifacts are often not as visible (because they are enlarged less if at all).

When talking about CRF, it must be remembered that the "hdr10-opt" parameter that should be enabled with HDR encodes, shifts the scale a bit so you can use a 1-2 points lower value for the same average bitrate.

Thanks for the info on hdr10-opt especially since i always encode with a CRF of 18.
I did a couple quick tests and re-encoded some hdr material using hdr10-opt in the command (along with what I believe is correct from reading also adding --aq-mode 2).
I can not tell any visual difference in the new encodes EXCEPT I am now getting anywhere from a 5 - 40 percent decrease in the final output size. So a win-win in my book.

Since having --hdr10-opt in the profile will not ignore and blow up the encode on non-hdr material, I just now have an additional profile I use specifically for hdr material now which is no problem.

Also, I posted back a bit that I was having issues with the latest encoding client .exe. Just recently I let ripbot auto update again which installed the latest version. I have done a bunch of encodes recently and have had no issues. Not sure if something was updated with ripbot, or something maybe with a windows update took care of the issue. Just wanted to get that out there....

[Ryushin]

It is a bug. I will fix that soon.

I was coming to post about this exact same bug.

If I have:
[Subtitles]
File=English;
Default=FORCED;
Forced=FORCED;

The default will always be populated and the Forced will be blank. If I set "Default=;" then it will show up in Forced. But yea, I set both the Default and Forced to be FORCED and I make my MKV files to be the same way.

So having Default and Forced be populated with the forced subtitle would be appreciate it. Also if it's possible to automatically move the Forced subtitle to be the first subtitle would be best too.

Thanks Atak.

[Ryushin]

Has anyone been able to get RipBot to work with Linux via WINE?
I know a Virtual Machine (VM) option exists but would take more resources... and I'm trying to de-windows my life, but it is soo hard :(
I saw some interest from a few users (TDS, apol847, dv8r, BLKMGK, Ryushin, and mparade)

Or is there something for Linux that does distributed encoding like RipBot?

No, no success working under WINE when I tried to make it work several years ago. So I settled on using a virtual machine using KVM under Linux which gives near bare metal performance.

[hardkhora]

No, no success working under WINE when I tried to make it work several years ago. So I settled on using a virtual machine using KVM under Linux which gives near bare metal performance.
I hadn't tried KVM, just VirtualBox since I usually use Nobara or Linux Mint.
I'll have to give that a go.
Thank you for the insight.

[rp1989]

I hadn't tried KVM, just VirtualBox since I usually use Nobara or Linux Mint.
I'll have to give that a go.
Thank you for the insight.

I’ve made significant progress on macOS by installing the encoding server through CrossOver. Everything launches as expected, but the encoding server cannot access the main shared folder via CrossOver. I suspect this is due to a limitation with Wine when accessing UNC paths. It would be ideal if there were a way to configure the shared folder for each encoding server to use mapped drives instead. Since CrossOver/Wine supports accessing mapped drives, configuring the encoding server to look for a mapped drive instead of directly accessing the shared folder via a UNC path would resolve this issue.

[stryker412]

Looking to build a new Intel PC. What is the best mix of GPU/CPU that helps with Ripbot that won't break the bank? I was thinking of an i7-14700K with a 2070 Ti Super.

[rlev11]

Looking to build a new Intel PC. What is the best mix of GPU/CPU that helps with Ripbot that won't break the bank? I was thinking of an i7-14700K with a 2070 Ti Super.

Can't help with the GPU side as I don't do any gpu based encoding (cpu only), but on the processor side I have the non-K i7-14700 which I push to about 175 watt. This slots in between a ryzen 7700x and a ryzen 7900x. I would imagine you should be able to push a 14700k real close to a 7900x.
Just as a comparison , a cheap i5-14500 I see about 30% slower than a 7900x and similar to the 7700x. I have never run a i9-14900k, but I can't imagine (might be wrong) that 4 extra E cores would make it that much faster than the i7 for the additional price.

[stryker412]

Well this will also be a gaming PC too so it'll be a mix of video encoding and gaming. Does Intel offer anything with their latest generation that AMD can't match when it comes to encoding (Ripbot use)?

Here's an AMD build to compare: https://www.microcenter.com/site/content/custom-pc-builder-amd.aspx?load=da1dec8f-9b9b-46e2-a795-2ccbcee2e3ba

[rlev11]

Well this will also be a gaming PC too so it'll be a mix of video encoding and gaming. Does Intel offer anything with their latest generation that AMD can't match when it comes to encoding (Ripbot use)?

Here's an AMD build to compare: https://www.microcenter.com/site/content/custom-pc-builder-amd.aspx?load=da1dec8f-9b9b-46e2-a795-2ccbcee2e3ba

I don't game, but everything I have read is the AMD x3d processors are the king of gaming performance. I have nothing to compare, but I don't think the x3d variants help at all with encoding. They are also a lot more expensive than the non-x3d amd's.

Encoding is more of a CPU/Thread count for performance as opposed to other factors. CPU generations can also affect encoding performance a bit. There is a big jump on the AMD side going from the 5000 series to the 7000 series. 9000 series is a smaller jump from the 7000 series. My 9950x is a tad bit faster than my 7950x , but not significant. I have a i5-13500 and an i5-14500 and they encode identically (they also have the same thread count).

It is my understanding that the intels game a little better than a non-x3d equivalent processor probably due to their higher boost clock rates. There is also a lot of talk lately about issues with intel 13 and 14 gen cpu's having manufacturing issues to consider.

In my opinion, the best bang for your buck just for encoding would be a AMD 7900x. There are plenty of sites with gaming benchmarks out there (and also encoding), so I would look at those and see what works with your price range and has the best balance between the 2.

[Emulgator]

Excactly, and Sagittaire has just made a nice benchmark:
https://forum.doom9.org/showthread.php?t=185855
On my 2 main encoding systems I am running Intel i9-11900K from September 2021, and there it is:
AMD Ryzen 9950x beats mine easily @ 400% encoding fps. Their price 700$ looks feasible for me as well,
the Intel CPUs in my past systems had always set me back around 1000$ each, but outlasting decades.

On the same sidenote: x3D I would rather consider as a testbed:
Can TMSC's engineers get 2 chips perfectly smooth stacked without any real contact as we are used to ?
Will that design around the "4nm" node outlast decades ?
Thermal diffusion might lead to decaying contact zones, I fear, and still would like to adhere to monolithic...

[rlev11]

Since we are talking about cpu performance with ripbot, below I ran a quick test with all of my current machines just to see where they all stacked out in comparison. This might be useful for someone looking into what processor they want to get. This is taken from a 2.40:1 aspect 4k movie with some light degraining, HEVC 10 bit CRF 18. I did a sample of 3 chunks for each server and averaged them together in the middle of the movie using the result fps number for the chunk in the distributed encoding client window. This is more though about how the numbers compare to each other than the actual numbers....

9950x 20.02
7950x 18.3
7900x 17.37
7700x 11.26
5950x 11.15
5900x 9.07
3950x 9.43
3900x 9.78
i7-14700 13.98
i5-14500 12.44
i5-13500 12.64
i5-12600k 9.59