Ive checked this on black and white background and found no problem in terms
of readability.
flames welcome.
Originally committed as revision 22946 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 allows applications/libraries which require that symbol
(e.g. libavfilter) to be compiled without to depend on the presence of
libavcodec/avcodec.h, which may not be installed.
Originally committed as revision 22736 to svn://svn.ffmpeg.org/ffmpeg/trunk
major bump, using an FFmpeg specific error code rather than EINVAL,
which has a quite different semantics.
Originally committed as revision 22601 to svn://svn.ffmpeg.org/ffmpeg/trunk
major bump, using an FFmpeg specific error code rather than EDOM,
which has a quite different semantics.
Originally committed as revision 22528 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVERROR(ENOMEM) must be used instead, and there are no occurrences of
AVERROR_ENOMEM in the FFmpeg basecode so it can be safely dropped.
Originally committed as revision 22514 to svn://svn.ffmpeg.org/ffmpeg/trunk
avctx->get_buffer() in case of error, rather than AVERROR_UNKNOWN
which is deprecated, and mark AVERROR_UNKNOWN for deletion at the next
major bump.
Originally committed as revision 22512 to svn://svn.ffmpeg.org/ffmpeg/trunk
libavutil/error.h.
Error code definitions and handling code belong to libavutil, where
they can be shared by all the libav* libraries.
See the thread:
Subject: [FFmpeg-devel] [PATCH] Move error codes definitions from lavc to lavu
Date: Sun, 19 Jul 2009 12:09:16 +0200
Originally committed as revision 22501 to svn://svn.ffmpeg.org/ffmpeg/trunk
This reduces the number of false dependencies on header files and
speeds up compilation.
Originally committed as revision 22407 to svn://svn.ffmpeg.org/ffmpeg/trunk
ffmpeg.c uses lrintf(), which is missing on some systems. Previously
it picked up the replacement via libavutil/internal.h due to
HAVE_AV_CONFIG_H being erroneously defined.
Moving these replacements to a separate header enables ffmpeg.c to
use them without being exposed to internal interfaces.
This use of a non-public header is justified by the header in question
not being part of the internal interface either. It should rather be
considered as part of the build system, which is shared between the
libraries and the applications.
This header cannot be installed since the tested conditions depend on
the compiler.
Originally committed as revision 22399 to svn://svn.ffmpeg.org/ffmpeg/trunk
This is a bit hackish. I will try to think of something nicer, but
this will do for now.
Originally committed as revision 22366 to svn://svn.ffmpeg.org/ffmpeg/trunk
Some of the per-arch headers are only meant to be used through
the parent header of the same name. Testing these standalone
does not make sense.
Originally committed as revision 22341 to svn://svn.ffmpeg.org/ffmpeg/trunk
These macros are redundant. All uses are replaced with the generic
DECLARE_ALIGNED macro instead.
Originally committed as revision 22233 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Janusz Krzysztofik jkrzyszt tis icnet pl
Original thread:
Subject: [FFmpeg-devel] [PATCH v2] Add initial support for 12-bit color mode.
Date: Mon, 1 Mar 2010 02:05:07 +0100
Originally committed as revision 22220 to svn://svn.ffmpeg.org/ffmpeg/trunk
consistent with the allocation currently done for PIX_FMT_GRAY8
pictures.
No significant slow-downs have been measured.
See the thread:
Subject: [FFmpeg-devel] [PATCH] Is gray8 a paletted format?
Date: Sun, 15 Nov 2009 23:36:03 +0100
Originally committed as revision 22191 to svn://svn.ffmpeg.org/ffmpeg/trunk
Michael Niedermayer
Ronald S. Bultje
Diego Biurrun
Andreas Öman
Alex Converse
Stefano Sabatini
Benoit Fouet
Måns Rullgård
Janusz Krzysztofik
Vitor Sessak