| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 75dd3ec2106701cb865f52966de66c51cb6f9204.
This broke seeking with ordered chapters in some situations. While
the reverted commit was perfectly fine for playback of normal files,
it overlooked that in the ordered chapters case switching segments
actually reinitialized the audio chain completely, including the
decoder. And decoders still read packets on initialization. We can
restore the original commit as soon as decoders stop doing this.
|
|
|
|
|
|
|
|
|
|
|
| |
This AO pretended to support volume operations when in spdif passthrough
mode, but actually did nothing. This is wrong: at least the GET
operations must write their argument. Signal that volume is unsupported
instead.
This was probably a hack to prevent insertion of volume filters or so,
but it didn't work anyway, while recovering after failed volume filter
insertion does work, so this is not needed at all.
|
|
|
|
|
|
|
|
|
|
| |
It is possible to have ao->reset() called between ao->pause() and
ao->resume() when seeking during the pause. If the underlying PCM
supports pausing, resuming an already reset PCM will produce an error.
Avoid that by explicitly checking PCM state before calling
snd_pcm_pause().
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
References to WinMM/OLE/UUID were missing.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Oops.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The player didn't quit when the end of a file was reached. The reason
for this is that jack reported a constant audio delay even when all
audio was done playing. Whether that was recognized as EOF by the player
depended whether the exact value was higher or lower than the player's
threshhold for what it considers no more audio.
get_delay() should return amount of time it takes until the last sample
written to the audio buffer reaches the speaker. Therefore, we have to
track the estimated time when the last sample is done, and subtract it
from the calculated latency. Basically, the latency is the only amount
of time left in the delay, and it should go towards 0 as audio reaches
ths speakers.
I'm not sure if this is correct, but at least it solves the problem. One
suspicious thing is that we use system time to estimate the end of the
audio time. Maybe using jack_frame_time() would be more correct. But
apart from this, there doesn't seem to be a better way to handle this.
|
|
|
|
| |
<lachs0r> it fixes issues with recent python3
|
|
|
|
| |
Pressing 'h' in idle mode -> crash.
|
| |
|
|
|
|
| |
This should be pretty safe compared to forcing the codepage.
|
|
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
Closes #580.
|
| |
|
|
|
|
|
|
|
|
|
| |
MP_CMD_COMMAND_LIST commands (used to implement key bindings with
multiple commands) were not checked for abort commands. Implement it.
Remove the remarks about multi-commands being special from the manpage.
Seek coalescing is handled differently now, and the issue with abort
commands is fixed with this commit.
|
|
|
|
|
| |
This prevents keys from getting stuck if the modifier is released before
the base key.
|
|
|
|
|
| |
Small errors are unavoidable, but truncation can cause anamorphic video
to be off by 1 or 2 pixels.
|
|
|
|
|
|
|
|
|
| |
When timeline was used, and the --start option was not used, the initial
seek (needed to switch to the first timeline segment) seeked to -1 due
to an oversight.
Conflicts:
player/loadfile.c
|
|
|
|
|
| |
Basically, chapter marks and chapter seek-points were incorrect, while
the rest worked.
|
|
|
|
|
| |
Windows will automatically choose the correct icon size if this field is
unset.
|
|
|
|
|
|
|
|
| |
Same rationale as b2c2fe7a but updated to work with path-win.c
Signed-off-by: wm4 <wm4@nowhere>
Merges/closes #543.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set subtitle resolution to video resolution when avctx->width and
avctx->height are zero.
This can happen with broken vobsubs that have no size set in their
.idx file (or Matroska extradata). At least with the test file provided
in issue #551, using the video resolution as fallback instead of what
guess_resolution() does is better.
Note that these files clearly are broken. It seems this particular
file was created by trying to use ffmpeg to transcode DVB subtitles
to vobsub, and ffmpeg "forgot" to set the subtitle resolution in the
destination file. On the other hand, ffmpeg DVB and PGS decoders set
the resolution on the first subtitle packet (or somewhere close), so
it's not really clear what to do here.
Closes #551.
Signed-off-by: wm4 <wm4@nowhere>
Patch by xylosper, rewritten commit message by wm4.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that it was causing issues with certain perl setups (such as
the one on issue #549). It also turns out that it was not behaving correctly
(not all constants were being promoted to big nums as they should), so we
use explicit objects to derive the constants.
There were also precedence issues. I wonder if this even worked right to
begin with.
The 'double' path (8-byte floats) is untested, as I couldn't easily find
a file with such a field.
Closes #549.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cygwin's libc (newlib) doesn't obey a lot of unix feature test macros,
including _GNU_SOURCE; as a result, a lot of functions and defines get
masked out -- important defines such as M_PI and strcasecmp. Work around
it by undefining __STRICT_ANSI__ on cygwin systems.
This will still cause compilation issues on any non-cygwin system that
uses newlib, but hopefully nobody does that, or if they do, they will
find this commit message and know to add -U__STRICT_ANSI__ to their
CFLAGS. Hopefully.
|
|
|
|
|
|
|
|
|
|
|
| |
The mplayer decoder (spudec.c) actually handled this. There was explicit
code for binary palettes (16 32 bit values), and the subtitle resolution
was handled by video resolution coincidentally matching the subtitle
resolution.
Whoever puts vobsub into mp4 should be punished.
Fixes the sample gundam_sample.mp4, closes github issue #547.
|
|
|
|
|
| |
This includes the magical input padding required by libavcodec, which we
possibly didn't do before this commit.
|
| |
|
|
|
|
| |
Fixup commit for 20fa191ad.
|
|
|
|
|
|
|
|
|
| |
The minimum required version was bumped in the old configure script, but
for the waf build system is was somehow forgotten or overlooked.
Probably happened while the waf build system was developed in a separate
branch.
Closes #546.
|
|
|
|
|
|
| |
Thanks to @wm4 for catching the bug.
Fixes #405
|
| |
|
|
|
|
|
|
|
|
| |
This is the same issue as addressed by 257d9f1, except this time for
the :srgb option as well. (257d9f1 only addressed :icc-profile)
The conditions of the srgb_compand mix() call are also flipped to
prevent an off-by-one error.
|
|
|
|
| |
This crashed when retrieving the raw property value. Oops.
|
|
|
|
| |
With the new xdg_shell the problem will be no gone by itself.
|
|
|
|
|
|
|
| |
Use of these is "discouraged", but they're there to select these special
cases with the "aspect" property. They really should use some sort of
choice option type, but since it would be some work to make these work
with float values, the simple and dumb alternative was picked.
|
|
|
|
| |
This also affects the --aspect option and the "aspect" property.
|
|
|
|
|
| |
The correct value is 0.081, not 0.18. The scale factor also needed
slight adjustment due to the order of operations.
|
|
|
|
| |
Some drivers do not supply timestamps, use old timestamp in these conditions.
|
|
|
|
|
| |
When a time sync happens the last sync time is the minimum time that can be
used for presentation.
|
| |
|
|
|
|
|
|
|
|
| |
This sometimes happened when changing playback speed (= reinitializing
audio) after seeking of playback start. The assertion in audio.c:441 was
triggered, because buffer_playable_samples wasn't reset correctly when
the audio buffer was cleared or shortened. The assertion is correct and
should hold up any time.
|
|
|
|
|
|
| |
I could not see any difference whatsoever, but for usage with a 3DLUT
there's zero performance difference so we might as well follow the spec to
the letter.
|
|
|
|
|
|
|
|
| |
Legacy GL context creation (glXCreateContext) explicitly requires a X
visual, while the modern one (glXCreateContextAttribsARB) does not for
some reason. So fail only on the legacy code path if we don't find a
visual. Note that vo_x11_config_vo_window() will select a default visual
if a NULL visual is passed to it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issue #504. For some reason, glXChooseFBConfig() will return
a fbconfig with no associated visual. (I'm not sure if this allowed.
They don't always have a visual, but since GLX_X_RENDERABLE is set
and GLX_DRAWABLE_TYPE is (implicitly) set to GLX_WINDOW_BIT, why would
there be no visual?)
Even worse, a test program seems to show that a 16 bit fbconfig is
selected (instead of 24/32 bit), which doesn't sound nice at all. Since
there _are_ better fbconfigs available, glXChooseFBConfig() should
normally sort them by quality, and return the better ones first. It's
worth noting that this function should also prefer GLX_TRUE_COLOR
over anything else, although this comes last in the sort order.
Whatever is going on, requesting GLX_X_VISUAL_TYPE with GLX_TRUE_COLOR
seems to fix it.
|
|
|
|
|
| |
Now it does basically the same as mkv.desktop. Explanation is included
in the description comment.
|
| |
|
|
|
|
| |
This makes it show a window even when playing audio-only files.
|
|
|
|
| |
This was marked as unsigned, but it's signed. Found by xylosper.
|
|
|
|
|
|
|
|
| |
Use an arbitrary constant instead, which is as good as PATH_MAX.
This helps us to avoid having to think about pull request #523.
Also fix a case where a potentially signed char was passed to isspace().
|
|
|
|
| |
Apparently, at least sub_reload was missing a refresh at all.
|
|
|
|
|
| |
Change minimum version to 1.3 and remove the version checking in the source
code.
|
|
|
|
|
|
|
|
|
|
| |
This was done incorrectly in the previous commit: the fallback size used
the window size as requested with the first config call, which is the
size of the hidden window in the vo_opengl case. (That damn hidden
window again...)
Conflicts:
video/out/x11_common.c
|
|
|
|
|
|
|
|
|
| |
This code essentially does nothing. As far as I could find out, this
actually used to do something. Then it was removed with commit efe7c39f,
leaving some leftover code that didn't do anything useful. This happened
12 years ago!
Also remove a commented debug printf.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_opengl creates a hidden X11 window to probe the OpenGL context. It
must do that before creating a visible window, because VO creation and
VO config are separate phases.
There's a race condition involving the hidden window: when starting with
--fs, and then leaving fullscreen, the unfullscreened window is
sometimes set to the aspect ratio of the hidden window. I'm not sure why
the window size itself uses the correct size (but corrupted by the wrong
aspect), but that's perhaps because the window manager is free to ignore
the size hint while honoring the aspect, or something equally messed up.
It turns out this happens because x11_common.c thinks the size of the
hidden window is the size of the unfullscreened window. This in turn
happens because vo_x11_update_geometry() reads the size of the hidden
window when called in vo_x11_fullscreen() (called from
vo_x11_config_vo_window()) when mapping the fullscreen window. At that
point, the window could be mapped, but not necessarily. If it's not
mapped, it will get the size of the unfullscreened window... I think.
One could fix this by actively waiting until the window is mapped. Try
to pick a less hacky approach instead, and never read the window size
until MapNotify is received.
vo_x11_create_window() needs a hack, because we'd possibly set the VO's
size to 0, resulting e.g. in vdpau to fail initialization. (It'll print
error messages until a proper resize is received.)
Conflicts:
video/out/x11_common.c
|
|
|
|
| |
See previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a weird bug with aspect ratio handling. It has to do with
float handling: with -std=gnu99, gcc implicitly enables broken non-
standard semantics giving float variables excess precision. This can for
example make this fail in theory: "float a = 0.1; assert(a == a);"
While standard C allows excess precision _within_ expressions, it
requires truncation when storing float values in variables of types
"float" or "double". The "gnu99" mode breaks this. It can be unbroken by
using "c99", or by specifying -fexcess-precision=standard. The former
seems less likely to break compilers other than modern gcc. Note that
-ffloat-store would also fix this, but also makes float expressions less
efficient and less precise for no reason.
The code that mistakenly fails because of this is dec_video.c line 393.
It caused the container aspect to be ignored in some or all situations,
depending how the compiler optimizes. For example, on gcc-4.6 with -Os,
the aspect is always ignored.
In future, we should probably just get rid of storing aspects as floats.
Note: requires mingw-w64 trunk for math.h fixes (M_PI was hidden).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this still happens in the stream level, so we can't have
nice highlevel behavior restricting seeking. Instead, if a seek leads
to the demuxer requesting data outside of the cached range, the seek
will simply fail. This might confuse the demuxer, and the resulting
behavior is not necessarily useful.
Note that this also doesn't try to skip data on a forward seek. This
would just freeze the stream with slow unseekable streams.
One nice thing is that stream.h has a separate function for merely
skipping data (separate from seeking forward), which is pretty useful
in this case: we want skipping of data to work, even if we reject
seeking forward by skipping data as too expensive. This probably is
or will be useful for demux_mkv.c.
|
| |
|
|
|
|
| |
No real problem.
|
|
|
|
| |
This is slow and unreliable, basically unusable.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
| |
This used to work; I'm not sure when or why it regressed. When setting
AVProbeData.filename to NULL, libavformat will crash in rtp_probe() by
unconditionally accessing the string.
We used to set the filename to NULL to prevent probing by file extension
when we don't deem it as necessary. Using an empty string also works for
this purpose.
|
|
|
|
|
|
|
|
|
|
|
| |
Larger sizes can introduce overflows, depending on the image format. In
the worst case, something larger than 16000x16000 with 8 bytes per pixel
will overflow 31 bits.
Maybe there should be a proper failure path instead of a hard crash, but
not yet. I imagine anything that sets a higher image size than a known
working size should be forced to call a function to check the size (much
like in ffmpeg/libavutil).
|
|
|
|
|
|
|
| |
Not everything in the OSD path handles 0x0 sized sub-bitmaps well. At
least the code implementing --sub-gray had severe problems with it.
Fix this by skipping such bitmaps.
|