Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Andreas Rheinhardt	790f793844	avutil/common: Don't auto-include mem.h There are lots of files that don't need it: The number of object files that actually need it went down from 2011 to 884 here. Keep it for external users in order to not cause breakages. Also improve the other headers a bit while just at it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	9 months ago
softworkz	fee765c207	fftools/fopen_utf8: support long paths on Windows for fftools Signed-off-by: softworkz <softworkz@hotmail.com> Signed-off-by: Martin Storsjö <martin@martin.st>	3 years ago
Martin Storsjö	4cdc14aa95	libavutil: Deprecate av_fopen_utf8, provide an avpriv version Since every DLL can use an individual CRT on Windows, having an exported function that opens a FILE* won't work if that FILE* is going to be used from a different DLL (or from user application code). Internally within the libraries, the issue can be worked around by duplicating the function in all libraries (this already happened implicitly because the function resided in file_open.c) and renaming the function to ff_fopen_utf8 (so that it doesn't end up exported from the DLLs) and duplicating it in all libraries that use it. This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in the exact same way as the existing avpriv_open / ff_open, with the same setup as introduced in `e743e7ae6e`. That mechanism doesn't work for external users, thus deprecate the existing function. Signed-off-by: Martin Storsjö <martin@martin.st>	3 years ago
Martin Storsjö	3fb9244642	fftools: Stop using av_fopen_utf8 Provide a header based inline reimplementation of it. Using av_fopen_utf8 doesn't work outside of the libraries when built with MSVC as shared libraries (in the default configuration, where each DLL gets a separate statically linked CRT). Signed-off-by: Martin Storsjö <martin@martin.st>	3 years ago