Why did this exist in the first place? Other than being completely
useless, this even caused some regressions in the past. For example,
there was the case of a laptop exposing its accelerometer as joystick
device, which led to extremely fun things due to the default mappings of
axis movement being mapped to seeking.
I suppose those who really want to use their joystick to control a media
player (???) can configure it as mouse device or so.
We've been prefering the libavcodec mp3 decoder for half a year now.
There is likely no benefit at all for using the libmpg123 one. It's just
a maintenance burden, and tricks users into thinking it's a required
dependency.
Precise seeking requires skipping audio, since the demuxer usually
doesn't seek precisely enough. There is a sanity check that prevents
skipping more than 300 seconds of audio. This still fails with very
large mp3s. For example, with a 1GB sized mp3 with Xing headers, entries
will be 4 MB apart on average, and occasionally much more.
Just bump the limit. I'm not even sure why it was added in the first
place; I suppose it's most important for files with real PTS resets.
When not receiving frame callbacks, we should not draw anything to avoid
blocking the OpenGL renderer. We do this by extending gl context api, by
introducing new optional function 'is_active', that indicates whether
OpenGL renderers should draw or not.
This fixes issue #249.
Define frame callback logic in wayland_common.c
As this should be used by opengl renderer as well.
Preferably drawing should be skipped entierly when no frame callbacks
are received. However, for now only swap buffers is skipped.
Like FFmpeg/Libav do. It seems not all code can actually deal with this
situation, so it's better to shift the special-cases to code which needs
it (possibly OSD code; screenshots of 0x0 windows would just fail).
I guess we don't really care whether this particular function succeeds.
If it fails, it must be completely broken anyway and it would not matter
much to us.
"Non-monotonic" isn't even 100% correct; it's missing "strictly" (for
briefness I guess), and also the message is printed if the PTS jumps
forward. So just print something that is likely a bit easier to
understand.
Unlike other VOs, this rendered OSD even while no VO was created
(because the renderer lives as long as the API user wants). Change this,
and refactor the code so that the OSD object is accessible only while
the VO is created.
(There is a short time where the OSD can still be accessed even after VO
destruction - this is not a race condition, though it's inelegant and
unfortunately unavoidable.)
--af=bs2b:help abort()ed because the default value of the "profile"
option is not represented by any choice. Fix it by adding an "unset"
choice. (It's a bit odd because there's already a "default" choice,
which is not default, but I don't care enough about this filter.)
Fixes#1712.
gl_video_set_options() didn't update it, so the default value set on
initialization was used. Fix by always setting the clear color before
the clear command; it's slightly easier to follow too.
Codecs for hardware acceleration are not blacklisted, but whitelisted.
Also, if this emssage is printed, the codec might not have any hardware
acceleration support in the first place.
Trying to handle such video is almost worthless, but it was requested by
at least 2 users.
If there are no timestamps, enable byte seeking by setting
ts_resets_possible. Use the video FPS (wherever it comes from) and the
audio samplerate for timing. The latter was already done by making the
first packet emit DTS=0; remove this again and do it "properly" in a
higher level.
Normally, the size of an mage plane is assumed to be stride*height. But
in theory, if stride is larger than width*bpp, the last line might not
be padded, simply because it's not necessary. FFmpeg's or mpv's image
allocators always guarantee that this padding exists (it wastes some
insignificant memory for avoiding such subtle issues), but some other
libraries might not.
I suspect one such case might be Xv via vo_xv (see #1698), although my X
server appears to provide full padding. In any case, it can't harm.
There's literally no reason why these functions have to be inline (they
might be performance critical, but then the function call overhead isn't
going to matter at all).
Uninline them and move them to mp_image.c. Drop the header file and fix
all uses of it.
The libavformat rtmp protocol's "timeout" option has two problems:
1) Unlike all other protocols, it's in seconds and not microseconds
2) It enables "listen" mode, which breaks playback
Make the --network-timeout do nothing in the rtmp case.
Fixes#1704.
For some reason there were two points in the code where it warned
against non-monotonic video PTS. The one in video.c triggered on PTS
going backwards or making large jumps forwards, while dec_video.c
triggered on PTS going backwards or PTS not changing. Merge them into a
single check, which warns against all cases.
wm4
James Ross-Gowan
Jari Vetoniemi
Patrick Hipp
Niklas Haas
Sai Ke WANG