| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the last traces of the old MPlayer FourCC-based codec
mapping code. Forcing all codec IDs through a FourCC table and then
back to codec names was confusing at best, so this is a nice cleanup.
Handling of PCM (non-VfW case) is redone to some degree.
Handling of AC3 is moved below realaudio handling, since "A_REAL/DNET"
is apparently AC3, and we must not skip realaudio-specific handling.
(It seems unlikely that anything would actually break, but on the other
hand I don't have any A_REAL/DNET samples for testing.)
Instead of explicitly matching all the specific AAC codec names, just
match them all as prefix.
Some codecs don't need special handling other than their mapping
entries, so they fall away (like Vorbis and Opus).
The prores check in mkv_parse_and_add_packet() is not strictly related
to this, but is done for consistency with the wavpack check above.
|
|
|
|
| |
Total time and ms
|
| |
|
|
|
|
| |
Broken by e00e9d65.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
mingw-w64-x86_64-lua maps to Lua 5.3, which we do not support. Change it
to mingw-w64-x86_64-lua51.
|
|
|
|
|
|
| |
Very stupid.
Was pointed out in #2056.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing cover art, the decoding logic pretends that the source has
an infinite number of frames. This slightly simplifies dealing with
filter data flow. It was done by feeding the same packet repeatedly to
the decoder (each decode run produces new output).
Change this by decoding once at the video initialization. This is easier
to follow, and increases robustness in case of broken images. Usually,
we try to tolerate decoding errors, so decoding normally continues, but
in this case it would just burn the CPU for no reason.
Fixes #2056.
|
|
|
|
|
|
|
| |
Fix some errors in the man pages by spell checking them. Most of them
were typos.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is slightly "dangerous", because it could overwrite a log callback
another library has set, after we've set our own callback. But it's
probably still slightly better than leaving our own callback, which will
run the fallback code if no mpv instance is set. (Multiple mpv instances
sharing the same global state will safely avoid overwriting each other's
log callback.)
Note that we can't do much better, because the global state in FFmpeg is
obviously insane.
|
|
|
|
|
| |
On init error, the mp_msg macros are actually called. They could cause
a crash because state->log was NULL.
|
|
|
|
| |
The 24 bit conversion code needs the relevant preprocessor symbols.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous behavior is confusing if the B point is near EOF (consider
B being the duration of the file, which is strictly speaking past the
last video timestamp). The new behavior is fine as well for B being far
past EOF.
Achieve this by checking the EOF state in addition to whether playback
has reached the B point. Also, move the A-B loop code out of
command_event(). It just isn't useful anymore, and obfuscates the code
more than it makes it loop simple.
Fixes #2046.
|
|
|
|
|
|
|
|
|
| |
Seems logical.
Note that if playback otherwise ends while playback is active and a seek
is still queued, we still exit. Otherwise you couldn't end playback by
seeking past the end of the file (which is classic MPlayer and mpv
behavior).
|
|
|
|
|
|
| |
This attempted to find a minimal filter graph for a format conversion
involving multiple conversion filters. With the last 2 commits it
becomes dead code - remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|