Michael Niedermayer (2017-12-03):
> 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 

Yes, you are right. The problem is not as severe as I made it. But it is
still a worry. These checks are there to protect from bugs. Or more
precisely to protect from the consequences of bugs, and these changes
weaken that protection.

And there are bugs. Our very own src_movie does not check for formats
changes in decoded frames. An application trusting it could write
outside the frame data, and cause security issues. It would be better if
it crashed on an assert failure, because assert failures, at the very
least, are not exploitable.

> 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

That would be very suboptimal, but as long as somebody is willing to do
the work properly, why not.


  Nicolas George

Attachment: signature.asc
Description: Digital signature

ffmpeg-devel mailing list

Reply via email to