The toolchain for this target is unmaintained since many years.
While it has been continuously build tested on fate, it hasn't
actually been tested at runtime since many, many years (and back
then, only a few codecs in libavcodec were tested).
So far, keeping support for it has been mostly effortless, but
the compiler does seem to have issues with dllimported data symbols,
ending up as internal compiler errors in some cases. Instead of
jumping through further hoops to work around that, just remove the
target.
Signed-off-by: Martin Storsjö <martin@martin.st>
Supporting the system was a nice joke for the 9 release, but it has
run its course. Nowadays Plan 9 receives no testing and has no
practical usefulness.
The MoveFileExA is available in the headers regardless which API
subset is targeted, but it is missing in the Windows Phone link
libraries. When targeting Windows Store apps, the function is
available both in the headers and in the link libraries, and thus
there is no indication for the build system that this function
should be avoided - such an indication is only given by the
Windows App Certification Kit, which forbids using the MoveFileExA
function.
Therefore check the WINAPI_FAMILY defines instead, to figure out
which API subset is targeted.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows getting the normal unix semantics, where a rename
allows replacing an existing file.
Based on a suggestion by Reimar Döffinger.
Signed-off-by: Martin Storsjö <martin@martin.st>
This doesn't add any dependency on library internals, since this
only is a static inline function that gets built into each of the
calling functions - this is only to reduce the code duplication.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that the internal utf8 path names are handled
properly - the normal file handling functions assume path names
are in the native codepage, which isn't utf8.
This assumes that the tools outside of lavf don't use the mkdir
definition. (The tools don't do the same reading of command line
parameters as wchar either - they probably won't handle all possible
unicode file parameters properly, but at least work more predictably
if no utf8/wchar conversion is involved.)
This is moved further down in os_support.h, since windows.h shouldn't
be included before winsock2.h, while io.h needs to be included before
the manual defines for lseek functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
When libavformat was changed to use the new avpriv_open function
in 51eb213d00, this silently bypassed the existing wrapper for
win32. Move the win32 wrapper into libavutil/file.c to make sure
it gets called everywhere (not just in the libavformat case).
This makes sure that non-ascii file names gets opened properly
(where file names internally are stored as utf8, but they get
converted to wchar_t and opened with _wsopen).
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds support for building on Plan 9 x86-32. The compat/plan9
directory contains these items:
- replacements for the 'head' and 'printf' shell commands
- wrapper for main() to disable FPU exceptions
Larger required changes to the system are described in the
documentation.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Windows CE doesn't have neither mkdir nor _mkdir officially (only
CreateDirectoryW), but mingw32ce has compat wrappers with these names
(declared in io.h since direct.h is unavailable).
Signed-off-by: Martin Storsjö <martin@martin.st>
This muxer splits the output from the ismv muxer into individual
files, in realtime.
The same can also be done by the standalone tool ismindex, but this
muxer is needed for doing it in realtime (especially for live
streams that need extra handling for updating the lookahead fields
in the fragment headers).
Using this muxer, one can deliver live smooth streaming from a
normal static file web server. (Using ismindex, one can deliver
premade smooth streaming files from a static file web server,
or prepare files for serving with IIS.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Mingw headers provide similar defines already (unconditional #defines,
without any #undef or #ifdef around it), while MSVC doesn't have
them.
Signed-off-by: Martin Storsjö <martin@martin.st>
The fallback function is a non-static function, we shouldn't be
defining non-static functions outside of the proper ff/av prefix
namespaces.
This is especially important for a function like poll, which
other parties (other libraries, or executables linking these
libraries) also might provide similar but incompatible fallbacks for.
Signed-off-by: Martin Storsjö <martin@martin.st>
We need to include winsock2.h here, to make sure we have the
real pollfd struct definition, if one exists, before defining the
fallback poll function.
Signed-off-by: Martin Storsjö <martin@martin.st>
tcp_shutdown() isn't needed at the moment, but is added for
consistency to explain how the function is supposed to be used.
Signed-off-by: Martin Storsjö <martin@martin.st>
All file names should be in UTF-8 within libavformat.
This is handled by mapping the open() function to an internal one
in os_support.h for windows.
fopen() could be overridden in the same way, but if that would be
used from ffmpeg.c, it would add a dependency on an ff prefixed
internal lavf function.
Signed-off-by: Martin Storsjö <martin@martin.st>
poll() is only used by networking code, so the fallback should
only be built if networking is enabled. Also remove CONFIG_FFSERVER
condition from the declarations.
This should fix building on systems without poll(), broken
by a8475bbdb6.
Signed-off-by: Mans Rullgard <mans@mansr.com>
for broken OSes. This is included in rtsp.h, as opposed to os_support.h.
Should fix OS/2 broken build on fate.
Originally committed as revision 25035 to svn://svn.ffmpeg.org/ffmpeg/trunk
message, if available (RFC 2326, section 12.39), fixes issue 2212.
Patch by John Wimer <john at god vtic net>.
Originally committed as revision 25032 to svn://svn.ffmpeg.org/ffmpeg/trunk
BeOS support has been broken for many years and the "maintainer" of the port
has not reacted to countless requests to get the port fixed.
approved by Mans
Originally committed as revision 23562 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes compilation on WinCE, which does not support _lseeki64.
patch by Ismail Dönmez, ismail namtrac org
Originally committed as revision 19425 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.' to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".
Originally committed as revision 15120 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
Add missing header #includes.
Policy violation (change not approved by maintainer)
and while discussions where ongoing and no consensus has been reached.
Originally committed as revision 14500 to svn://svn.ffmpeg.org/ffmpeg/trunk
os_support.h used to be included in all lavf files, and including windows.h
here caused a significant slowdown.
Originally committed as revision 12377 to svn://svn.ffmpeg.org/ffmpeg/trunk
Windows x64 has no __stdcall.
It is not yet supported, but someday it might...
Originally committed as revision 12363 to svn://svn.ffmpeg.org/ffmpeg/trunk
Martin Storsjö
Diego Biurrun
Hendrik Leppkes
Mans Rullgard
Ronald S. Bultje
Dave Yeo
Samuel Pitoiset
Kirill Gavrilov
John Wimer
kemuri
Ramiro Polla
İsmail Dönmez
Aurelien Jacobs
Stefano Sabatini
Michael Niedermayer
Luca Abeni
Dave Yeo
Michael Kostylev