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

[mini-moose]

Originally Posted by Atak_Snajpera

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]

Originally Posted by mini-moose

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]

Originally Posted by Atak_Snajpera

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]

Originally Posted by mini-moose

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


Bitrate Distribution for chunks with CRF 16


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/gr..._for_1.18.3.7z

[mini-moose]

Originally Posted by Atak_Snajpera

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

[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.



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]

Originally Posted by soneca

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]

Originally Posted by hoju3508

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

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

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.



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

Originally Posted by hoju3508

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

[Atak_Snajpera]

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