Changing the lowres value is risky because the user application may have a
local copy and not read back into it, or not undo some lowres dependant things.
A patch implementing this in ffplay is already on ffmpeg-dev, so this feature
should be back soon.
This reverts commit 125ea3ee06.
This extends the lock manager in avcodec to manage two separate
mutexes via the user-specified lock functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This code was already added by Yuvi in c82cbea68273c6f08c4d0e94fc9fd50bfdea4e2b
It was subsequently lost somehow
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Replace our incomplete w32threads implementation with x264's pthreads
w32threads wrapper.
Relicensed to LGPL with kind permission by Pegasys Inc.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
There is no valid reason the user should ever send such packets in the
first place, but the documentation for CODEC_CAP_DELAY states that the
codec is guaranteed not to get a NULL packet unless that capability is
set. That isn't true without preventing this case.
The table is automatically generated from the definition of enum CodecID in
avcodec.h and contains the name of all known codecs, even those for which no
encoder nor decoder exists or is enabled.
The table is queried using the avcodec_get_name function.
If CONFIG_SMALL is true, the table is not compiled in; the avcodec_get_name
looks for names in the list of available decoders and encoders.
"SAR" (Sample Aspect Ratio) is globally preferred over "PAR" (Pixel
Aspect Ratio), although the two terms share the same semantics.
For example the corresponding AVStream field is called
sample_aspect_ratio, and libavfilter has a filter named setsar.
Therefore prefer the term "SAR" over "PAR" in the
libavformat/utils.c:dump_stream_format() and avcodec_string() output
for avoiding confusion.
The attached patch fixes the crash which happens when user passes lowres value lower than 0 to FFplay.
ffplay -lowres -1 test.mpg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The format is a per-frame property, having it in AVFrame simplify the
operation of extraction of that information, since avoids the need to
access the codec/stream context.
width and height are per-frame properties, setting these values in
AVFrame simplify the operation of extraction of that information,
since avoids the need to check the codec/stream context.