[FFmpeg-devel] [PATCH] rl.h: Use on-stack temporary VLC tables instead of having them static.

[Clément Bœsch]

On Tue, Sep 02, 2014 at 01:59:50AM +0200, Michael Niedermayer wrote:
> On Mon, Sep 01, 2014 at 11:25:57PM +0200, Reimar Döffinger wrote:
> > On Mon, Sep 01, 2014 at 10:59:51PM +0200, Reimar Döffinger wrote:
> > > On Mon, Sep 01, 2014 at 10:19:36PM +0200, Michael Niedermayer wrote:
> > > > On Mon, Sep 01, 2014 at 08:59:43PM +0200, Reimar Döffinger wrote:
> > > > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > > > ---
> > > > >  libavcodec/mpeg12.c    | 21 ++++++++++-----------
> > > > >  libavcodec/mpegvideo.c | 12 ++++++++----
> > > > >  libavcodec/rl.h        |  8 ++------
> > > > >  3 files changed, 20 insertions(+), 21 deletions(-)
> > > > 
> > > > assuming the amount is ok on the stack the patch LGTM
> > > 
> > > I reduced the mpeg12 to the 680 required - since that's a
> > > local function I think it's unnecessary to be conservative there.
> > > For the other one...
> > > Well, HP-UX seems to use 16 kB stack. I guess that we'd have
> > > problems there (probably even without the patch). But I
> > > don't think we'll have any volunteers to test and fix FFmpeg
> > > on that (I doubt anyone would use HP-UX voluntarily at all..).
> > > Next closest is OpenBSD with 64 kB (though maybe that is outdated
> > > information?).
> > > We'll be testing that, but of course that is small enough that
> > > it can easily fail if the calling application already used up quite
> > > a bit of it (and the ff_init_vlc_sparse uses up another 3 kB).
> > > On the other hand, ffv1enc uses a lot more than that:
> > > uint8_t best_state[256][256];
> > > (I suspect that should probably be fixed > 64 kB I'd surely consider
> > > unreasonable, and it will definitely crash on older OpenBSD at least).
> > 
> > Btw. should we maybe set up a fate test with ulimit -s 64 (or so -
> > higher might be ok as well)?
> 
> this sounds like a great idea
> i could easily do it but my boxes already run quite a few fate clients
> so i wont add a new one for that
> but if noone else sets up a seperate one for that then someone ping me
> and ill add it to a random existing one

I also have 30+ FATE instance on the same machine, including very slow and
consuming runs (multiple valgrind memcheck/helgrind/drd, tsan, ...) so I'd
prefer not to add this one either, sorry.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140902/d1371bd2/attachment.asc>