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

[ReinerSchweinlin]

Originally Posted by duffbeer

Quick hardware question....
Which would you prefer?

1. Increase 16GB 3200 DDR4 RAM to 3600
2. Increase 16GB 3200 DDR4 RAM to 32GB 3200

Purely encoding related usage - no games

Are you asking which is better for encoding purpose? Getting a bigger CPU or more RAM? Definitely go for a bigger CPU - 16GB of RAM is enough for encoding

[Ronski]

I've had a couple of encodes hang after it finished encoding (once today, once some months back). The encoding server had appeared to have closed, but Ripbot was just saying please wait. When looking in task manager it was still showing the Ripbot264 Encoding Client (32 bit) process, so I killed the process and then Ripbot went on to mux the chunks and completed successfully.

No idea what's causing this but others may find the above useful if it happens to them.

[Pauly Dunne]

Originally Posted by Ryushin

Most of the time after I join them, I have to end up re-encoding the whole thing to fix the audio and a blip at the join.

Fair point, and in theory, that's all that might need doing...

However, what can be done if "part 2" does out of sync at the join..

If I playback the joined movie, and go to the timeline of the join, and watch...as soon as part 2 starts, it's out of sync....how do you "adjust" half the movie ??

Not much point splitting it again, as that's just going back to same problem.

[Pauly Dunne]

Originally Posted by jojo54000

In fact, i think copy /b "file1.h265" + "file2.h265" "full.h265" (if h265 video and after demuxing video via mkvextract)

Well, I've given this a try, and it does indeed join the files, HOWEVER, for whatever reason, part 2 is still out of sync...it's +1000ms, which is about the same as the black frames in between parts, that get's added somehow.

[jojo54000]

Originally Posted by Pauly Dunne

Well, I've given this a try, and it does indeed join the files, HOWEVER, for whatever reason, part 2 is still out of sync...it's +1000ms, which is about the same as the black frames in between parts, that get's added somehow.

Sorry but i don't know why.
Are you sure 2 parts are encoded with exactly same settings (options encoder, resolution) ??

[jojo54000]

atak i would have a question is your software safe to re-encode hdr10 videos? I don't have a 4k tv yet so I can't test if the hdr10 videos re-encoded by ripbot264 send metadata to the tv ... how can I test this without 4k tv?

[blublub]

Hdr10 works just fine

[jojo54000]

Originally Posted by blublub

Hdr10 works just fine

Thanks, so you tested on a 4k hdr tv directly and everything works well ?
directly on usb port tv or/and using mpc-be/madvr for example ?

[blublub]

Originally Posted by jojo54000

Thanks, so you tested on a 4k hdr tv directly and everything works well ?
directly on usb port tv or/and using mpc-be/madvr for example ?

In my setup it works fine with MPC Be and MadVR

[Pauly Dunne]

Originally Posted by jojo54000

Sorry but i don't know why.
Are you sure 2 parts are encoded with exactly same settings (options encoder, resolution) ??

TBH, I haven't checked that, I am assuming that they are the same, as it's part 1 & 2 of the movie.

Maybe I should re encode them, and make sure they ARE the same.

Wasted 2 days on this already

I still think it's got something to do with the slight "black" transition between the parts.

[Pauly Dunne]

Originally Posted by jojo54000

atak i would have a question is your software safe to re-encode hdr10 videos? I don't have a 4k tv yet so I can't test if the hdr10 videos re-encoded by ripbot264 send metadata to the tv ... how can I test this without 4k tv?

I can confirm that if you run a HDR10 thru RB, it retains that (unless you change the HDR to SDR setting).

It works via USB port on my LG 4K TV.

[GZZ]

Originally Posted by Pauly Dunne

Well, I've given this a try, and it does indeed join the files, HOWEVER, for whatever reason, part 2 is still out of sync...it's +1000ms, which is about the same as the black frames in between parts, that get's added somehow.

You cant do copy /b without making sure your chunks are frame accurate. Why dont you use DE process in RB it analyse the video and does exactly that.

DE (Distributed Encoding) doesnt have to use more the one computer, but multiple computers can speed up the encoding. It devide the chunks in to 1,2,3... minutes and encode each other and then merge them. You can stop the process at any time, if done inside at chunk, this chunk will have to be reencoded once the process is restarted. But if you have a power loss, then only the chunk (min. 1 min) encoding will be lost.

[Pauly Dunne]

Originally Posted by GZZ

You cant do copy /b without making sure your chunks are frame accurate.

I have to agree with you that copy /b didn't do what I was hoping it would.

However, I did manage to join this with out further issue.

It seems that whatever is used to join the 2 files together add's an approx 1 sec of black video, but it doesn't add the 1 second to the audio. Hence the instant 1 second of out of sync.

Why dont you use DE process in RB it analyse the video and does exactly that.

DE (Distributed Encoding) doesn't have to use more the one computer, but multiple computers can speed up the encoding. It divide the chunks in to 1,2,3... minutes and encode each other and then merge them. You can stop the process at any time, if done inside at chunk, this chunk will have to be re-encoded once the process is restarted. But if you have a power loss, then only the chunk (min. 1 min) encoding will be lost.

But as for the rest of your post, I find rather offensive !!!

You're implying that I have NO experience using RipBot...which is so far from the truth, I've been using it for probably 15 years or so.

Also, what your suggestion has to do with joining 2 files together, is anyone's guess...

So before you provide suggestions on what one should do, check that you are actually targeting a real "newbie"

And just a sidenote, the files in question would not load into RipBot, so your suggestions could not be proven.

[jojo54000]

Originally Posted by Pauly Dunne

I can confirm that if you run a HDR10 thru RB, it retains that (unless you change the HDR to SDR setting).

It works via USB port on my LG 4K TV.

Cool! Thanks!
By cons I have read on other forums that it is not advisable to crop / resize the video of the file to be re-encoded so as not to corrupt the HDR10 / HDR10 + metadata, which would be based on positioning data, therefore HDR10 / HDR10 + values should be recalculated ...
But the conclusions are not clear, I do not know what to expect.
I would like to know your opinion on the subject?
Is it better not to crop / resize the video in this case?

[duffbeer]

Originally Posted by jojo54000

Cool! Thanks!
By cons I have read on other forums that it is not advisable to crop / resize the video of the file to be re-encoded so as not to corrupt the HDR10 / HDR10 + metadata, which would be based on positioning data ...
But the conclusions are not clear, I do not know what to expect.
I would like to know your opinion on the subject?
Is it better not to crop / resize the video in this case?

As far as I understand it, you can crop sources with HDR10 no problem as it is a fixed brightness for the entire video. HDR10+ is dynamic and should not be cropped because of the reasons you stated.

I crop my HDR10 files with no problem at all. I have not tried manually extracting the HDR10+ data and entering it into the x265 parameters......yet.

[jojo54000]

Originally Posted by duffbeer

As far as I understand it, you can crop sources with HDR10 no problem as it is a fixed brightness for the entire video. HDR10+ is dynamic and should not be cropped because of the reasons you stated.

I crop my HDR10 files with no problem at all. I have not tried manually extracting the HDR10+ data and entering it into the x265 parameters......yet.

So, you have no difference in gamma / colors / contrast compared to the original? I mean does it change anything to crop the video?
MaxCLL and MaxFALL does not affect anything ?

[duffbeer]

Originally Posted by jojo54000

So, you have no difference in gamma / colors / contrast compared to the original? I mean does it change anything to crop the video?
MaxCLL and MaxFALL does not affect anything ?

HDR10 works perfectly as far as I'm concerned. HDR10+ is a different matter from what I've read. I might try it one day but I prefer to crop my encodes.
Regular HDR10 looks great to me so I'm not sure if I can be bothered to mess around with HDR10+ if it's not straight forward.

[Ripmann]

Originally Posted by Atak_Snajpera

This should explain why I decided to not use MDegrain3


Quick summary:
MDegrain1 vs No Denoise
Encoding speed reduction = 1.72x
File size reduction = 1.49x
Size/Speed ratio = 0.87

MDegrain2 vs No Denoise
Encoding speed reduction = 2.70x
File size reduction = 1.75x
Size/Speed ratio = 0.65

MDegrain3 vs No Denoise
Encoding speed reduction = 3.57x
File size reduction = 1.92x
Size/Speed ratio = 0.54

Correct me if I'm wrong (and I may as well be), but is size-to-speed ratio really the only factor here? What about the actual visuals? From what I understand, while MDeGrain3 is slower, it's more suited for heavier noise reduction as it produces little better results as far as video quality is concerned. If that's the case, perhaps adding it as an option like "MDegrain3 [slow]" is a better solution?

By the way, thanks for fixing that 5.1 audio profile size calculation bug. I just noticed that it went away with the update.

[Ryushin]

Originally Posted by Ripmann

Correct me if I'm wrong (and I may as well be), but is size-to-speed ratio really the only factor here? What about the actual visuals? From what I understand, while MDeGrain3 is slower, it's more suited for heavier noise reduction as it produces little better results as far as video quality is concerned. If that's the case, perhaps adding it as an option like "MDegrain3 [slow]" is a better solution?

MDegrain3 has it's uses for very heavy grain. Blade Runner and Black Hawk Down saw large improvements using MDegrain3 over MDegrain2 using a thSAD=600 value. The encoding time does increase a bit, but the results are worth it to me.

[byteshare]

Originally Posted by Ripmann

Correct me if I'm wrong (and I may as well be), but is size-to-speed ratio really the only factor here? What about the actual visuals? From what I understand, while MDeGrain3 is slower, it's more suited for heavier noise reduction as it produces little better results as far as video quality is concerned. If that's the case, perhaps adding it as an option like "MDegrain3 [slow]" is a better solution?

MD3 is better than MD2 for visuals in some cases, but when using MD3 (personally) you need to make other adjustments such as the thSAD. In some of the cases that MD3 isn't visually better is because it wasn't catching as much since it is comparing changes in 3 frames vs 2, (rare) very slow or jittery changes such as in anime, or also there are times they look pretty much the same so all you did was waste CPU running MD3.
Personally I use SMDegrain because it is a much more dynamic than MDegrain alone. SMD can be more than you need when compared with just MD, but when you use it right it makes some great results, as with any good filter.
All that said, even MD2 has its uses but if you're looking for an all-in-one perfect degrainer it won't happen without some sort of AI (to be invented). I haven't done it much but you could even apply degrain to specific scenes and not all scenes with AVISynth.

If you want MD3 create a script and then you can load it when you add a file or when you're running a batch add. [search here others have done this with MD3 or let us know and we'll help] (..\RipBot\Tools\AviSynth plugins\Scripts\Custom)
StaxRip has way more filters builtin and I've used it as a base for either getting a filter (if I couldn't get one from a website to work) or getting other filter ideas. RipBot could have more built in filters but personally built-in filters are often only a starting point and not an end point for great video processing/encoding. Maybe the dev feels different but indications are that the dev isn't likely to start adding lots of filters.
TLDR degrain filters are tricky and there is not a single use case for one degrain filter/settings, which is why with five builtin degrain options the dev likely didn't see a reason for a sixth.