| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some window managers let you change the fullscreen state of any window
using a key combination. For example, on XFWM you can use Alt+F11 and
on Compiz you can configure a key combination with the
"Extra WM actions" plugin.
With this change mpv will handle these fullscreen state changes. So, if
you enter into fullscreen mode using the WM's shortcut and then you use
mpv's fullscreen toggle, you will get back into window mode.
Merges PR #2081.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the EditionFlagOrdered is set, chapters without ChapterTimeEnd make
no sense. Ordered chapters will play the chapters in the order they
appear, but will play the ranges the chapters cover. So if the end time
is missing, the range is incomplete and it's not clear what should be
played. If you assume the start of the next chapter as end time, the
ordered flag will have no observable effect, so that's not a useful
assumption.
This fixes playback of a file which (apparently) had the
EditionFlagOrdered set accidentally, with normal chapters.
|
| | |
|
| | |
|
| |
|
|
| |
Pointed out by a certain wiiaboo.
|
| |
|
|
|
|
| |
At least Matroska files have a "forced" flag (in addition to the
"default" flag). Export this flag. Treat it almost like the default
flag, but with slightly higher priority.
|
| |
|
|
|
|
|
|
|
|
|
| |
The "FrameRate" element is probably deprecated (it's greyed out in the
"spec", and described as "Informational only" in bold). Normally files
use DefaultDuration. In fact, the FrameRate field was preferred over
DefaultDuration for determining framerate if present. Do not do this and
rely on DefaultDuration only.
Also, if no framerate is set, do not assume PAL (25 FPS). Such a
fallback makes little sense and will cause more problems than it solves.
|
| |
|
|
|
| |
Some of the ASCII art makes sense (like the lines starting with "|"),
but these do not make any sense to me and just look annoying.
|
| |
|
|
|
| |
"mpv --ao=wasapi:help" on Linux gave "Option ao doesn't exist.".
Completely misleading and stupid.
|
| | |
|
| |
|
|
|
|
|
|
| |
We want to distinguish actual errors, and just aborting the program
intentionally.
Also be a bit more careful with handling the wait() exit status: do not
called WEXITSTATUS() without checking WIFEXITED() first.
|
| |
|
|
| |
This probably fixes the regression introduced with commit 6147bcce.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv usually sets the terminal to non-canonical mode (which in particular
disables line buffering). But the old mode is restored if the process is
not foregrounded. This is supposed to make mpv behave nicer when it is
backgrounded.
getch2_poll() enables canonical mode. Unfortunately, this was only
called after the poll timeout elapsed, so non-canonical mode is first
enabled after about a second after program start. Fix this by moving the
poll call before the timeout.
(As far as we're aware, there's no event-based way to determine when the
FD's process group changes, thus we're polling.)
|
| |
|
|
|
| |
And use it for the mono case. This is slightly more formal and will make
it easier to add more such cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DVD/BD menu support never worked right, and are a pain to maintain. In
particular, DVD menus never actually worked correctly, because
highlights were not rendered correctly. Fixing this requires major
effort, which I'm not interested to spend.
Most importantly, the requirement to switch streams without losing the
DVD/BD state caused major weirdness in the playback core. It was
implemented by somehow syncing the playback state to the DVD/BD
implementation (in stream_dvdnav.c etc.), and then reloading the demuxer
without destroying and recreating the stream. This caused a bunch of
special-cases which I'm looking forward to remove.
For now, don't just remove everything related to menu support and just
disable it. If someone volunteers, it can be restored (i.e. rewritten)
in a reasonable way. If nobody volunteers soon, it goes.
|
| |
|
|
| |
No need to define extra types.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace all the check macros with function calls. Give them all the
same case and naming schema.
Drop af_fmt2bits(). Only af_fmt2bps() survives as af_fmt_to_bytes().
Introduce af_fmt_is_pcm(), and use it in situations that used
!AF_FORMAT_IS_SPECIAL. Nobody really knew what a "special" format
was. It simply meant "not PCM".
|
| |
|
|
| |
Having a big switch() is simpler.
|
| |
|
|
|
|
|
|
|
|
| |
Audio formats used a semi-clever schema to encode the properties of the
PCM encoding as bitfields into the format integer value.
The af_fmt_change_bits() implementation becomes a bit weird, but it's
an improvement to the rest of the code.
(I've always disliked it, so why not get rid of it.)
|
| |
|
|
|
| |
This is actually the last line of code outside of format.c/h which still
tries to fiddle with the format bitfields.
|
| |
|
|
|
|
| |
So whoever (nobody?) would want to deal with this broken and obscure AO
for an obscure audio API could add support for some more channel
layouts.
|
| |
|
|
|
|
| |
The X11 video output was removed recently and is a difference
from mplayer. That's why it should be documented in the
mplayer-changes document.
|
| |
|
|
|
|
|
| |
It only causes additional maintenance work.
Even if you wanted to have a fallback, it's probably better to use
--vo=sdl or so.
|
| |
|
|
|
| |
This saves us the trouble of interleaving the audio data for
no reason.
|
| |
|
|
|
|
|
| |
This may or may not fix some issues with the format switching
code. Actually, it seems somewhat unlikely, but then checking
the stream type isn't incorrect either, and is probably
something the API user should always be doing.
|
| |
|
|
|
|
| |
Originally, this was written for comparing the sample format only, but
ca_change_physical_format_sync() actually expects that the full format
is compared. (For all other uses it doesn't matter.)
|
| |
|
|
|
| |
This gets you the "logical" channel layout, instead of the exact thing
we're sending to the AO. (Tired of the cryptic shit ALSA gives me.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The speaker replacement nonsense sometimes made blatantly incorrect
decisions. In this case, it prefered a 7.1(rear) upmix over outputting
5.1(side) as 5.1, which makes no sense at all. This happened because 5.1
and 7.1(rear) appeared equivalent to the final selection, as both of
them lose the sl-sr channels. The old code was too stupid to select the
one with the lower number of channels as well.
Redo this. There's really no reason why there should be a separate final
decision, so move the speaker replacement logic into the
mp_chmap_is_better() function.
Improve some other details. For example, we never should compare the
plain number of channels for deciding upmix/downmix, because due to NA
channels this is essentially meaningless. Remove the NA channels when
doing this comparison. Also, explicitly handle exact matches.
Conceptually this is not necessary, but it avoids that we have to
needlessly shuffle audio data around.
|
| | |
|
| |
|
|
| |
Who knows when this broke?
|
| | |
|
| |
|
|
| |
Obvious bug added earlier today.
|
| |
|
|
|
|
|
| |
This reverts commit fc9695e63b5baa1a478acb8e79c038571ee0e9b3.
Users were complaining that both mpv and something else (what? I don't
know) respond to some multimedia keys, such as volume change.
|
| | |
|
| |
|
|
|
|
|
|
| |
Integer and float elements are encoded as a sequence of bytes prefixed
by a variable-length encoded length specifier. If the length is 0, then
there is no data. Whether this is valid or not is not really clear, but
some sample files which do this have surfaced. It's not particularly
hard to handle this, so just do it.
|
| |
|
|
|
| |
Change the demuxer_add_attachment() and demuxer_add_chapter() signatures
to take char* instead of bstr, and everything which depends on it.
|
| |
|
|
|
|
| |
Use char* for strings instead of bstr (data ptr + length pair). Matroska
actually (probably) allows "padding" strings with \0 bytes, so using
normal C strings instead of byte strings is more appropriate.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
500ms is a bit too high. Change it to 50ms. This improves client API
(and Lua) playback state update frequency.
Updating absolutely every time the audio PTS changes would be possible,
but is not helpful. Audio samplerates are high to trigger a wakeup
feedback loop, so the process would waste CPU time on updating the
playback position all the time.
(If a client application wants to ensure smooth update of the playback
position, it should update the position manually using a timer and by
reading the property - the application can make a much better decision
at how often the playback has to happen.)
|
| | |
|
| |
|
|
| |
Fixes #2066.
|
| |
|
|
|
| |
And also simplify it (it certainly had the most awkward API you could
think of for such a simple function).
|
| | |
|
| |
|
|
|
|
|
|
| |
This avoids keeping "bad" state from previous reconfig calls, such as
the internal_sample_format option (which is set only on the first
reconfig call).
There's no advantage to keeping the resample contexts around anyway.
|
| |
|
|
|
| |
mp_format is not a libavresample input format here, and the comment was
more confusing than it helped.
|
| |
|
|
|
|
| |
Basically, af_fix_format_conversion() behaves stupid you insert a
conversion filter that won't work, and adding back the conversion test
function is the simplest fix to it.
|
| |
|
|
| |
libswresample verbosely complains.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So apparently, this essentially happens when the kernel driver doesn't
implement write accesses in the channel map control. Which doesn't
necessarily mean that the channel map is unsupported, or that there is a
bug - it's just lazyness and a consequence of the terrible ALSA kernel
API for the channel mapping stuff.
In these cases, the channel count implicitly selects the channel map,
and snd_pcm_set_chmap() always fails with ENXIO.
I'm actually not sure what happens if dmix is on top of e.g. HDMI, which
actually lets you change the channel mapping.
I'm also not sure why commit d20e24e5d1614354e9c8195ed0b11fe089c489e4
(alsa-lib git repository) does not take care of this.
|
| |
|
|
| |
This one is used for demux_mf and for dmeux_mkv image attachments.
|
| |
|
|
|
| |
As a side effect, video tracks now actually export some fields
(language, default flag) to the player.
|
| |
|
|
|
|
|
| |
MPlayer traditionally had completely separate sh_ structs for
audio/video/subs, without a good way to share fields. This meant that
fields shared across all these headers had to be duplicated. This commit
deduplicates essentially the last remaining duplicated fields.
|
| |
|
|
|
|
| |
Always use the already existing extradata[_len] variable, instead of the
awkward switch between manually changed extradata and falling back to
passing through extradata at the end.
|
| |
|
|
|
| |
Why not. "format" sounds too misleading for the actual importance and
meaning of this field.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using --hwdec=auto, about half of all systems will print:
"[vdpau] Error when calling vdp_device_create_x11: 1"
this happens because usually mpv will be linked against both vdpau and
vaapi libs, but the drivers are not necessarily available. Then trying
to load a driver will fail. This is a normal part of probing, but the
error messages were printed anyway. Silence them by explicitly
distinguishing probing.
This pretty much goes through all the layers. We actually consider
loading hw backends for vo_opengl always "auto probed", even if a hw
backend is explicitly requested. In this case vd_lavc will print a
warning message anyway (adjust this message a bit).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Client API users can enable log output with mpv_request_log_messages().
But you can enable only a single log level. This is normally enough, but
the --msg-level option (which controls the terminal log level) provides
more flexibility. Due to internal complexity, it would be hard to
provide the same flexibility for each client API handle. But there's a
simple way to achieve basically the same thing: add an option that sends
log messages to the API handle, which would also be printed to the
terminal as by --msg-level.
The only change is that we don't disable this logic if the terminal is
disabled. Instead we check for this before the message is output, which
in theory can lower performance if messages are being spammed. It could
be handled with some more effort, but the gain would be negligible.
|
| |
|
|
|
|
|
|
| |
This happens with av_log(NULL, ...) calls. Drop the "?: " fallback
prefix, because it was confusing.
(Of course FFmpeg should not do this at all, but it's a very long way to
making the FFmpeg log callback sane.)
|
| |
|
|
|
|
|
|
| |
That's how mime types are.
(This makes redirection with a specific HLS URL work, because some idiot
thought it'd be a great idea to spell the mime type as
"application/x-mpegURL".)
|
| |
|
|
|
|
|
| |
No particular reason, but it's still possible that it causes additional
corner cases, and it's not really needed to test this on wine (other
than testing fullscreen stuff, which should be done on a real Windows
anyway).
|
| |
|
|
|
|
| |
No particular reason, but since we already have an internal variable,
it's better than using the option struct, which will be redone sooner
or later.
|
| | |
|
| |
|
|
|
| |
These decoders do not reference it. I suspect this was originally done
for the sake for MPlayer's vfw/dshow wrappers.
|
| |
|
|
|
|
| |
The only decoders I could find and which (possibly) require this field
are codecs which can be used via VfW only, and realaudio sipr. For VfW
we still passthrough this field.
|
| |
|
|
|
|
| |
Verify memory accesses and such. The behavior should be equivalent.
(RealAudio causes pain for everyone even in its grave.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Native Matroska codec support has to map the Matroska codec IDs to
libavcodec ones, and also has to undo codec-specific Matroska
strangeness, such as restoring AAC extradata and realaudio handling. The
VfW codec support doesn't need it, because AVI maps well enough to
libavcodec conventions (possibly because AVI was a dominant codec when
libavcodec was created). But there's still some need for generic codec
handling, such as enabling parsers and messing with various codec
parameters.
Separate these two, and move the parts which are guaranteed not to be
needed by VfW to the if-else tree that handles the VfW case
("A_MS/ACM"), making the cases exclusive.
(This should probably be done more radically, since it's very unlikely
that we should or have to mess with the VfW parameters at all - they
should just be passed through to the decoder.)
|
| |
|
|
|
| |
This is actually more readable. Most of the defines are used only once,
so using a symbol instead of the direct string only obfuscated it.
|
