psy_rd and zones

[ncahammer]

I am using x264_x86_r1114_techouse build and I did an encode using
--ref 9 --bframes 9 --psy-rd 1.80:0.20 --aq-strength 0.90 --zones 0,200,b=0.2,psy-rd=3:1,aq-strength=0,bframes=12,ref=12
When the encoding is finished and checked the video using a hex editor (Media Info can show this also) and I get the following
ref=12 psy_rd=3.0:1.0 bframes=9 aq=1:0.90 zones=0,200,b=0.2,psy-rd=3:1,aq-strength=0,bframes=12,ref=12It seems that some zone values overridden the main video values.

Is that just wrong info that x264 writes or my video encoded with wrong parameters ?

Is anyway I can detect what parameters actually used, ignoring that info part ?

[Sagittaire]

Well first don't use zone with really useless setting. 12 bframes and 12 ref are really useless and don't save bits. Moreover these setting break the hardware compatibility in most case.

[Sharktooth]

...and your answer is completely useless...
the user seems to have exposed a problem with x264, zones and psy-rd.
oh, btw, zones are not useless.

[ncahammer]

Well first don't use zone with really useless setting. 12 bframes and 12 ref are really useless and don't save bits. I am trying to allocate as less bitrate I can (and have a relative watchable image) to the HBO intro. You know, the one with a lot of static noise.

Moreover these setting break the hardware compatibility in most case.I doubt, my video is 712x480@29.97

[ajp_anton]

Well first don't use zone with really useless setting. 12 bframes and 12 ref are really useless and don't save bits. Moreover these setting break the hardware compatibility in most case.How do you know they are useless?
How do you know it will break hardware compatibility?
And most importantly, how does that answer the question?

Does this happen if the zone starts at frame 1 instead of 0?
It seems logical that the maximum number of refs goes into the header, but I don't know why the larger number of b-frames doesn't go there...

[ncahammer]

It seems logical that the maximum number of refs goes into the header, but I don't know why the larger number of b-frames doesn't go there...
AQ it's also preserved
Does this happen if the zone starts at frame 1 instead of 0?
No, when I use 1 as start frame, the info is as expected. The new video even it's not identical but is *very* close to the previous one.

I am 99% sure that both times the video was not encoded with psyrd 3:1, but with 1.8:0.2 and I don't have any tool/method to verify it.

OT: I remember that the warning x264 [warning]: width or height not divisible by 16 (712x480), compression will suffer. was about to get silenced. Not only it didn't, but in this encode I see it 6 times in the log!

[burfadel]

How do you know they are useless?
How do you know it will break hardware compatibility?
And most importantly, how does that answer the question?

Does this happen if the zone starts at frame 1 instead of 0?
It seems logical that the maximum number of refs goes into the header, but I don't know why the larger number of b-frames doesn't go there...

Setting b-frames to 12 and using the old b-frame method is pointless anyway, it would be much more beneficial using the new b-frame method and 5 b-frames. Using 12 b-frames with the new method just results in a much slower encode. Only with the new b-frame method will you see possible benefit from using a higher b-frame number, but the benefit is of diminishing returns, and not viable for normal material about about 5. If there are lots of fades etc, 10 may be of slight benefit from what I've read.

In terms of reference frames, the same things occurs. Above about 5 you have diminishing returns. For animated/cartoon material, 10 may be a worthwhile exercise depending on your desired results. At higher resolutions I agree though, in both cases the seemingly ideal '5' for both may be a more suitable option to consider for compatibility with hardware based decoders.

I believe for TrueHD material (1920x1080) is it 3 ref and 4 b-frames considers the maximum for full compatibility? its something along those lines! Its in the specifications for blu-ray, and since thats the case when hardware h264 plays become more common (even for mp4/avi/hopefully mkv files), they are most likely to follow the same requirements. Its more taxing on the decoder to have a higher number of ref/b-frames, and even if you could physically play the video it may make seeking (fast forwarding/rewinding) very slow which can in a way, be described as a hardware compatibility issue. Wouldn't want the video to skip when it gets to a point of a high ref/b-frame number! and since the benefits of a high number is generally extremely low it seems a little pointless :)

It is a little off topic, but important information as it is important to have the settings correct before trying to resolve other issues.

Don't take it as offence for advice that may not pertain exactly to your query, poeple on here are just trying to make your encoding experience more enjoyable and many have encoding experience that can be very beneficial when certain issues arise!

[MasterNobody]

I don't think that this is the bug (at least that only cosmetics). Params simply written for the current params of frame #0 (because x264_sei_version_write calls only for frame #0) which were overwritten by zones. If x264_sei_version_write would be called after frame #200 than it will return the original params specified in command line.

[Manao]

If you don't want to allocate bitrate to the HBO logo, just don't encode it and trim it out. That's the sane thing to do imho.

[Sagittaire]

How do you know they are useless?


Because H264 use high bframe nomber and high ref number is usefull only on static scene. And static part use by itself small bitrate. Use more than 5 bframes is really useless and more than 3 bframes useless in most case (less than 1% of efficiency gain).


How do you know it will break hardware compatibility?

Well ncahammer don't indicate encoding resolution and profil@level but I am pretty sure than 12 bframes and 12 ref will break hardware decoding for negligeable gain (3 bframes and 3 ref is by far better for hardware comapatibilty)


And most importantly, how does that answer the question?

Simply because it's useless. If HBO intro is like I think it's an HBO logo with analogique noise in background. Analogique noise is pure and hard noise. It's an high complexity spatio-temporal part and use high bframe number and high ref number is simply useless because x264 will not use bframe and ref for this part.

Moreover use psy (SSD) on this part will raize dramaticaly the bitrate. Only AQ will be good here for preserve the HBO logo. For me the best way is to use strong spatio-temporal filtering on this part.

[ajp_anton]

[...] (less than 1% of efficiency gain).If he wants to really maximize the quality/bitrate, and time is not an issue, then let him, because the topic wasn't about that.
[...] don't indicate encoding resolution [...] will break hardware decoding for negligeable gainSure, you did say "in most case", but why are you even assuming he's going to use hardware decoding? Also, HW compatibility is just as much on-topic as this post =)
Simply because it's useless. If HBO intro is like I think [...].Using other settings still won't solve his problem, which has nothing to do with the settings being overkill, but the fact that the settings (or some of them?) used for frame 0 in a zone goes into the header. Also, you didn't know about the HBO when you posted.

And I still don't understand why the b-frame setting from the zone isn't shown...

[ncahammer]

I don't think that this is the bug (at least that only cosmetics). Params simply written for the current params of frame #0 (because x264_sei_version_write calls only for frame #0) which were overwritten by zones. If x264_sei_version_write would be called after frame #200 than it will return the original params specified in command line.I'd like to believe that (so I don't have to reencode everything), but it doesn't explain the AQ and B-frame values

If you don't want to allocate bitrate to the HBO logo, just don't encode it and trim it out. That's the sane thing to do imho.But then I have to fix audio, subs and chapters ! No I don't think so. With a single zone parameter I can encode (at least I did try) all episodes

@Sagittaire: I use the 12/12 for 200 frames only.
I used that high ref and B values because the x264 log told me that they are used.
I did trim just those 200 frames and I did few test encodes, just few (not an excessive test), until I got a watchable output at a low bitrate.

And I do know that high refs may hurt hardware compatibility (again I doubt that will have any for a res of 712x480) but not for b-frames. Month ago (maybe a year) I heard a bug that x264 had (regarding high B-Frames) but it's now fixed (No, I am not 100% sure, correct me if I am wrong)

High AQ values totally destroy the logo. Lines blurred and were no longer straight. So I used high psy values only and zeroed the AQ for those frames.

I have two objectives:
a) The HBO logo to look decent
b) I want the next scene not to suffer from a *very*-high bitrate intro. That's what b=0.2 does

[poisondeathray]

According to this thread below, psy rd doesn't work with zones. It's from Oct 2008, have things have changed? What things are included/excluded in the encoder_reconfig?

http://forum.doom9.org/showthread.php?t=141784&highlight=zones

It does work, it just only works with things that happen to be in encoder_reconfig, of which psy_rd isn't.

[J_Darnley]

http://git.videolan.org/?p=x264.git;a=commit;h=86a0fe50c6e369d6dacac5b992febb4bd09de85d

[poisondeathray]

http://git.videolan.org/?p=x264.git;a=commit;h=86a0fe50c6e369d6dacac5b992febb4bd09de85d

:) thanks for the clarification!

[MasterNobody]

I'd like to believe that (so I don't have to reencode everything), but it doesn't explain the AQ and B-frame values
They didn't change because changing number of B-frames and AQ-params don't supported in zones.
By the way refs also wouldn't work really because number of refs can be only decreased in zones.

[ncahammer]

They didn't change because changing number of B-frames and AQ-params don't supported in zones.
By the way refs also wouldn't work really because number of refs can be only decreased in zones.That explains it!
Topic closed
Thanks a lot Master ! :)