Moderate quality at high bitrate

[martinfrombern]

i want to make an encode of planet earth extras for myself. source is dvd pal. i'm probably tweaking encode parameters for a week but cannot find the right ones for this source. i came to conclusion that this source is very uncompressable (lots of fast hand-held camera movements, grain on some parts, ...). however, i tried using a very high bitrate (up to 2500 kbps) but the results are still not satisfactory enough. the basic x264 commandline i'm working with is (i change deblock, psy-rd, psy-trellis, aq)

x264.exe --pass 2 --bitrate 2500 --stats "test.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid
--weightb --direct auto --deblock -2:-2 --subme 9 --trellis 2 --partitions all --8x8dct --me umh --merange 32 --threads 6 --aq-strength 0.9
--psy-rd 1.0:0.7 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --sar 64/45 --frames 1100 --fps 25 --output test.h264 - 716x572

avs script is very simple (cropping + tempgaussmc for deinterlacing). below you can find source vs. encode screenshots at 2500 kbps (thumbnails).

source / encode
http://hdimage.org/images/vt1e1409pvheggc2w4p_s1_thumb.png (http://hdimage.org/viewer.php?file=vt1e1409pvheggc2w4p_s1.png)http://hdimage.org/images/p99tu6pyraddjc4k1cg_e1_thumb.png (http://hdimage.org/viewer.php?file=p99tu6pyraddjc4k1cg_e1.png)
http://hdimage.org/images/otx5yfzwqdledgmpj0t_s2_thumb.png (http://hdimage.org/viewer.php?file=otx5yfzwqdledgmpj0t_s2.png)http://hdimage.org/images/4eobql3flyasoiyzag2v_e2_thumb.png (http://hdimage.org/viewer.php?file=4eobql3flyasoiyzag2v_e2.png)

as you can see from the screenshots, quality is nearly good as it is usually with most sources at this bitrate (e.g. look at grain on green jacket in ss 2).
my question is are there really sources that need such high (or even higher) bitrate for transparency. am i missing somthing obvious? any tricks? :)
I never needed more than cca 1800 kbps for PAL source to make it transparent. However, with this it seems that even 2500 kbps is not enough.

[Snowknight26]

If it needs it doesn't look good with those settings, it needs more bitrate.

Also, your psy-trellis setting is too high.. it's creating artifacts.

[Sagekilla]

Thoughts:

Try increasing deblocking a bit to -1:-1 (-2:-2 is a bit low). Remove no-dct-decimate from your command line, as that's probably eating up bits that are going to waste. Also, try dropping psy-rd to 0.7:0.3 or so, like Snowknight said that's a bit strong.

Otherwise, you can try denoising in avisynth a bit to improve compression. If you do it so you can just stabilize the grain a bit, the quality of the encoded video should be much better.

[Yoshiyuki Blade]

Thoughts:

Try increasing deblocking a bit to -1:-1 (-2:-2 is a bit low). Remove no-dct-decimate from your command line, as that's probably eating up bits that are going to waste. Also, try dropping psy-rd to 0.7:0.3 or so, like Snowknight said that's a bit strong.

Otherwise, you can try denoising in avisynth a bit to improve compression. If you do it so you can just stabilize the grain a bit, the quality of the encoded video should be much better.

Does --no-dct-decimate really eat up enough bits to have a negative effect at a given bitrate? I never really knew of its impact.

[Forteen88]

source is dvd pal.Strange resolution on those screenshots for that source then (intentional upscaling to 1018x572?). --no-dct-decimate is not good to enable when doing bitrate-starved encodes.

[Mr VacBob]

I would suspect dct-decimate of not being useful at --trellis 2, but with psy-trellis and live action it's probably best to leave it on.

[audyovydeo]

simple common sense :

crappy sources (handheld / high motion / blurry) want high bitrates, not fancy encoding options.

preprocessing is what you need. I usually improve (to my eyes) grainy night footage by increasing the contrast/gamma.

cheers, audyovydeo

[martinfrombern]

Strange resolution on those screenshots for that source then (intentional upscaling to 1018x572?). --no-dct-decimate is not good to enable when doing bitrate-starved encodes.
it's anamorphic pal. 2500 kbps for sd = bitrate starved?

Try increasing deblocking a bit to -1:-1 (-2:-2 is a bit low). Remove no-dct-decimate from your command line, as that's probably eating up bits that are going to waste. Also, try dropping psy-rd to 0.7:0.3 or so, like Snowknight said that's a bit strong.
it's just one of probably hundred tests, i tried different encoding parameters (even 0.0 for psy-trellis). followed yours and snowknight advice but no help. Here comes commandline and screenshots
x264.exe --pass 2 --bitrate 2500 --stats "test.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid
--weightb --direct auto --deblock -1:-1 --subme 9 --trellis 2 --partitions all --8x8dct --me umh --merange 32 --threads 6 --aq-strength 0.9
--psy-rd 0.7:0.3 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --sar 64/45 --frames 1100 --fps 25 --output test.h264 - 716x572

source / dct decimate / no dct decimate
http://hdimage.org/images/vt1e1409pvheggc2w4p_s1_thumb.png (http://hdimage.org/viewer.php?file=vt1e1409pvheggc2w4p_s1.png)http://hdimage.org/images/3kehpy1e4cj96nliyu_e549_thumb.png (http://hdimage.org/viewer.php?file=3kehpy1e4cj96nliyu_e549.png)http://hdimage.org/images/yyifm26oszahbpl1u7yc_e5492_thumb.png (http://hdimage.org/viewer.php?file=yyifm26oszahbpl1u7yc_e5492.png)

as you can see, quality is far from satisfactory, grain/detail preservation is awful in some areas. somehow my encoding philosopy is to avoid denoising filters, would rather like to preserve the grain and to have it in the same amount as it is in the source. however, would like to give them a try. which ones did you have in mind?

[Forteen88]

it's anamorphic pal. 2500 kbps for sd = bitrate starved?I'm a bit noob at 'anamorphic' :p , but doesn't anamorphic signal require more bitrate because of more pixels (as non-anamorphic have black bars at the top and bottom of the frame instead)?

anamorphic info-link (http://www.thedigitalbits.com/articles/anamorphic/anamorphic185demo.html)

[Chengbin]

What resolution are you using? Are you using anamorphic encoding? If you are, just to tell you that it is a waste of bitrate. For 16:9, just use 704x400.

[martinfrombern]

I'm a bit noob at 'anamorphic' :p , but doesn't anamorphic signal require more bitrate because of more pixels (as non-anamorphic have black bars at the top and bottom of the frame instead)?
no, number of pixels is the same, the difference is in the pixel dimension (there are not square any more)

What resolution are you using? Are you using anamorphic encoding? If you are, just to tell you that it is a waste of bitrate. For 16:9, just use 704x400.
read my command line. i just put sar flag to indicate it's anamorphic so it's not waste of bitrate

[*.mp4 guy]

Look, you have 4 options to get this video to look better.

1 - Increase the bitrate - This is dead simple

2 - Reduce the resolution - Your source has more resolution then meaningful information within that resolution, so you can downsample and get some compressability "for free"

3 - Use better pre processing - This is often overlooked, but becomes more and more important the more difficult the source video is, often to the point of overshadowing the actual encoding settings used for dificult cases. As far as I can tell, there is nothing horribly wrong with your video, but this could still help considerably.

4 - Use slower encoder settings - Your settings are at the point where this is easily the least likely to be useful.


I expect you will be unhappy with these suggestions for the following reasons:

1 - I don't wanna, I want magical settings that will make everything better

2 - do not insult my source unlike 99% of all video it makes complete use of its resolution, I will not believe your blasphemy

3 - This will change my preciouse source, this is unacceptable, as it is perfect, also I don't know how, and don't want to go to the avisynth forum

4 - Yeah, this sounds good, but Dark Shikari shoould get off his ass and make TESA + QNS + subme11 work in realtime. On a sun altra sparc 2. For UXHDWGVA resolutions.

Note: This isn't targeted at you personally, as you have been entirely reasonable so far, but personal experience has shown me that these are usually the responses I get when I make these suggestions.

[martinfrombern]

@*.mp4 guy thank you very much for your constructive suggestions. here are my opinions about them

1 - i opened this thread mainly because till now i didn't believe there really are sd sources that need more than 2500kbps for transparency. thanks to yours and other guys' answers i now believe there are, and mine seems to be one of them. i don't have problems with addiditionaly increasing bitrate since source is 3.1 GB which would make about 7100 kbps, so even using 3500 kbps for my encode would be significant reduction.

2 - never thought about this because i'm working with famous source (planet earth) so i somehow blindly believed that it makes use of full resolution. will check whether it is actually the case

3 - along with option 1, this one seems to be one i'm most likely to go with. although i don't have much experience with preprocessing, will definetly see what can be done with my source

4 - you said it yourself, apart from switching umh to tesa i'm already using quite slow settings

[Dark Shikari]

1 - i opened this thread mainly because till now i didn't believe there really are sd sources that need more than 2500kbps for transparency.Ha ha ha, you haven't seen some of my concert footage then... ;)

[martinfrombern]

Ha ha ha, you haven't seen some of my concert footage then... ;)
:) out of curiosity, which bitrate was needed there?

[Dark Shikari]

:) out of curiosity, which bitrate was needed there?I ended up using 2 megabits per second...

... after heavily dfttesting the source ...
... and decimating every other frame (I originally MCbobbed it to 50fps) ...
... and there was still noticable loss as compared to the dfttested input.

Of course, the source was pretty bad as well, as one can imagine this didn't look very good with 3 hours of concert in MPEG-2 on one DVD.

One can see here (http://mirror05.x264.nl/Dark/Flash/floweringnight.html) why this was rather difficult to encode.

(Multi-colored floodlights anyone?)

[Sagekilla]

What resolution are you using? Are you using anamorphic encoding? If you are, just to tell you that it is a waste of bitrate. For 16:9, just use 704x400.

What? Anamorphic encoding isn't a waste of bitrate. For a 16:9 DVD at 480p, the resolution is supposed to be 853.33 x 480 pixels. They used anamorphic encoding at 720x480, instead of at the source resolution of 853.33 x 480.

If you stretch the video (i.e. to 848x480) then you're not really gaining anything, but losing compression. Staying at 720x480 means you have 15% less pixels so less bitrate necessary.

[roozhou]

If you stretch the video (i.e. to 848x480) then you're not really gaining anything, but losing compression. Staying at 720x480 means you have 15% less pixels so less bitrate necessary.

IMO upscaling before encoding is always meaningless unless for compatible reasons.

[Chengbin]

What? Anamorphic encoding isn't a waste of bitrate. For a 16:9 DVD at 480p, the resolution is supposed to be 853.33 x 480 pixels. They used anamorphic encoding at 720x480, instead of at the source resolution of 853.33 x 480.

If you stretch the video (i.e. to 848x480) then you're not really gaining anything, but losing compression. Staying at 720x480 means you have 15% less pixels so less bitrate necessary.

If you're using 720x480 for 16:9, it is a waste of bitrate since 720x480 is 1.5, you're wasting bits to encode the parts that are stretched to make it an AR of 1.5 instead of 1.7777

[Sagekilla]

What I'm trying to say is that if you encode at the original resolution and use anamorphic signaling to stretch the image back to 16:9, it's better than encoding at the proper AR of 16:9 (which, for 720x480 is ~848x480). Downsizing to 720x400 is losing detail and resolution. Keeping it at 720x480 doesn't, and upsizing to 848x480 before encoding is wasting bits. That's the point I'm trying to make here.

[ajp_anton]

If you're using 720x480 for 16:9, it is a waste of bitrate since 720x480 is 1.5, you're wasting bits to encode the parts that are stretched to make it an AR of 1.5 instead of 1.7777Isn't it better to encode unstretched pixels instead of stretched ones?

[pcordes]

Isn't it better to encode unstretched pixels instead of stretched ones?

You can't gain anything by redistributing the source information to a different amount of pixels. If you assume that every unscaled source pixel has a full pixel-worth of information, then information-wise, your source resolution is the anamorphic 720x480.

It doesn't matter how it has to be scaled for display. Consider an extreme case, 64x480. (yes, sixty four, not 640). The video will have very low horizontal rez, but still has plenty of vertical detail. e.g. horizontal stripes would look fine, vertical stripes might not even be distinguishable. Clearly you're just making more work for the codec if you upscale to 848x480, because then the codec has to encode the horizontal gradients that the scaler produced, not just the source information.

If your source _is_ itself the result of upscaling from something, or is noisy, then there may not be that much real information in it in the first place. And you might not lose much by scaling it back down to its original resolution (anamorphic or not).