Commit Graph

222 Commits

Author SHA1 Message Date
wm4 f26dfb6e4d player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.

This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.

This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.

This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).

The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.

Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.

The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.

Maybe this cache-pause feature should just be removed...
2019-10-11 20:01:51 +02:00
wm4 c84ec02128 ao: add API for underrun reporting
AOs can now call ao_underrun_event() (in any context) if an underrun has
happened. It will print a message.

This will be used in the following commits. But for now, audio.c only
clears the underrun bit, so that subsequent underruns still print the
warning message.

Since the underrun flag will be used in fragile ways by the playback
state machine, there is the "reports_underruns" field that signals
strong support for underrun reporting. (Otherwise, underrun events will
not be used by it.)
2019-10-11 19:25:45 +02:00
wm4 299916bde2 audio: raise log level of playback reset on audio timestamp
Make it a warning. This is such an intrusive and shitty hack (but of
course my fault) that it should not be hidden.
2019-10-06 20:46:22 +02:00
wm4 e5a97ef27f audio: do not try gapless if video is still ongoing
In this case, gapless will most likely not work. It will result in (very
slight) desync, or (more commonly with small buffer sizes), in an
underflow.

I think it would be legitimate to disable gapless at end of playback
completely if video is enabled at all. But this would need an exception
for cover art mode, so I guess the current solution is OK as well.
2019-10-06 20:46:22 +02:00
wm4 c1956e82c2 audio: make playback end with --end and --audio-spdif
In spdif mode, there are hacks that try to cut audio on frame boundaries
(blame spdif, which is a hack in itself). The "alignment" is used in a
bunch of places, but --end does not respect it. This leads to some audio
that can't be pushed because the alignment is off (I don't know why, not
do I care), which puts audio into an underrun state forever.

Fix this by discarding unusable extra samples if no new data can be
expected.

Fixes: #6935
2019-09-26 19:52:10 +02:00
wm4 5858e3cdbd audio: fix use-after-free with fuzzed file
reinit_audio_filters_and_output() can fully shutdown the audio chain on
failure. Specifically, it will deallocate mpctx->ao_chain. The value of
that field was cached in ao_c. The code after the call did not account
that the audio chain can be shutdown, and used the stale ao_c value.

Fixes: #6808
2019-09-21 21:59:09 +02:00
wm4 60a0db39aa player: ensure backward playback state is propagated on track switching
Track switching doesn't run reset_playback_state(), so a track enabled
at runtime during backward playback would lead to a messed up state.

This commit just does a bad code monkey fix to this. It feels like there
needs to be a much better way to propagate this state.
2019-09-19 20:37:05 +02:00
wm4 f68d9e75f8 player: fix --end for backwards playback
We need to transform the timestamp returned by get_play_end_pts().

I considered making it return the transformed timestamp directly. There
are 4 callers; 2 need a transformed timestamps, 2 don't. So I guess it
doesn't matter.
2019-09-19 20:37:04 +02:00
Ben Boeckel 6f0ed8e0b2 audio: increase a buffer size
The buffer is written to in `audio_config_to_str_buf` using `snprintf`
with a `%s` formatting of a 128-byte buffer. This can overflow the
target buffer of 80 causing a truncated output.
2018-10-31 09:20:26 +01:00
wm4 e02c9b9902 build: make encoding mode non-optional
Makes it easier to not break the build by confusing the ifdeffery.
2018-05-03 01:08:44 +03:00
wm4 0ab3184526 encode: get rid of the output packet queue
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.

Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
2018-05-03 01:08:44 +03:00
wm4 f4351e6f7d audio: fix EOF handling if there was no data at all
It stopped and did nothing, instead of terminating (or just letting
video play, if there was any video). Regression due to recent filter
changes.
2018-04-20 12:34:43 +02:00
wm4 4e7cbb7606 audio: don't recreate AO if a filter changes the output format
Until recently, the AO was reinitialized strictly only on decoder format
changes. But the commit for simplifying audio format negotiation removed
this. Now the AO is recreated for any format change.

This is sort of annoying if you change playback speed. The
insertion/removal of af_scaletempo can change the sample format. For
example, the acompressor filter will convert output to double, so
toggling scaletempo will force the format back to float. This recreates
the AO under the --gapless-audio=weak default. This likely affects a lot
of other filters too.

Work this around by allowing sample format changes, and keeping the
current AO format in these cases. This is probably not a big problem.
Most audio APIs force the output format to float anyway.

This means you actually have to worry about what the default gapless
mode does to your audio. If you start with a file that uses 8 bit per
sample, and then continue playing a 24 bit FLAC, it will be converted
down to 8 bit per sample. (Assuming they are played in a way that uses
the gapless logic.)
2018-04-15 23:11:33 +03:00
wm4 4527409c8d audio: improve behavior if filters output nothing during probing
Just bail out immediately (and disable audio) if format probing has no
result, instead of doing nothing and then apparently freezing.

This can happen with bogus filters, cases where the first audio frame is
essentially dropped by filters (can happen with large resampling
factors), and if the audio track contains no packets at all, or all
packets fail to decode.
2018-02-21 22:35:24 -08:00
wm4 02f9087de9 audio: move back PTS jump detection to before filter chain
The recent changes to player/audio.c moved PTS jump detection to after
audio filtering. This was mostly done for convenience, because dataflow
between decoder and filters was made "automatic", and jump detection
would have to be done as filter. Now move it back to after decoders,
again out of convenience. The future direction is to make the dataflow
between filters and AO automatic, so this is a bit in the way. Another
reason is that speed changes tend to cause jumps - these are legitimate,
but get annoying quickly.
2018-02-13 17:45:29 -08:00
wm4 76e7e78ce9 audio: move to decoder wrapper
Use the decoder wrapper that was introduced for video. This removes all
code duplication the old audio decoder wrapper had with the video code.

(The audio wrapper was copy pasted from the video one over a decade ago,
and has been kept in sync ever since by the power of copy&paste. Since
the original copy&paste was possibly done by someone who did not answer
to the LGPL relicensing, this should also remove all doubts about
whether any of this code is left, since we now completely remove any
code that could possibly have been based on it.)

There is some complication with spdif handling, and a minor behavior
change (it will restrict the list of codecs to spdif if spdif is to be
used), but there should not be any difference in practice.
2018-01-30 03:10:27 -08:00
wm4 6d36fad83c video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.

One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().

Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.

Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.

I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-30 03:10:27 -08:00
wm4 0366ba2531 player: replace old lavfi wrapper with new filter code
lavfi.c is not necessary anymore, because f_lavfi.c (which was actually
converted from it) can be used now.
2018-01-30 03:10:27 -08:00
wm4 b9f804b566 audio: rewrite filtering glue code
Use the new filtering code for audio too.
2018-01-30 03:10:27 -08:00
wm4 082029f850
player: redo hack for video keyframe seeks with external audio
If you play a video with an external audio track, and do backwards
keyframe seeks, then audio can be missing. This is because a backwards
seek can end up way before the seek target (this is just how this seek
mode works). The audio file will be seeked at the correct seek target
(since audio usually has a much higher seek granularity), which results
in silence being played until the video reaches the originally intended
seek target.

There was a hack in audio.c to deal with this. Replace it with a
different hack. The new hack probably works about as well as the old
hack, except it doesn't add weird crap to the audio resync path (which
is some of the worst code here, so this is some nice preparation for
rewriting it). As a more practical advantage, it doesn't discard the
audio demuxer packet cache. The old code did, which probably ruined
seeking in youtube DASH streams.

A non-hacky solution would be handling external files in the demuxer
layer. Then chaining the seeks would be pretty easy. But we're pretty
far from that, because it would either require intrusive changes to the
demuxer layer, or wouldn't be flexible enough to load/unload external
files at runtime. Maybe later.
2018-01-18 01:25:53 -08:00
wm4 a5f53da229 af_lavrresample: deprecate this filter
The future direction might be not having such a user-visible filter at
all, similar to how vf_scale went away (or actually, redirects to
libavfilter's vf_scale).
2018-01-13 03:26:45 -08:00
wm4 5103b5dc2c player: handle audio playback restart in central playback start code
No idea why this wasn't done earlier. This makes playback start in audio
only tracks closer to video-only or video/audio restart. It has the
consequence that --cache-pause-initial now works for audio-only streams
too.
2018-01-07 05:03:15 -08:00
wm4 69ae23fdd1 options: drop some previously deprecated options
A release has been made, so drop options deprecated for that release.
Also drop some options which have been deprecated a much longer time
before.

Also fix a typo in client-api-changes.rst.
2017-12-25 04:06:17 -07:00
wm4 076b1d266e audio: fix missing volume update on init and reinit
This is never updated after the AO inits, so there are several cases
where the volume would stay at 100%, even if it shouldn't. This affects
initial volume as well as track switching or switching between files.
2017-12-01 21:18:06 +01:00
wm4 d725630b5f audio: add audio softvol processing to AO
This does what af_volume used to do. Since we couldn't relicense it,
just rewrite it. Since we don't have a new filter mechanism yet, and the
libavfilter is too inconvenient, do applying the volume gain in ao.c
directly. This is done before handling the audio data to the driver.

Since push.c runs a separate thread, and pull.c is called asynchronously
from the audio driver's thread, the volume value needs to be
synchronized. There's no existing central mutex, so do some shit with
atomics. Since there's no atomic_float type predefined (which is at
least needed when using the legacy wrapper), do some nonsense about
reinterpret casting the float value to an int for the purpose of atomic
access. Not sure if using memcpy() is undefined behavior, but for now I
don't care.

The advantage of not using a filter is lower complexity (no filter auto
insertion), and lower latency (gain processing is done after our
internal audio buffer of at least 200ms).

Disavdantages include inability to use native volume control _before_
other filters with custom filter chains, and the need to add new
processing for each new sample type.

Since this doesn't reuse any of the old GPL code, nor does indirectly
rely on it, volume and replaygain handling now works in LGPL mode.

How to process the gain is inspired by libavfilter's af_volume (LGPL).
In particular, we use exactly the same rounding, and we quantize
processing for integer sample types by 256 steps. Some of libavfilter's
copyright may or may not apply, but I think not, and it's the same
license anyway.
2017-11-29 21:30:51 +01:00
wm4 3d27a0792b af: remove deprecated audio filters
These couldn't be relicensed, and won't survive the LGPL transition. The
other existing filters are mostly LGPL (except libaf glue code).

This remove the deprecated pan option. I guess it could be restored by
inserting a libavfilter filter (if there's one), but for now let it be
gone.

This temporarily breaks volume control (and things related to it, like
replaygain).
2017-11-29 21:30:51 +01:00
wm4 41beaa653a audio: fix small memory leak
Most commonly happened with --end, in which case that field tends to be
set.
2017-10-27 13:54:08 +02:00
wm4 5f012f2d16 audio: clarify GPL-only parts 2017-10-10 17:36:35 +02:00
wm4 bfa9b62858 build: add preliminary LGPL mode
See "Copyright" file for caveats.

This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
2017-09-21 13:56:27 +02:00
wm4 fdb300b983 audio: make libaf derived code optional
This code could not be relicensed. The intention was to write new filter
code (which could handle both audio and video), but that's a bit of
work. Write some code that can do audio conversion (resampling,
downmixing, etc.) without the old audio filter chain code in order to
speed up the LGPL relicensing.

If you build with --disable-libaf, nothing in audio/filter/* is compiled
in. It breaks a few features, such as --volume, --af, pitch correction
on speed changes, replaygain.

Most likely this adds some bugs, even if --disable-libaf is not used.
(How the fuck does EOF notification work again anyway?)
2017-09-21 12:48:30 +02:00
wm4 caaa1189ba audio_buffer: remove dependency on mp_audio
Just reimplement it in some way, as mp_audio is GPL-only.

Actually I wanted to get rid of audio_buffer.c completely (and instead
have a list of mp_aframes), but to do so would require rewriting some
more player core audio code. So to get this LGPL relicensing over
quickly, just do some extra work.
2017-09-21 04:10:19 +02:00
wm4 181b071431 audio: fix format change regression
Ever since the mp_aframe change, audio mid-stream format changes crash.
I have no idea why the recent mp_aframe change triggers this. Didn't
look too deeply into it either. It appears to work now, though.

Fixes #4828.
2017-09-03 13:09:49 +02:00
wm4 1f593beeb4 audio: introduce a new type to hold audio frames
This is pretty pointless, but I believe it allows us to claim that the
new code is not affected by the copyright of the old code. This is
needed, because the original mp_audio struct was written by someone who
has disagreed with LGPL relicensing (it was called af_data at the time,
and was defined in af.h).

The "GPL'ed" struct contents that surive are pretty trivial: just the
data pointer, and some metadata like the format, samplerate, etc. - but
at least in this case, any new code would be extremely similar anyway,
and I'm not really sure whether it's OK to claim different copyright. So
what we do is we just use AVFrame (which of course is LGPL with 100%
certainty), and add some accessors around it to adapt it to mpv
conventions.

Also, this gets rid of some annoying conventions of mp_audio, like the
struct fields that require using an accessor to write to them anyway.

For the most part, this change is only dumb replacements of mp_audio
related functions and fields. One minor actual change is that you can't
allocate the new type on the stack anymore.

Some code still uses mp_audio. All audio filter code will be deleted, so
it makes no sense to convert this code. (Audio filters which are LGPL
and which we keep will have to be ported to a new filter infrastructure
anyway.) player/audio.c uses it because it interacts with the old filter
code. push.c has some complex use of mp_audio and mp_audio_buffer, but
this and pull.c will most likely be rewritten to do something else.
2017-08-16 21:10:54 +02:00
wm4 68201f4591 player: make refresh seeks slightly more robust
Refresh seeks are automatically issued when changing filters, which
improves user experience if these filters change buffering or such.

The refresh seek could actually overwrite a previously ongoing seek:

	set pause yes
	set time-pos 10
	set vf ""

Here, the video code issued a refresh seek to the previous video
position, which could be different from the previously triggered (and
still ongoing) seek, this overwriting the seek.

Factor all refresh seek handling into a new function, and make it handle
ongoing seeks correctly.

Remove the weird new canonical_pts field, which actually had no use.

Fixes #4757.
2017-08-14 14:02:13 +02:00
wm4 b531332835 player: fix another audio resync issue
This oddly triggers bogus EOF when switching filter graphs between two
audio files (in this case, "[vid1]f[vo];[aid2]f[ao]"->"[aid1]f[ao]",
with aid2 being an external audio source).

This commit also fixes desync when seeking with an external file
connected via --lavfi-complex.

(Yes, the audio resync code is cursed.)
2017-08-12 23:35:12 +02:00
wm4 f1d161d55f player: make --lavfi-complex changeable at runtime
Tends to be somewhat glitchy if subtitles are enabled, and you enable
and disable tracks.

On error, this will disable --lavfi-complex, which will result in
whatever behavior.
2017-08-12 23:10:40 +02:00
wm4 c391640645 player: fix --lavfi-complex freeze
Commit 0e0b87b6f3 fixed that dropped packets did not trigger further
work correctly. But it also made trivial --lavfi-complex freeze. The
reason is that the meaning if DATA_AGAIN was overloaded: the decoders
meant that they should be called again, while lavfi.c meant that other
outputs needed to be checked again. Rename the latter meaning to
DATA_STARVE, which means that the current input will deliver no more
data, until "other" work has been done (like reading other outputs, or
feeding input).

The decoders never return DATA_STARVE, because they don't get input from
the player core (instead, they get it from the demuxer directly, which
is why they still can return DATA_WAIT).

Also document the DATA_* semantics in the enum.

Fixes #4746.
2017-08-11 21:29:35 +02:00
wm4 0e0b87b6f3 player: fix confusion in audio resync code
Just the audio resync code in its normal state: buggy. This time,
AD_NO_PROGRESS was handled about the same as AD_WAIT. But it means the
decoder didn't output data, even though input is still readily
available.

This happened in particular when the timeline code was used (potentially
skipping many packets), and thus should fix #4688.
2017-08-08 14:55:02 +02:00
wm4 8ef50016be player: fix --end with large values
Causea a simple integer overflow.

Fixes #4650.
2017-08-08 14:11:58 +02:00
wm4 6dde9ab27a player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.

player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.

Here is a relatively detailed list of potential issues:

8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.

5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.

cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)

kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.

anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.

Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.

Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)

I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.

This does not make the player LGPL yet.
2017-06-23 16:55:02 +02:00
wm4 c5cd49d75f player/audio: mark some libaf interfacing parts as GPL only
"anders" has not agreed to relicense most of his changes (although he
gave permission for 4943e9c52c and 242aa6ebd4).

Note that commit 3053a8b7f is in part also affected. The commit message
hides this, but it seems some code was based on anders':

http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-October/011773.html

Much of the final commit was by Arpi, but it's still grating that there
was no proper attribution (and in a case that turned out to be so
important).

This means player/audio.c won't even compile (and other parts of the
player also use audio/audio.h, which is still GPL). But whether the end
result compiles doesn't matter for copyright.

Due to the heavy refactoring applied over the year, the boundaries are
rather fuzzy and also somewhat arbitrary, though.

Most of this code will have to be replaced with a new filter chain
later.
2017-06-23 16:54:09 +02:00
wm4 698416ee97 audio: replace from_dB function
The author of the old code disagreed with LGPL. The new code is a clean
room reimplementation by Niklas Haas. It lacks the clamping, but we
decided it doesn't matter.

Untested, bugs can be fixed later anyway.
2017-05-05 01:22:06 +02:00
wm4 afead7a356 audio: merge --replaygain-track and --replaygain-album into one option
This is probably better than separate options. For example, the user
does not have to guess which one is applied if both options are enabled.
2017-04-27 00:21:17 +02:00
wm4 90a1ca02a2 audio: fix replaygain volume scale
The new replaygain code accidentally applied the linear gain as cubic
volume level. Fix this by moving the computation of the volume scale out
of the af_volume filter.

(Still haven't verified whether the replaygain code works correctly.)
2017-04-27 00:15:32 +02:00
wm4 f1c4d20e65 audio: move replaygain control to top-level options
af_volume is deprecated, and so are its replaygain sub-options. To make
it possible to use replaygain without deprecated options (and of course
to make it available at all after af_volume is dropped), reintroduce
them as top-level options.

This also means that they are easily changeable at runtime by using them
as properties. Change the "volume" property to use the new update
mechanism as well.

We don't actually bother sharing the implementation between new and
deprecated mechanisms, as the deprecated one will simply be deleted.

For the from_dB() functions, we mention anders' copyright, although I'm
not sure if a mere formula is copyrightable. This will have to be
determined later.

This whole change is mostly untested. Our distributed human CI will take
care of it.
2017-04-26 21:45:55 +02:00
Marko Hauptvogel 3fe6b36eb0 player: close audio device on no audio track
Close the audio device if there is no audio track (or stream) in the
current file. It will be opened again if the next file should contain
audio.

Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Signed-off-by: wm4 <wm4@nowhere>
2017-04-25 20:21:09 +02:00
wm4 b96a74ec2a audio: deprecate most audio filters
Well, ok, only 4 filters. The rest will survive in one or the other
form.
2017-04-04 15:04:07 +02:00
wm4 d606b6af17 player: specifically log audio EOF too 2017-03-14 15:55:42 +01:00
wm4 c4ad2732f9 audio: stop being dumb
Obvious mistake: we entered EOF drain mode if the decoder returned
AD_WAIT, which is very wrong. AD_WAIT means we should retry after
waiting for a while (or to be precise, until the demuxer/decoder
have more data). We should just pass down this status, and not
change the audio chain state.

This was exposed by a libavfilter EOF handling bug. Feeding a filter
chain with af_dynaudnorm, and sending an EOF before a frame is returned
makes it stuck and keeps returning EAGAIN, instead of returning the
buffered audio. In combination with the bug at hand, which entered
EOG drain mode, it could happen that it got stuck due to libavfilter
discarding buffered data each time the demuxer ran out of data.

Fixes #3997.
2017-01-08 14:47:53 +01:00
Aman Gupta 7cd32ec29e audio: force pts_reset only when pts jumps forward more than 5s
i've seen several mpegts samples where pts jumps backwards and repeats
itself. this usually happens on live tv streams from cable providers,
particularly when the stream switches from one advertisement to another.
2016-10-21 17:11:26 +02:00