| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set,
sh->aspect is overwritten. With software decoding fallback behaviour,
this makes the aspect ratio from container ignored since
last_sample_aspect_ratio is already set in first try with hardware
decoding.
|
|
|
|
|
|
|
|
| |
I did commit 86c05655d by thinking `mpv` already removed the `mpv` from
argc/argv. It actually is still there, so the argc must be 1 to check for no
arguments.
Thanks to @Nyx0uf for pointing out the bug and for testing on 10.9!
|
|
|
|
|
| |
This is not really something you want to disable anyway. If there is no bundle
the code already does it's falbacks anyway.
|
|
|
|
|
|
|
|
| |
File opening through Finder, apparently drops `--psn` arguments on Mavericks
and just uses no args. Modify the code to account for that case.
This wasn't tested on 10.9 itself (I don't have a paid dev account), but it
*should* work if I understood the problem correctly.
|
|
|
|
| |
Well that was dumb.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, mpv incorrectly used the %HOME% environment variable on
MinGW to determine the current user’s home directory. This is wrong;
the correct variable to use would be %HOMEPATH%, which would however
still be wrong since application data goes into the application data
directory, not the user’s home. This patch makes it use the local
AppData path instead of reading an environment variable.
This however exposed another problem (which also affected users who
actually had the %HOME% variable set):
b2c2fe7a3782 (discussed in issue #95) introduced some changes that
make mpv load user config files from the executable path on Windows.
The problem with this change is that config_dir was still declared
static, so once a config file had been found in the executable path,
it would set config_dir to an empty string, so mpv would dump e.g.
watch_later data straight into the user’s home. This commit also
fixes that.
One side effect of this is that mpv no longer considers the “mpv”
subdirectory in the executable path (that behavior resulted from
the homedir variable always being empty), unless it is somehow
unable to determine the local AppData path.
|
|
|
|
| |
Commits 40624100 and 72f2942df didn't update the variable accordingly.
|
| |
|
|
|
|
|
|
| |
Took a superficial look at the manpage, and fixed whatever I spotted.
Cherry picked from master, but required adjustments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the cluster used for prerolling contains an insane amount of
subtitle packets. Then the demuxer packet queue would be full of
subtitle packets, and demux.c would refuse to read any further packets -
including video and audio packets, resulting in EOF. Since everything
involving Matroska and subtitles is 100% insane, this can actually
happen.
Fix this by putting a limit on the number of subtitle packets read by
preroll, and throw away any further packets if the limit is exceeded. If
this happens, the preroll mechanism will stop working, but the player's
operation is unaffected otherwise.
|
| |
|
|
|
|
|
|
|
|
| |
The --volume option accepted values up to 10000, but internally, the
value is always clipped to 0-100 range. What makes this even worse is
that --softvol-max suggests that it extends the range of --volume, which
is not the case. (And passing a volume larger than 100 to --volume
didn't even print a warning.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The really funny thing about this commit is that this code is added on
top of another work around. Basically, subtitle seeking in libavformat
is completely broken. To make it useful, we have to add yet another
workaround.
The basic problem is that libavformat's subtitle seeking code always
uses the stream time base, instead of AV_TIME_BASE if stream index -1 is
passed to the avformat_seek_file() function.
Fixes github issue #216. Hopefully this will be fixed in ffmpeg too at
some point.
|
|
|
|
|
| |
Well, this was dumb. The resume message was printed for every file,
whether a resume config file existed or not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is basically a libavcodec API oddity: it can happen that
avcodec_decode_audio4() returns 0 (meaning 0 bytes were consumed). It
requires you to feed the complete packet again to decode the full
packet, and to successfully decode the following packets.
We ignored this case with the argument that there's the danger of an
endless decode loop (because nothing of that packet is apparently
decoded, so it would retry forever), but change it in order to decode
mpc8 files correctly.
Also add some comments to explain the mess.
|
|
|
|
|
|
|
|
|
|
| |
MPlayer handles this correctly, because MPlayer still has the FourCC
codec dispatch (codecs.conf). We need to handle this case specially,
because the libavformat rawvideo decoder will of course not eat mjpeg.
mjpeg is the only supported format, though. (Even MPlayer needs to
convert between V4L2 formats and MPlayer FourCCs, and mjpeg is the only
non-raw format.)
|
|
|
|
|
|
|
| |
The option list contains an empty string member with this option value,
so ignore that. I'm not sure whether the option list should maybe be
empty in this case, but it could be the wrong thing in case of other
options.
|
|
|
|
|
|
|
|
| |
This happens by default with pausing: if a file was paused when doing
quit_watch_later, then resume and unpause, then the file played after
that would start in paused mode. This is because the pause option is
backed up at thr wrong place, so it backs up the state from resuming,
instead of whatever it was set to before that.
|
| |
|
| |
|
|
|
|
| |
The option did nothing. This was probably broken with 5b38a52.
|
|
|
|
|
|
|
|
| |
This probably has been broken since bbc865a: a test was added that uses
a FBO, but it's always run, even if FBOs were not detected. On the other
hand, fbotex_init() just runs into an assert. Fix the test that
triggered this condition, and make fbotex_init() "nicer" by just failing
if FBOs are not available.
|
|
|
|
| |
A cocoa bug doesn't allow to do otherwise. Will open a radar later.
|
|
|
|
|
|
|
|
|
| |
Odd video sizes if pixel formats with chroma subsampling and PBOs were
used, garbage was rendered. This was because the PBO path created
buffers with an unpadded size, and then tried to upload a padded
image to it. Fix it by explicitly setting the padded size. (As with
the non-PBO path, we rely that image allocations are somehow padded,
which is normally the case.)
|
|
|
|
|
| |
The help and configure result wrongly showed this feature was autodetected,
while it is infact disabled by default.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
cocoa_common contains some locking calls to support video outputs that support
live resizing (at this moment only vo=opengl).
These should not be used unless the VO declares it is multithreaded by
registering the resize_redraw callback used for live resizing.
Fixes #200
|
|
|
|
|
|
|
|
| |
Otherwise, this would just try to demux a good chunk of the file, even
though the operation can't succeed anyway.
This caused some pretty strange issues, where perfectly valid use cases
would print a "Too many packets in the demuxer packet queue..." message.
|
|
|
|
|
|
|
|
|
|
| |
The rawaudio demuxer read one frame per packet, basically a few bytes,
which caused insane overhead. (I found this when I couldn't play raw
audio without dropouts when using -v, which printed a line per packet
read.)
Fix this and read 1 second of audio per packet. This is a regression
since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
|
|
|
|
|
|
|
|
|
|
|
| |
Regression since ff3b98d11c. The window positioning code relied on the
visibleFrame's height without taking into account the dock's presence.
Also moved the constraining code to the proper method that overrides the
original NSWindow behaviour. This avoids having to check for border since the
constraining is performed by Cocoa only for titled windows.
Fixes #190
|
|
|
|
| |
One example in ao.rst used the old syntax with misspelling of "no-block".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.
This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
|
|
|
|
| |
Was broken since the speed property was switched from float to double.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, do what MPlayer did all these years. It worked for them, so
there's probably no reason to change this.
Apparently fixes playback with some files, where the VDPAU decoder does
not formally support a profile, but decoding works with a more powerful
profile anyway.
Though note that MPlayer did this because it couldn't do it in a better
way (no decoder reported profiles available when creating the VDPAU
decoder), so it's not entirely clear whether this is a good idea. An
alterbative implementation might try to map the profiles exactly, and
do some fall backs if the exact profile is not available. But this
hack-solution works too.
Conflicts:
video/decode/vdpau.c
|
| |
|
|
|
|
|
|
|
| |
When panscan was used, i.e. the video is cropped to make the video fill
the screen if video and screen aspects don't match, screenshots
contained only the visible region of the source video, stretched to
original video size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider:
mpv file1.mkv file2.mkv
and file1.mkv is restored from an earlier session when quit_watch_later
was used. Then all restored options were reset when file2.mkv is played,
even if the user changed them during playback. This affects for example
the fullscreen setting.
Make it so that after finishing a resumed file, the previously restored
settings are not reset again. (Which means only resuming will forcefully
overwrite the settings.)
|
|
|
|
|
|
|
| |
One example in ao.rst used the old syntax with mangled device names.
Fix it. Mention some shell related caveats. Explicitly mention the
change of device name syntax in changes.rst, because it seems to be
a common issue.
|
|
|
|
|
|
| |
Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without
forward-declaring them and without including the headers declaring them.
FFmpeg's header for this is fine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix_overlaps_and_gaps() function in dec_sub.c fixes small gaps or
overlaps between subtitle events. However, sometimes it could happen
that the corrected subtitle events could overlap by 1ms due to bad
rounding, making libass shift subtitles to reduce collisions. (The
second subtitle will be shown above the previous one, even if both
subtitles are visible only for 1ms.)
sd_ass.c rounds the timestamps when converting to integers for unknown
reasons. I think it would work fine without that rounding, but since
I have no clue why it rounds, and since it could be needed to ensure
correct timestamps with ASS subtitles demuxed from Matroska, I'd rather
not touch it. So the solution is to use already rounded timestamps to
calculate the new subtitle duration in fix_overlaps_and_gaps().
See github issue #182.
|
|
|
|
| |
Apply it after mapping.
|
| |
|
|
|
|
|
| |
demux_subreader is quite aggressive, and sometimes detects random
strings in EXIF as subtitle text.
|
| |
|
| |
|
|
|
|
|
|
|
| |
No idea what the correct workflow is for these things. In any case, we
somehow have to make the github release system to include the correct
version in its tarball. I don't think you can provide your own tarballs
either, so it has to be in git.
|
|
|
|
|
|
|
|
| |
Disable the hack by default, because it's interfering with some more
modern WMs. MWM (Motif Window Manager) is probably pretty dead, but
we still allow enabling the old hack with "--fstype=mwm_hack".
See github issue #179.
|
|
|
|
|
|
|
|
| |
This is in theory more correct with respect to hardware decoding. With
hardware decoding, the VOs play the role of the video surface allocator,
and nothing is allowed to reference surfaces past the VO lifetime. But
in theory waiting_mpi could be a reference to a HW video surface, so it
should be relased before the VO is uninitialized.
|
|
|
|
|
| |
The hw decoding context was set only for the first file (when the VO was
initialized), instead of every file.
|
|
|
|
| |
Might be helpful when creating a tarball.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is basically reconstructed from 46b218c. Since we now have proper
release tags, we want this again.
Add --tags to the git describe call, because the github release system
creates light-weight tags only, and we're too lazy to create annitated
tags (or is that bad practice?).
Add --long, so that the git commit hash is part of the output even if
the tag matches.
|
|
|
|
|
|
|
|
|
|
| |
This is completely useless, and in this particular case, it broke the
fallback for MLP2 subtitles (stored as .txt files) to demux_subreader.
(Yes, libavformat should be fixed to handle this, but for now this will
_always_ break playback of subtitle files stored in .txt.)
You can still force this demuxer, but by default we will just pretend
that the "tty" demuxer does not exist.
|
| |
|
|
|
|
|
| |
Uses the same defaults as BTN3/4/5/6 which are hardcoded by most backends for
the mouse wheel.
|
|
|
|
|
|
|
|
| |
The default value for a standard mouse is 10.0. Because we don't want to
multiply the value in the input config file we scale it down to 1.0.
Hopefully this should work for more precise mousewheels or touchpad, but
I don't have access to such hardware.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support horizontal and vertical axes of input devices.
If the input device support precise scrolling with an input value then it
should first be scaled to a standard multiplier, where 1.0 is the default.
The multiplier will then applied to the following commands if possible:
* MP_CMD_SEEK
* MP_CMD_SPEED_MULT
* MP_CMD_ADD
All other commands will triggered on every axis event, without change the
values specified in the config file.
|
|
|
|
| |
Followup commit. Fixes all the files references.
|
|
|
|
|
|
|
|
|
|
| |
core is used in many unix systems for core dumps. For that reason some tools
work under the assumption that the file is indeed a core dump (for example
autoconf does this).
This commit just renames the files. The following one will change all the
includes to fix compilation. This is done this way because git has a easier
time tracing file changes if there is a pure rename commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allocate textures big enough to include the bottom/right borders (so the
chroma texture sizes are rounded up instead of down). Make the texture
large enough to include the additional luma border. Conceptually, we
pretend that the video frame is fully aligned, and then crop away the
unwanted borders. Filtering (even just bilinear) will access the
borders anyway, so it's possible that we might need to switch to
"harder" cropping instead, but at least pixels not close to the
border should be displayed correctly now.
Add a comment to mp_image.c about this luma border. These semantics are
kind of subtle, and the image allocation code handle this in a subtle
way too, so it's better to document this explicitly. The libavutil
image allocation code does similar things.
|
|\
| |
| | |
WASAPI stops working after pause
|
| |