For 9-15 bit material, cutting off the lower bits leads to significant
quality reduction, because these formats leave the most significant bits
unused (e.g. 10 bit padded to 16 bit, transferred as 8 bit -> only
2 bits left). 16 bit formats still can be played like this, as cutting
the lower bits merely reduces quality in this case.
This problem was encountered with the following GPU/driver combination:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 9.0.1
It appears 16 bit support is rather common on GPUs, so testing the
actual texture depth wasn't needed until now. (There are some other Mesa
GPU/driver combinations which support 16 bit only when using RG textures
instead of LUMINANCE_ALPHA. This is due to OpenGL driver bugs.)
The extension checking logic was broken, which reported OpenGL 3 if the
OpenGL .so exported OpenGL 3-only symbols, even if the reported OpenGL
version is below 3.0. Fix it and simplify the code a bit. Also never
fail hard if required functions are not found. The caller should check
the capability flags instead. Give up on the idea that we should print
a warning if essential functions are not found (makes loading of ancient
legacy-only extensions easier).
This was experienced with the following version strings:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 9.0.1
(Possibly reports a very old version because it has no GLSL support,
and thus isn't even GL 2.0 compliant.)
Uses the same trick as the planarization code to turn per-sample memcpy
calls into mov instructions. Makes decoding a ~25min 48000Hz 2ch floatle
audio file faster from 3.8s to 2.7s.
Change from gamma 2.2 to the slightly more precise 1/0.45 as per BT.709.
https://www.itu.int/rec/R-REC-BT.709-5-200204-I/en mentions a value of
γ=0.45 for the conceptual non-linear precorrection of video signals.
This is approximately the inverse of 2.22, and not 2.20 as the code had
been using until now.
The warnings in demux_mpg were silenced by additional no-operation
casts.
A variable in ass_mp was used only for some versions of libass; now the
declaration is in that version #ifdef too to avoid a compiler warning.
This mainly serves as a fallback for platforms where nothing better is
available; also as a debugging help. Both the audio and video driver are
not first class - the audio driver lacks delay detection, and the video
driver only supports a single YUV color space.
Configure options: --disable-sdl2 to disable SDL 2.0+ detection,
--disable-sdl to disable SDL 1.2+ detection. Both options need to be
specified to turn off SDL support entirely.
Now, extra_ldflags ought to only consider LDFLAGS, and all libraries
shall go into libs_mplayer. In the end, the command line first contains
extra_ldflags, and then libs_mplayer.
So altogether this change has the effect that libraries get added to the
linker command line in the order the configure script checks them.
Previously there was some reordering due to some checks adding libraries
to libs_mplayer and some to extra_ldflags.
This is better than having just the operating system type decide the
wakeup period, as e.g. when compiling for Win32/cygwin, a wakeup period
of 0.5 would work perfectly fine.
Instead, the default wakeup period is now only decided by availability
of a working select() system call (which is the case on cygwin but not
mingw and MSVC) AND a vo that can provide an event file descriptor or a
similar hack (vo_corevideo). vos that cannot do either need polling for
event handling and now can set the wakeup period to 0.02 in the vo code.
If one of the bundled libraries is pointing to a missing dylib stop the
bundling and exit with an error. This can happen if the user uninstalled a
dependency after he built the binary/libraries.
The osxbundle target creates a bundle that is supposed to be distributable
to third parties. As they may not have fontconfig installed they miss a
fonts.conf pointing to the usual fonts directories in OSX.
For people installing from source and using from the terminal this commit
changes nothing. You just have to make sure that your fontconfig is installed
with a sane configuration (XQuartz does). If you are installing fontconfig from
source you can force a sane OSX default using `--with-add-fonts`. For example:
`./configure --with-add-fonts=/Library/Fonts,~/Library/Fonts`
Homebrew already addressed this with mxcl/homebrew@b242883
Add `mp_find_config_file` to search different known paths and use that in
ass_mp to look for the fontconfig configuration file.
Some incidental changes spawned by this feature where:
* Buffer allocation for the strings containing the paths is now performed
with talloc. All of the allocations are done on a NULL context, but it still
improves readability of the code.
* Move the OSX function for lookup inside of a bundle: this code path was
currently not used by the bundle generated with `make osxbundle`. The plan
is to use it again in a future commit to get a fontconfig config file.
Even if this is not so bad as other files, I need to add some stuff so...
why not!?
`uncrustify -l C -c TOOLS/uncrustify.cfg --no-backup --replace core/path.h`
`uncrustify -l C -c TOOLS/uncrustify.cfg --no-backup --replace core/path.c`
The header was unchanged by the tool.
This allows to use a fontconfig fonts.conf that is customized for mpv. The
configuration file is assumed to be located at `~/.mpv/fonts.conf`. If not
found the default fcontconfig config file is used.
Using vf_screenshot on Libav printed useless/misleading error messages
when playing 10 bit h264 with a VO that supports 8 bit yuv420p only:
Unsupported format 444p14le
Unsupported format 444p14be
...
The cause of this is that vf_scale is inserted to handle the format
conversion, and tries to find a pixel format with best quality. This
includes the 14 bit and 12 bit formats, which don't exist on Libav.
vf_screenshot tries to query whether Libav's libswscale supports it,
resulting in these error messages. (In theory, vf_scale is missing this
check, but it doesn't matter in practice.)
Since this warning is rather useless anyway, because all input video
comes from libavcodec, and only the conversion into the other could
possibly fail. Silence the warning by raising it to verbose message
level.
Closes#7.
Keep the currently displayed subtitles even when the user cycles through
subtitle tracks, and the subtitle is decoded by libavcodec (such as
vobsubs). Do this by not clearing the subtitles on reset(). reset() is
also called on seek, so check the start PTS whether the subtitle should
really be displayed (there's already an end PTS). Note that sd_ass does
essentially something similar.
The existing code has checks for whether the PTS reported by the demuxer
is invalid (MP_NOPTS_VALUE). I don't know under what circumstances this
can happens, so fall back to the old behavior if the PTS is invalid.
Doesn't define AVPROBE_SCORE_RETRY for some reason. They use
AVPROBE_SCORE_MAX/4 directly internally. AV_DISPOSITION_ATTACHED_PIC
is not defined with the most recent Libav release.
AVIOContext.av_class exists in Libav, but is apparently disabled in
old releases. Disable it for now until people stop torturing me with
old crap releases.
Commit c02f25 switched the "http://" protocol to use ffmpeg's HTTP
implementation (stream_lavf.c), instead of the mplayer internal one
(http.c). Unfortunately, it turns out that there are some network
related options that are not respected by stream_lavf.c, and
consequently do not work anymore for "http://" URLs. This might be
fixed later. Mark them as deprecated for now, as it might take
arbitrarily long until this is taken care of.
This slightly improves display of the current playback time in files
with sparse video packets (like video tracks containing a slow MJPG
slideshows as in [1]), or audio files with cover art image attachments.
While the video PTS is always "stuck" at the last frame displayed or
the last seek, audio is usually continuous. Given sane samplerates and
working audio drivers (to query how much of the current audio buffer has
been played), the audio PTS should always be more reliable.
[1] http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/rtpodcast/Rooster_Teeth_Podcast_191.m4a
Improve EOF handling in ds_fill_buffer for the case where one stream ends
much earlier than the others, in particular make sure the "too many ..."
message is not printed over and over.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32823 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
Try to improve seeking in files with only few video packets,
in particular files with cover art.
This might cause issues with badly interleaved files, particularly
together with -audio-delay, even though I did not see issues
in my very limited testing.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35486 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
libmpdemux/demuxer.h
Fix code that detects streams temporarily lacking data to work
properly with e.g. DVDs.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35499 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
Make stream eof detection less sensitive.
Fixes bug #2111.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35543 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
ffmpeg pretends that image attachments (such as contained in ID3v2
metadata) are video streams. It injects the attached pictures as packets
into the packet stream received with av_read_frame().
Add the --audio-display option to allow configuring whether attached
pictures should be displayed. The default behavior doesn't change
(images are displayed).
Identify video streams, that are actually image attachments, with "[P]"
in the terminal output.
Modify the default stream selection such that real video streams are
preferred over attached pictures. (This is just for robustness; I do not
know of any samples where images are added before actual video streams
and could lead to bad default stream selection with the old code.)
ad_dvdpcm reads MPEG specific headers directly (passed through codecdata
by demux_mpg), so you couldn't use ffmpeg's "pcm_dvd" with demux_mpg.
Change demux_mpg to set the correct audio parameters directly. The code
for this is taken from ad_dvdpcm.
ad_dvdpcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
Since libavcodec doesn't have a "generic" PCM decoder, we have to go out
of out way to make it look like ad_lavc provides one: make it provide a
pseudo "pcm" decoder, which maps some format tags manually to the
individual libavcodec PCM decoders.
Format tags which uniquely map to one libavcodec could be mapped via
codecs.conf. Since defining these in tag_map[] is much shorter (one line
vs. a full codec entry in codecs.conf), and since we need tag_map[]
anyway, we don't use codecs.conf for these.
ad_pcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
This caused errors like:
core/mplayer.c:4308:5: error: implicit declaration of function 'pthread_win32_thread_detach_np' [-Werror=implicit-function-declaration]
It turns out a pthread.h include was missing. It's not clear why this
used to work (or rather, why it happens only sometimes). Possibly some
libraries or system headers recursively include pthread.h under certain
circumstances or configurations.
Fix missing quoting in configure, which led to broken terminal output.
Closes#6.
This is a fix for web radio streams that send raw AAC [1]. libavformat's
AAC demuxer probe is picky enough to request hundreds of KBs data, which
makes for a slow startup. To speed up stream startup, try use the HTTP
MIME type to identify the format. The webstream in question sends an AAC
specific MIME type, for which demux_lavf will force the AAC demuxer,
without probing anything.
ffmpeg/ffplay do the same thing. Note that as of ffmpeg commit 76d851b,
av_probe_input_buffer() does the mapping from MIME type to demuxer. The
actual mapping is not publicly accessible, and can only be used by
calling that function. This will hopefully be rectified, and ideally
ffmpeg would provide a function like find_demuxer_from_mime_type().
[1] http://lr2mp0.latvijasradio.lv:8000
libavformat wants to read a full ~400KB of data to determine whether
it's really AAC. This causes slow startup with AAC web radio streams [1]
(possible due to a broken initial packet). There are similar issues
with other file formats.
Make the probe "score" (libavformat's mechanism for testing file
formats) configurable with the -lavfdtops:probescore option. This allows
lowering the amount of data read on probing. If the probe score is below
the probescore option value, demux_lavf will try to get a higher score
by feeding more data to libavformat, until the required score or the
max. probe size is reached.
Remove the lavf_preferred demuxer entry. This had a purpose in
mplayer-svn, but now there doesn't seem to be any good reason for it
to exist. Make sure that our native "good" demuxers are above
demux_lavf in demuxer_list[] instead (so that they are preferred).
[1] http://lr2mp0.latvijasradio.lv:8000
Use ffmpeg (stream_lavf) instead of internal mms support (asf_streaming.c)
for mms://, mmsh://, mmst:// URLs.
The old implementation is available under mp_mms:// etc.
There are some caveats with this:
- mms:// now always maps to mmsh://. It won't try mmst://. (I'm not sure
if mms:// URLs really can use the mmst protocol, though.)
- MMS streams under the http:// prefix are not handled. (ffmpeg ticket
#2001.) (Was already broken in mpv since c02f25.)
- It downloads all video streams now. MMS streams often have redundant
video streams, which encode the main stream at different quality. The
client is supposed to select one according to its bandwidth
requirements. (Explicit MMS stream selection has been broken in mpv
for a while, because MPOpts.vid maps to the stream number, not the
demuxer's stream ID - but the old logic doesn't work anyway when
using demuxer_lavf as opposed to demux_asf.)
ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and
.idx files). Get rid of the internal vobsub reader, and use the ffmpeg
demuxer instead.
Sneak in an unrelated manpage change (autosub default).
This affects streams loaded with -subfile and -audiofile. They could get
out of sync when they were deselected, and the main file was seeked. Add
code to seek external files when they are selected (see
init_demux_stream()).
Use avformat_seek_file() under certain circumstances. Both av_seek_frame()
("old" API) and avformat_seek_file() ("new" API) seem to be broken with
some formats. At least the vobsub demuxer doesn't implement the old API
(and the old API doesn't fallback to the new API), while the fallback
from new API to old API gives bad results. For example, seeking forward
with small step sizes seems to fail with the new API (tested with
Matroska by trying to seek 1 second forward relative to priv->last_pts).
Since only subtitle demuxers implement the new API anyway, checking
whether iformat->read_seek2 is set to test whether the old API is not
supported gives best results. This is a hack at best, but makes things
work.
Remove backwards seeking on seek failure. This was annoying, and only
was there to compensate for obscure corner cases (see 1ad332). In
particular, files with completely broken seeking that used to skip back
to the start on every seek request may now terminate playback.
Do this only if demux_lavf is used. Using demux_mpg and the ffmpeg DVD
subtitle decoder doesn't work. The problem is probably that demux_mpg
doesn't join split sub packets, while demux_lavf does. The internal
DVD sub decoder (spudec.c) can, while ffmpeg's dvdsub can't. I do not
know whether this is the actual problem.
If DVD playback is used, create "fake" vobsub-style text extradata
(like .idx files) to pass resolution and palette information to the
ffmpeg decoder. We could use the "palette" AVOpt and avcodec_set_dimensions()
instead, but it's actually simpler this way. Note that the decoder
doesn't parse any other fields. Also note that DVD playback still uses
demux_mpg by default, so this code is inactive unless -demuxer lavf is
specified. This is mainly preparation for the case when we manage to get
rid of demux_mpg for DVD playback.
The option sub-forced-only was accidentally renamed back to
forcedsubsonly in commit 72205635ab, causing a segfault in
mp_property_generic_option due to missing option.
