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!
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.
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):
b2c2fe7a37 (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.
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.
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.
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.
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.)
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
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.
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.
