> > +#include "compat/w32dlfcn.h"
> This adds a dependency on nonpublic headers - which I think can be
> tolerated as it's only a build-time issue, and fftools are currently built
> as part of the rest of the ffmpeg build anyway.
Currently the header consist entirely of static inline functions and macros.
If it's not OK to use it here, please suggest a better place for
get_module_filename().
> > const char *base[3] = { getenv("FFMPEG_DATADIR"),
> > getenv("HOME"),
>
> Hmm, I guess neither of these are commonly set on Windows - otherwise this
> would suddenly change to interpret generic environment variables as UTF8.
>
> ...
>
> As mentioned elsewhere, I realized that av_fopen_utf8 is problematic, but
> that's an orthogonal issue, and the issue is already preexisting, and it's
> used for a fairly marginal feature here, so I guess that can be tolerated
> too (and if the root cause is fixed, this gets taken care of at the same
> time too).
Reverted back to fopen().
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
