Re: [FFmpeg-devel] Politics

["Daniel Cantarín" <canta@canta.com.ar>]

> 
> I am not sure the direction from which you approuch this is going to
> increase the chances this patch has.
> 

Me neither.

But I can barely talk about ffmpeg internals: they're huge, and I know
the little bits I'm familiar with, having some experience with filters.
So, whatever argument I may have come from use cases experience and not
from ffmpeg internals knowledge.

That's why I don't deny there may be issues with softworkz code. But I
can say when the critics are presenting unreal use cases as some kind of
proof of a problem.


> 
> All stream types in libavformat/codec are timebase based, that was
> done because its exact (for some definition of exact at least)
> 
> I think you should argue why this is the best way forward not why its
> not too bad
> 

No, I don't think that's the case.
I recognize what you say has ground. Thing is, what I do does too.

It's not about it being "not too bad", but about it working were no
other code is present, and nothing being broken by it. You may speak
about ffmpeg internals, I speak about real life use cases, both are
valid considerations.

Your (and others) criticism against the patchset seems legit. However,
softworkz has been dealing with such criticism from months now, he has
been sustaining that what he did was neccessary, and suspiciously every
single example against that seems to be unreal. So, softworkz may be
wrong somehow, but the devs are clearly exaggerating about the supposed
consequences of such wrongness. Why? Devs here are experts. Why would
they need to exaggerate like this? I say something's fishy.

I understand devs may have biases towards norms, standard or otherwise,
but I find it hard to believe that somebody experienced in software
development would not accept a patch if it adds use cases and doesn't
break any previously implemented one, specially when the proper way to
implement it was object of debate for a decade without anybody doing it.
That's no small detail. And this patchset is no small feat. This is
special, not norm.

I'm doing tests from my side, by the way: it's not about "just approve
it". I see the thing working, and I'm looking for problems when somebody
say there's a problem. That's why I also discuss what I believe to be
fantasy problems: I respect the devs claims, even if I don't believe in
it. But this "frame-perfect serious problem" is clearly an exaggeration,
and that says something about arguments against the patchset.

Breaking something is the real issue here IMO, and not some clearly
unachievable purity, whatever the reason of the unachievability. I
pretend to intervene here with that logic in mind. If that doesn't help,
so be it.

In any case, devs biases will be there no matter what I say. So it's not
really about me: it's about softworkz against the ffmpeg devs community.
I just happen to want the use cases, and find this patchset working.


> 
> also in a few places where a fixed timebase is used ffmpeg uses
> AV_TIME_BASE_Q which is micro not milli seconds. That suddenly
> allows exactly addressing individual frames and audio samples.
> And it should be easy to change to from ms, its just a *1000
> it would weaken the precission argument
> 

Then softworkz would most likely adapt the code. He doesn't seem to be
reluctant to apply small modifications in order to be approved. Yet,
again and again he claims it's not that easy, and we get back to unreal
examples. This part I don't understand yet, as my time and knowledge are
both limited. But, with time, I will; if the patch doesn't die, perhaps
we'll find its way to be implemented. I just hope softworkz doesn't get
burned.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".