[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171203/25abf83c/attachment.sig>