Log in

View Full Version : x264 - bitrate problem


i'mroot
24th July 2014, 16:15
Hello guys,

i'm new to encoding and only work on 1080i HDTV captures for now.
It seems my encodes(720p) lack of bitrate, source have no issues when I watch them but some people complain about my encodes.
I do use CRF method since I think that transparency is easier to reach with it and I also think it's less involving than 2pass method.

Here's an example with my encoding settings below
source : bitrate - 11 000
encode : bitrate - 3016

Encoding settings : cabac=1 / ref=9 / deblock=1:-2:-1 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.90

I don't know why I didn't use deblock=1:-3:-3,I didn't pay enough attention but it's not the problem here.
Hopefully, someone will explain to me what I did wrong so I can improve :)

benwaggoner
24th July 2014, 18:44
i'm new to encoding and only work on 1080i HDTV captures for now.
It seems my encodes(720p) lack of bitrate, source have no issues when I watch them but some people complain about my encodes.
I do use CRF method since I think that transparency is easier to reach with it and I also think it's less involving than 2pass method.

Here's an example with my encoding settings below
source : bitrate - 11 000
encode : bitrate - 3016
That seems like a completely expected result from a conversion from 1080i30 to 720p30. You have less than half the bits, and progressive encoding is more efficient than interlaced. Also, CRF and x264 are likely a lot more efficient than whatever created your original source file.

You only have a low bitrate problem if the quality isn't good. Try a --crf 10 and see if it looks meaningfully different. You may have already hit the saturation point where more bits don't improve quality; crf 17 is quite good for 720p for most content. If --crf 10 doesn't look any better, than you need to look elsewhere for quality improvements.

More probable sources of quality issues are either the original source, the scaling algorithm, and especially the deinterlacing algorithm used. Working with interlaced sources often feels like sprinting towards mediocrity through molasses ...

Encoding settings : cabac=1 / ref=9 / deblock=1:-2:-1 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.90
Can you share your command line? Looks like you're forcing some odd parameters. For normal film/video content, I'd just start with --preset veryslow --tune film --crf 17 and iterate from there based on visual quality.

I don't know why I didn't use deblock=1:-3:-3,I didn't pay enough attention but it's not the problem here.
Hopefully, someone will explain to me what I did wrong so I can improve :)
I don't know why you'd need to use -3:-3. Is the source something atypical?

Sharc
24th July 2014, 19:11
How do you resize from 1080i to 720p? If this is not done properly you will obtain ugly results which cannot be fixed with a higher bitrate. Can you post your script?

i'mroot
24th July 2014, 19:21
That seems like a completely expected result from a conversion from 1080i30 to 720p30. You have less than half the bits, and progressive encoding is more efficient than interlaced. Also, CRF and x264 are likely a lot more efficient than whatever created your original source file.

You only have a low bitrate problem if the quality isn't good. Try a --crf 10 and see if it looks meaningfully different. You may have already hit the saturation point where more bits don't improve quality; crf 17 is quite good for 720p for most content. If --crf 10 doesn't look any better, than you need to look elsewhere for quality improvements.

More probable sources of quality issues are either the original source, the scaling algorithm, and especially the deinterlacing algorithm used. Working with interlaced sources often feels like sprinting towards mediocrity through molasses ...
Yeah, I already did test encodes before sticking to CRF 17 and didn't notice a much better quality with lower values.



Can you share your command line? Looks like you're forcing some odd parameters. For normal film/video content, I'd just start with --preset veryslow --tune film --crf 17 and iterate from there based on visual quality.

Preset veryslow - Tuning None - Profile High

Custom Encoder parameters
--level 4.1 --deblock -3:-3 --min-keyint 23 --bframes 8 --ref 9 --qpmin 10 --qpmax 51 --rc-lookahead 250 --aq-strength 0.9 --merange 32 --partitions p8x8,b8x8,i8x8i4x4 --no-dct-decimate --no-fast-pskip


I don't know why you'd need to use -3:-3. Is the source something atypical?
An encoder recommended me to use --deblock -3,-3 for everything that isn't a terrible quality source.

I still don't understand why my encode is jerky, but if my bitrate is fine then I don't know where the problem come from.

i'mroot
24th July 2014, 19:24
How do you resize from 1080i to 720p? If this is not done properly you will obtain ugly results which cannot be fixed with a higher bitrate. Can you post your script?

Sure, here's the script I used :
MPEG2Source("E:\Sources\The.Leftovers.S01E04.1080i.MPEG2.DD5.1-CtrlHD.d2v", cpu=0)
Crop(0, 8, -0, -0)
Spline36Resize(1280,714)
TFM().TDecimate()

Sharc
24th July 2014, 19:31
You seem to resize an interlaced source. You should deinterlace it first, and then resize.
Perhaps you may upload few seconds of your source for better advice.

i'mroot
24th July 2014, 20:02
Here it is : sample_source-002.mkv - 41.8 MB (http://uptobox.com/whl5abxjndaj)

Sharc
24th July 2014, 22:47
Your source is progressive video 29.97fps, encoded as interlaced.
=> No need to inverse telecine, it would just introduce jerkyness.

For conversion to 720p I would bob or frame duplicate the video to 59.94 fps which makes it blu-ray format compliant (just in case...) and keeps the audio in sync.

Script:

ConvertToYV12()
LoadPlugin("C:\.......\decomb521.dll") #or a deinterlacer of your choice
FieldDeinterlace(blend=false) #or your deinterlacer
BicubicResize(1280,720)
ChangeFPS(60000,1001) #59.94 fps
ConvertToYV12()
AssumeFPS(60000,1001)

x264 (example):
--preset medium --bluray-compat --b-pyramid strict --weightp 1 --open-gop --qpmin=0 --crf 20 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --vbv-maxrate 35000 --threads auto --slices 4 --thread-input --me=hex --subme=7

nhakobian
25th July 2014, 00:14
For conversion to 720p I would bob or frame duplicate the video to 59.94 fps which makes it blu-ray format compliant (just in case...) and keeps the audio in sync.


You can also use the pulldown flags to encode at 29.97 and playback at 59.94 (for bluray players). The instructions for that are located here (http://www.x264bluray.com/home/720p-encoding).

Sharc
25th July 2014, 08:01
You can also use the pulldown flags to encode at 29.97 and playback at 59.94 (for bluray players). The instructions for that are located here (http://www.x264bluray.com/home/720p-encoding).
Yes, true.
The reason why I "standardized" on frame duplication was some issues with tsMuxer (http://www.x264bluray.com/issues-with-certain-players)with --pulldown. Not sure whether this has been solved since.

nhakobian
25th July 2014, 21:05
Yes, true.
The reason why I "standardized" on frame duplication was some issues with tsMuxer (http://www.x264bluray.com/issues-with-certain-players)with --pulldown. Not sure whether this has been solved since.

Ah, thats good to know. I was unaware of that issue. Thanks!

i'mroot
25th July 2014, 22:06
Alright, thanks for your help guys.
I'll re-encode it and see how it looks :)

sneaker_ger
25th July 2014, 23:35
FWIW, tsMuxer changelog lists fixed pulldown for version 1.7.1(b).

foxyshadis
27th July 2014, 08:44
Closed for Rule 6 violation.