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. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
