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-requ...@ffmpeg.org with subject "unsubscribe".
