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]

Originally Posted by 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?

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 (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]

Originally Posted by Atak_Snajpera

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]

Originally Posted by LigH

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]

Originally Posted by Daringbaaz

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]

Originally Posted by stryker412

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]

Originally Posted by slalom

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.