| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now af_lavrresample can output 24 bit samples directly, by doing the
conversion "inline". Luckily, S32->S24 can be done in-place, so this
isn't too much work. But the output conversion logic (which seems to be
adding up) gets slightly more complicated again.
Normally this is done by af_convert24. But having multiple conversion
filters complicates some aspects of the filter chain. S24 output is the
only thing the code for multiple conversion filters is still needed for,
and getting rid of that is preferable.
|
|
|
|
|
|
| |
If the code path for additional output conversion is active,
reorder_planes() is always called, even if the reorder_out array wasn't
filled. This is obviously wrong - always fill this array.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are useless. Not only are they actually rarely in use; but
libavcodec doesn't even output them, as libavcodec has no such sample
formats for decoded audio.
Even if it should happen that we actually still need them (e.g. if doing
direct hardware output), there are better solutions. Swapping the sign
is a fast and lossless operation and can be done inplace, so AO actually
needing it could do this directly.
If you wonder why we keep U8 instead of S8: because libavcodec does it.
|
| |
|
|
|
|
| |
Shit.
|
|
|
|
|
|
| |
The filter can buffer singificant amounts of audio.
(The proper fix is making the filter chain PTS-aware.)
|
|
|
|
|
| |
Even if we flush the current filter, we have to read the remaining
output from the frame we previously fed to the filter.
|
|
|
|
| |
Its last use was removed in 433402b5.
|
| |
|
|
|
|
|
|
| |
The existing code avoided doing this for some codecs. I see no point in
this, and it seems the original reason this exists was due to some
cleanup in 2007. libavformat doesn't do this. So just drop it.
|
|
|
|
|
|
|
|
| |
It's well possible that we've always ended up invoking the
AV_CODEC_ID_MPEG1VIDEO codec, but it's hard to tell. Mangling everything
through FourCCs (and then back) makes it hard to analyze. Also,
libavformat's Matroska demuxer uses AV_CODEC_ID_MPEG2VIDEO here, so it
should be quite safe to do anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inherited from MPlayer times, we used FourCCs to identify video codecs.
This was later changed to libavcodec codec names (which made life a
whole lot simpler). But demux_mkv still uses FourCCs a lot.
Change this for video. It's pretty simple, because some preparation was
done in the past. We just have to replace some "internal" FourCCs with
different handling.
One potentially complicated issue is that there is no natural way to
set the sh->format (AVCodecContext.codec_tag) field anymore. Most
decoders do not need it, though mjpeg is an exception.
Note that the AVI compatibility code still requires codec mappings, but
these are provided by FFmpeg. Also, the audio code is not changed.
For the MKV_V_MPEG2 -> mpeg1video thing see next commit.
|
|
|
|
|
| |
Replace an else block with a nested if with just "else if". No
functional or other changes.
|
|
|
|
| |
Reduces the mess slightly.
|
| |
|
| |
|
|
|
|
|
| |
Going by the existing names, these should make sense. HDMI knows about
these layouts, but does not name them.
|
|
|
|
|
|
|
| |
Channel maps reported by the device as SND_CHMAP_TYPE_VAR can be freely
reordered. We don't use this much (out of laziness), but in this case
it's a simple way to reduce necessary reordering (which would be an
extra libavresample invocation), and to make debug output more readable.
|
|
|
|
|
| |
SDR/SDL is what lavc outputs for 7.1(rear), while RRC/RLC is what ALSA
uses for some 7.1 layouts, so this makes sense to me.
|
|
|
|
|
| |
This didn't really work since the last time the channel map fallback
code was touched. In some cases, quite bad results were selected.
|
|
|
|
|
| |
This prevents that the potentially better pick by
mp_chmap_sel_fallback() is overridden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, we didn't do this, because it required some effort, and
didn't seem to be necessary. It probably still isn't, but it sounds
like a good idea not to output arbitrary data on these channels.
The situation is complicated by the fact that just adding new channels
to a planar frame would require messing with buffers. So we would have
to allocate new buffers and add them to the frame. We could have to
maintain an extra buffer pool for this. Avoid this by being "clever",
and just allocate a frame with enough channels in the first place.
libav/swresample won't know about these channels and won't write to
them, but we can grab them in reorder_planes() and use them for the
NA channels.
|
|
|
|
|
|
|
|
|
| |
This is just a conceptual issue, since for now every channel count has
an associated standard layout.
But should the max. channel count ever be bumped, some things would stop
function if mp_chmap_from_channels() refused to work for any channel
count within the allowed range.
|
|
|
|
| |
Quite a blunder, really.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the AVFrame-style system (which we inreasingly map our internal data
stuctures on), buffers and plane pointers don't necessarily have a 1:1
correspondence. For example, a single buffer could cover 2 or more
planes, all while other planes are covered by a second buffer, and so
on. They don't need to be ordered in the same way.
Change mp_audio_get_allocated_size() to retrieve the maximum size all
planes provide. This also considers the case of planes not pointing to
buffer start.
Change mp_audio_realloc() to reset all planes, even if corresponding
buffers are not reallocated. (The caller has to be careful anyway if it
wants to be sure the contents are preserved on realloc calls.)
|
|
|
|
| |
And also add the missing "unknown" entry to the manpage.
|
|
|
|
|
| |
Requested. Minor incompatible behavior change, as it was signalling
MPV_END_FILE_REASON_EOF previously.
|
|
|
|
|
| |
Making sure this is true makes it closer to the libmpv docs, and
possibly less confusing in corner cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you try to play surround with dmix, it will advertise surround and
lets you set more than 2 channels, but will report a stereo channel map,
with the extra channels identified as NA. We could handle this now, but
we don't want to (because it's excessively stupid).
Do it only if the channel map is not what we requested, instead of just
acting if it contains NA entries at all. This avoids that we hurt
ourselves in the unlikely but possible case we actually have to use
channel maps with NA entries.
|
|
|
|
|
| |
These commands are used to simulate keypresses using the key names from
input.conf.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So successful playback and user quit can be distinguished, for whatever
reason you may want to do this.
Normally, the "quit" command can be customized, but this does not work
for quit commands sent by the terminal signal handler. One solution
would be introducing something like "ON_SIGNAL" (equivalent to
"CLOSE_WIN"), but considering there are a bunch of possible signals, I'd
rather not get into this. So go with the dumb solution.
Probably fixes #2029.
|
|
|
|
|
| |
Affects for example --script-opts. A bunch of characters are now allowed
in them without causing trouble to the user.
|
|
|
|
|
| |
When gl_shader_cache was destroyed, existing user shader entries leaked
the file path string.
|
|
|
|
|
|
|
|
|
|
|
|
| |
gl_video_set_options() does not acquire ownership of the opts parameter
or its contents. In case of vo_cmdline, opts will point to temporary
memory. This memory will be free'd at a later point, and p->opts will
point to free'd memory on the next reinitialization.
The fix is pretty ugly, but it's a quick bug fix. This can probably be
removed once VO sub-options are exposed as properties.
Fixes #2035.
|
|
|
|
|
| |
We must be sure that every change comes with a notification. Otherwise,
some property changes could possibly be missed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the audio API takes a while for starting the audio callback, the
current heuristic can be off. In particular, with very short files, it
can happen that the audio callback is not called before playback is
stopped, so no audio is output at all.
Change draining so that it essentially waits for the ringbuffer to
empty. The assumption is that once the audio API has read the data
via the callback, it will always output it, even if the audio API
is stopped right after the callback has returned.
|
|
|
|
|
|
|
|
| |
If a frame could only be partially filled with real audio data, the
silence wasn't written at the correct offset. It could have happened
that the remainder of the frame contained garbage.
(This didn't happen in the more common case of playing dummy silence.)
|
|
|
|
|
|
|
| |
Used a wrong condition, and I suppose it could crash in some situations.
Change it to lazily initialize the hotplug stuff, like the
audio-device-list property does.
|
|
|
|
|
| |
These were actually not needed for correct function, since individual
property change notifications via mp_notify_property() are used.
|
|
|
|
|
|
| |
This was matching e.g. both "foo/bar" and "foobar" against "foo", when
only the former should match. This could cause more property
notifications than necessary.
|
|
|
|
| |
I suspect we need to hand this more gracefully in some cases.
|
|
|
|
|
|
| |
Absence of license header implies LGPL, as mentioned in the "Copyright"
file. But vaapi.h contains some code taken from the mplayer-vaapi
patch, which was under the typical MPlayer license.
|
|
|
|
|
|
|
| |
All vo_gl.c related code has been GPL+LGPL dual-licensed. The OSD code
is no exception and is also derived from vo_gl.c. Thus it should have
the same license (although I think technically speaking sub-licensing
it by removing one of the licenses is ok).
|
|
|
|
|
| |
This is (at least currently) redundant, but makes the code more
explicit. (This was discussed on IRC.)
|
|
|
|
|
|
|
|
|
| |
Commits 92b27be and f4ce99d removed high-fps logic to to a bug. That bug was
a missing parenthesis around everything after duration >= 0 && ... at the
removed code.
This patch restores the removed code, fixes the bug and then refactors the
code a bit.
|
|
|
|
|
| |
They can be handled by the same codes used for playlists, most of them will use an EDL.
Fixes #2027.
|
|
|
|
|
|
|
| |
This reverts commit f1746741dee6000b7fd139e7a10f72aba0674b3b.
Together with the other revert, this fixes #2023 (the reason being
broken framedrop handling - it was dropping frames when it shouldn't).
|
|
|
|
| |
This reverts commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b.
|
|
|
|
|
|
|
|
| |
read_output_surface() could fail and return NULL.
Also, make sure we don't set the image to a size larger than the
allocated size. Normally this shouldn't happen, but in theory it could
in corner cases; this is for robustness.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides a new method for enabling spdif passthrough. The old
method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated
method will probably stop working at some point.
This also supports PCM fallback. One caveat is that it will lose at
least 1 audio packet in doing so. (I don't care enough to prevent this.)
(This is named after the old S/PDIF connector, because it uses the same
underlying technology as far as the higher level protoco is concerned.
Also, the user should be renamed that passthrough is backwards.)
|
|
|
|
|
|
|
|
|
| |
This deprecates the --ad-spdif-dtshd option, and replaces it with a
pseudo decoder. This means ad_spdif will report two decoders, "dts" and
"dts-hd", of which the second simply enables what the option did.
The --ad-spdif-dtshd option will actually be deprecated in the next
commit.
|
|
|
|
|
|
|
| |
This makes no sense, because the format can't be converted anyway. It
just sets up the filter chain init code, which will vomit a bunch of
useless and confusing messages. So uninit and fail explicitly when this
happens.
|
|
|
|
|
|
| |
We can't do much in this case, but at least we can not call the vdpau
API functions with too large sizes. Apparently the API considers this
undefined behavior, and random stuff might happen.
|
|
|
|
|
|
|
| |
The previous code was not wrong, but I'd claim this makes the code more
robust. If a situation could happen in which the passed surface size is
incorrect, we could have passed a too small image, and
VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
|
|
|
|
| |
Why should I be required to type so much?
|
|
|
|
|
| |
All this information is already output otherwise. Except the FourCC,
which lost most of its importance in mpv.
|
| |
|
|
|
|
|
| |
This is because it turns out the regular robidoux is pretty useful for
tscale etc.
|
|
|
|
|
|
|
|
|
| |
Check the maximum size of video surfaces, and refuse initialization if
the video is too large for them.
Maybe we could do something more sophisticated, like inserting a
software scaler. On the other hand, this would have a very questionable
benefit, as it would be guaranteed to be too slow.
|
|
|
|
|
|
|
|
| |
When starting in paused mode, no audio is written to the device at all,
because writing audio implicitly unpauses the AO. If the file is very
small, and all audio fits within the AO buffer, this accidentally
triggered the EOF condition. (In unpaused mode, it would write all
audio, end playback, and then wait until the AO has everything played.)
|
|
|
|
|
| |
Seems like a good idea to avoid accidentally playing noise by writing
spdif data to pure PCM devices.
|
|
|
|
|
|
|
| |
On libavresample, don't ignore the buffered output data.
On libswresample, don't round the total buffer size to the input
samplerate.
|
|
|
|
|
| |
It was recently added to libswresample, and it does exactly what we
need.
|
|
|
|
|
|
| |
This is better, because now we call swr_get_delay() with the output
samplerate, instead of with the input samplerate and then multiplying it
with the ratio and rounding it up.
|
| |
|
|
|
|
|
|
| |
Apparently, just running ./waf and hoping that it will be run with a
Python interpreter doesn't necessarily work. The workaround is pretty
simple and reliable.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "osd" command cycles between 4 states (OSD level 0-3), which is
probably confusing and inconvenient. OSD levels 0 and 2 are rarely
needed. I would claim there |