transcode vob to mp4 - highter bitrate vs resize larger - how much of each

[wolfdogg]

ive done the research, its a broad search, too many opinions that are likely not tending the details, so here it goes.

I have a dvd source, flipper 1963, i want to re-compress it to H264 using vdub, i have x264 codec, leaving audio already AC3. I thought i would try for about ~1GB in size, then i thought maybe i could get the best quality by upping it to 1280px right off the top, using lanczos(not lknowing best for large resize like this) and im not happy with the CRF28-38 results at all. Should i leave the size as is, and transcode at "higher bitrate", or should i resize and trancsode at a slightly lesser rate than the "higher bitrate" mentioned.

So when testing encodes, should i shoot for 1280 4x3 material, or leave it 720x576 and just take a higher bit rate, for best quality network playback on future hdtv monitors at the best 1963 quality? Note, this source quality is pretty nice, but im just not seeing that represented in this shot!

Here is the CRF-28 compressed

Note, ill run a multipass once i get the basic figured out here.

I also managed to get the 720 vs 1280 comparison shot (its not the exact same frame), on a 3000kb multipass compression, heres the two, notice the huge white artifact spots in the sky on the 720px one on the right.

[johnmeyer]

Why are you doing this? Why not just watch the movie and be done with it? If you want to add quality, that is a waste of time because you won't get any additional quality. If you want to upscale it so it displays at 720p or 1080p on a big display, use a DVD player that includes upscaling. These players do a fine job and take exactly zero effort: you just put the DVD into the player, and press the play button.

Feel free to try different things, but when you are finished, if you compare the result to what I just suggested, my guess is that the results of your efforts will almost certainly look worse, and will definitely not look any better.

[jagabo]

im not happy with the CRF28-38 results[/ATTACH]

Of course not. Try around 18.

[wolfdogg]

Thanks for the responses.

Hi, I see what your saying, yeah I am doing this because my method of archive is to go with my standards, which are pretty-much avi/mkv/mp4 types, xvid/h264 ~1.2g/hr material. mpeg-1 and mpeg-2's get promptly destroyed around here. I allow about 1.2GB for 90 minute movies, when possible. I dont want any vobs laying around. (all movies are played from laptop slaves, sit on a NAS, and aim to only be read-only from there out).

So, at CRF 18, ouch. What about multipass, 2 passes total? @3000kbps is actually what im going with on my latest decent looking tests, but will be near 2GB for 90 mins to my calculation (i could be off), thats a bit too big, but looks good. I might go with near 2500kbps multi-pass. So, that's keeping it @720x576. Is this near CRF18 you think? Im not sure but sounds like that might land a larger than 2GB file for the 90 mins.

What are anybody's thoughts on that, and what if i now took that and tried to make something better off a 1280 resize with slightly lower bit rate, so that it might playback on larger screens better?? I know screens always getting larger, and better, again that's my future proof thinking. Since i have a good source, I wanted to up the rez if possible If it would help, instead of just going higher bitrate. note, i already pretty much gave up on the upping the rez idea, as you notice my specs above are not resizing, i feel that will just help destroy i. Can someone corroborate this?

[_Al_]

How about VOB2mpeg utility, it gets you one mpeg file, you just select particular title where the movie is together with audio track. That is perfectly ready for streaming or NAS storage, no quality oss. Volume all the way up to about 4GB or less.

If that is too much, you want to encode, use handbrake or better Vidcoder, encode with CRF (RF)

Do not upscale, that is a nonsense. It is even counterproductive for what you want, to decrease volume for video.

2pass takes longer and it is pretty unscientific, all you do is trying to pick a random box and trying to fit random stuff in it. And sometimes you pick up a box that is too big for what you need, not even knowing that. CRF method would find you perfect box for particular stuff. Sometimes box would be bigger, for other movie smaller, but statistically you end up with a decent average size, isn't that what you want?

CRF 18 would not give you bitrates higher than 3000kbps, but who knows, there might be grainy action flicks where you it might.

Check out this link, that telss you more about CRF value.

[wolfdogg]

I tried vidcoder, and im pretty satisfied with those results. at filesize it chose 1981kb/s and results look nice.

for the record, CBR18 looked way over what 3000kb/s output on filesize, at least on my tests, for 25 mins video 2GB files, but i didnt look into the intracies really as to why. they nearly doubled using mostly default and auto settings it seemed.

I took the suggestion not to upscale, so i just chose to go with a bitrate solution to achieve the file-size i wanted. There is one thing i was going to do, using vdub, thats run a unsharp mask on it, not sure how to do that yet on handbrake/vidcoder, but ill be playing with handbrake more often. Hmm, is there something inherently wrong with vdub, or does the standard vfw x264 codecs need tweaking before achieving those results?

[sneaker]

Same x264 settings = same results, no matter if VidCoder, HandBrake or x264vfw in VirtualDub.

[jagabo]

for the record, CBR18 looked way over what 3000kb/s output on filesize, at least on my tests, for 25 mins video 2GB files,

Don't run tests on one video and assume all movies will give the same bitrate. Different videos will give different bitrates. Some might give 1000 kbps, others 5000 kbps, depending on the amount of action, film grain, etc. But they will all have the same visual quality (relative to the source -- it won't make a very bad source look good). At CRF 18 they will all look almost the same as the source at normal viewing speed and viewing distances. You will notice differences if you look at enlarged still frames. In my experience most full length movies movies from DVD will turn out between 1 GB and 2 GB.

If CRF 18 gives higher quality than you want try a higher value (lower quality, smaller files) until you find what you want. Once you've done that you can encode all your movies at that CRF and they will all have the same quality. Watch for are posterization in shallow gradients, especially dark areas. That's where problems start as you reduce the quality.

By the way, upscaling video before encoding , even with a very good upscaler like nnedi3_rpow2() in AviSynth (much better than a simple resize in VirtualDub), usually isn't advisable. There's very little gain. The exception is animated material like cartoons. Those can be upscaled very well with the right tools, much better than the upscaling your typical TV can do.

[_Al_]

Don't run tests on one video and assume all movies will give the same bitrate. Different videos will give different bitrates. Some might give 1000 kbps, others 5000 kbps, depending on the amount of action, film grain, etc.

encoding CRF .... but statistically you end up with a decent average size

You can tell how much overall bitrate CRF gives you only after encoding 20 or so movies of your liking, your typical movie choices, or even more, ..., then you can average it out and say what average bitrate you are about getting. That is what fills your hardisk. Not just one test, not even one movie. That virtual average at the end might surprise you. Some grainy movies out of nowhere have bitrate very high, and some very low , not even close what you might think beforehand.

Think of it like trying to weight, scale one very large Airbus airplaine with people, to be full, you cannot even judge overall size after you weight 10 people. That sample might be not typical. Airlines might go thru stuff like that and averaging out even numbers of airplaines, not just one airplain which corresponds to fuel consumption.

[hello_hello]

If anything, I tend to do the opposite. Instead of upscaling I downscale a little and encode at a higher quality. If there's a little loss of fine detail it's probably not something you'll be able to see without a direct comparison to the source, but compression artefacts are more obvious. For interlaced PAL, it's often possible to de-interlace and resize to 640x480 without any obvious loss of detail (at least when de-interlacing with QTGMC) but often even progressive PAL 4:3 DVDs don't have 720x576 worth of detail.

Encoding at 720x576 is no doubt technically the best method as there's no resizing involved, but even resizing to 720x540 or 704x528 square pixel dimensions might be worth trying. I always encode after resizing to square pixel dimensions myself, although that's partly because a couple of the players in my house don't obey aspect ratios for MP4s or MKVs.

[wolfdogg]

If CRF 18 gives higher quality than you want try a higher value (lower quality, smaller files) until you find what you want. Once you've done that you can encode all your movies at that CRF and they will all have the same quality. Watch for are posterization in shallow gradients, especially dark areas. That's where problems start as you reduce the quality.

By the way, upscaling video before encoding , even with a very good upscaler like nnedi3_rpow2() in AviSynth (much better than a simple resize in VirtualDub), usually isn't advisable. There's very little gain. The exception is animated material like cartoons. Those can be upscaled very well with the right tools, much better than the upscaling your typical TV can do.

All that difference surely cant be just a twopass difference, the vdub sample is destroyed.

Some grainy movies out of nowhere have bitrate very high, and some very low , not even close what you might think beforehand.

If anything, I tend to do the opposite. Instead of upscaling I downscale a little and encode at a higher quality.
For interlaced PAL, it's often possible to de-interlace and resize to 640x480 without any obvious loss of detail (at least when de-interlacing with QTGMC) but often even progressive PAL 4:3 DVDs don't have 720x576 worth of detail.

Encoding at 720x576 is no doubt technically the best method as there's no resizing involved, but even resizing to 720x540 or 704x528 square pixel dimensions might be worth trying. I always encode after resizing to square pixel dimensions myself, although that's partly because a couple of the players in my house don't obey aspect ratios for MP4s or MKVs.

This is extremely helpful info thanks much guys for the input.

So, i gave up the upscaling idea, thanks for clarifying the terminology there.

I tried vidcoder vs. the bitrate that vidcoder said it was going to use (1921), and ran vdub at that rate (x264@1921) and the results are very different.

So i think this is why i was asking why earlier how encoding through vdub encoder setting, the output could be so drastically different. However now that i think of it, there is those settings(placebo, fast, etc..) i guess that makes up a good part of it, however I used Medium Auto on vdub, and vidcoder compressed still very fast, maybe twice as fast as vdub, not sure but was maybe an hour or two for all 4 vobs. nice.

So, look at the vidcoder video output (in vdub on the left) compared to the vlc output of vidcoder file (on the right, looks just as good in vlc) what gives?


I cant open the output file from vidcoder in gspot or vdub either, even though it looks cleaner, is this normal?

I grabbed a shot of my vid coder settings here

and the advanced tab, all pretty much default


I also just grabbed my vdub compression settings for comparison

[jagabo]

GSpot is pretty useless for mp4 or mkv files. Use MediaInfo instead. And when you encode with x264 the settings used are stored as metadata in the file. MediaInfo show you those settings. Compare MediaInfo reports of your Virtualdub and Vidcoder files to see what's different.

[wolfdogg]

Im loving this, thanks. You guys are being super helpful. Surely ill get a good recompression system figured out here for vobs, including some options. Thats greatly appreciated. I updated my post above with some screens. Ill get media-info going here in a bit and see what that yields. I havent used it yet, and i ALWAYS stick with avi container, so this makes sense now, yeah, i forgot im dealing with a legit mpg now, i would rather contain this in avi, x264, thats not where the quality loss is is it? I wouldnt have thought possible if so, unless related to something like bvops, bframes, or something mpeg crazy that i dont understand yet.

[jagabo]

Single pass ABR is the worst method of encoding.

The best method for DVD conversions is to use DgIndex to build an index file, AviSynth to open that index file with Mpeg2Source, do whatever processing is needed in that script (IVTC, blend removal, resizing, noise filtering, whatever), then encode with x264 cli. finally mux the new video with the audio from the DgIndex step.

AVI is not a good container for h.264. Forget it and use mkv or mp4.

[wolfdogg]

Single pass ABR is the worst method of encoding.

The best method for DVD conversions is to use DgIndex to build an index file, AviSynth to open that index file with Mpeg2Source, do whatever processing is needed in that script (IVTC, blend removal, resizing, noise filtering, whatever), then encode with x264 cli. finally mux the new video with the audio from the DgIndex step.

AVI is not a good container for h.264. Forget it and use mkv or mp4.

Interesting on both the ABR point, and the avi container point; So forget it? i had at one point decided to go with avi and mp4, some mkv in my collection, most of my stuff eventually goes through an xvid/ffmpeg wringer, now that im testing using H264, im happier with the results, feel better about it, and im hearing to drop avi altogether. A bit of elaboration on this as to how it could adversly affect things, i would like to hear, even if in another port, or link.

Note, i liked the results from vidcoder, so ive adopted handbrake as potentially my new goto, since im moving to H.264 AVC here mainly in this age in day for archiving, using vdub for maintenance stuff and huffyuv capture mainly. So as we speak, im running some new profile tests, so far i notice the @1920 medium preset speed @high profile, @4.1 level 2 pass turbo is 'still' not as quality still as the vidcoder output. im testing with @slow speed now to compare those. This might be the minumum acceptable for me (e.g. @~1920kbps@slow)


Ill admit, my problem is i cant figure out how to get started with avi synth, i have yet to get through a tutorial, i dont know what to do. i have a couple scripts, not sure how to run them, ill look into this, thanks for the tips, cause i definitely need to use it. i have used ffmpeg in the past, on linux, cli, thats fine, good results there, fun stuff, so i should be able to do that once i figure out how to get avisynth working i guess.

In the end i just want one clean process for each vob to mpg, vhs capture to mpg, pretty much those two. Im not after much more, and filtering another topic. So this has been helpful, thanks for all the advice.

[jagabo]

Again, use MediaInfo to see what's different between your encodings. An example of the x264 encoding settings from MediaInfo:

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L3
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 30 min 0 s
Bit rate                                 : 2 172 kb/s
Width                                    : 704 pixels
Height                                   : 576 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Standard                                 : PAL
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.214
Stream size                              : 466 MiB (98%)
Writing library                          : x264 core 148 r2721 72d53ab
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language                                 : English
Default                                  : Yes
Forced                                   : No

Just the x264 settings with word wrap:

cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

[wolfdogg]

wow, the settings is very intricate. Ok, i see how that makes a huge difference. ill be looking closer at that then, i did use mediainfo, but didnt really notice what i was looking at for the options there, thinking about it, yeah, ill compare those, i can see how even small tweaks in that will make a huge difference.

So, my latest here, i got a pretty encoding using handbrake. heres the scene @1900kbps, high, 4.1, multipass, slower, no filters, loose anamporphic, 16mod, 720w, crop auto. Heres the mediainfo, and Superb, i JUST rememberd now i use to use this on linux for mpeg-2 compression, ok, heres the 'text' and accompanying screenshot

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 25 min 56 s
Bit rate : 1 920 kb/s
Width : 720 pixels
Height : 406 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.263
Stream size : 356 MiB (91%)
Writing library : x264 core 142 r2479 dd79a61
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=1920 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2016-12-17 02:50:38
Tagged date : UTC 2016-12-17 02:50:38
Color range : Limited
Color primaries : BT.601 PAL
Transfer characteristics : BT.709
Matrix coefficients : BT.601

here is the comparison stat of the virtualdub encoded file mentioned in early posts.

ideo
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : H264
Duration : 25 min 56 s
Bit rate : 1 921 kb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 FPS
Standard : PAL
Color space : RGB
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.185
Stream size : 353 MiB (90%)
Writing library : x264 core 148 r2694bm 3b70645
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=1921 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Color range : Full
Matrix coefficients : RGB

Major difference in setting in this initial vdub one, i see it used 'hex' too.

As far as the AR, thats kind of unwieldly for me, i want a clean 4x3, so it self maximizes avoiding the fricken double black border (top/bottom and also left/right), which is unacceptable, and happening. not sure if i need to force it 4x3 or what.

Here is a comparison of the setting differences (in vdub parameter format, since im going to test compare using the HB parameters in vdub to see if i find comparable results.
vdub (an abr pass)

--ref 3 
--me hex 
--subme 7
--b_adapt 1 
--b_bias 0 
--direct 1 
--rc_lookahead 40 
--rc abr

HB (a multipass, and notice several new params here also)

--ref 5 
--me umh 
--subme 8 
--b_adapt 2 
--direct 3 
--rc_lookahead 50 
--rc 2pass 
--cplxblur 20.0 
--qblur 0.5 
--vbv_maxrate 62500 
--vbv_bufsize 78125 
--nal_hrd none 
--filler 0

going to try these latter params in vdub momentarily.
Edit: tried, alot of these params wont work in vdub, ill use cli or handbrake next time, consier a bat file, but ill like use linux before i use a bat. So i think i have a system here. Im happy with Handbrake (thanks to vidcoder test), and this is my scenario. Any last suggestiong im open to, and maybe i can stick with my last encodes as my finals it looks like.

[jagabo]

Again, stop using ABR. Use 2-pass VBR.

[wolfdogg]

Yeah i use 2pass only, as i mentioned, that was just the 'mediainfo' from the previous post virtualdub copy. by no means do i have any, or given any, intentions to do otherwise, for sure. So 2pass is vbr, whoa. im a big anti-Variable guy, you might have changed my mind, but i have alot of video problems in the past using variable encoding, althought that may mostly be variable audio(different topic i know)

[wolfdogg]

Yeah i use 2pass only, as i mentioned, that was just the 'mediainfo' from the previous post virtualdub copy. by no means do i have any, or given any, intentions to do otherwise, for sure. So 2pass is vbr, whoa. im a big anti-Variable guy, you might have changed my mind, but i have alot of video problems in the past using variable encoding, althought that may mostly be variable audio(different topic i know)

[jagabo]

You should always use variable bitrate encoding for video. The only devices that required constant bitrate were VCD. And you should forget 2-pass bitrate based encoding and use CRF. You're wasting your time with 2-pass encoding and getting no real benefit.

[wolfdogg]

I thought you just mentioned that i should use 2 pass, which is it? Im a firm believer in 2-pass or multi pass, butill trust your judgement enough if you say h.264 doesnt need it, to run some compare tests. Im super happy with the latest results, from the culmination of what i learned from this post. Heres my final output archive file specs, thanks to all your help

Complete name                            : D:\Flipper (1965).mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/iso2/avc1/mp41)
File size                                : 1.27 GiB
Duration                                 : 1 h 26 min
Overall bit rate                         : 2 096 kb/s
Encoded date                             : UTC 2016-12-17 13:17:46
Tagged date                              : UTC 2016-12-17 13:17:46
Writing application                      : HandBrake 0.10.5 2016021100

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 8 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1 h 26 min
Bit rate                                 : 1 900 kb/s
Width                                    : 720 pixels
Height                                   : 592 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.178
Stream size                              : 1.15 GiB (91%)
Writing library                          : x264 core 142 r2479 dd79a61
Encoding settings                        : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1900 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Encoded date                             : UTC 2016-12-17 13:17:46
Tagged date                              : UTC 2016-12-17 13:17:46
Color range                              : Limited
Color primaries                          : BT.601 PAL
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.601
Menus                                    : 3

Note, this same file, ran through CRF18 came out to 7GB or something, as i mentioned, where my aim was exactly near ~1.2GB for archive purposes allotment for any given video max size for long term storage, etc...

How can i make this better using CRF at this file size?

[jagabo]

Most full movie DVD rips I've made with CRF 18 turn out somewhere between 1 and 2 GB. 7 GB would be unheard of. Either your movie is 8+ hours long or you did something wrong. Maybe you upscaled the video to 1080p? That would obvious result in higher bitrates.

[hello_hello]

I thought you just mentioned that i should use 2 pass, which is it? Im a firm believer in 2-pass or multi pass, butill trust your judgement enough if you say h.264 doesnt need it

CRF, 2 pass and ABR are all variable bitrate encoding methods.

CRF - you pick the quality and the file size will be what it'll be.
2 pass - you pick the file size and the quality will be what it'll be.
If you encode using CRF encoding, make a note of the resulting bitrate, then use that bitrate for a 2 pass encode of the same source, the result will be virtually identical (assuming the rest of the encoder settings are the same). Encoders such as Xvid didn't have a true quality based, single pass encoding method, but x264 does.
ABR - is pretty much the "guess as it encodes" method. It's variable bitrate and you specify the average bitrate, but the encoder can only achieve it by making constant quality adjustments as it encodes. 2 pass knows how to distribute the bits for uniform quality due to the first pass, and CRF produces uniform quality because it's not constrained by a specified bitrate.

When you said you've had problems with variable bitrate video in the past, you're not confusing that with variable frame rate video are you? Pretty much all the usual video types are variable bitrate and as a general rule they're constant frame rate.

7GB at CRF18 does sound way over the top. Even resizing PAL 16:9 DVDs and encoding at 1024x576 without any noise filtering, between 2GB and 3GB would usually be as large as it gets.

Mod16 isn't required any more (width and height evenly divisible by 16). Mod4 with anamorphic loose is fine, although I'd use anamorphic strict which disables resizing and encodes the video as-is after cropping. That can result in mod2, depending on the cropping, but I wouldn't worry about it. If you do want a particular mod when using anamorphic strict, let Handbrake auto-crop, then manually adjust the cropping if need be. For mod4, which is perfectly fine, it means you'd have to increase the cropping by no more than 2 pixels if auto-cropping results in mod2. Handbrake displays the resolution after cropping (I'm pretty sure) so it's easy enough to check the mod yourself. It's not too much of an issue though. Anamorphic strict is fine and I wouldn't worry too much about the mod.

[wolfdogg]

CRF, 2 pass and ABR are all variable bitrate encoding methods.

CRF - you pick the quality and the file size will be what it'll be.
2 pass - you pick the file size and the quality will be what it'll be.
If you encode using CRF encoding, make a note of the resulting bitrate, then use that bitrate for a 2 pass encode of the same source, the result will be virtually identical (assuming the rest of the encoder settings are the same). Encoders such as Xvid didn't have a true quality based, single pass encoding method, but x264 does.
ABR - is pretty much the "guess as it encodes" method. It's variable bitrate and you specify the average bitrate, but the encoder can only achieve it by making constant quality adjustments as it encodes. 2 pass knows how to distribute the bits for uniform quality due to the first pass, and CRF produces uniform quality because it's not constrained by a specified bitrate.

all pretty much what i knew, excewpt for some of the latter intricacies, thanks for that. However where you mention 2 pass being virtually identical, this is the part im taking your word for, sounds like your saying this is nature of the quality of H.264 im guessing, which is nice.

When you said you've had problems with variable bitrate video in the past, you're not confusing that with variable frame rate video are you? Pretty much all the usual video types are variable bitrate and as a general rule they're constant frame rate.

That is possible, but i think not, mainly it was avi's that when played with vlc it complained about vbr audio i think it was, and i had to recompress using cbr audio to resolve, i think thats what i mixed up with the vbr issues.

7GB at CRF18 does sound way over the top. Even resizing PAL 16:9 DVDs and encoding at 1024x576 without any noise filtering, between 2GB and 3GB would usually be as large as it gets.

Well, @jagabo was right when he guessed it was upscaled, that filter was persistent at that time, and i didnt mean for it to be. however, yeah sounds like alot doesnt it. So i chose 1900 bit rate to achieve the size, to conform to your CFR suggestion, i would need to know what 1900CFR equivalent, and somebody added a link for a chart here i think on that. Its near that exact size i want to achieve, give or take.

Mod16 isn't required any more (width and height evenly divisible by 16). Mod4 with anamorphic loose is fine, although I'd use anamorphic strict which disables resizing and encodes the video as-is after cropping. That can result in mod2, depending on the cropping, but I wouldn't worry about it. If you do want a particular mod when using anamorphic strict, let Handbrake auto-crop, then manually adjust the cropping if need be. For mod4, which is perfectly fine, it means you'd have to increase the cropping by no more than 2 pixels if auto-cropping results in mod2. Handbrake displays the resolution after cropping (I'm pretty sure) so it's easy enough to check the mod yourself. It's not too much of an issue though. Anamorphic strict is fine and I wouldn't worry too much about the mod.

super good info, thanks for this, that about helps me completely refine my procedure on this. i like the idea of scrict but personally i hate when i have video that doesnt have numbers that jibe with standards, so for e.g. it would urk me to see a vid that was 718x576 for e.g. or whatever, assuming i have strict understood correctly, in which case i believe i would prefer the loose mod 4, autocrop, keeping an eye on how many pixels it crops to make sure they are not more than 2, or divisible by 4 i guess.

Edit: in hindsight, i dont really mind sidebars, i dont like having both, as mentioned. a 718px width would be fine, i would either stretch to 16x9, or leave it anyway. HB has been adding black bars showing top/bottom and sides in me, still grappling with the par/dar anamorphic sizing deal here apparently.

[hello_hello]

However where you mention 2 pass being virtually identical, this is the part im taking your word for, sounds like your saying this is nature of the quality of H.264 im guessing, which is nice.

It's the nature of x264 encoding, not h264 encoding in general. I don't think any other encoders have an equivalent of x264's CRF method.
CRF & 2 pass determine frame complexity in different ways, and there's small differences there, but I'm pretty sure the video is encoded using the same algorithms for both methods, so at normal bitrates and/or CRF values it doesn't translate into a perceived quality difference. The various x264 rate control methods are explained better here. https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encod...=1#post2470457

That is possible, but i think not, mainly it was avi's that when played with vlc it complained about vbr audio i think it was, and i had to recompress using cbr audio to resolve, i think thats what i mixed up with the vbr issues.

There's differing opinions about VBR audio in AVIs. I've never had problems with it, but are you sure you're not thinking about VirtualDub complaining rather than VLC? If it's VirtualDub, there's an option to disable the VBR audio warning.

i like the idea of scrict but personally i hate when i have video that doesnt have numbers that jibe with standards, so for e.g. it would urk me to see a vid that was 718x576 for e.g. or whatever, assuming i have strict understood correctly, in which case i believe i would prefer the loose mod 4, autocrop, keeping an eye on how many pixels it crops to make sure they are not more than 2, or divisible by 4 i guess.

Edit: in hindsight, I dont really mind sidebars, i dont like having both, as mentioned. a 718px width would be fine, i would either stretch to 16x9, or leave it anyway. HB has been adding black bars showing top/bottom and sides in me, still grappling with the par/dar anamorphic sizing deal here apparently.

Myself, I'm not fussed about the resolution being anything specific as such, but I'm fairly OCD about making related encodes, such as episodes of a TV show, all the same. I'm also fairly OCD about using a minimum aspect ratio of 4:3, which sometimes means cropping the black, then cropping a bit of picture as required for a 4:3 aspect ratio (or 16:9 as the case may be), then resizing each episode to the same dimensions. That's for sources very close to either 4:3 or 16:9. For widescreen movies I'd just crop the black and encode. That's just me and the way I prefer to do it though.

Maybe have a play with this calculator. It'll calculate the aspect ratio distortion for you. https://www.videohelp.com/software/Yodas-Resize-Calculator
As an example, select PAL 16:9 as the source and uncheck the ITU BT 601 Coeff option (as a general rule you'd probably leave it checked for 4:3 and uncheck it for 16:9) you'll see it display the source aspect ratio as 1.7777 and when you set it to 16:9 dimensions such as 1024x576 (for square pixel resizing) it'll show 1.7777 as the resize dimensions and 0% aspect error.
Assuming you had to crop six pixels from either side to remove the crud, I'd also crop a total of 10 pixels from the top and bottom to make it 16:9 again, whether it needed cropping top and bottom or not. That way you could encode it as-is using "anamorphic strict"and it'd be 708x566 and 16:9. or you could resize to 704x560 (if you want mod16 dimensions) and set a 1.77777 aspect ratio, which would be much like using "anamorphic loose" (Handbrake would set the correct aspect ratio), or you could resize to any 16:9 square pixel dimensions such as 1024x576 or 960x540 etc which would be the same as using "anamorphic none". Handbrake calculates resizing the same way, but it doesn't display the aspect distortion (I don't think). For Handbrake encoding, aspect distortion would only apply to using "anamorphic none" anyway, because for anamorphic loose or strict it'd set the exact aspect ratio required for zero aspect distortion (around 1.779 rather than 1.7777 for my previous example).

My preferred method is to pick an anamorphic type and a resolution and resize every episode the same way after adjusting the cropping to achieve the same aspect ratio, although I invariably resize to square pixels so I'd only worry about adjusting the cropping as required for minimum aspect ratio distortion.

Handbrake doesn't add black bars although it's possible auto-crop isn't always removing them completely so it probably pays to use the preview function. If the encoded video isn't exactly 16:9 (including any remaining black bars) a player should also add black bars as required when viewing the encode on a 16:9 display so as not to distort the picture.

Anyway, have a play with the calculator and maybe it'll help you decide on your own preferred method.

[jagabo]

i chose 1900 bit rate to achieve the size, to conform to your CFR suggestion, i would need to know what 1900CFR equivalent, and somebody added a link for a chart here i think on that. Its near that exact size i want to achieve, give or take.

I assume you meant to write CRF, not CFR. There's no such thing as a chart that will tell you what size a CRF encodings will deliver. The point of CRF encoding is deliver a specific quality. Different videos will require different bitrates to deliver that quality.

With 2-pass VBR encoding you are specifying the size (size = bitrate * runningn time) bur you don't know what the quality will be.

With CRF encoding your are specifying the quality but you don't know what the file size will be.

When the two methods deliver the same file size the quality is nearly identical.

You can verify that yourself. Run a CRF encoding and note the final average bitrate. Then run a 2-pass VBR encoding at that average bitrate (other settings being the same). Compare the two results. You'll see the quality is the same.

The bitrate required to retain quality varies with every video. The size of the frame, the complexity of the picture, the amount and complexity of motion, the frame rate, noise, flickering lights, anything that changes pixels from frame to frame increase the amount of bitrate required. If you encode all your DVDs at 1900 kbps most will probably look pretty good. But many of those encodings will have wasted bitrate because much less bitrate would have looked nearly as good. And a few will not look good because they needed a higher bitrate. Even within a particular TV series, where all the videos have the same frame size, frame rate, running time, etc., there can be a 2x difference it bitrate required to maintain visual quality. Saying you want to use 1900 kbps for every video is like saying you want size 10 shoes for everybody. Why? Because you tried on a size 10 shoe once and it fit perfectly?

The only reason ever to use bitrate based encoding with x264 is when you must fit a file (or files) in a limited space -- like when putting movies on CDs where you want 715 MB files for the best quality you can fit on the CD. You could get the same quality with CRF encoding but you would have to encode several times with different CRF values to zero in on the right size. So in that case it makes sense to perform a 2-pass VBR encoding because you'll get the right size the first time.

[hello_hello]

As an example I had a look at the bitrate range for some old encodes. First was an old TV show from a Bluray source. Quite noisy so I filtered it and was able to resize each episode to 1024x576 without much detail loss. That sort of reduction doesn't happen too often, but each episode was encoded with CRF18, Preset Slow, and Tune Film. I kept the original 5.1ch AC3 (384kbps).

Minimum 1495kbps / 600MB
Second highest 2586kbps / 950MB
Maximum 3252kbps / 1.14GB (that was unusually high compared to the rest)
Average file size 755MB

An old BBC Si-Fi series from DVD, episodes between 48 min and 51 min, de-interlaced to 50fps (QTGMC), resized to 640x480, CRF18, Preset Slow. I kept the original 2ch AC3 (256kbps).

Minimum 1056kbps / 470MB
Maximum 1768kbps / 750MB
Average file size 626MB

[jagabo]

Here's a post that shows the x264 bitrate distribution using CRF, ABR, and 2-pass VBR encoding:

https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encod...=1#post2470202

[wolfdogg]

There's differing opinions about VBR audio in AVIs. I've never had problems with it, but are you sure you're not thinking about VirtualDub complaining rather than VLC? If it's VirtualDub, there's an option to disable the VBR audio warning.

Ill keep an eye out, but yeah it was a playback issue when played as normal, on the NAS, on a player somewhere, was torrent of Northern Exposure older seasons on that particular instance.

Myself, I'm not fussed about the resolution being anything specific as such, but I'm fairly OCD about making related encodes, such as episodes of a TV show, all the same. I'm also fairly OCD about using a minimum aspect ratio of 4:3, which sometimes means cropping the black, then cropping a bit of picture as required for a 4:3 aspect ratio (or 16:9 as the case may be), then resizing each episode to the same dimensions. That's for sources very close to either 4:3 or 16:9. For widescreen movies I'd just crop the black and encode. That's just me and the way I prefer to do it though.

im the same way, just more careful when i clip top and bottom, and dont OCD on that part, just all the rest, lol, i have to have all my episodes same. You are shedding light on some of the intricacies that count though, i think i SHOULD be paying more attention to that detail, since i have been struggling with(well thats the OCD in me, cause they mostly all come out perfect, lol) AR, usually par/dar as mentioned, but the end result is always a strict 4x3, 16x9, or blackbar/envelope on only ONE side (when played-back with default vlc settings in fullscreen for e.g.)

Maybe have a play with this calculator. It'll calculate the aspect ratio distortion for you. https://www.videohelp.com/software/Yodas-Resize-Calculator
As an example, select PAL 16:9 as the source and uncheck the ITU BT 601 Coeff option (as a general rule you'd probably leave it checked for 4:3 and uncheck it for 16:9) you'll see it display the source aspect ratio as 1.7777 and when you set it to 16:9 dimensions such as 1024x576 (for square pixel resizing) it'll show 1.7777 as the resize dimensions and 0% aspect error.
Assuming you had to crop six pixels from either side to remove the crud, I'd also crop a total of 10 pixels from the top and bottom to make it 16:9 again, whether it needed cropping top and bottom or not. That way you could encode it as-is using "anamorphic strict"and it'd be 708x566 and 16:9. or you could resize to 704x560 (if you want mod16 dimensions) and set a 1.77777 aspect ratio, which would be much like using "anamorphic loose" (Handbrake would set the correct aspect ratio), or you could resize to any 16:9 square pixel dimensions such as 1024x576 or 960x540 etc which would be the same as using "anamorphic none". Handbrake calculates resizing the same way, but it doesn't display the aspect distortion (I don't think). For Handbrake encoding, aspect distortion would only apply to using "anamorphic none" anyway, because for anamorphic loose or strict it'd set the exact aspect ratio required for zero aspect distortion (around 1.779 rather than 1.7777 for my previous example).

Ill try this sometime, after i go through my encodes using these refined methods. This is VERY HELPFUL, SUPER THANKS for those few examples , especially i would have never attempted anything at 1.777 anything, and im totally not familiar with PAL much, i have been an NTSC guy until recently, since im ready to learn it.

On another note, also because im hopeful still that 25fps will help shrink the file sizes, knowing that the brain really only needs 15fps for fluid motion, so if the flicker isnt visible at 25fps, i think all vid should be encoded to that, lol, save file space.

My preferred method is to pick an anamorphic type and a resolution and resize every episode the same way after adjusting the cropping to achieve the same aspect ratio, although I invariably resize to square pixels so I'd only worry about adjusting the cropping as required for minimum aspect ratio distortion.

So this is a bit confusing to me as to what that means, so picking an anamorphic type, you mean in HB, e.g. strict vs loose? If so i can follow; And so your saying resize, AFTER crop it looks like, so meaning let HB crop, then resize to specific apsect ratio (all episodes), (and im guessing at the expense that widths, or is it hieghts, may differ, but dont always; but then your saying during that resize, it will definitely be square pixel (where is this determined? you mean by keeping the dimensions exactly proportional to the source(minus the crop)?

This points out to why sometimes i will just not resize, since i wasn't able to see the subtle losses, but lately i have been able to pick them out nicely (i need a good IPS display, never had one), so once i understand when and why i need to pay attention to the PAR, and when and why i need to pay attention to the DAR, ill be good, for now,
-i just make sure:
-- when i resize, its divisible by 16
--blackbars only ever end up on one plane (on PLAYBACK)
--result is square pixel with no distortion of source pixel aspect. this is all based on when in vdub, if i do a resize, and it looks distorted on w or h, i need to pay closer attention to what im doing
Kind of caveman-ish way to keep aspect ratio of source, lol. That was my previous xvid thinking, but im changing all that right now.

Handbrake doesn't add black bars although it's possible auto-crop isn't always removing them completely so it probably pays to use the preview function.

Oh, i imagined auto crop was removing them completely to 1 pixel past the inside edge.

If the encoded video isn't exactly 16:9 (including any remaining black bars) a player should also add black bars as required when viewing the encode on a 16:9 display so as not to distort the picture.

The point of the day on AR, yes the PLAYER, not the encode, thats what i have been meaning. My OCD stated that we ONLY want the player adding the black bars, and NEVER the encode, lol. So Im trying to avoid from EVER having a black bar on an encode, is this feasible? This is because once the encode makes a black bar, if its on the perpendicular plane of the bar that happens to be the fill point of your monitor AR, then becomes the dreaded double black bar. How do i completely avoid this? Im sure if i just reread this post over a couple times you guys have mentioned this already. thanks.

Edit: on another vob, from another source/movie i decided to test CRF-18, its giving me huge sizes still, @slower interlace, @l4.1, @loose mod4, @slowest, a 1GB 49 min VOB file outputs to 1.3GB mp4. i was expecting something less than or near 750mb. mp4. That 1900kbps 2 pass was sure coming out nice, i cant see how the CRF without the 2 pass, at something like over 20, which will make the file size equivalent, can come out even as nice as the 2 pass 1900, which would make it about or less than 750gb i think.

But to quote

The point of CRF encoding is deliver a specific quality. Different videos will require different bitrates to deliver that quality.

yes thats what i understand

With 2-pass VBR encoding you are specifying the size (size = bitrate * runningn time) bur you don't know what the quality will be.

With CRF encoding your are specifying the quality but you don't know what the file size will be.

When the two methods deliver the same file size the quality is nearly identical.

So then i think i must me making a mistake not yet calculating this out properly, which i have NOT done yet, i just blindly used CRF18 as suggested, but thats way past my specs fpor file size yield then, i believe. Im sure its not crf 18 then, so ill figure out what this decent looking 1900kbps compares to on the Flipper source, then use that for an archiving starting point, adjusting out from there to fine tune. I assume that will be my needed target(finding the CRF that matches the 1900 on that source). I think i got this.

Edit: ooh that calculators nice, that will help me figure out somethings in resizing, for e.g. when i set it to pal 4:3 material, it outputs 640x464, and a source and ar of ~1.3, which looks alot more understandable to me that when i first looked at it at 720x576 before i switched it to PAL, on square pixel, @1.77, although i havent figured out exactly whats going on, it looks promising. :-p

Edit:

As an example I had a look at the bitrate range for some old encodes. First was an old TV show from a Bluray source. Quite noisy so I filtered it and was able to resize each episode to 1024x576 without much detail loss. That sort of reduction doesn't happen too often, but each episode was encoded with CRF18, Preset Slow, and Tune Film. I kept the original 5.1ch AC3 (384kbps).

Minimum 1495kbps / 600MB
Second highest 2586kbps / 950MB
Maximum 3252kbps / 1.14GB (that was unusually high compared to the rest)
Average file size 755MB

An old BBC Si-Fi series from DVD, episodes between 48 min and 51 min, de-interlaced to 50fps (QTGMC), resized to 640x480, CRF18, Preset Slow. I kept the original 2ch AC3 (256kbps).

Minimum 1056kbps / 470MB
Maximum 1768kbps / 750MB
Average file size 626MB

So were those 49 minute shows or 24 min shows? If 49 minute shows, then that sounds good to me, and i guess then maybe because there was alot of water scenes, or because flipper was an older video its coming out higher. Yeah i might be happier with CRF21, doing some tests now for 21 and 22 (Nasa video) to see if i can get the 1GB vob to become 750GB or less on average of the 6 separate 49 minute episodes.

Edit: Doubling back, i noticed you did say they were indeed the full hour episide (49-51) ok good.

Thanks for the superb, and friendly responses!