On Sun, Dec 03, 2017 at 08:21:50PM +0100, Nicolas George wrote: > Michael Niedermayer (2017-12-01): > > Do you think this comment will fix any issue or improve anything ? > > This comment had one goal: prevent somebody from pushing incorrect > changes before I had time to make my point. > > > First i do not even know what you speak of exactly and as this is > > I posted the exact reference in my previous mail in this thread, which > is not very long: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221480.html > > > supposedly about code i wrote, i doubt others will have a better idea. > > > > And there is possibly a difference in goals. Reinitializing filters > > would loose filter state, so avoiding reinit unless really needed was > > a big goal. Last but not least what i had envissioned is just in my head, > > i never implemeted it. (the bikeshedding made me loose > > interrest back then as i already mentioned) what is in git is a small > > part of it, that alone certainly is not that great. > > and "too simple" yes my vission of this was and is simple > > I agree that avoiding resets is a worthy goal. I do not know if what you > had in your head was correct or not. But what you committed in > 9225513242 (and related commits 5d2b885074, 6c702c3c63, 5d859e5980) was > just wrong. And one of the reason we can be sure it was wrong is that it > caused assert failures, that you did not fix but just hid with more of > the same.
I think i may be missing something here The way i remember this, is that all the changes do never get triggered unless the user application passes frames with changing parameters into the filter graph. That is something not supported before these commits. So an application first has to introduce changes to get changes out or to get any of these failure modes. While before all this should have failed [...] > > You are overly optimistic when saying it is simple. It will involve > quite a bit of work: checking filters to see if their code is safe to > call several times; probably use some kind of flag to see which one are > safe; inserting scale if necessary; providing an API to enable/disable > parameters changes on buffersink; providing an API to detect parameters > changes conveniently. > > Not overwhelmingly difficult, but not an easy task either. I think our difference here is entirely linguistic its a lot of work, and indeed as there are more filters now its more work than what it would have been in the past. But it is simple work (as in alot but it does not seem to be complicated work) > > And this is only speaking of changes in resolution and other shallow > parameters. If you want to allow changes in pixel format (which your > commits do), you need to adapt the whole format negotiation. iam not sure naively the same approuch (flag & insert scale or reinit or do nothing) should work too. I do not think we need to rebuild parts of the filter graph totally reoptimizing for changed pixel formats but we could of course if thats something someone wants to implement [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list email@example.com http://ffmpeg.org/mailman/listinfo/ffmpeg-devel