Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead
increased SHADER_MAX_HOOKS, since I forgot that they were separate (for
whatever reason).
To prevent this mistake from happening again, and to unify the location
in which user_shader-specific #defines are placed, get rid of the two
constants in opengl/video.c and move/reuse them from user_shaders.h
instead.
Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a
precaution against adding more passes to vo_opengl. I think we're
already flirting with the limit.
There is no technical need for this, but it's nicer if --list-options
appears to output them sorted (it only actually sorts the actual option
list, while actions are output in the order they are defined).
This means you can use --sub-file-set=a,b,c to set a string list
separated by ',', while --sub-file=filename,with,commas.srt still works
(the original motivation for changing the --sub-file option this way).
You can also use it to append strings to string list options without the
need for escale, e.g.: --opengl-shaders-add-str=unescapesdfilename.glsl
(The normal -add for some reason expects a ',' separated list as
argument.)
These are not "really" separate actions, but on the command line they're
obserable as such. So it would be a good idea to list them too.
Adds about 117 options (holy fuck).
This is even better at preventing discoloration than tone mapping on the
XYZ image. Partly inspired by the HLG OOTF. Also simplifies the way we
tone map, and moves this logic to the pass_tone_map function where it
belongs.
This also fixes what could arguably be considered a bug in the HLG
implementation when using HLG for non-BT.2020 colorspaces, which is not
permitted by spec but thinkable in theory. Although in this case, I
guess it will be arbitrary whether people use the BT.2020-normalized
luma coefficients or change it to fit the colorspace, so I guess either
way could be considered "right", depending on what people end up doing.
Either way, in lieue of standard practice, we do what makes the most
sense (to me), and hopefully others will follow.
The downside is that we upload an extra vec3 uniform even if we don't
use it, but eliminating that would be ugly.
For HLG, due to the usage of a reference OOTF configured for 1000 cd/m²,
the default sig_peak of =nom_peak was suboptimal. We can go down to
1000/100 (=10.0), since that's the true dynamic range of the output
signal after it passes through the OOTF.
This affects options like --vf or --display-tags. These used a "*"
suffix to match all options starting with a specific name, and handled
the rest in the option parser. Change this to remove the "*" special
case, and require every option parser to declare a list of allowed
suffixes via m_option_type.actions.
The new way is conceptually simpler, because we don't have to account
for the "*" in a bunch of places anymore, and instead everything is
centrally handled in the CLI part of the option parser, where it's
actually needed.
It automatically enables suffixes like -add for a bunch of other
stringlist options.
You could do mpv_set_option(h, "no-fs", ""), which would behave like
"--no-fs" on the command line. At one point, this had to be emulated for
compatibility, and printed a deprecation warning. This was almost a year
ago, so remove it.
While I'm not particularly attached to this, the history is pretty
simple, and all relevant authors have agreed.
2f004875: removed in 2c693a47, patch author was not asked.
1ef239a4: removed, author was not asked.
This makes things like --show-profile=enc-v-h264 just work again.
Currently I don't see a reason why we should not always load the
encoding profiles. Although I guess this used to be different in the
past. (It probably won't take long until I revert this again - seems
like a fight you can't win for some reason.)
Fixes#4551.
This is only for the comments, but since the old syntax is "discouraged"
(and might change semantics one day), we should use the new syntax in
all documentation-like things.
Before this change, AOs could have internal alignment, and play() would
not consume the trailing data if the size passed to it is not aligned.
Change this to require AOs to report their alignment (via period_size),
and make sure to always send aligned data.
The buffer reported by get_space() now always has to be correct and
reliable. If play() does not consume all data provided (which is bounded
by get_space()), an error is printed.
This is preparation for potential further AO changes.
I casually checked alsa/lavc/null/pcm, the other AOs might or might not
work.
These can never be uninitialized because the enum cases are exhaustive and
the fallback is in the correct order, but GCC is too dumb to understand
this.
Also explicitly initialize tex_type, because while GCC doesn't warn
about it (for some reason), maybe it will in the future.
All relevant authors have agreed.
I'm removing the NV12 FourCC, which was added in f910f3d9 by someone who
was not contacted for the relicensing. I doubt the remaining code is
copyrightable (basically all what remains the fact is that NV12 uses the
same amount of space like YV12), but in this case I feel more
comfortable removing it.
Might contain some trace amounts of "michael"'s copyright, who agrees
with LGPL only once the core is relicensed - but with the core already
mostly relicensed, I'm changing the license header to LGPL, and only
marking this in the "Copyright" file.
cehoyos, who did not agree to the relicensing, added bcb5c78ce3. If
there was copyright, we consider it gone, because the table changed. It
does not map file extension to a FourCC anymore, and codecs.conf is
gone. The new mapping is a libavcodec codec name (happens to be the same
as the file extension).
The same applies to commits 60ecafec, b749836b, 5b3e3be1. None of these
authors were contacted. These were before the code was replaced with a
table (in d0326807). The parts outside of demux_mf.c were removed a long
time ago. Like in the previous comment, we don't think any copyright
applies at least to the new code (at least after the FourCC removal).
iive authored 0aa37a0d, which is probably still left in some form, and
makes demux_mf.c "LGPL 3 or later".
stream_avdevice.c (unrelated) has been marked as LGPL before.
I'm not even sure when/if FFmpeg produces those. It's just confusing. If
you really need this, you can still use dl-dr. I expect that most use is
unintentional.
Probably fixes#4545.
Right now, the current order pretty much means that pulse defaults to
S16 for arbitrary unsupported formats, but fallback to float would make
more sense since it's the easiest to convert everything to without
requiring dithering, and PA will probably just internally convert things
to float anyway.
Also move S32 above S16, which essentially means format_maps is sorted
by preference. (Although ao_pulse currently ignores this and always
picks the first as a fallback)
This was an annoying option type. And still is. But at least it's on the
same level as m_option_type_print_fn now, and can probably cleaned up
further like it. Both types are for options that are only on the command
line, always have special handling (i.e. do something with them in
parse_commandline.c before passing them to the generic
m_config.c/m_option.c layers), and are m_options only for --list-options
and (oddly) the split_opt_silent() function.
This was especially grating because it causes problems with the
option/property unification, uses as only thing OPT_FLAG_STORE, and
behaves weird with the client API or scripts.
It can be reimplemented in a much simpler way, although it needs
slightly more code. (Simpler because less special cases.)
- Fix a signed/unsigned comparison involving info.segment_uid.len
(doesn't actually warn here, but seems fragile). Code was previously
safe though.
- Match up all printf format strings with the respective value types,
using the *int*_t printf specifiers where necessary, and fixing
multiple signed/unsigned differences. Removed some casts that
otherwise may have truncated values.
- Fix a warning when initializing ebml_info.
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
"anders" has not agreed to relicense most of his changes (although he
gave permission for 4943e9c52c and 242aa6ebd4).
Note that commit 3053a8b7f is in part also affected. The commit message
hides this, but it seems some code was based on anders':
http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-October/011773.html
Much of the final commit was by Arpi, but it's still grating that there
was no proper attribution (and in a case that turned out to be so
important).
This means player/audio.c won't even compile (and other parts of the
player also use audio/audio.h, which is still GPL). But whether the end
result compiles doesn't matter for copyright.
Due to the heavy refactoring applied over the year, the boundaries are
rather fuzzy and also somewhat arbitrary, though.
Most of this code will have to be replaced with a new filter chain
later.
I think the idea is that you can pass multiple help options on the
command line, and it will print them all, instead of printing only the
first one and exiting. This was added in commit 43844d09, but the patch
author could not be reached. Revert it, as it's not a critical feature.
This was added in 0810e4275. The patch author did not reply (yet). Not
sure if copyrightable, but I'm making the still existing C part GPL-only
for now (in a previous commit).
Commit d8fd7131 changes this. "tibcu" did not reply. While I'm not sure
whether copyrightable code remains, I'd tend towards saying yes (the
basic idea is still intact after years of refactoring), so make it
GPL-only for now.
