[x264-devel] Encoder questions

[vpstranger at tutanota.com]

How annoying it is to hear this bullshit all over again. For the truth's sake I'll answer that.

It is you who doesn't understand (or more likely pretends not to understand) something. 
First, free software is about giving necessary FREEDOMS to users, but those like you pervert this idea into a FREERIDE for programmers, where the programmer does whatever he likes and is free of any responsibility for his program. This is total crap - freedom of software doesn't take responsibility off you to support your program, including answering users' questions.
Second, as this mailing list is the only communication channel between developers and users, this support must be given here, so don't tell me this crap about lower priority. The only case where you could say something like that is if you had explicitly stated that support for your program is paid only (like Red Hat does). But as you haven't, don't you dare even hinting at it.
And third, words "pushy" and "offensive" are absolutely irrelevant to me in this situation, but I do hear those very often from whorish people like programmers who are using these insinuations to distract attention from their flakiness and whoreness. But you are not cheating me with those - I see what you are.
Finally, don't you pour those tiny threats on me - I'm not afraid. 
What is interesting here is whether you've been specially chosen by other developers as a first-line whore who answers "inconvenient" questions like mine in this whorish manner. Is that true?

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Nov 23, 2018, 7:30 PM by BugMaster at narod.ru:

> On Fri, 23 Nov 2018 12:11:29 +0100 (CET), > vpstranger at tutanota.com <mailto:vpstranger at tutanota.com>>  wrote:
>
>> Finally, there you are. I want you to answer questions without
>> reminder. I understand that you do it when you have time, but simply
>> ignoring them is just obnoxious - don't do that.
>>
>
> First, you should understand that nobody is obligated to answer your
> questions. Second, questions that don't have anything with x264
> development (patches discussion, bug reports, feature suggestions,
> etc.) have lower priority and can be even ignored (if it is decided
> that answering is waste of time that doesn't provide any benefit).
> Third, being pushy and offensive wouldn't help and may backfire by
> lowering priority of your email.
>
>> Now for the subject. What linux kernel or anyone else uses is not
>> an argument, because everyone, including Linus Torvalds, is prone to
>> stupidity or bad habits: we're all just humans. So you must make your own decisions.
>>
>
> No comments (I already said what I wanted).
>
>> As for the encoder, I need to clarify something. You say 8*8 is not
>> always better. In what sense better? Compression or quality? Can you
>> explain it comprehensively or give a link to a paper or book chapter
>> where this point is explained in such way?
>>
>
> Compression and quality is the same thing for lossy encoder which try
> to find optimal point at this curve.
>
>> Then you said about b-adapt algorithm. I looked up the x264 paper
>> by Loren Merritt, but it describes this choice just briefly, and I
>> need more detail. It says there's a low-res ME run for each couple
>> of alternative frame sets, but is it a full-featured ME or is it
>> further truncated in some way? Also the parameters include 2
>> versions of it, fast and optimal, and I want to understand the
>> difference between the two. Actually when I tried to switch from
>> fast to optimal, leaving other pars untouched, I got a bigger
>> bitrate in my test encode, which is the opposite of what I expected.
>>
>
> If you want details than read source code.
>
>> And the last question that is the most crucial. When I used the CRF
>> mode and compared it to CQ of the same value, I noticed that it
>> often  increases and decreases the QP in very unnecessary frames. So
>> if the QP choice for CRF is based on the amount of frame motion as
>> described in the paper, then maybe it will give better results when
>> using a different frame evaluation method from 2-pass VBR mode. So
>> the question is: can I use the CRF mode in conjunction with an evaluation pass?
>>
>
> You can use CRF for 1-st pass of 2-pass encode. If you mean other way
> around than no CRF pass doesn't need and can't use 1-st pass statistic.
>
>
>
>
> _______________________________________________
> 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/20181125/b9cdf89a/attachment.html>