These functions return void*, which is compatible with any pointer,
so there is no need for casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30744 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids clashes with fcntl.h under certain circumstances.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30680 b3059339-0415-0410-9bf9-f77b7e298cf2
libmpcodecs/vd_dmo.c:81: warning: implicit declaration of function 'memalign'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30678 b3059339-0415-0410-9bf9-f77b7e298cf2
least vo_xv and vo_sdl can not handle it and the scale filter seems
to work fine either way.
The FFmpeg vp3/Theora decoder produces such slices.
Fixes bug #1646.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30630 b3059339-0415-0410-9bf9-f77b7e298cf2
The functions are required to load binary XAnim codecs, so they need to be kept.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30607 b3059339-0415-0410-9bf9-f77b7e298cf2
The functions are required to load binary Real codecs, so they need to be kept.
Group all functions together in ad_realaud.c because all the functions are used
to load audio binaries and only some to load video binaries.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30606 b3059339-0415-0410-9bf9-f77b7e298cf2
This ensures that function declarations in both files always match.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30596 b3059339-0415-0410-9bf9-f77b7e298cf2
This is the appropriate place for the declaration; the variable is
declared in libmpcodecs/vd.c.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30579 b3059339-0415-0410-9bf9-f77b7e298cf2
not set, even if it is not very relevant currently.
Based on patch by John Lindgren [john lindgren tds net]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30485 b3059339-0415-0410-9bf9-f77b7e298cf2
The input bitrate isn't needed for anything in normal playback, so
there is no reason to print a warning message for practically all
files using the decoder.
AC3 is still broken due to the libavcodec parser being broken.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30421 b3059339-0415-0410-9bf9-f77b7e298cf2
scattered all over the place with half of it forgotten in some places.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30420 b3059339-0415-0410-9bf9-f77b7e298cf2
Also always try keeping input and output format the same first.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30409 b3059339-0415-0410-9bf9-f77b7e298cf2
difficult while the speed advantage in normal use cases is not measurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30408 b3059339-0415-0410-9bf9-f77b7e298cf2
the code (crash if malloc(0) != NULL, otherwise wrong qscales used for B-frames).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30405 b3059339-0415-0410-9bf9-f77b7e298cf2
Makes sure it will not be around if we e.g. try again with a different codec,
which can lead to -vo null being excessively slow.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30391 b3059339-0415-0410-9bf9-f77b7e298cf2
The get_format() function was defined under
#if CONFIG_XVMC || CONFIG_VDPAU
but recent commit ca217f4557 added an
unconditional reference to it, causing linking to fail with an
undefined reference if neither feature was enabled. Fix by removing
the #if, there's no reason reason why it would be needed.
Move two messages printed when using VDPAU/XvMC to MSGL_V level:
"[VD_FFMPEG] XVMC-accelerated MPEG-2.\n"
"[VD_FFMPEG] Trying pixfmt=%d.\n"
The first is redundant because this info is normally visible from the
decoder name, and it was also incorrectly printed in the VDPAU case
too. Add a different MSGL_V message for VDPAU.
Also make all these messages not translatable.
MPlayer's slice and direct rendering related callbacks are not safe to
call from other threads, so disable those features if more than one
decoding thread is specified. This should fix some issues when using
threaded decoding with formats other than h264 (in the h264 case the
callbacks were already disabled for other reasons).
This commit moves most of the code that sets special avctx parameters
for VDPAU and XvMC. Before that was done after avcodec_open() based on
the selected output image format; now it's done before avcodec_open()
based on the capabilities of the selected decoder. At least the code
selecting the thread count must be before avcodec_open(), and I think
there is no reason to try to keep the previous structure otherwise
either. The image format-based approach was implemented by Reimar
with the intended goal of eventually selecting between software and
VDPAU decoders under one FFmpeg decoder type. I consider that goal to
be questionable, and the approach certainly made the existing code
significantly messier for no functionality benefit.
not be used without a declaration, causing issues on 64 bit systems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30355 b3059339-0415-0410-9bf9-f77b7e298cf2
When using libass with a VO that has direct EOSD support the vf_ass
video filter is unnecessary and is not added automatically, but the
code that adds the filter when it is needed produced misleading output
messages in this case. The following two messages were printed at
MSGL_ERR level, making it look like an error condition:
Couldn't open video filter 'ass'.
ASS: cannot add video filter
Add a version of vf_open_plugin() called vf_open_plugin_noerr() that
does not itself print an error message if opening a vf fails and that
returns the exact status code returned by the vf open() function. Make
vf_ass return a different status code depending on whether there was
an actual error or if it determined a filter would be redundant. Use
the _noerr function in the code adding the filter to avoid the first
message and check the status code to avoid the second.
a parser, not when just needs_parsing is set.
Fixes playback of e.g. ADPCM in AVI like http://samples.mplayerhq.hu/avi/imaadpcm.avi
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30314 b3059339-0415-0410-9bf9-f77b7e298cf2
though that is already done that way for dts support in hwac3.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30280 b3059339-0415-0410-9bf9-f77b7e298cf2
order.
While the 16-bit yuv formats should not be preferred over the 8-bit ones,
it seems reasonable to probe them directly after the equivalent 8-bit formats.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30155 b3059339-0415-0410-9bf9-f77b7e298cf2
The code in vf.c and mp_image.c is almost the same, though the one in vf.c
is more up-to-date/has more bug fixes and thus is used as the basis
(which is why the diff is so big).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30154 b3059339-0415-0410-9bf9-f77b7e298cf2
A couple of months ago MPlayer's ALSA driver started rounding the
amount of input data it was willing to accept in one call down to an
integer multiple of the value it set in ao_data.outburst. In some
configurations it was possible for this value to exceed the 64 KiB
limit on the amount MPlayer was willing to write in a single call to
the AO. As a result ao_alsa accepted 0 bytes in each play() call and
audio playback failed. Fix this by removing the fixed 64 KiB limit on
the amount of audio sent to AO at once; the limit was mostly a remnant
of older code anyway.
Revert 3 old code uglification changes that were done with the excuse
of gcc-2.95 support. The last reverted change was a fix to a bug
introduced in the middle change.
Revert "10l, len may change after initialization time"
This reverts commit ae9db277c7.
Revert "fix declaration after statement, take 2"
This reverts commit 4bceedee93.
Revert "fix declaration after statement"
This reverts commit aef0374c1c.
via libavcodec.
Parsing can be done at the demuxer stage (currently disabled) or at the decoder
(ad_ffmpeg, enabled).
Should allow using the libavcodec AAC, DTS, ... decoders independent of container
format.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30130 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes playback and a memory leak for FFmpeg codecs which use reget_buffer
with paletted data, e.g. cdgraphics.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30116 b3059339-0415-0410-9bf9-f77b7e298cf2
Move vf_uspp from the list of filters depending on internal non-API
FFmpeg code to the list of filters only depending on libavcodec
normally - at least it doesn't need any internal headers, and I don't
see other obvious unsafe non-API usage either.
Change a leftover CONFIG_LIBAVCODEC_A test to the now correct
CONFIG_LIBAVCODEC_INTERNALS to actually allow using the video filters
requiring non-API libavcodec internals when --ffmpeg-source-dir was
specified.
Change the vo_control(vo, VOCTRL_RESET, NULL) call done when the vf_vo
filter is uninited to vo_seek_reset(vo). The latter also sets
vo->frame_loaded to false.
Remove the vo->config_ok check from vo_seek_reset(). The reset call
should be doable even if config failed.
the args argument to open will always be NULL and vf->priv will always be
!= NULL.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29945 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a mode where libavcodec's reordered_opaque feature is used to
associate container packet timestamps with decoded frames. This should
improve behavior at least for MPEG files with interlaced h264; the
previous code does not cope well with the libavformat demuxer
producing two field packets with separate timestamps but the
libavcodec h264 decoder only producing a single output frame for those
two packets (so half the timestamps have no associated output frame).
The current libavformat mpeg demuxer seems to finally work with
interlaced h264 files and produce valid timestamps which are useful
with a mode like this.
By default MPlayer now selects between this new mode and the old one
automatically based on the number of timestamp problems they cause; by
default the new mode is used if both seem to work. The new option
-pts-association-mode can be used to force a particular mode. If
correct-pts mode is disabled this has no effect on timing.
Also remove the "EXPERIMENTAL" marker from the manpage description of
-correct-pts.
Add a property to select YUV colorspace. Currently implemented only in
vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and
SMPTE-240M (vdpau only).
The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA
card supports that; I don't know whether other xv implementations do.
Bind the colorspace switch to the 'c' key by default. 'c' is currently
used by vo_sdl for some fullscreen mode change thing, but at the moment
that does not conflict and if it will in the future then vo_sdl can
change.
VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
Patch by Francesco Lavra [francescolavra interfree it] with modifications by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29875 b3059339-0415-0410-9bf9-f77b7e298cf2
Where 8 channel support is non-trivial (e.g. ao_dsound), at least ensure we
fail gracefully.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29868 b3059339-0415-0410-9bf9-f77b7e298cf2
DVB teletext support is nearly finished, it will be possible to read
teletext from file, it will not be depending on reception any more.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29851 b3059339-0415-0410-9bf9-f77b7e298cf2
will crash (happens e.g. when encoding ends before any frames were actually encoded,
e.g. when an MPEG file was cut down to much so it no longer contains a full video frame).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29835 b3059339-0415-0410-9bf9-f77b7e298cf2
Patch submitted by Nicolas George, nicolas.george normalesup org
The layout exceptions removed by this patch were rendered unnecessary by
changes in ffmpeg which normalize channel layout for aac (r20067) and vorbis
(r20148).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29821 b3059339-0415-0410-9bf9-f77b7e298cf2
Move av_log callback handling from vd_ffmpeg.c to a new file
av_log.c and install the callback immediately when starting the
program. Main functionality improvements of the new code:
- The old version only installed the callback when opening an FFmpeg
video decoder. If nothing had triggered that then av_log() messages
from other sources (libavformat, audio decoding, swscale usage)
bypassed MPlayer's output system completely. Now the callback is
always installed.
- Current av_log message severity levels are handled correctly. The
old code used MSGL_ERR for some messages that should be MSGL_V.
- Message type is now set for libavformat contexts
(MSGT_DEMUXER / MSGT_MUXER).
- The old code did "mp_msg_test(type, mp_level)" before actually
determining the type, so that it always used MSGT_FIXME. This led
to some messages being incorrectly dropped in case the user
had specified module-specific verbosity levels. The old check in
question was originally motivated by performance problems when
there were a lot of callbacks; however it's not clear whether the
part about it skipping the type determination was intentional (most
of the performance problems must have come from the way the
original code used snprintf) and in my tests current FFmpeg
libraries have not generated unreasonable amounts of callbacks
anyway.
TODO item.
Patch by Francesco Lavra, francescolavra interfree it
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29809 b3059339-0415-0410-9bf9-f77b7e298cf2
Original patch by Francesco Lavra, francescolavra interfree it
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29807 b3059339-0415-0410-9bf9-f77b7e298cf2
in comments.
Based on a patch by Francesco Lavra, francescolavra interfree it
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29802 b3059339-0415-0410-9bf9-f77b7e298cf2
As part of merging subtitle-in-terminal changes make
update_subtitles() only clear existing subtitles if called with the
reset argument, and not try to set new ones. Later calls should set
the needed new subtitles, and this change avoids some problems with
trying to set subtitles when mp_property_sub() in command.c gets
called from initialization code before full initialization.
currently requires that.
That probably is an unintended API change and should be fixed/reverted
in lavc but it hurts little to workaround here.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29709 b3059339-0415-0410-9bf9-f77b7e298cf2
* vdpau: (22 commits)
VO: Prefer vo_vdpau over vo_xv again
vo_vdpau: Fix X event handling bugs
vo_vdpau: Fix memory corruption bug with MP_IMGTYPE_NUMBERED
core/VO: Allow VO drivers to add/modify frames
video_out.h: Cosmetics
VO interface: Remove obsolete draw_frame() from new interface
vo_vdpau: Support recovering from VDPAU display preemption
vo_vdpau: Support updating OSD while paused
vo_vdpau.c: Reindent control() switch statement
vo_vdpau: Allocate one large surface for EOSD content
vo_vdpau.c: cosmetics
vo_vdpau: reindent after GUI code removal
vo_vpdau: Clean up uninit logic
vo_vdpau: Make CHECK_ST macro safer
vo_vdpau: Move all remaining static/global variables to context
vo_vdpau: Move things to context struct
vo_vdpau: Make info struct const
vo_vdpau: Replace global function table with context variable
vo_vdpau: Move VDPAU interface pointers into one struct
vo_vdpau: Add template file for VDPAU functions
...
The way vo_vdpau kept references to vf mpi objects was unsafe; with
fixed-vo enabled the vf object could be destroyed and a new one
created, but vo_vdpau would still keep the now stale references and
modify memory through them to adjust usage counts. Send a VOCTRL_RESET
from vf_vo uninit() to allow vo_vdpau to erase such references.
Add interfaces to allow VO drivers to add or remove frames from the
video stream and to alter timestamps. Currently this functionality
only works with in correct-pts mode. Use the new functionality in
vo_vdpau to properly support frame-adding deinterlace modes.
Frames added by the VDPAU deinterlacing code are now properly timed.
Before every second frame was always shown immediately (probably next
monitor refresh) after the previous one, even if you were watching
things in slow motion, and framestepping didn't stop at them at all.
When seeking the deinterlace algorithm is no longer fed a mix of
frames from old and new positions.
As a side effect of the changes a problem with resize events was also
fixed. Resizing calls video_to_output_surface() to render the frame at
the new resolution, but before this function also changed the list of
history frames, so resizing could give an image different from the
original one, and also corrupt next frames due to them seeing the
wrong history. Now the function has no such side effects. There are
more resize-related problems though that will be fixed in a later
commit.
The deint_mpi[] list of reserved frames is increased from 2 to 3
entries for reasons related to the above. Having 2 entries is enough
when you initially get a new frame in draw_image() because then you'll
have those two entries plus the new one for a total of 3 (the code
relied on the oldest mpi implicitly staying reserved for the duration
of the call even after usage count was decreased). However if you want
to be able to reproduce the rendering outside draw_image(), relying on
the explicitly reserved list only, then it needs to store 3 entries.
will be recalculated correctly e.g. after aspect change and -vf expand=aspect=4/3
command line.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29666 b3059339-0415-0410-9bf9-f77b7e298cf2
failing to init the decoder completely just because the first packet is broken.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29553 b3059339-0415-0410-9bf9-f77b7e298cf2
ffdca, ffflac, ffaac, fftruehd). In the process, adds support for 32-bit
samples.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29533 b3059339-0415-0410-9bf9-f77b7e298cf2
written on FLUSH_FRAMES, this is necessary since using multiple threads adds
an additional delay beyond the B-frame delay.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29480 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove code to support specifying arguments in hex form. This code
depended on libpostproc internals, and has been deprecated and
undocumented for years.
The following are affected: vo_yuv4mpeg, vf_halfpack, vf_palette,
vf_rgb2bgr, vf_yuy2, vo_mga, vo_xmga. In vo_yuv4mpeg, only disable
RGB support (which is probably little used). Others are disabled
completely for now.
vo_mga and vo_xmga are disabled by preventing configure from enabling
them. The rest is placed under LIBSWSCALE_INTERNALS variable which
isn't currently enabled anywhere.
These includes were added earlier after the definition of the
DECLARE_ALIGNED and DECLARE_ASM_CONST macros were moved to this
header in FFmpeg. However now those macros are again in the public
mem.h header, and there is no need to include internal.h.
