PDA

View Full Version : Pls check my x264 options


grennis
28th January 2008, 05:12
Please check my x264 options, I am archiving camcorder footage from mini DV codec. Thanks

x264\x264.exe --crf 20 --ref 5 --mixed-refs --bframes 3 --weightb --bime --subme 6 --b-rdo --me umh --analyse all --8x8dct --threads 2 --thread-input --progress --no-psnr --no-ssim --output %1.264 %1.avs

:thanks:

Sagekilla
28th January 2008, 05:15
You should enable 16 bframes and throw in --b-pyramid. Otherwise, that should do fine.

Dark Shikari
28th January 2008, 05:17
1. Add --trellis 1.
2. I'd personally use subme7, but that's just me.
3. Use --threads auto.
4. --thread-input does nothing when --threads is enabled.
5. --analyse all is pretty unnecessary, since all it does over the defaults is enable p4x4 partitions, which aren't particularly useful.
6. I'd add --direct auto personally.
7. I'd add --b-pyramid personally.
8. No reason not to do --bframes 16, since x264 automatically chooses the best number to use (3 or 16 is just the limit).

Overall, the settings are quite good though.

Sagekilla
28th January 2008, 05:18
1. Add --trellis 1.
2. I'd personally use subme7, but that's just me.
3. Use --threads auto.
4. --thread-input does nothing when --threads is enabled.
5. --analyse all is pretty unnecessary, since all it does over the defaults is enable p4x4 partitions, which aren't particularly useful.
6. I'd add --direct auto personally.
7. I'd add --b-pyramid personally.

Overall, the settings are quite good though.

Don't forget the --bframes 16 too ;) I've found --direct auto to be sort of useless actually, it had a tendency to increase bitrate, slow down encoding, and had little impact on PSNR and SSIM whenever I used it.

grennis
28th January 2008, 05:27
Cool, thanks!!!

audyovydeo
28th January 2008, 10:00
I am archiving camcorder footage from mini DV codec. Thanks
:thanks:

mmmh, these are more like the settings I'd use for a final encode.
Your saying "archiving" makes me suspect that you somehow intend to reuse (edit) the footage at a later time. If that is the case, my advice is not to use x264 as intermediate format, and if you must, use lossless settings.
Indeed I am looking (but haven't finalised yet) to do just that.
These are the settings I'm using, which are of course open to criticism :

x264 --qp 0 --level 3.0 -r 1 -b 0 --me hex -m 1 -t 0 -A none --direct auto --no-fast-pskip --no-cabac --threads auto --no-psnr --progress -o lossless.mp4 input.avs


Not entirely off-topic, I'd be curious to know what archiving codec you've chosen for audio.

cheers
audyovydeo

grennis
28th January 2008, 15:20
Audyovdeo, what I'm actually doing is storing the captures on network share with some basic transitions, titles, etc.

The "archive" for me is the physical DV tape which I keep in the closet. So I don't mind having some loss cause I can always go back and re-run the AVS scripts on the originals if there is some need to.

I found that lossless compression increased file size to unacceptable levels... too much higher than just keeping the untouched original DV codec firewire capture.

audyovydeo
28th January 2008, 15:46
The "archive" for me is the physical DV tape which I keep in the closet.


me too, plus the dv.avi files on DVD, in the same closet ;-)


cheers
a/v

chipzoller
29th January 2008, 07:05
This may seem a *very* stupid question, but I thought I'd ask if for no other reason than to be laughed at, which might deter someone else from asking the same. But does it matter where in the options string you place certain settings? For example, once --output is specified, is anything added afterwards still considered, say, --aq-strength X?

Dark Shikari
29th January 2008, 07:15
This may seem a *very* stupid question, but I thought I'd ask if for no other reason than to be laughed at, which might deter someone else from asking the same. But does it matter where in the options string you place certain settings? For example, once --output is specified, is anything added afterwards still considered, say, --aq-strength X?Yes, you can specify in any order you want.

chipzoller
29th January 2008, 07:24
That's what I thought. Thanks.

chipzoller
29th January 2008, 16:12
If I wanted to use MeGUI to apply this exact profile as you outlined above, how can I get it to remove the options: --analyse all --thread-input ? I can't seem to find the right combination to disable these, or does it really make a difference if I already have the following command line established: --crf 20 --ref 5 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb
--direct auto --subme 7 --trellis 1 --aq-strength 1.0 --8x8dct --me umh --threads auto --progress
--no-psnr --no-ssim --output "output" "input"

nurbs
29th January 2008, 17:01
Goto codec config -> advanced. Uncheck P4x4.
You can't get rid of thread-input in megui. It doesn't help, but doesn't hurt either.
Also you might want to set a level for hardware compatibility.

chipzoller
29th January 2008, 17:04
Goto codec config -> advanced. Uncheck P4x4.
Tried, but it still leaves the command "--analyse". Is this even a valid command to the encoder, or will it simply be ignored?
Also you might want to set a level for hardware compatibility.
This profile I'm using is designed only for computer playback.

Sagekilla
29th January 2008, 22:02
Doesn't matter. x264 defaults to all partitions EXCEPT p4x4. As long as p4x4 isn't there it doesn't really matter that --analyse remains.

chipzoller
30th January 2008, 02:59
Understood. Thank you.

Poopoo
30th January 2008, 14:21
What's the reason why p4x4 ain't on by default ?
Does it have a negative impact on quality ? According to the avidemux, it is recommended to have all partitions enabled. :stupid:

LoRd_MuldeR
30th January 2008, 15:46
What's the reason why p4x4 ain't on by default ?
Does it have a negative impact on quality ? According to the avidemux, it is recommended to have all partitions enabled. :stupid:

It seems "p4x4" isn't very helpful but doesn't hurt either...

Dark Shikari
30th January 2008, 16:17
What's the reason why p4x4 ain't on by default ?
Does it have a negative impact on quality ? According to the avidemux, it is recommended to have all partitions enabled. :stupid:Its pretty much useless except at relatively high bitrates, and even then its only particularly helpful at low resolutions, and even then its not that great.

Sagekilla
30th January 2008, 23:12
p4x4 is a tricky setting. Like Dark Shikari said, in all practical applications you'll see no realistic use for it. Unless you're encoding at some ridiculously low resolution, like 160x120 (WHY?!) then I don't see where it would be used often at all.


On a related note, is there such a thing as b4x4? And if there is, is there a reason why it's not implemented? I'm guessing if it does exist, it's because it's not useful just as p4x4 isn't. Would like to know concretely though :)

Dark Shikari
30th January 2008, 23:17
p4x4 is a tricky setting. Like Dark Shikari said, in all practical applications you'll see no realistic use for it. Unless you're encoding at some ridiculously low resolution, like 160x120 (WHY?!) then I don't see where it would be used often at all.


On a related note, is there such a thing as b4x4? And if there is, is there a reason why it's not implemented? I'm guessing if it does exist, it's because it's not useful just as p4x4 isn't. Would like to know concretely though :)p4x4 is useful at high bitrates in general--as in, high bitrates relative to the resolution. Low resolutions its obviously more useful than at high. Useful is a relative term--overall its still not that useful, and we'd probably be better off if H.264 didn't support sub-8x8 partitions, as it would speed decoding.

b4x4 does exist--there are 9 sub-b8x8 partition types:

b8x4_L0
b8x4_L1
b8x4_DIRECT
b4x8_L0
b4x8_L1
b4x8_DIRECT
b4x4_L0
b4x4_L1
b4x4_DIRECT

Akupenguin didn't implement them simply because they'd be even less useful than p4x4.

Terranigma
30th January 2008, 23:19
On a related note, is there such a thing as b4x4? And if there is, is there a reason why it's not implemented? I'm guessing if it does exist, it's because it's not useful just as p4x4 isn't. Would like to know concretely though :)


[quote=dark and peng from freenode on Jan 22nd]
«Dark_Shikari» I noticed the H.264 standard recognizes b4x4, b4x8, and b8x4 blocks of Direct, L0, and L1 type each
«Dark_Shikari» why doesn't x264 seem to have these?
«pengvado» Dark_Shikari: there are enough types already in B-frames, it doesn't need more. and after seeing how little p4x4 does, I didn't bother to implement the B versions.
[/unquote]

Does that answer your question? =P

Sagekilla
30th January 2008, 23:27
Yes, Dark Shikari beat you by two minutes though ;)

LoRd_MuldeR
31st January 2008, 01:24
What about "p4x8" and "p8x4" partition types? Are they useful?
I ask, because in Avidemux there is only one checkbox for "4x4, 4x8 and 8x4 P-Frame search" ...

Dark Shikari
31st January 2008, 01:25
What about "p4x8" and "p8x4" partition types? Are they useful?They're related to p4x4 in much the same way p8x16/p16x8 are related to p8x8...

LoRd_MuldeR
31st January 2008, 01:28
They're related to p4x4 in much the same way p8x16/p16x8 are related to p8x8...
So using p4x4 implies using p4x8 and p8x4?
And disabling p4x4 will also disable p4x8 and p8x4?

BTW: Is there any drawback of p4x4, except wasting a few CPU cycles?

Sagekilla
31st January 2008, 01:34
As was just said, p4x4 is slower and it can actually increase bitrate needed sometimes.

I've had video bitrate jump maybe 10 - 30 kbps -- not a lot, but annoying since it encoded (slightly) slower and took more bitrate then necessary.

Dark Shikari
31st January 2008, 01:36
So using p4x4 implies using p4x8 and p8x4?
And disabling p4x4 will also disable p4x8 and p8x4?Yes.

BTW: Is there any drawback of p4x4, except wasting a few CPU cycles?It won't generally decrease quality or efficiency, since (at least at subme >= 6) the decision is RDO-based.

However, especially if your video has lots of p8x8 partitions (to search p4x4 on), it will cut speed noticeably.

LoRd_MuldeR
31st January 2008, 01:40
Thanks for info :)

Dethis
31st January 2008, 01:47
I recall that Ben Waggoneer & Amir have many times stated that one of the VC-1's greatest advantages is the use of these 8X4, 4X8 blocks. Why isn't it the same for both codecs (VC1, AVC).??

Dark Shikari
31st January 2008, 01:48
I recall that Ben Waggoneer & Amir have many times stated that one of the VC-1's greatest advantages is the use of these 8X4, 4X8 block. Why isn't it the same for both codecs (VC1, AVC).??VC-1 has no partitions other than 8x8 and 16x16. Its advantage is multiple DCT sizes: 4x4 and 8x8 like H.264, and also 8x4 and 4x8.

burfadel
4th February 2008, 17:48
b4x4 does exist--there are 9 sub-b8x8 partition types:

b8x4_L0
b8x4_L1
b8x4_DIRECT
b4x8_L0
b4x8_L1
b4x8_DIRECT
b4x4_L0
b4x4_L1
b4x4_DIRECT

Akupenguin didn't implement them simply because they'd be even less useful than p4x4.

Would any particular one of those be beneficial in cases such as anime/animation? would L1, L0, or direct types make a difference?

And moreso, are all partitions above 8x8 supported & optimised?

Dark Shikari
4th February 2008, 17:50
Would any particular one of those be beneficial in cases such as anime/animation? would L1, L0, or direct types make a difference?

And moreso, are all partitions above 8x8 supported & optimised?All partitions of 8x8 size or larger (p16x16, p16x8, p8x16, b8x16, b16x8, and b8x8) are supported.

Animated would likely not make them useful; if anything, they'd be less useful, because animation doesn't have fine, high-bit-cost details.

burfadel
4th February 2008, 18:26
ah ok! at 3:15am I wasn't quite thinking it the right way around :)