All authors agreed.
The author of 1ee8ce75 did not respond, but it was a mpv pull request,
and at this time DOCS/contribute.md and the "Copyright" file stated that
all contributions must include LGPL relicensing permission. But you
could claim that this was too "hidden". Sort of a corner case, I guess,
but not my problem.
Since this demuxer is based on code by michael, this file can become
LGPL only once the mpv core becomes LGPL, and this is preparation for
it.
There were quite a lot of changes for rearranging preferred libavformat
vs. internal MPlayer demuxers, codec mappings, and filename extensions,
but all this got removed, so some of the relevant authors weren't asked.
cehoyos, who disagreed with LGPL, made a few changes in the past (mostly
codec mapping and deinterlacing related things), but all of them were
removed, mostly due to libavformat API cleanups.
adland, who could not be reached, did commit 057916ee65, but it's easy
to essentially revert the change (this is what the source changes in
this commit do), so we don't need to think about it.
Chris Welton, who could not be reached, made a simple change in commit
958c41d9b6. Fortunately, the API changed again, and his changes were
removed, so we don't need to think about this either.
There is an anonymous contribution in commit 085f35f4b4 - since this
did not introduce any original code, and the probe code was heavily
rewritten multiple times, I don't consider it relevant.
Don't use __thread, which requires heavy runtime in some cases (such as
MinGW-w64, at least under some configurations, forcing you to link to
its pthread runtime DLL).
The pthread_t struct was needed over a simple thread ID, because
pthread_join() needed to access some sort of context from pthread_t.
Further, pthread_exit() and pthread_detach() need the context of the
current thread, for which we relied on TLS.
Replace these uses by a global thread array. This includes all threads
created by the thread wrapper. Hopefully the number of threads created
by mpv is low (say, below 20), and threads are not that often created or
destroyed. So just keeping them in an array with linear search lookup
should be reasonable.
iive agreed only to LGPL 3.0+ only. All of his relevant changes are for
XvMC, for which mpv completely dropped support back in mplayer2 times.
But you could claim that the get_format code represents some residual
copyright (everything else added by iive was removed, only get_format
still is around in some form). While I doubt that this is relly
copyright-relevant, consider it is for now.
michael is the original author of vd_lavc.c, so this file can become
LGPL only after the core becomes LGPL.
cehoyos did not agree with the LGPL relicensing, but all of his code is
gone.
Some others could not be reached, but their code is gone as well. In
particular, vdpau support, which was originally done by Nvidia, had
larger impact on vd_lavc.c, but vdpau support was first refactored a few
times (for the purpose of modularization) and moved to different files,
and then decoding was completely moved to libavcodec.
Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in
commit 8e5edec13e. Agreement is pending (due to copyright apparently
owned by the author's employer). So just undo the change, so we don't
have to think about whether the change is copyrightable.
Before this, options with co->data==NULL (i.e. no storage) were not
added to the bridge (except alias options). There are a few options
which might make sense to allow via the bridge ("profile" and
"include"). So allow them.
In command_init(), we merely remove the co->data check, the rest of the
diff is due to switching the if/else branches for convenience.
We also must explicitly error on M_PROPERTY_GET if co->data==NULL. All
other cases check it in some way.
Explicitly exclude options from the property bridge, which would be
added due this, and the result would be pointless.
Certain options, such as --profile, --help, and many others require
special-handling, because they don't fit conceptually into the option
and property model. They don't store data, but perform actions.
This caused the situation that profiles could not be set when using
libmpv in encoding mode (although you should probably not used libmpv in
encoding mode). Using libmpv always ends up in calling
m_config_set_option_raw_direct(), while --profile was handled in
m_config_parse_option().
Solve this by moving the handling of this from m_config_parse_option()
to m_config_set_option_raw_direct(). Actually we just stuff most of this
into m_config_handle_special_options(), which is only called by the
aforementioned function.
Strangely this also means that the --h/--help option declarations need
to be changed, because they used OPT_PRINT, and now the option "parser"
is always invoked before the special code. Thus, make them a string.
Them being OPT_PRINT was apparently always redundant. (The other option
declarations are moved for cosmetic purposes only.)
The most weird change is how co->data==NULL is handled. We now allow
passing down involved options to m_config_set_option_raw_direct(). The
thing is that we don't want them to error if the command line parser is
using them (with special handling done there), while all other code
paths should raise an error. We try using M_SETOPT_FROM_CMDLINE to
distinguish these cases.
Note that normal libmpv users are supposed to use the "apply-profile"
command instead.
This probably contains a bunch of bugs, which you should report.
All relevant authors of the current code have agreed.
As always, there are the usual historical artifacts that could be
mentioned. For example, there used to be a large number of decoders
by various authors who were not asked, but whose code was all 100%
removed. (Mostly due to FFmpeg providing all codecs.)
One point of contention is that Nick Kurshev might have refactored the
old audio decoder code in 2001. Basically, there are hints that it might
have been done by him, such as Arpi's commit message stating that the
code was imported from MPlayerXP (Nick's fork), or all the files having
his name in the "maintainer" field. On the other hand, the murky history
of ad.h weakens this - it could be that Arpi started this work, and Nick
took it (and possibly finished it).
In any case, Nick could not be reached, so there is no agreement for
LGPL relicensing from him. We're changing the license anyway, and assume
that his change in itself is not copyrightable. He only moved code, and
in addition used the equivalent video decoder framework (done by Arpi,
who agreed) as template. For example, ad_functions_s was basically
vd_functions_s, which the signature of the decode callback changed to
the same as audio_decode(). ad_functions_s also had a comment that said
it interfaces with "video decoder drivers" (I'm fixing this comment in
this commit).
I verified that no additional code was added that is copyright-relevant,
still in today's code, and not copied from the existing code at the time
(either from the previous audio decoder code or the video framework
code). What apparently matters here is that none of the old code was not
written by Nick, and the authors of the old code have given his
agreement, and (probably) that Nick didn't add actual new code (none
that would have survived), that was not trivially based on the old one
(i.e. no new copyrightable "work").
A copyright expert told me that this kind of change can be considered
not relevant for copyright, so here we go.
Rewriting this would end with the same code anyway, and the naming
conventions can't be copyrighted.
All authors of the current code have agreed.
The code probably originates from a software named GySmail (as the
copyright header indicates). As far as I can tell, it was written by
Arpi (who has agreed), possibly with unknown co-authors. This is most
likely OK, as none of the original code is around anymore anyway. I
could not find a working download of GySmail, that actually contained
the original getch2.c code.
This also has a wild history of random people adding ifdef guards to
control ioctl() vs. tcgetattr() calls. (See for example 2b1310abba4c1.)
Later, the ioctl() was removed in favor of the POSIX tcgetattr(), and
the ifdeffery was removed. So these people were not contacted.
Implements JS with almost identical API to the Lua support.
Key differences from Lua:
- The global mp, mp.msg and mp.utils are always available.
- Instead of returning x, error, return x and expose mp.last_error().
- Timers are JS standard set/clear Timeout/Interval.
- Supports CommonJS modules/require.
- Added at mp.utils: getenv, read_file, write_file and few more.
- Global print and dump (expand objects) functions.
- mp.options currently not supported.
See DOCS/man/javascript.rst for more details.
Not all tools apply line breaking. Which is probably good, because you
wouldn't be able to put lines in there which should _not_ be broken.
Don't ask me whether there is an "official" git convention for this.
Sometime earlier, "sub-ass-style-override" was renamed to
"sub-ass-override". The option's documentation was updated to support
this, but not the documentation for the hotkey that toggles this option.
This commit updates the keyboard shortcut documentation to fix that.
Signed-off-by: wm4 <wm4@nowhere>
The original functions come from 24c6f11c8b, which says that these
functions were copied from another project. This other project is GPL
and was written by an unknown author, so there is no hope to relicense
them to LGPL.
Replace the existing functions with code written by Avi Halachmi. He did
not see the old code, but wrote it based on the function signature and
an extended description of what they should do (http://sprunge.us/edia).
Some additional help was provided by me (in particular the function of
the "ok" parameter and how to implement it - not in the original
ASFRecorder code).
Some of the code is hilariously similar, but these are coincidences. The
name of the variable "c" probably "leaked" from me, but "o" is a true
coincidence.
The code was integrated by me - my only change is changing the function
names to the old ones, moving the order of the top-level declarations,
and changing "default_ok" to "url_default_ok", and changing the strings
from char* to char[].
The author of the new code is Avi Halachmi.
This switches back the --demuxer-lavf-probe-info default for HLS from
"no" to "yes".
Apparently the old default caused problems with the FFmpeg MediaCodec
wrapper. I'm not sure whether it's due to the extradata (which would not
make any sense as MediaCodec takes in Annex B formatted h264 data), or
something else. Reportedly, enabling probing fixes it though, so enable
it again.
Add disparaging comment about Google software/APIs here.
All authors of the current code have agreed (as far as this commit
requires).
options.c/options.h will take more effort, because it contains all the
option declarations, and thus is touched extremely often.
m_option.c is technically still GPL, because of commit 2c82d5a1d8
(michael has agreed to LGPL, but only once the core of mpv is LGPL).
The geometry parsing code in m_option.c was originally by someone who
could not be reached. However, it was heavily rewritten anyway, and only
the syntax remains (i.e. not copyright-relevant).
parse_commandline.c contains a change by "adland" (commit 1d0ac71ae8),
who could not be reached - this this specific part is GPL only.
Fortunately, it matters only for DVD (and even then is more like a hack,
but whatever).
There are some other relevant changes, but they have all been reverted,
moved somewhere else, deleted, or replaced.
All authors have agreed.
mpv.exe.manifest probably can't have a copyright header, so it doesn't.
These files don't add license info to the executables. And of course the
executable license is still GPL.
The history goes back to 2001 or so, but everyone involved with still
existing code has agreed.
One person who could not be reached yet (elevengu) has changes in this,
which as far as I can tell were overwritten anyway at a later point.
I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is
called a Möbius transform, which is the algorithm this is based on. In
the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0),
smoothly transitioning between the two depending on the parameter.
This is a useful tone mapping algorithm since the tunable mobius
transform allows the user to decide the trade-off between color accuracy
and detail preservation on a continuous scale. The default of 0.3 is
already far more accurate than `reinhard` while also being reasonably
good at preserving highlights, without suffering from the overall
brightness drop and color distortion of `hable`.
For these reasons, make this the new default. Also expand and improve
the documentation for these tone mapping functions.
Unfortunately quite a mess, in particular due to the need to have some
compatibility with the old API. (The old API will be supported only in
short term.)
When the drm video output is used under VT with a terminal multiplexer
like screen, the VT_SETMODE ioctl call will fail since the controlling
terminal is a pseudoterminal instead of a real one, thus the VT switcher
will be unavailable.
The problem is, the wait_events function inside vo_drm.c will test for
this, and will do nothing if the switcher is not active. Normally, this
would not be noticed, however, when you pause a video, or if you're playing
multiple image files, mpv will suddenly start busy waiting on a single
core.
I confirmed this by building mpv with gprof support, in a few seconds,
wait_events got called about 90 million times.
So I added a fallback, when the VT switcher is not availble, just use the
vo_wait_default function. I tested it and it's working well so far.
There's probably no reason to keep this disabled. The -rdynamic (and the
approach we use) is probably a bit scary, but should not break anything.
Just to be sure I'm hard-disabling this on win32 anyway. We know it
can't work there in its current form.
Fixes#4491.
This affects in particular the heuristic that enables byte seeks in some
cases with .ts input. --demuxer-lavf-hacks=no should disable this
behavior now.
List of changes:
1. Rename `signfs` to `scale`, to better match what it actually does
(force --sub-scale to apply to ASS subtitles), and fix the blatantly
wrong documentation (it actually specifically does *not* apply to
signs)
2. Rename `--sub-ass-style-override` to `--sub-ass-override` to help
reduce confusion between it and `--sub-ass-force-style`, as well as
pointing out that it doesn't necessarily actually override styles.
(The new `scale` option, for example, only sets
ASS_OVERRIDE_BIT_FONT_SIZE, but not ASS_OVERRIDE_BIT_STYLE)
3. Mention that `--sub-ass-override` is generally sort of smart about
only overriding dialog, not signs.
Usually a good idea to do this when encoding to mp4, but it's
commented since usefulness is arguable nowadays.
Equivalent to running qt-faststart tool on the resulting mp4.
Adds a bit of delay at the end of encoding.
In the previous commit, I claimed that this GUID stuff was a libavformat
extension, but that seems to be completely wrong. (LATM might be an
extension of some kind, though.)
I don't know what Microsoft calls this GUID "suffix" though. It's
generally used to wrap wav format tags and video FourCCs as GUIDs.
I guess you could grep Microsoft headers for it to find its name,
or something.
Indeed, FFmpeg found a way to maximize the misery around VfW/AVI-style
muxing. It appears it can mux a number of random codecs by using random
format tags. To make this even more stranger, it has a probably custom
GUID for signaling them, although for unknown reasons this is done only
"sometimes" (judging from FFmpeg's riffenc.c).
Whatever, it's not too hard to support it. Also apparently fix the
incorrect interpretation of extended formats - there's absolutely no
reason to assume they're always PCM. Instead, check for the correct
GUIDs. Also while we're at it, move the channel mask handling also to
codec_tag.c, so all WAVEFORMATEXTENSIBLE handling is in one place. (With
the normal wav header handling strangely still in demux_mkv.c.)
The case I was looking at (aac_latm muxing) decodes now. While I'm not
entirely sure about its correctness (libavformat has a weird
special-case for SBR), it certainly doesn't try to play it as PCM,
which is much of an improvement.
The extradata mess in the demux_mkv.c A_MS/ACM code path is unfortunate
and ugly, but has less impact than refactoring all the code to make
this specific case nicer.
Did I mention yet that I hate VfW-style mkv muxing?
In a multi GPU scenario, it may be desirable to use different GPUs
for decode and display responsibilities. For example, if a secondary
GPU has better video decoding capabilities.
In such a scenario, we need to initialise a separate context for each
GPU, and use the display context in hwdec_cuda, while passing the
decode context to avcodec.
Once that's done, the actually hand-off between the two GPUs is
transparent to us (It happens during the cuMemcpy2D operation which
copies the decoded frame from a cuda buffer to the OpenGL texture).
In the end, the bulk of the work is around introducing a new
configuration option to specify the decode device.
Add "or URLs" to the default OSD message when mpv is launched without parameters.
Since this works flawlessly with youtube-dl integration, the fact that you can drop URLs directly to the window should be advertised more.
The new API has literally no advantages (other than that we can drop
mp_vt_download_image and other things later), but it's sort-of uniform
with the other hwaccels.
"--videotoolbox-format=no" is not supported with the new API, because it
doesn't "fit in". Probably could be added later again.
The iOS code change is untested (no way to test).
