Using the default output audio unit should provide a much better user
exeperience since it changes automatically the output device based on which
becomes the default one.
Instead of generating vdpau_template.c with a Perl script, just include
the generated file in git. This is ok because it changes very rarely,
and the script is larger than the output it generates.
It also simplify the Makefile, and fixes the build. The problem was that
transitive dependencies do not work with generated files: there is no
dependency information yet when building it the first time. I overlooked
this because I didn't delete the .d files for testing (which contained
the correct dependencies, but only _after_ a first successful build).
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").
Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)
Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.
Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)
Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.
Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.
Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
See previous commits. This time, the lock is kept for rather long
times (e.g. for the duration of a big image memory allocation), but
this (probably) still doesn't matter at all.
This also affects legacy code only (pre-refcounting libavcodec).
See previous commits. Also simplify this thing: 2 flags per pool image
are enough to avoid a weird central refcount and an associated shared
object keeping the refcount. We could even just store these two flags
in the mp_image itself (like in mp_image.flags or mp_image.priv), but
let's not for the sake of readability.
This hasn't been done yet, because pthreads is still an optional
dependency, so this is a bit annoying. Now doing it anyway, because
maybe we will need this capability in the future.
We keep it as simple as possible. We (probably) don't need anything
more sophisticated, and keeping it simple avoids introducing weird
bugs. So, no atomic instructions, no fine grained locks, no cleverness.
All these --no-... options in --list-options made the output rather
unreadable, so hide them. Make the code for finding positional
parameters (which are supposed to skip these no-* options) slightly
simpler too.
Do this by recreating the m_config from scratch, which then must
contain the default values. This doesn't quite work with legacy options
using global variables: the default values get lost, so using
--list-options will print the value as set by the config file. This
also introduces a memory leak for string options backed by global
variables. All of these issues will be eventually fixed by moving all
options to structs.
Change how m_config is initialized. Make it more uniform; now all
m_config structs are intialized in exactly the same way. Make sure
there's only a single m_option[] array defining the options, and keep
around the pointer to the optstruct default value, and the optstruct
size as well. This will allow reconstructing the option default values
in the following commit.
In particular, stop pretending that the handling of some special options
(like --profile, --v, and some others) is in any way elegant, and make
them explicit hacks. This is really more readable and easier to
understand than what was before, and simplifies the code.
Prevents some awkwardness in a later commit, and makes the code more
uniform with other places where MPOpts is accessed.
This is a pretty annoying commit (touches tons of lines all over the
place), but it hurts only once.
This change affects vf_lavfi. Until recently, libavfilter was not
colorspace aware at all. This changed with the addition of colorspace
fields to AVFrame. libavfilter's vf_scale picks them up (as of recent
ffmpeg git). Since this support is still kind of wonky and not part of
the normal format negotiation, this won't set the correct output
colorspace, though.
Not adding a separate test for HAVE_AVFRAME_COLORSPACE. This is slightly
unclean, but on the other hand adding an explicit test seems like a
waste of effort.
The symptom was that "-vf scale,format=rgba" broke the vsfilter
colorspace hack in sd_ass. vf->reconfig is allowed to overwrite its
input parameter for convenience (maybe that was a bad idea).
This was removed in d427b4fd. I now found a sample that causes underruns when
moving to a chapter and apparently this is also a problem when taking
screenshots.
Reverts one of the changes from 18777ecf. `kAudioObjectPropertyScopeOutput`
was introduced in the 10.8 SDK while `kAudioDevicePropertyScopeOutput` was
moved to `AudioHardwareDeprecated.h`. Since the deprecation is silent for now
(no warnings), just use the old constant.
Either way, they both evaluate to 'outp', and in the 10.8 SDK the deprecated
constant is defined in terms of the non-deprecated one.
Fixes#155
Fixes reports of printing of garbage (or anything else) other than clearing
the status line to the end of line: the buffer returned by termcap_get
could get moved, and if that happened then these 3 caps pointed to garbage.
setupterm abort()s if it can't initialize the terminal and the last
parameter is NULL; handle setupterm errors and retry with "ansi" if
the TERM env var was unset.
Remove the (now unused) code for determining correct-pts mode based on
the demuxer in use. Change its description in the manpage to reflect
what this option does now.
Due to the termcap matching and the hardcoded fallbacks, the ESC keypress
has to be followed by another non-matching keypress (such as another ESC)
for it to be accepted. We drop the second ESC in case it was typed twice.
On Linux, the check fails because NULL is not defined. Fix by using 0
instead, which is a perfectly valid null pointer constant, but doesn't
require stddef.h.
Doing e.g. show_text "${time-pos/full}" will show the time formatted
with a milliseconds part.
This is actually special cased for a few properties which use
CONF_TYPE_TIME, instead of making all properties using CONF_TYPE_TIME
respect this. This is a technical limitation.
I'm not entirely happy with this approach, so I'll leave it
undocumented. It's relatively ok, but he fact that it's special-cased to
some properties is not elegant. So for now, this is just a hack to make
ChrisK2 happy (hi there).
The "options" pseudo-property allows reading global like this:
show_text ${options/name}
Where "name" maps to the option "--name". This allows retrieving option
values that are not properties. Write-access is not possible: this is
reserved for normal properties.
Note: it is possible that we'll change this again, and don't require the "options/" prefix to access options.
Windows doesn't send WM_MOUSELEAVE by default unless you ask it to;
request tracking for leave events when the mouse enters the window (or is
moved).
Tracking is automatically de-activated once the mouse leaves the window,
so we have to re-request it every time the mouse re-enters the window.
If the first character is not a valid UTF-8 start code nor is in termcap,
getch2 would enter an infinite loop. Always walk 1 byte in the UTF-8 case
unless it's a valid start code.
If we still haven't read the full key from the input but it's regardless a
unique match in the database, we could receive a NULL keycode from
keys_search (it's not a full match after all) and proceed to use it.
Don't disable the keycode matching code if we don't have termcap as we can
still match against the hardcoded sequences.
Still uses termcap, but uses terminfo for loading the termcap database if
possible. Adds configure test to find terminfo; skips the termcap test
if terminfo is found since terminfo provides termcap.
Use termcap completely for special keys; if we can't get it from termcap
and it isn't one of the known fallbacks, we ignore its specialness and
treat as a sequence of UTF-8 codes.
Further hardcoded fallbacks can be added by calling keys_push_once in
load_termcap; there is no limit to the amount of keys pushed.
Uses the "ke" and "ks" capabilities to start / exit application mode, which
is necessary on vt100 emulators (including screen, xterm and all terminals
that emulate either of those) to correctly receive arrow keys.
It's now possible to compile getch2 even without termcap, though it won't
be of much use since it'll be unable to detect special keys.
Converted to 4 spaces per tab, prettified some statements.
It appears the API requires you to cover all plane data with AVBuffers
(that is, one AVBuffer per plane in the most general case), because
certain code can make certain assumptions about this. (Insert rant
about how this is barely useful and increases complexity and potential
bugs.) I don't know any cases where the current code actually fails,
but we want to follow the API, so do it anyway.
Note that we don't really know whether or not planes are from a single
memory allocation, so we have to assume the most general case and create
an AVBuffer for each plane. We simply assume that the data is padded to
the full stride in the last image line. All these extra dummy references
are stupid, but the code might become much simpler once we only support
libavcodec versions with refcounting and can use AVFrame directly.
The --profile top-level option is handled specially in m_config.c. But
this code also broke sub-options that happened to be named "profile"
(e.g. when trying to use "-af-add=bs2b=profile=cmoy"). Handle it
specially only if it's the top-level --profile option.
This didn't setup the linked list of sub-commands for multi-part
commands ("a ; b ; c") correctly. Also, the new commands were attached
to the allocation of the _old_ command instead of the new one. (Wow,
whatever the hell I was (not) thinking when I wrote this code.)
Gives really funky results with PNG attachments otherwise. The main
problem is that avcodec_flush_buffers() does not fully reset the
decoder, so passing multiple PNG packets without keyframe flags will
attempt to combine the new picture with the previously decoded
contents. (Makes no sense with proper PNG - maybe this codepath is
intended for MNG or APNG.)
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
