On Mon, Dec 20, 2021 at 03:32:05PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-12-20 11:50:21)
> > On Mon, Dec 20, 2021 at 10:51:56AM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2021-12-17 22:51:55)
> > > > Fixes: OOM
> > > 
> > > This is very non-obvious and could use more explanation.
> > 
> > I guess its obvious to me as ive seen this bug more than once
> > the problem is that directly setting width/height leaves
> > coded_w/h unset, then something sets coded_w/h and next time
> > width/height is set again it is unrelated to the still set
> > coded_w/h and theres a FFMAX() between coded_w and width
> > so the image allocated is much bigger
> > ff_set_dimension() breaks this chain by setting both width and
> > coded_width 
> > 
> > should i add this long explanation above to the commit message
> > or something shorter like
> > "sets coded_width / coded_height too to keep them consistent with
> >  width / height"
> 
> Either is fine with me.

ok will use the shorter and apply the 2 tiff patches

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.