[x264-devel] Encoder questions

[vpstranger at tutanota.com]

I see. You must include the notion of deadzone units in the help for the corresponding option, because now it's totally confusing.

Several more questions have come up to me. 
-Why don't you have a search on the mailing list contents? I might have found answers to some of my questions there, but without search the previous months are essentially unavailable to me.
-With 8*8 DCT active, why does the algorithm choose when to apply it? Whatever the blocks partitioning is, it could be applied everywhere (except for intra macroblocks), wouldn't it be more efficient?
-In the list of block partitions for B frames directly predicted blocks are listed as a separate block size with its own percentage, although they are not a separate size, but may have different sizes. Why?
-How does the algorithm decide, whether to insert IDR or simple I frame? Actually, I haven't seen a single IDR frame in my test encodes except for the initial one. So maybe it doesn't use them at all? And what exactly does the keyint parameter (and scenecut) specify? IDR frames only, simple I only or both types?
-What is the choice of frame type based on?
-What is the difference between simple RD and RD refinement for the subme parameter?
-How does the algorithm choose reference frames for blocks and what part of it makes that decision? I assume this choice is made collectively by the motion estimator set by me parameter and the RD optimizer, is this correct?

1. Nov 2018 20:01 by lorenm at u.washington.edu <mailto:lorenm at u.washington.edu>:


> On Thu, 1 Nov 2018, > vpstranger at tutanota.com <mailto:vpstranger at tutanota.com>>  wrote:
>
>> The default deadzone size (21 for inter blocks,11 for intra) seems large to
>> me. If the 21 interval is centered at zero, then all the frequency
>> coefficients less than 10.5 will turn to zero with this deadzone. As I
>> understand, there are quite many of them which are lower than this value and
>> the compression literature that I read mentioned much less deadzone. So why
>> is it so big?
>
> The deadzone parameter is a fixed-point number, divide it by 64 to get the
> logical value. Also, it applies to each side of zero, not split in half;
> and is in addition to the amount of deadzone implied by "round to nearest".
>
> So a deadzone parameter of "0" means that coefs up to 0.5 round down to 0.
> A parameter of "21" means that coefs up to 0.83 round down to 0.
> A parameter of "64" means that coefs up to 1.5 round down to 0.
>
>> When I see the encode stats for each frame, I see that for all B frames there
>> is the amount of P blocks listed and no B blocks. I assume it is a program
>> error, isn't it?
>
> The each-frame stats line just doesn't distinguish between P blocks and B
> blocks, they're added to the same counter.
>
> If the summary at the end of the encode says something like
> "L0:39.7% L1:42.9% BI:17.4%", then it's working correctly.
> If it hypothetically said "L0:100% L1:0% Bi:0%", that would indicate
> P-blocks in B-frames.
>
>> When I tried to calculate SSIM for each frame, I got a warning in the log
>> that with adaptive quantization turned off SSIM calculation will be
>> incorrect. I don't understand how these two are related. Adaptive
>> quantization modifies quantization parameter values for different blocks in a
>> frame, so why is it not possible to calculate the metric correctly if it is
>> turned off?
>
> The SSIM measured in that situation is still true, it's just not as useful.
>
> Basically, the main reason you'd turn off AQ is if you want the encoder
> to optimize for PSNR at the expense of every other metric. In which case
> you probably want to measure PSNR too, rather than the other metrics you
> told it to sacrifice. (There could be weird use-cases that justify
> otherwise, of course.)
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org <mailto:x264-devel at videolan.org>
> https://mailman.videolan.org/listinfo/x264-devel <https://mailman.videolan.org/listinfo/x264-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20181103/917f97e9/attachment.html>