[Ffmpeg-devel] [PATCH] mingw and temorary files

[Michael Niedermayer]

Hi

On Sat, Mar 25, 2006 at 12:21:22PM +0000, M?ns Rullg?rd wrote:
> Corey Hickey <bugfood-ml at fatooh.org> writes:
> 
> > Michael Niedermayer wrote:
> >> Hi
> >> On Fri, Mar 24, 2006 at 01:54:37PM -0800, Corey Hickey wrote:
> >>> It seems that mkstemp() doesn't exist on mingw, which makes mplayer
> >>> (and, presumably, ffmpeg) fail to compile when CONFIG_XVID is
> >>> defined. There's a workaround in xvidff.c but not in xvid_rc.c. The
> >>> attached patch makes a new function av_tempfile() that contains the
> >>> workaround.
> >>>
> >>> Also, the call to open() in the current mingw workaround doesn't
> >>> include O_CREAT, so I don't think it ever worked properly.
> >>>
> >>> This patch has been tested by a few people on the mplayer mailing
> >>> lists, so I'm reasonably sure it works right.
> >>>
> >>> -Corey
> >>
> >>> Index: avcodec.h
> >>> ===================================================================
> >>> RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/avcodec.h,v
> >>> retrieving revision 1.458
> >>> diff -u -r1.458 avcodec.h
> >>> --- avcodec.h	21 Mar 2006 17:27:46 -0000	1.458
> >>> +++ avcodec.h	23 Mar 2006 06:01:48 -0000
> >>> @@ -2598,6 +2598,8 @@
> >>>   extern unsigned int av_xiphlacing(unsigned char *s, unsigned int
> >>> v);
> >>>  +int av_tempfile(char *prefix, char **filename);
> >>> +
> >> avcodec.h is a public header, IMHO this isnt the correct spot for it
> >
> > I was wondering about that, but then I thought it could theoretically
> > be useful to a calling program. I don't know anything about such
> > stuff, though, so I definitely don't mind putting the prototype
> > somewhere else if you prefer. Which header file should I use? I don't
> > know where things like that go.
> 
> It certainly shouldn't go in avcodec.h, since it has nothing to do
> with codecs.  I'd say such things belong in libavutil and it's header
> files.

i disagree, libavutil should stay small, and this is a almost useless function
for the end user ...

[...]

-- 
Michael