| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused failures when doing single threaded decoding in some cases.
It's unknown what exactly the reasons are for these failures, but
direct rendering is probably worthless anyway.
Disable slices by default as well, just to be sure not to invoke broken
code paths. Multithreading disables these too.
The old behavior can be restored by passing the -dr1 -slices command
line options. (-dr1 is left undocumented intentionally.)
Multithreaded decoding worked fine, because vd_ffmpeg.c automatically
disables direct rendering in this case.
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
DOCS/man/en/options.rst
|
| | |
| |
| |
| |
| |
| | |
Note that this also adds a RGB colorspace for general symmetry. The
frontend (colormatrix property and options) and
mp_get_yuv2rgb_coeffs() don't support this.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mplayer (and all forks) use a single FourCC field to map codecs. This is
what sh_video->format and sh_audio->format is used for. Basically it's a
key into the codecs.conf table to find out what decoder to use. (There's
only one video codec and one major audio codec left - both libavcodec.
But we still have to deal with mapping coming from non-libavformat
demuxers.)
It seems this causes some video codecs to fail, such as WV1F in AVI [1].
demux_lavf generally throws away the codec_tag from libavformat if the
codec is MPEG-in-AVI. There are probably other cases like this. Add a
hack to enforce passing the correct codec tag when only ffmpeg demuxers
and decoders involved.
Note: the sample [1] needs to be flipped. With --demuxer=avi, this is
done correctly, because unlike demux_lavf, the demuxer uses the FourCC
directly for the sh_video->format tag, and finds the correct codecs.conf
entry (which contains the flip flag). We could just add a "whitelist" of
codec tags which can be passed through to sh_video->format, but I don't
want to do that just for such an obscure format as the sample at hand.
Note 2: when demux_lavf is used, the AVCodecContext could be passed
directly to vd_ffmpeg/ad_ffmpeg. The code to convert to/from the
internal mplayer stream headers is probably still needed, as there are
non-ffmpeg demuxers and audio decoders.
[1] http://samples.mplayerhq.hu/V-codecs/WV1F/AVI/title2.avi
|
| |/
|
|
|
|
| |
Detect broken mpi usage count also in decoder.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35134 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes for palette allocation handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34304 b3059339-0415-0410-9bf9-f77b7e298cf2
This caused a crash with http://samples.ffmpeg.org/cdxl/fruit.cdxl if
direct rendering was used. (Which is rarely these days.)
With small changes: avoid av_freep() use, as this function is not sane.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was needed by the now-removed mov demuxer for QuickTime video, or
to be more specific, the Sorenson 3 video codec. QuickTime can
(probably) still decoded by libavcodec, but this field is not needed
for this.
The reference in demux_mkv was apparently for decoding QuickTime in
Matroska, using binary QuickTime codecs (QTX stuff). It's possible that
this has been broken with the binary codecs removal (see commit
aebfbbf2bdd), because it removed related code from demux_mkv. On the
other hand, the code section in question was enabled only if binary
win32 codecs were enabled. The win32 codec loader worked on 32 bit x86
only. This means QuickTime-in-Matroska was broken on all other
architectures, including 64 bit x86. Despite being possibly broken on a
major platform, nobody has complained about it yet, and since I couldn't
find a sample of such a mkv file, so don't bother with it.
|
| |
|
|
|
| |
Remove remaining references to XvMC. It was already not supported;
remove references to the imgfmt too. Reformat img_format.c.
|
| |
|
|
|
|
| |
If either of them is not defined, the old behavior is used:
- the colormatrix is guessed based on resolution.
- the color range is assumed to be tv aka limited range.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change vd_ffmpeg such that if sh_video->format is a mplayer pixel
format, and there's no other codec information, try to play it as raw
video. (The case of no codec information happens if the "generic" ffmpeg
decoder is instantiated, which is tried last. This means clashes with
actual existing formats are less likely.)
demux_mng did not initialize all fields of the bih, which made vd_ffmpeg
do invalid memory accesses when trying to copy the extradata. Also, use
IMGFMT_RGB32 instead of creating the FourCC directly. (They should be
the same, but what if mplayer changes the IMGFMT_* values.)
This also fixes demux_rawvideo.
|
| |
|
|
|
| |
This seems to be more portable. Should fix compilation on OSX and
FreeBSD. Apparently also works on MinGW-w64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mplayer had three ways of enabling CPU specific assembler routines:
a) Enable them at compile time; crash if the CPU can't handle it.
b) Enable them at compile time, but let the configure script detect
your CPU. Your binary will only crash if you try to run it on a
different system that has less features than yours.
This was the default, I think.
c) Runtime detection.
The implementation of b) and c) suck. a) is not really feasible (it
sucks for users). Remove all code related to this, and use libav's CPU
detection instead. Now the configure script will always enable CPU
specific features, and disable them at runtime if libav reports them
not as available.
One implication is that now the compiler is always expected to handle
SSE (etc.) inline assembly at runtime, unless it's explicitly disabled.
Only checks for x86 CPU specific features are kept, the rest is either
unused or barely used.
Get rid of all the dump -mpcu, -march etc. flags. Trust the compiler
to select decent settings.
Get rid of support for the following operating systems:
- BSD/OS (some ancient BSD fork)
- QNX (don't care)
- BeOS (dead, Haiku support is still welcome)
- AIX (don't care)
- HP-UX (don't care)
- OS/2 (dead, actual support has been removed a while ago)
Remove the configure code for detecting the endianness. Instead, use
the standard header <endian.h>, which can be used if _GNU_SOURCE or
_BSD_SOURCE is defined. (Maybe these changes should have been in a
separate commit.)
Since this is a quite violent code removal orgy, and I'm testing only
on x86 32 bit Linux, expect regressions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was some confusion about the "flags" field in demuxer packets.
Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the
field was not used to indicate anything else). This didn't cause
visible problems because nothing read the value. Replace the "flags"
field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on
this field in packets fed to libavcodec video decoders (looks like PNG
and ZeroCodec are the only ones which depend on values from demuxer;
previously this was hardcoded to true for PNG).
Make demux_mf set the keyframe field in every packet. This matters for
PNG files now that the demuxer flag is forwarded to libavcodec.
Fix logic setting the field in demux_mkv. It had probably not been
updated when adding SimpleBlock support. This probably makes no
difference for any current practical use.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for using libavcodec decoders that do not have entries in
codecs.conf. This is currently only used with demux_lavf, and the
codec selection is based on codec_id returned by libavformat. Also
modify codec-related terminal output somewhat to make it use
information from libavcodec and avoid excessively long default output.
The new any-lavc-codec support is implemented with codecs.conf entries
that invoke vd_ffmpeg/ad_ffmpeg without directly specifying any
libavcodec codec name. In this mode, the decoders now instead select
the libavcodec codec based on codec_id previously set by demux_lavf
(if any). These new "generic" codecs.conf entries specify "status
buggy", so that they're tried after any specific entries with
higher-priority status.
Add new directive "anyinput" to codecs.conf syntax. This means the
entry will always match regardless of fourcc. This is used for the
above new codecs.conf entries (so the driver always gets to decide
whether to accept the input, and will fail init() if it can't find a
suitable codec in libavcodec). Remove parsing support for the obsolete
codecs.conf directive "cpuflags". This directive has not had any
effect and has not been used in default codecs.conf since many years
ago.
Shorten codec-related terminal output. When using libavcodec decoders,
show the libavcodec long_name field rather than codecs.conf "info"
field as the name of the codec. Stop showing the codecs.conf entry
name and "vfm/afm" name by default, as these are rarely needed;
they're now in verbose output only. Show "VIDEO:" line at VO
initialization rather than at demuxer open. This didn't really belong
in demuxer code; the new location may show more accurate values (known
after decoder has been opened) and works right if video track is
changed after initial demuxer open.
The vd.c changes (primarily done for terminal output changes) remove
round-to-even behavior from code setting dimensions based on aspect
ratio. I hope nothing depended on this; at least the even values were
not consistently guaranteed anyway, as the rounding code did not run
if the video file did not specify a nonzero aspect value.
|
| |
|
|
|
|
|
|
|
| |
The vd_ffmpeg decode() function returned without doing anything if the
input packet had size 0. This meant that flushing buffered frames at
EOF did not work. Remove this test. Have the core code skip such
packets coming from the file being played instead (Libav treats
0-sized packets as flush signals anyway, so better assume such packets
do not represent real frames with any codec).
|
| |
|
|
|
|
|
|
|
| |
Libav has changed back to not modifying avctx->has_b_frames based on
the extra buffering caused by thread use. Add back the code to do the
adjustment on the player side once again.
The timing mode using the buffering info is no longer the default, so
in most cases having this right or not won't matter for playback.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove the private bswap and intreadwrite.h implementations and use
libavutil headers instead.
Originally these headers weren't publicly installed by libavutil at
all. That already changed in 2010, but the pure C bswap version in
installed headers was very inefficient. That was recently (2011-12)
improved and now using the public bswap version probably shouldn't
cause noticeable performance problems, at least if using a new enough
compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change various code to use the latest Libav API. The libavcodec
error_recognition setting has been removed and replaced with different
semantics. I removed the "--lavdopts=er=<value>" option accordingly,
as I don't think it's widely enough used to be worth attempting to
emulate the old option semantics using the new API. A new option with
the new semantics can be added later if needed.
Libav dropped APIs that were necessary with all Libav versions
until quite recently (like setting avctx->age), and it would thus not
be possible to keep compatibility with previous Libav versions without
adding workarounds. The new APIs also had some bugs/limitations in the
recent Libav release 0.8, and it would not work fully (at least some
avcodec options would not be set correctly). Because of those issues,
this commit makes no attempt to maintain compatibility with anything
but the latest Libav git head. Hopefully the required fixes and
improvements will be included in a following Libav point release.
|
| |
|
|
|
|
|
|
|
|
|
| |
Libav started automatically enabling threaded decoding a while ago.
This is not safe, as it means callbacks can suddenly get called from
other threads and outside calls to libavcodec. We need to know when
threading will be used and disable thread-unsafe callbacks in those
cases. Explicitly set thread count to 1 instead of leaving it at 0
(which triggers the autodetection) when we are not requesting more
threads; this should make sure that autodetection on libavcodec side
will not be used.
|
| |
|
|
|
|
|
|
| |
Update various code using Libav libraries to remove use of API
features that were deprecated at Libav release 0.7. I think this
removes them all with the exception of URLContext functions still used
in stream_ffmpeg.c (at least other uses that generated deprecation
warnings with libraries from 0.7 are removed).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Require versions of the Libav libraries corresponding to Libav release
0.7. These are:
libavutil 51.7.0
libavcodec 53.5.0
libavformat 53.2.0
libswscale 2.0.0
libpostproc 52.0.0
Also disable the fallback to simple header check if these libraries
could not be found with pkg-config; now compiling without pkg-config
support for these always requires explicitly setting --enable-libav
and any needed compiler/linker flags. The simple check would have let
compilation proceed even if a version mismatch was detected.
|
| |
|
|
|
|
|
|
|
| |
The implementation of the switch_ratio command was hacky and called
mpcodecs_config_vo() to reconfigure the filter/VO chain from under an
existing decoder. This call no longer worked properly with vd_ffmpeg
after that started using mpcodec_config_vo2(). Add new video decoder
control command VDCTRL_RESET_ASPECT and use this to tell vd_ffmpeg to
reinitialize the output chain properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When not using direct rendering, vd_ffmpeg created an mp_image struct
before calling libavcodec decoder, so that possible slice support
could be checked from the mpi_image and output would be ready for
slice-drawing calls. However, this behavior is unsound with decoders
that can change output size, as the parameters can change after the
mp_image was created. Disable the code creating the mp_image at that
point, which also disables use of slices in this case. Slices are
disabled with threading anyway, so I think trying to add workarounds
to support them is not a high priority.
I think this code has always been buggy, but before common thread use
it was rarely executed because the direct-rendering case was used
instead.
|
| |
|
|
| |
Libavcodec has ignored the caller-set sub_id value since 2006.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Pass the libavformat packet side_data field from demux_lavf to
vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and
passing it is required for the playback of some paletted video codecs.
The implementation works by giving vd_ffmpeg a copy of the struct
demux_packet used to store the video packet (from which it can access
the avpacket field). The definition of struct demux_packet is moved to
new file demux_packet.h so that vd_ffmpeg.c can use it without
including all of demuxer.h.
|
| |
|
|
|
|
|
| |
Do the global initialization of libavcodec and libavformat
(avcodec_register_all(), av_register_all()) immediately on program
startup and remove the initialization calls from various individual
modules that use libavcodec/libavformat functionality.
|
| |
|
|
|
|
|
|
| |
Remove the copy of the "lowres" field that vd_ffmpeg kept in its
private struct and use the value from AVCodecContext directly instead.
The copy gave no benefit and it could be set to the wrong value if
someone used "-lavdopts o=lowres=X" (which would change the real value
but not the copy).
|
| |
|
|
|
|
|
| |
Support for -lavdopts skipframe had been broken since commit bc767c2a9
as framedrop logic now set the same field and thus overwrote the value
set from the option. Change that code to set it to the original value
instead of 0 when not dropping frames.
|
| |
|
|
|
| |
Drop from frequent (per-frame) messages from DBG2 to DBG3. Drop VDPAU
clock adjustment messages from V to DBG2.
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix segfault with -lavdopts vstats and some codecs.
The vstats option relies on avctx->coded_frame being filled.
Unfortunately not all codecs do that (e.g. VP8) thus causing
NULL dereference.
FFmpeg code seems to always check if coded_frame != NULL,
so we should do the same.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33347 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Selecting the colorspace to output from a decoder is done in the
function mpcodecs_config_vo(). Add a new version of this function,
mpcodecs_config_vo2(), that allows the decoder to specify a list of
candidate colorspaces instead of always using a hardcoded list
specified in the codecs.conf entry. If the codecs.conf entry has any
"out" lines then those still take priority and the decoder-provided
list (if any) is ignored. Make vd_ffmpeg provide a list of the
colorspaces it's willing to output. Remove "out" lines from most
entries for libavcodec video decoders in codecs.conf, so that the
automatic values are now used instead.
|
| |
|
|
|
|
|
|
|
| |
Due to libavcodec changes vo_xvmc would have needed some modifications
to keep working. However, I think there's little real demand for XvMC,
so I'll just drop XvMC support. XvMC only supported MPEG-2, making it
of very limited usefulness nowadays, plus the vo_xvmc implementation
was not high quality and never worked particularly well or reliably
anyway.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Allow DR to work with reget_buffer when no buffer_hints are set.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33287 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| | |
| |
| |
| |
| |
| | |
Allow reget_buffer to somewhat work after direct rendering failure.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33286 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| | |
| |
| |
| |
| |
| |
| | |
Change MP_IMGFLAG_ACCEPT_STRIDE to MP_IMGFLAG_ACCEPT_ALIGNED_STRIDE in
get_buffer() as various FFmpeg assembly routines assume aligned input.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33097 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |/
|
|
|
|
|
|
|
|
|
| |
Update various code to use newer alternatives instead of deprecated
functions/fields that are being dropped at libav API bump. An
exception is avcodec_thread_init() which is being dropped even though
it's still _necessary_ with fairly recent libav versions, so there's
no good alternative which would work with both those recent versions
and latest libavcodec. I think there are grounds to consider the drop
premature and revert it for now; if that doesn't happen I'll add a
version-test #if check around it later.
|
| |
|
|
|
|
|
|
| |
Recent ffmpeg-mt versions changed the API for setting the number of
decoding threads to use (I'm not sure whether dropping backwards
compatibility was intentional or not). As a result only one thread was
used. Make the thread setting compatible with the new API to restore
proper multithreaded decoding.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
af_lavcac3enc: use old SampleFormat names without AV_ prefix, the
latter were only added in 2010-11
vd_ffmpeg: add ifdef around CODEC_ID_LAGARITH use
demux_real: use ffmpeg_files/intreadwrite.h
stream/http.c, stream/realrtsp/real.c: define AV_BASE64_SIZE macro for
old libavutil versions lacking it
|
| |
|
|
| |
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32773 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
|
|
|
| |
Make "-lavdopts threads=0" mean an autodetected number of threads, and
make that the default value of the option. Also increase the upper
limit of the option from 8 to 16. Add new file osdep/numcores.c which
tries to determine the number of cores available on the machine.
numcores.c is based (heavily modified) on public domain numcpus.c by
Philip Willoughby <pgw99@doc.ic.ac.uk>, downloaded from
http://csgsoft.doc.ic.ac.uk/numcpus/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change direct rendering buffer allocation code to treat non-ref frames
like B-frames even if has_b_frames is not set and they are indeed not
B-frames (no reordering). Treating it as an I/P frame would violate
the assumptions of MPlayer |
