Allocate af_instance->data in generic code before filter initialization.
Every filter needs af->data (since it contains the output
configuration), so there's no reason why every filter should allocate
and free it.
Remove RESIZE_LOCAL_BUFFER(), and replace it with mp_audio_realloc_min().
Interestingly, most code becomes simpler, because the new function takes
the size in samples, and not in bytes. There are larger change in
af_scaletempo.c and af_lavcac3enc.c, because these had copied and
modified versions of the RESIZE_LOCAL_BUFFER macro/function.
No AO can handle these, so it would be a problem if they get added
later, and non-interleaved formats get accepted erroneously. Let them
gracefully fall back to other formats.
Most AOs actually would fall back, but to an unrelated formats. This is
covered by this commit too, and if possible they should pick the
interleaved variant if a non-interleaved format is requested.
Based on earlier work by Stefano Pigozzi.
There are 2 changes:
1. Instead of mp_audio.audio, mp_audio.planes[0] must be used.
2. mp_audio.len used to contain the size of the audio in bytes. Now
mp_audio.samples must be used. (Where 1 sample is the smallest unit
of audio that covers all channels.)
Also, some filters need changes to reject non-interleaved formats
properly.
Nothing uses the non-interleaved features yet, but this is needed so
that things don't just break when doing so.
This affects 64 bit floats and big endian integer PCM variants
(basically crap nobody uses). Possibly not all MS-muxed files work, but
I couldn't get or produce any samples.
Remove a bunch of format tags that are not needed anymore. Most of these
were used by demux_mov, which is long gone. Repurpose/abuse 'twos' as
mpv-internal tag for dealing with the PCM variants mentioned above.
Now to shift audio pts when outputting to e.g. avi, you need an explicit
facility to insert/remove initial samples, to avoid initial regions of
the video to be sped up/slowed down.
One such facility is the delay filter in libavfilter.
My main problem with this is that the output format will be incorrect.
(This doesn't matter right, because there are no samples output.)
This assumes all audio filters can deal with len==0 passed in for
filtering (though I wouldn't see why not).
A filter can still signal an error by returning NULL.
af_lavrresample has to be fixed, since resampling 0 samples makes
libavresample fail and return a negative error code. (Even though it's
not documented to return an error code!)
When blending OSD and subtitles onto the video, we write bogus alpha
values. This doesn't normally matter, because these values are normally
unused and discarded. But at least on Wayland, the alpha values are used
by the compositor and leads to transparent windows even with opaque
video on places where the OSD happens to use transparency.
(Also see github issue #338.)
Until now, the alpha basically contained garbage. The source factor
GL_SRC_ALPHA meant that alpha was multiplied with itself. Use GL_ONE
instead (which is why we have to use glBlendFuncSeparate()). This should
give correct results, even with video that has alpha. (Or at least it's
something close to correct, I haven't thought too hard how the
compositor will blend it, and in fact I couldn't manage to test it.)
If glBlendFuncSeparate() is not available, fall back to glBlendFunc(),
which does the same as the code did before this commit. Technically, we
support GL 1.1, but glBlendFuncSeparate is 1.4, and I guess we should
try not to crash if vo_opengl_old runs on a system with GL 1.1 drivers
only.
Apparently we were using FFmpeg-specific APIs. I have no idea whether
this code is correct on both FFmpeg and Libav (no examples, bad
doxygen... why do they even complaint aht people are using their APIs
incorrectly?), but it appears to work on FFmpeg. That was also the case
before commit ebc4ccb though, where it used internal libavformat
symbols.
Untested on Libav, Travis will tell us.
Set the PulseAudio stream title, just like the VO window title is set.
Refactor update_vo_window_title() so that we can use it for AOs too.
The ao_pulse.c bit is stolen from MPlayer.
In theory, af_volume could use separate volume levels for each channel.
But this was never used anywhere.
MPlayer implemented something similar before (svn r36498), but kept the
old path for some reason.
This member was redundant. sh_audio->sample_format indicates the sample
size already.
The TV code is a bit strange: the redundant sample size was part of the
internal TV interface. Assume it's really redundant and not something
else. The PCM decoder ignores the sample size anyway.
Also do some cosmetic changes, like merging definition and
initialization of local variables.
Remove an annoying debug mp_msg() from af_open(). It just printed the
command line parameters; if this is really needed, it could be added
to af.c instead (similar as to what vf.c does).
Helps with readability. Also remove the ctx_opt_set_* helper macros and
use av_opt_set_* directly (I think these macros were used because the
lines ended up too long, but this commit removes two indentation levels,
giving more space).
This should allow to make format negotiation much simpler, since it
takes the responsibility to compare actual input and accepted input
formats from the filters. It's also backwards compatible. Filters which
have expensive initialization still can use the old method.
I have no idea what these do, but apparently they are needed to inform
ALSA about spdif configuration. First, replace the literal constant "6"
for the AES0 parameter with the symbolic constants from the ALSA
headers (the final value is the same). Second, copy paste some funky
looking parameter setup from VLC's alsa output for setting the AES1,
AES2, AES3 parameters. (The code is actually not literally copy-pasted,
but does exactly the same.)
My small but non-zero hope is that this could make DTS-HD work, or at
least work into that direction. I can't test spdif stuff though, and
for DTS-HD not even opening the ALSA device succeeds on my system.
Using spdif with alsa requires adding magic parameters to the device
name, and the existing code tried to deal with the situation when the
user wanted to add parameters too.
Rewrite this code, in particular remove the duplicated parameter string
as preparation for the next commit. The new code is a bit stricter, e.g.
it doesn't skip spaces before and after '{' and '}'. (Just don't add
spaces.)
This accessed tons of private libavformat symbols all over the place.
Don't do this and convert all code to proper public APIs. As a
consequence, the code becomes shorter and cleaner (many things the code
tried are done by libavformat APIs).
It's probably better if all auto-inserted filters are removed when doing
an af_add operation. If they're really needed, they will be
automatically re-added.
Fix the error message. It used to be for an actual internal error, but
now it happens when format negotiation fails, e.g. when trying to use
spdif and real audio filters.
Note that the change in seek_reset is not entirely equivalent: we even
drop the remainder of buffered audio when seeking. This should be more
correct, because the whole point of the reset_ao parameter is to control
whether audio queued for output should be dropped or not.
ao_lavc.c accesses ao->buffer, which I consider internal. The access was
done in ao_lavc.c/uninit(), which tried to get the left-over audio in
order to write the last (possibly partial) audio frame. The play()
function didn't accept partial frames, because the AOPLAY_FINAL_CHUNK
flag was not correctly set, and handling it otherwise would require an
internal FIFO.
Fix this by making sure that with gapless audio (used with encoding),
the AOPLAY_FINAL_CHUNK is set only once, instead when each file ends.
Basically, move the hack in ao_lavc's uninit to uninit_player.
One thing can not be entirely correctly handled: if gapless audio is
active, we don't know really whether the AO is closed because the file
ended playing (i.e. we want to send the buffered remainder of the audio
to the AO), or whether the user is quitting the player. (The stop_play
flag is overwritten, fixing that is perhaps not worth it.) Handle this
by adding additional code to drain the AO and the buffers when playback
is quit (see play_current_file() change).
Test case: mpv avdevice://lavfi:sine=441 avdevice://lavfi:sine=441 -length 0.2267 -gapless-audio
It spams these in verbose mode. It's caused by format negotiation code
in af.c. It's for the mpv format to ffmpeg-format case, and that one is
very uninteresting. (The ffmpeg supported audio formats are practically
never extended.)
This was supposed to handle preemption better. I still think the current
state isn't very nice, since the decoder can "accidentally" call the
previous render function after preemption (instead of calling the
reloaded function), so there might be issues. But all in all, this
dummy_render function is a bit confusing, and still not entirely
correct, so it's not worth it.
Turn the sample format definitions into an enum. (The format bits are
still macros.) The native endian versions of the new definitions don't
have a NE suffix anymore, although there are still compatibility defines
since too much code uses the NE variants.
Rename the format bits for special formats to help to distinguish them
from the actual definitions, e.g. AF_FORMAT_AC3 to AF_FORMAT_S_AC3.
We found that the stretching - although it usually improves the looks of
the fonts - is incorrect.
On DVD, subtitles can cover the full area of the picture, and they have
the same pixel aspect as the movie itself.
Too bad many commercially released DVDs use bitmap fonts made with the
wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make
these more pretty then.
The previous code used the output video's pixel aspect for stretching
purposes, breaking rendering with e.g. -vf scale in the chain. Now
subtitles are stretched using the input video's pixel aspect only,
matching the intentions of the original subtitle author.
I overlooked the fact that the ffmpeg/libav build system only supports `--cc`
and completly ignores $CC. Hopefully this makes the build times a little
faster.
Fixes#332
