This prefers ./ on Windows if-and-only-if the file being searched for
already exists there. (If the mpv directory is non-writable, the result
is still intended behavior.) This change is transparent to most users
because the user has to move the config files there intentionally, and
if anything, not being detected would be the surprising behavior.
The sequence of avcodec_alloc_context3() / avcodec_copy_context() /
avcodec_close() / av_free() leaks some memory. So don't copy the context
and use it directly.
Originally avcodec_copy_context() was used to guarantee that libavformat
can't update the fields of the context during demuxing in order to make
things a little more robust, but it's not strictly needed, and
ffmpeg/ffplay don't do this anyway. Still might make the situation worse
should we move demuxing into a separate thread, though.
Using -demuxer mpegts -correct-pts triggered the assertion in
ds_get_packet2(). This is not surprising, because the correct-pts code
was changed to accept _complete_ packets, while all the old demuxers
(including the mpegts demuxer) require you to use "partial" packet
reads, together with the video_read_frame(). (That function actually
parses video frames, so fragments of the original "packets" can be fed
to the decoder.)
However, it returns out demux_ts packet's are mostly useable. demux_ts
still adds an offset (i.e. ds->buffer_pos != 0) to the packets when
calling internal parser functions, such as in parse_es.c. While this is
unclean design due to mplayer's old video demuxing/decoding path, it can
be easily be made work by modifying the packet as returned by
ds_get_packet2(). We also have to change the packet freeing code, as
demux_packet->buffer doesn't have to point to the start of the memory
allocation anymore.
MPlayer handles this "correctly" because it doesn't have a function that
reads a complete packet.
Nobody uses this, and this is an absolute waste of time. Even the user
who reported this turned out to have produced a sample manually.
Sample produced with:
wget http://diracvideo.org/download/test-streams/raw/vts/vts.LD-8Mb.drc
mkvmerge -o dirac.mkv vts.LD-8Mb.drc
mkvmerge writes a sort of broken aspect ratio. libavformat interprets it
as 1:1 PAR, while demux_mkv thinks this is a 1:1 DAR. Maybe libavformat
is more correct here.
libavcodec generally shouldn't have this problem anymore (if libavcodec
ever had it). All other video decoders are gone. In any case, if this
commit actually causes regressions, these are libavcodec bugs and should
be fixed there instead.
In the long run this should be done differently. ID_... output sucks.
This commit will be reverted as soon as I have a good idea how this
should be done properly.
Commit 02bbd87b disabled SDL linking by default. This commit followed
the ancient mplayer convention of disabling detection of compiler flags
with --enable-* switches. Unfortunately, this makes compiling with SDL
enabled a pain.
Make --enable-sdl/sdl2 use autodetection, even if it's inconsistent with
most other --enable-* switches. The same is already done for
--enable-openal, though.
Based on a pull request by qyot27.
The vf-toggle option parsing (normally used for runtime video filter
switching only) was missing comparing the parameter values. Fix this,
and also make the code a bit more robust.
Travis-CI [1] is a continous integration cloud service. It is free for
open-source projects and tigthly integrated tiwh GitHub so there is really
no reason for us not use it. :)
For now we are going to do a total of 4 builds, mainly to test ffmpeg/libav
API breakage:
* ffmpeg-stable, libass-stable
* ffmpeg-git, libass-stable
* libav-stable, libass-stable
* libav-git, libass-stable
The compiler that is currently used is clang for two reasons:
* running 8 build targets would be quite wasteful and take a long time
* clang is less tested and used during development than gcc (especially on
linux)
Currently Travis doesn't support OS X environments alongside Linux ones [2].
When it will, we will add a fifth build target to test OS X compilation
breakage.
README was moved to markdown to add the little build status image. I ran some
tests with my GitHub fork and couldn't get images to show up using ReStructured
Text.
[1]: https://github.com/travis-ci/travis-ci
[2]: travis-ci/travis-ci#216
mpv still builds with ffmpeg 1.0.x, however libswresample keeps cuasing
trouble. In older releases, libswresample simply crashed when
downmixing. In somewhat newer versions, it produces distorted output and
downmixing isn't even close to correct.
With ffmpeg release 1.1 (ffmpeg git tag n1.1), everything seems to work
fine. The release uses 0.17.102 as libswresample version, so bump the
required minimum version to that.
Also add a "raw" prefix for commands, which prevents property expansion.
The idea is that if the commands are generated by a program, it doesn't
have to know whether the command expands properties or not.
This is more consistent, and doesn't bother the user with ordering
rules when new prefixes are added.
Will break obscure uses of legacy commands: if the command is supposed
to be translated by the legacy command bridge, and if that command uses
one of the pausing* prefixes, the command can't be parsed. Well, just
use the new commands in this case.
This happens only if an option actually allocates memory (like strings).
Change filter API such that vf->priv is free'd by vf.c instead by the
filters. vf.c will free the option values as well.
Add the "vf" command, which allows changing the video filter chain at
runtime. For example, the 'y' key could be bound to toggle deinterlacing
by adding 'y vf toggle yadif' to the input.conf.
Reconfiguring the video filter chain normally resets the VO, so that it
will be "stuck" until a new video frame is rendered. To mitigate this, a
seek to the current position is issued when the filter chain is changed.
This is done only if playback is paused, because normal playback will
show an actual new frame quickly enough.
If vdpau hardware decoding is used, filter insertion (whether it fails
or not) will break the video for a while. This is because vo_vdpau
resets decoding related things on vo_config().
With the current semantics, there's no reason to disallow this.
(Although in my opinion, -vf should rather map to -vf-add than -vf-set,
however that is an independent issue from this change.)
Works like -vf-add, except if a filter already exists and has the same
parameters, it's removed instead of added.
Not really useful on the command line itself, but will make sense for
runtime filter changing in the following commit.
Until now, -vf-del required a list of indexes. This was a bit
inconvenient, so add support for using filter names too. Also simplify
the code a bit, doing the change would have been too painful otherwise.
This tried to use ctx->pic (last decoded AVFrame) for the frame bounds.
However, if av_frame_unref() on the AVFrame is called, the function will
reset _all_ AVFrame fields, even those which are not involved with
memory management. As result, mpcodecs_config_vo() was called with 0
width/height, which made the function exit early, instead of
reconfiguring the filter chain.
Go back to using mpcodecs_config_vo() directly. (That's what it did
before this VDCTRL was originally introduced; the original reason for
it disappeared.)
vo_vdpau actually reads past the image allocation when displaying a
non-mod 2 420p image. The vdpau API specifies that VdpVideoSurfacePutBitsYCbCr()
requires a height that is a multiple of 4, and surface allocations are
automatically rounded.
So allocate video images with rounded height. libavutil does the same,
so images coming directly from the decoder or from libavfilter are no
problem. (libavutil does this alginment explicitly, not just because the
decoded image size is aligned to macroblocks.)
The main() function is special, and omitting the return statement would
make it always return 0. And also, mpv_main() actually never returns, it
calls exit() through exit_player() instead. But change it anyway,
because it looks misleading.
This changes the code so that it does the same as MPlayer, mplayer2
and mpv before ref-counted AVFrame. The problem is that get_buffer2
is called with aligned frame dimensions, while get_buffer didn't. This
breaks the mpv video frame size change detection.
elevengu
wm4
Stephen Hutchinson
Stefano Pigozzi
Rudolf Polzer
Paul B Mahol