[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h
Wed Dec 17 00:31:51 CET 2008
Uoti Urpala wrote:
> On Tue, 2008-12-16 at 14:29 -0800, Baptiste Coudurier wrote:
>> Uoti Urpala wrote:
>>> On Tue, 2008-12-16 at 13:10 -0800, Baptiste Coudurier wrote:
>>>> No, you threw numbers saying something you cannot prove, and
>>>> you assume we should trust your words. This is stupid.
>>> I told you the facts, and I told you how to verify them if you
>>> want to. What's stupid is your argumentation in this thread.
>> You are even contradicting yourself because you claimed that
>> changes and symptoms were random, how can you guarantee that my
>> tests would verify them ? This is still absurd, and your
>> argumentation is still stupid.
> I say a thrown die can end up any side up, and present a sequence of
> throws which shows every number appearing. You cannot reproduce the
> exact sequence of throws but you can reproduce every number
> appearing. You asking for the particular code changes I used is like
> asking for the particular way I threw the die to produce a certain
Comparing the situation to "die throwing" is awkward IMHO, considering
your first sentence, you need to show me first that your die can end up
and down. I did see this claim about the code, however Im still waiting
for your backup, until this I do not trust you, and I refute your claim.
Furthermore code relates in nothing to die, since a die has a fixed
number of faces at the beginning, code has probably unlimited number of
variants, especially in this case (H264). Please choose a better example.
This might explain why you fail to understand why you argumentation is
>>>>>> What are you trying to say here ?
>>>>> That you can't reproduce the same random values I did. If you
>>>>> want to verify the existence of random variation you need to
>>>>> find the samples that show differences on your system.
>>>> This is pure absurdity.
>>> Why? You couldn't find any stupider and less constructive way to
>> What is pure absurdity is claiming that I cannot reproduce the same
>> random values that you did, since you told me what to do to
>> experience the same random values ....
> I told you you can't reproduce the exact same random values but you
> can reproduce the same overall behavior. You can't reproduce the
> exact die throws but you can reproduce every side coming up at some
> point. What's so hard to understand about this?
First, see previous point, then after that, considering I accept your
"die throwing" comparision, while I don't, I want to know how you threw
the "die", and without this I consider your claim and everything you say
pointless. What's so hard to understand about this ? That's all about
>>> You quoted some text and asked whether that was what I was trying
>>> to say "here". So I answered that it was not. And I added this
>>> part: "But what I've said elsewhere in the thread is basically
>>> that small benchmark changes show little else than the absence of
>>> very significant changes either way.".
>>>> You claim that since every change produce random effects on
>>>> every computer, no benchmark is worth, no proof is worth being
>>> You snipped the part reproduced above where I clearly say
>>> something else and then wrote this false claim?
>> Twisting words as you always do won't lead you somewhere this time.
>> You deliberatly claimed that showing proof wouldn't makes your
>> point valid:
>> "How would giving a code example affect its validity?"
> Now how is your reply related to the part you're replying to? One
> talks about how benchmark results should be interpreted, the other
> about reproducing test results.
I'm talking about your interpretation of benchmarking _and_ about
reproducing test results. In this regard, what I said earlier totally
> And no the part you quoted last does not say anything about what
> showing proof would or wouldn't do.
Of course it does backup the fact that you said that showing your test
case would not affect the validity of your point, and I say this is
false, in case this was not obvious to you.
> It says that giving the particular code I used in my test would not
> be proof because it would not help you reproduce the exact _same_
> random effects, unless you somehow cloned a lot more of my system.
Again throwing random claims and random numbers without backup is
pointless. Please backup your claims once again.
>>>>>> not contain anything useless, and adding "useless" code
>>>>>> would be stupid, but I thought mentioning this would be
>>>>>> useless as this is obvious.
>>>>> Your comments here are such complete nonsense it's hard to
>>>>> even tell what mistake you're making and correct it...
>>>> Blabla, playing around won't make your point valid, I say your
>>>> point is void, because code is assumed to not contain anything
>>>> useless, so nothing useless will _ever_ be added, so don't even
>>>> consider it nor talk about it. Is it so hard to understand for
>>>> you ?
>>> That adding unused code affects performance in essentially random
>>> ways means that changes to meaningful code will also cause
>>> similar "random" performance changes as a side effect.
>> Your point is void until you show proof that adding "useless" code
>> cause slowdown _AND_ speedup. Stop claming things without backup.
> I mentioned a case where adding unused code gave a 0.8% speedup. I
> think it should be rather obvious that it's not always consistently
"Your point is void until you show proof that adding "useless" code
cause slowdown _AND_ speedup. Stop claming things without backup."
Im still waiting for your claim backup.
>>>> Debating with you is really tiring since you make so many
>>>> efforts to show that you do not understand what people say
>>>> while you obviously do.
>>> I honestly thought that you'd understand the point above. Sorry
>>> if I did not adequately consider the limits of your intelligence.
>> Your lack of understanding is not an excuse for insulting people.
> Do you claim your own tone was not insulting?
It was definitely not, again please backup your claims.
> Maybe I failed to understand your failure to understand the issue
> being discussed, but I think that's a lesser fault than yours.
You still fail to understand why your argumentation is absurd,
nonetheless that really does not excuse your insulting tone.
Now please stop this pointless and futile discussion.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
More information about the ffmpeg-devel