Finding the balance (x264)

[doggyjumper]

Hi all

Good thing I read the forum so I dont have to ask why a x264 compression resized to half the original framesize had the same filesize as compressed at original framesize with the same bitrate

nevertheless I would like to have some opinions on finding a balance between quality and filesize ( and compression speed) knowing that most of it can be very subjective .

I made a batch to convert hundreds of short (1 -1.5 minutes) clips regularly to deliver online to the subjects in the clips. I know that nothing beats the original (also debatable ) but its just impractical .

currently this is the process:

Source NTSC DV (fast moving/sport)

avisynth :

ConvertToYV12()
Yadif()
depend on the shoot some cropping (top and bottom)
LanczosResize(640,480) or vertically addapted to the cropping
Trim() based on external data
a subtitle()
a logo with scriptclip()

x264 parameters: --bitrate 1300 --stats ".stats" --keyint 300 --min-keyint 30 --ref 2 --mixed-refs --bframes 3 --b-pyramid --bime --weightb --direct auto --filter -1:-1 --subme 6 --partitions all --8x8dct --vbv-maxrate 2000 --no-fast-pskip --scenecut 30 --threads auto --progress --no-psnr --no-ssim .

I will admit I dont see the difference that well that many of you see when changing many of the parameters in a subtle way. Trying to understand all the settings as best as I can but takes time.
In other post its mentioned that bitrate of 1024 woudl be good for example and I tried it, somethimes I see difference in result but cant put my finger on it as seems to affect like static text , but comparing a screenshot of both I dont see a major difference. ( I am learning !)
Maybe one would say , well if you dont see a much difference why bother, but I do as I feel there will be catch later .

no doubt it can be tweaked to find a better balance between filesize, compression times and viewingquality
Any advice higly appreciated


tnx
G

[Soopafresh]

Post a short clip of your original DV file somewhere.

A fast noise reduction filter which works well with DV material is Fluxsmooth. Unzip and place in your Avisynth plugins folder. This will let you get away with lower bitrate video.

http://kvcd.net/sansgrip/avisynth/FluxSmooth-1.1a.zip

You'd put it in this order

Yadif()
FluxsmoothST()
BicubicResize(640,480)

[doggyjumper]

Thanks Soopafresh

5,10 or more seconds ?

G

[Soopafresh]

10-15 seconds with some movement in the scenes.

Also, Yadif() before you do the conversion to YV12 will result in cleaner colors in the deinterlaced video.

[doggyjumper]

10-15 seconds with some movement in the scenes.

See PM

Also, Yadif() before you do the conversion to YV12 will result in cleaner colors in the deinterlaced video.

Its often those small things
thanks

G

[Inspector.Gadget]

Doggyjumper, are you sending this to customers who would typically use Quicktime to view the resulting files? Here's what MeGUI uses for Quicktime compatibility ("Quicktime for Windows Unrestricted 2-Pass"):

--bitrate 1000 --stats ".stats" --ref 5 --bframes 1 --b-adapt 2 --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

If you're distributing the files to people who are not too technically inclined, and thus likely to use Quicktime, I think aiming for Quicktime compatibility - which can also be decoded by VLC, CoreAVC, MPlayer, etc. - is the way to go. The MeGUI profile quoted above is rather complex and will consequently take a lot of time to encode for what in some cases will be relatively little quality gain (depending, obviously, on bitrate). If you were to modify your original script for Quicktime compatibility, here's how it would look:

x264 parameters: --bitrate 1300 --stats ".stats" --keyint 300 --min-keyint 30 --ref 2 --bframes 1 --direct auto --filter -1:-1 --subme 6 --partitions p8x8,b8x8,i4x4 --vbv-maxrate 2000 --no-fast-pskip --scenecut 30 --threads auto --progress --no-psnr --no-ssim

You would be omitting the bidirectional mostion estimation and b-pyramid as well as some incompatible macroblock options and adaptive DCT. You would also be knocking down B-frames to 1. IMO, in this situation, limited to 1 B-frame, there's no reason not to use --ref 5 or greater to make each one as efficient as reasonably possible. I assume with the -1:-1 deblocking you found that to work well with your sources. I also don't know how Quicktime fares with the bitrate buffer but I don't remember seeing any posts where it was contraindicated. Hope this helps.

If you don't feel restricted to Quicktime by your target market, then go ahead and push x264 to the limits of efficiency

Also, some bitrate suggestions: Try encoding a few clips with your preferred Avisynth profile and x264 options with one-pass CRF at quality 18 to quality 24 or so. If, at (for instance) CRF 22 a high-motion, high-contrast source isn't easily distinguishable to you from the original, try at CRF 23 and so on until you can spot the difference. The bitrate of those final few smallest indistinguishable clips will be a good starting point for similar sources and if you're focused on a relatively consistent filesize you can adjust it upward or downward as needed. Good luck!

[Starkian]

trying CRF encoding is a good idea !
Quicktime is supposed to supported only 1 b-frame but I made differents tests using 3 b-frames and QT had no problem handling the video ! it would still required no b-pyramid and weighted b-prediction ,adapt DCT and so on ... but it could help to lower the bitrate!

[doggyjumper]

DOnt ask why , but for some reason I dont like QT (but maybe I shoudl get used to it)
Many of the people that like their clip have no clue what player they have on their computer.
I did notice the clips where not playing properly in QT so I adviced them GOMplayer (no fuss for them to install )
Online viewing is no problem at all

I chose x264 becasue it looks so much better then wmv etc compared to filesize

Guess I must have played a bit wrongly with the settings etc
I do admit that at times even trying out filters I have a hard time figuring the differences it makes ( I do see them but cant realy pinpoint them in how what to change , does that make sence ? .

They look good , people are happy , filesize is aceptable but I feel it can be better ( even if it' source is DV)

Thanks for the suggestions all , need to play again (and try to fully understand the differences )

G

[doggyjumper]

Lots of info

we have 2 main parts if I am correct

The avisynth part with filters etc to improve the footage
and the compression , keep as much of the original/improvemnt as possible

right ?

I didnt post the links to some footage here, hope you understand (but there are some available: pm)

btw, have used gui's but how does one tell to do a 2-pass in a ordenary batch script
?

G

[poisondeathray]

Yes,

1) preprocessing/filtering
2) encoder settings

Now you haven't posted a sample clip so I'm going to make some broad generalizations that may or may not apply to your particular source.

If you are using lower bitrate range ~1000-1300kbps for 640x480 sized frame, you might want to turn off psy-rd, or at least lower the value (default in the main x264 branch if you are using a modern build is 1.0:0 for psy-rd and psy-trellis) because it tends to cause outlining artifacting in smoother images at low bitrates.

--psy-rd 0.0:0

This might be what you were referring to when you said "it as seems to affect like static text " - you can see this when you use low bitrates and you have words/letters in the frame, you often see "haloing".

Also in this bitrate range, you might want to increase alpha & beta values to 0:0 or even 1:1 ; not only does doing these 2 things lower the bitrate required (in effect there is less "noisy detail"), but the image is cleaner & smoother - so along with a denoiser/smoother that Soopa suggested, you should get better results

If you were going for a high detail, grainy sharp picture - like many Hollywood films - this strategy wouldn't work. This is where the psy effects, and using higher bitrate shine.

It would be a good idea to test settings on a small representative test sample, then vary the settings & try again until you find a good combination of speed/quality that meets your goals.

[Soopafresh]

The deinterlacing method will also make a big difference, especially when it comes to the visual artifacts (aka the jaggies). Have a look at the various deinterlacers and the results. Better quality = slower processing time

stockholma_0-520_q3_yadif_mvbobmod_tgmca4_tdtmm.avi

BTW, I didn't create the above clip, credits to the person (unknown) who did.

The TempGaussMC method (obviously the best visual quality) transcodes at 2fps, compared to Yadif, which screams along at 38fps.

[poisondeathray]

^ Nice comparison Soopa!

I can't believe TempGaussMC is so much better than mvbob in that sample, I always thought they were close

I'd love to see that test re-done with Nvidia hardware deinterlacer that Neuron2 is working on for DGAVCdecNV and DGVC1decNV a(nd hopefully DGMPEGdecNV)

[doggyjumper]

If you are using lower bitrate range ~1000-1300kbps for 640x480 sized frame, you might want to turn off psy-rd, or at least lower the value (default in the main x264 branch if you are using a modern build is 1.0:0 for psy-rd and psy-trellis) because it tends to cause outlining artifacting in smoother images at low bitrates.

--psy-rd 0.0:0

Unknown option error ?

working from a bat file/script

G

[poisondeathray]

What revision of x264 ? Around r900+ starting having psy optimizations

you can change strength e.g.

--psy-rd 0.5:0

or

--psy-rd 0:0

[doggyjumper]

thought I had the latest as I just have reinstalled everything , guess I didnt
just got rev1046 , its going

tnx
G

[Soopafresh]

^

I'd love to see that test re-done with Nvidia hardware deinterlacer that Neuron2 is working on for DGAVCdecNV and DGVC1decNV a(nd hopefully DGMPEGdecNV)

From some early tests I was reading about on Doom9, it sounds like the built in Nvidia deinterlacer is pretty close to TempGaussMC and many magnitudes faster. 8)

[doggyjumper]

The TempGaussMC method (obviously the best visual quality) transcodes at 2fps, compared to Yadif, which screams along at 38fps

dont say that , a barely get 9 as it is

told you i dont have the latest

[poisondeathray]

This is an older comparison of denoisers, what you expect for compression vs. speed, from doom9. It was done before dual cores & quad cores, so I don't know how valid the results are now...

http://forum.doom9.org/showthread.php?t=51181

* = Added on first edit
** = Added on second edit
*** = Last added

Denoiser                     Time              Size

Noisy clip
None                         5:33 (100%)       64,0 (100%)
*Unfilter(-5,-5)             5:33 (100%)       56.0 (88%)
*Undot()        ´            5:35 (101%)       61.4 (96%)
temporalsoften(2,3,3,2,6)    5:47 (104%)       62,5 (98%)
Mergechroma(blur(1.3))       5:48 (105%)       61,4 (96%)   
**DNR2()                     5:57 (108%)       62.0 (97%)
*TemporalCleaner()           5:57 (108%)       62.0 (97%)   
temporalsoften(3,5,5,2,10)   5:59 (108%)       59,8 (93%)
**STMedianFilter(8,15,4,7)   6:04 (109%)       60.3 (94%)
temporalsoften(4,8,8,2,10)   6:04 (109%)       58,0 (91%)
*Deen()                      6:08 (111%)       53.3 (83%)
fluxsmooth()                 6:11 (111%)       57,4 (90%)
convolution3d("moviehq")     6:14 (112%)       62,2 (97%)
convolution3d("movielq")     6:14 (112%)       59,7 (93%)
**Peachsmoother()            6:28 (117%)       53.7 (84%)
SpaceDust()                  6:46 (122%)       54,0 (84%)
****convolution3d("vhsbq")   7:05 (128%)       57.6 (90%)
**SmoothHiQ(7,20,25,230,5)  16:54 (305%)       50.3 (79%)
FaeryDust()                 26:17 (474%)       55,6 (87%)
PixieDust()                 26:36 (479%)       48,7 (76%)
GoldDust()                  26:49 (483%)       40,4 (63%)

 
Clean clip
None                         3:20 (100%)       26,3 (100%)
*Undot()                     3:21 (101%)       25.8 (98%)
*Unfilter(-5,-5)             3:22 (101%)       23.5 (89%)
Mergechroma(blur(1.3))       3:30 (105%)       25,9 (98%)
**DNR2()                     3:31 (106%)       26.7 (102%) (!?)
temporalsoften(2,3,3,2,6)    3:34 (107%)       25,5 (97%)
temporalsoften(3,5,5,2,10)   3:42 (111%)       25,1 (95%)
**STMedianFilter(8,15,4,7)   3:43 (112%)       26.2 (100%)
*TemporalCleaner()           3:45 (113%)       25.9 (98%)
temporalsoften(4,8,8,2,10)   3:47 (114%)       24,9 (95%)
fluxsmooth()                 3:50 (115%)       24,2 (92%)
*Deen()                      3:56 (118%)       22.4 (85%)
convolution3d(movielq)       3:58 (119%)       25,0 (95%)
convolution3d(moviehq)       3:59 (120%)       25,6 (97%)
**Peachsmoother()            4:03 (122%)       24.3 (92%)
SpaceDust()                  4:07 (124%)       22,2 (84%)
***convolution3d("vhsbq")    4:23 (132%)       25.1 (95%)
FaeryDust()                 12:14 (367%)       23,9 (91%)
GoldDust()                  12:45 (383%)       20,5 (78%)
PixieDust()                 12:48 (384%)       22,3 (85%)
**SmoothHiQ(7,20,25,230,5)  14:10 (425%)       20.6 (78%)

Are you going to bob deinterlace? much smoother and good for action type videos, but 2x fps means more bitrate

[Soopafresh]

Good idea.

doggyjumper - change your Yadif command to

Yadif(mode=1,order=0)

[doggyjumper]

If you're distributing the files to people who are not too technically inclined, and thus likely to use Quicktime

been reminded of why I dont like QT

Been playing with the suggestions you guys gave me so far (still hard to see the subtleties , how do you guys do it ?) and well... playback in QT litterally S***. takes long time to load , jerky ( less then before ) and the colors ..

VLC, GOM even Window Mplayer (with FFdshow) are so much more satisfying to watch with.

Be it people are informed of the player to use , it seems better to not focus on playback in QT if they have it installed . Even better make it as bad as possible there but as good as possible in the others to force them to complain if they didnt read the information given so they do use the 'better' ones .
Yes most of them are completely computer illiterate , but its still easyer to explain them how to save a file follow a link and download a descend player . irronique but true . Last thing one wants is to explain how to change settings

so whe have now nr 3 in the list
1) preprocessing/filtering
2) encoder settings
3) player

G

[doggyjumper]

After trying out all the valueable suggestions which meant I had to included the latest build of x264 I now get "no ratecontrol methos specified" when I try my old settings ( first post) to compare

any ideas please

[poisondeathray]

It looks like you are doing a 1 pass ABR, not 2 pass ?

You need to add --pass 1 and --pass 2 for your passes, respectively

If you were going to do 1 pass, I would use CRF mode instead of ABR

Why not use a GUI to simplify & speed up things? e.g. MeGUI you can add/modify custom command lines and it has presets (you also create presets). There are other GUI's that work well too e.g. xvid4psp, ripbot264

[doggyjumper]

thanks

as mentioned before I am working from a batfile with some vbs for clipdetail processing (involves external trim details and stopwatch info) ( converting lots of small clips on a regular basis)

[doggyjumper]

ok

latest build ( x264)
also installed Megui per suggestion

copy the Megui settings into my bat file and.. no rate control specified
be it my location of x264 or MeGui's one

am lost

[Inspector.Gadget]

Doggyjumper, MEGUI uses slightly different syntax at the beginning of the command line than a batch file calling X264 directly would, I believe. Post your batch script as it looks now and I'm sure someone can help you sort it out. You might also try encoding with one of the MeGUI presets and using that through MeGUI (e.g., open your Avisynth script in MeGUI, set encoding options, queue it up, and start encoding).

[doggyjumper]

Is what I did ( Megui)

For example Megui will show
program --crf 18 --ref 3 --mixed-refs --bframes 16 --b-pyramid --weightb --deblock -1:-1 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"


so I copy :
--crf 23.5 --ref 3 --mixed-refs --bframes 16 --b-pyramid --weightb --deblock -1:-1 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --progress --no-psnr --no-ssim

resulting in the error

this works in the same script : --bitrate 1000 --stats ".stats" --keyint 300 --min-keyint 30 --ref 2 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -1:-1 --subme 6 --partitions all --8x8dct --vbv-maxrate 2000 --no-fast-pskip --scenecut 30 --threads auto --progress --psy-rd 0.5:0 --no-psnr --no-ssim

The code does specify the x264 location andof course the out and source are specified also

G

[poisondeathray]

What version of x264.exe?

Are you using .avs as input for your custom batch file? (i.e. is this done through avisynth and using filters)?

I don't think you can just copy the commandline from megui's commandline box because it omits some syntax, have a look at a sample encode's log file for the proper (full) command line

[doggyjumper]

that did the trick : --sar 1:1 was missing

thanks a bunch

I never stick to : if it aint broke , dont fix it

Edit : weird , got the error again when I switched between one and the other command line settings, went back again , no errors ?