RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/player/main.c

471 lines
14 KiB
C
Raw Normal View History

Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
/*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* This file is part of mpv.
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
*
player: change license of most core files to LGPL 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.
2017-06-23 13:53:41 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* mpv is distributed in the hope that it will be useful,
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
player: change license of most core files to LGPL 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.
2017-06-23 13:53:41 +00:00
* GNU Lesser General Public License for more details.
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
*
player: change license of most core files to LGPL 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.
2017-06-23 13:53:41 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <math.h>
#include <assert.h>
#include <string.h>
client API: add API function that ensures total destruction mpv_destroy() should perhaps better be called mpv_detach(), because it destroys only the handle, not necessarily the player. The player is only terminated if a quit command is sent. This function quits automatically, and additionally waits until the player is completely destroyed. It removes the possibility that the player core is still uninitializing, while all client handles are already destroyed. (Although in practice, the difference is usually not important.)
2014-06-07 13:08:45 +00:00
#include <pthread.h>
player: move locale check to mp_create() The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
2018-03-09 03:10:28 +00:00
#include <locale.h>
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "config.h"
mpv_talloc.h: rename from talloc.h This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 18:03:40 +00:00
#include "mpv_talloc.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 18:37:57 +00:00
#include "misc/dispatch.h"
command: add infrastructure for async commands This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
2018-05-06 16:27:18 +00:00
#include "misc/thread_pool.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "osdep/io.h"
Rename getch2....c/h to terminal....c/h "getch2" really tells nothing about what the heck this code does. It'd be even worse when moving the rest of terminal handling code there.
2013-12-19 20:31:27 +00:00
#include "osdep/terminal.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "osdep/timer.h"
build: move main-fn files to osdep And split the Cocoa and Unix cases. Simplify the Cocoa case slightly by calling mpv_main directly, instead of passing a function pointer. Also add a comment explaining why Cocoa needs a special case at all.
2015-05-02 16:47:57 +00:00
#include "osdep/main-fn.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 01:39:45 +00:00
#include "common/av_log.h"
#include "common/codecs.h"
#include "common/encode.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 01:02:25 +00:00
#include "options/m_config.h"
#include "options/m_option.h"
#include "options/m_property.h"
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 01:39:45 +00:00
#include "common/common.h"
#include "common/msg.h"
msg: move special declarations to msg_control.h While almost everything uses msg.h, the moved definitions are rarely needed by anything.
2014-01-16 20:24:39 +00:00
#include "common/msg_control.h"
stats: some more performance graphs Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
2020-04-08 22:27:54 +00:00
#include "common/stats.h"
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 01:39:45 +00:00
#include "common/global.h"
video: make decoder wrapper a filter Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
2018-01-28 09:08:45 +00:00
#include "filters/f_decoder_wrapper.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 01:02:25 +00:00
#include "options/parse_configfile.h"
#include "options/parse_commandline.h"
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 01:39:45 +00:00
#include "common/playlist.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 01:02:25 +00:00
#include "options/options.h"
options: expand ~ for the include option Fixes #1406
2014-12-30 08:23:36 +00:00
#include "options/path.h"
Move mpvcore/input/ to input/
2013-12-17 00:23:09 +00:00
#include "input/input.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "audio/out/ao.h"
Reduce stheader.h includes, move stream types to mp_common.h
2013-11-23 21:08:42 +00:00
#include "demux/demux.h"
misc: move mp_cancel from stream.c to thread_tools.c It seems a bit inappropriate to have dumped this into stream.c, even if it's roughly speaking its main user. At least it made its way somewhat unfortunately to other components not related to the stream or demuxer layer at all. I'm too greedy to give this weird helper its own file, so dump it into thread_tools.c. Probably a somewhat pointless change.
2018-05-17 18:58:49 +00:00
#include "misc/thread_tools.h"
Rename sub.c/.h to osd.c/.h This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
2013-11-24 11:58:06 +00:00
#include "sub/osd.h"
test: merge test_helpers.c and index.c No need to keep them separate. Originally I thought index.c was only going to contain the list of tests, but that didn't happen.
2019-11-08 13:35:35 +00:00
#include "test/tests.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "video/out/vo.h"
Rename mp_core.h to core.h Get rid of the mp_ prefix.
2013-12-17 00:08:53 +00:00
#include "core.h"
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
#include "client.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#include "command.h"
#include "screenshot.h"
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
static const char def_config[] =
#include "player/builtin_conf.inc"
;
libmpv/cocoa: make global events work and get rid of is_cplayer After @frau's split of macosx_events from macosx_application, `is_cplayer' is not needed anymore. At the moment only global events such as Media Keys and Apple Remote work, because the VO-level ones were hardcoded to be disabled. (that will be fix in a later commit ).
2014-10-09 19:02:47 +00:00
#if HAVE_COCOA
cocoa: move set_input_context to macosx_events
2014-04-16 02:33:58 +00:00
#include "osdep/macosx_events.h"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
#endif
player: print config.h contents in verbose mode It was requested that mpv should print what features etc. have been enabled at compile time. It can print the configure command line, but it obviously doesn't include autodetected features. I tried to think of a nicer way than dumping the config.h as text, but this was still the simplest way.
2015-01-02 02:06:06 +00:00
#ifndef FULLCONFIG
#define FULLCONFIG "(missing)\n"
#endif
atomic: remove __atomic builtin usage Using these was a temporary solution while some compilers implemented the underlying atomic mechanisms, but not the C11 language parts (or that's what I guess). Not really useful for us anymore. Also, there is the slight risk of having subtly incorrect semantics by using potentially changing compiler internals and such.
2017-02-13 05:45:40 +00:00
#if !HAVE_STDATOMIC
atomics: readd some emulation This time it's emulation that's supposed to work (not just dummied out). Unlike the previous emulation, no mpv code has to be disabled, and everything should work (albeit possibly a bit slowly). On the other hand, it's not possible to implement this kind of emulation without compiler support. We use GNU statement expressions and __typeof__ in this case. This code is inactive if stdatomic.h is available.
2016-09-06 18:13:30 +00:00
pthread_mutex_t mp_atomic_mutex = PTHREAD_MUTEX_INITIALIZER;
#endif
player: improve exit message in some scenarios If you played e.g. an audio-only file and something bad happened that interrupted playback, the exit message could say "No files played". This was awkward, so show a different message in this case. Also overhaul how the exit status is reported in order to make this easier. This includes things such as not reporting a playback error when loading playlists (playlists contain no video or audio, which was considered an error). Not sure if I'm happy with this, but for now it seems like a slight improvement.
2014-10-30 22:54:06 +00:00
enum exit_reason {
EXIT_NONE,
EXIT_NORMAL,
EXIT_ERROR,
};
Remove the _ macro This was a gettext-style macro to mark strings that should be translated.
2013-12-18 16:12:07 +00:00
const char mp_help_text[] =
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
"Usage: mpv [options] [url|path/]filename\n"
"\n"
"Basic options:\n"
" --start=<time> seek to given (percent, seconds, or hh:mm:ss) position\n"
" --no-audio do not play sound\n"
" --no-video do not play video\n"
" --fs fullscreen playback\n"
options: rename subtitle-related options --ass → --sub-ass --autosub → --sub-auto --autosub-match → --sub-auto-match --sub → --sub-file --subcp → --sub-codepage --subfps → --sub-fps
2014-04-24 15:42:54 +00:00
" --sub-file=<file> specify subtitle file to use\n"
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
" --playlist=<file> specify playlist file\n"
"\n"
" --list-options list all mpv options\n"
options: change --h=... behavior Does not match a shell pattern anymore. Instead, a simple sub-string search is done.
2016-12-16 15:09:10 +00:00
" --h=<string> print options which contain the given string in their name\n"
Remove the _ macro This was a gettext-style macro to mark strings that should be translated.
2013-12-18 16:12:07 +00:00
"\n";
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
client API: allow multiple mpv instances with terminal=yes This is simply not allowed, and doing it triggered an assertion. It's still not allowed, because the terminal and related functionality is a global resource, and there doesn't seem to be a sane way to manage the signal handlers. But be a bit nicer, and just the terminal if it's already in use. Note that terminal _output_ happens anyway. This becomes usable with this commit. To facilitate logging-only usage further, also explicitly disable terminal input, so that "terminal=yes" can be used for logging without much interference with other things. (It'll still overwrite some signal handlers, though.)
2014-12-02 19:35:18 +00:00
static pthread_mutex_t terminal_owner_lock = PTHREAD_MUTEX_INITIALIZER;
static struct MPContext *terminal_owner;
static bool cas_terminal_owner(struct MPContext *old, struct MPContext *new)
{
pthread_mutex_lock(&terminal_owner_lock);
bool r = terminal_owner == old;
if (r)
terminal_owner = new;
pthread_mutex_unlock(&terminal_owner_lock);
return r;
}
player: enable reading from stdin after loading input.conf Someone requested this.
2016-09-29 14:26:54 +00:00
void mp_update_logging(struct MPContext *mpctx, bool preinit)
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
{
player: make sure version information is always included in --log-file If --log-file was used in config files, this could be missing due to the exact timing when the messages are print, and when the options are applied. Fix this by always dumping the version again when a log file is opened.
2017-05-22 16:30:39 +00:00
bool had_log_file = mp_msg_has_log_file(mpctx->global);
player: get rid of mpv_global.opts This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
2018-05-21 14:25:52 +00:00
mp_msg_update_msglevels(mpctx->global, mpctx->opts);
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
bool enable = mpctx->opts->use_terminal;
bool enabled = cas_terminal_owner(mpctx, mpctx);
if (enable != enabled) {
if (enable && cas_terminal_owner(NULL, mpctx)) {
terminal_init();
player: enable reading from stdin after loading input.conf Someone requested this.
2016-09-29 14:26:54 +00:00
enabled = true;
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
} else if (!enable) {
terminal_uninit();
cas_terminal_owner(mpctx, NULL);
}
}
player: make sure version information is always included in --log-file If --log-file was used in config files, this could be missing due to the exact timing when the messages are print, and when the options are applied. Fix this by always dumping the version again when a log file is opened.
2017-05-22 16:30:39 +00:00
if (mp_msg_has_log_file(mpctx->global) && !had_log_file)
mp_print_version(mpctx->log, false); // for log-file=... in config files
player: enable reading from stdin after loading input.conf Someone requested this.
2016-09-29 14:26:54 +00:00
if (enabled && !preinit && mpctx->opts->consolecontrols)
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
terminal_setup_getch(mpctx->input);
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
}
m_option, m_config: mp_msg conversions Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
2013-12-21 18:45:42 +00:00
void mp_print_version(struct mp_log *log, int always)
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
{
int v = always ? MSGL_INFO : MSGL_V;
build: move copyright statement to a shared location Now macosx_menubar.m and mpv.rc (win32) use the same copyright string. (This is a bit roundabout, because mpv.rc can't use C constants. Also the C code wants to avoid rebuilding real source files if only version.h changed, so only version.c includes version.h.)
2018-01-01 11:16:42 +00:00
mp_msg(log, v, "%s %s\n built on %s\n",
mpv_version, mpv_copyright, mpv_builddate);
player: rearrange libav* library check No need to be nice. Also hopefully breaks idiotic distro patches.
2020-03-08 17:54:01 +00:00
check_library_versions(log, v);
msg: rename mp_msg_log -> mp_msg Same for companion functions.
2013-12-21 20:49:13 +00:00
mp_msg(log, v, "\n");
player: print config.h contents in verbose mode It was requested that mpv should print what features etc. have been enabled at compile time. It can print the configure command line, but it obviously doesn't include autodetected features. I tried to think of a nicer way than dumping the config.h as text, but this was still the simplest way.
2015-01-02 02:06:06 +00:00
// Only in verbose mode.
if (!always) {
mp_msg(log, MSGL_V, "Configuration: " CONFIGURATION "\n");
player: dump list of satisfied deps instead of config.h with -v Starting to get tired of seeing the full config.h in verbose output every time. Make it slightly more elegant by outputting the list of satisfied dependencies instead.
2015-03-11 22:33:05 +00:00
mp_msg(log, MSGL_V, "List of enabled features: %s\n", FULLCONFIG);
main: fix typo What the heck. This negated the entire check.
2018-01-01 10:29:13 +00:00
#ifdef NDEBUG
player: log if NDEBUG is defined I sure want to know whether assert()s were unexpectedly not compiled in.
2017-11-04 16:48:30 +00:00
mp_msg(log, MSGL_V, "Built with NDEBUG.\n");
#endif
player: print config.h contents in verbose mode It was requested that mpv should print what features etc. have been enabled at compile time. It can print the configure command line, but it obviously doesn't include autodetected features. I tried to think of a nicer way than dumping the config.h as text, but this was still the simplest way.
2015-01-02 02:06:06 +00:00
}
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
void mp_destroy(struct MPContext *mpctx)
{
client API: cleanup mpv_handle termination This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
2018-03-09 03:46:09 +00:00
mp_shutdown_clients(mpctx);
client API: fix init/destruction race conditions mp_new_client() blatantly accessed some mutex-protected state outside of the mutex. The destruction code is in theory OK, but with changes in the following commits it'll be a bit hard to guarantee that it stays this way. Add a simple flag that makes adding new clients impossible, so that having no clients after shutdown_clients() remains guaranteed.
2016-09-21 13:55:34 +00:00
player: adjust uninit order of components Most things should be allowed to access the client API unconditionally (for example for sending events), so move destroying the client API down. Also, mp_uninit_ipc() should happen before the point at which all clients are shutdown, or there will be a small time window in which new clients can be created after destroying them all.
2014-10-24 13:34:04 +00:00
mp_uninit_ipc(mpctx->ipc_ctx);
mpctx->ipc_ctx = NULL;
player: remove central uninit_player() function and flags mess Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
2014-10-03 17:57:49 +00:00
uninit_audio_out(mpctx);
uninit_video_out(mpctx);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
encode: rewrite half of it The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
2018-04-22 17:40:36 +00:00
// If it's still set here, it's an error.
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
encode_lavc_free(mpctx->encode_lavc_ctx);
mpctx->encode_lavc_ctx = NULL;
command_uninit(mpctx);
player: adjust uninit order of components Most things should be allowed to access the client API unconditionally (for example for sending events), so move destroying the client API down. Also, mp_uninit_ipc() should happen before the point at which all clients are shutdown, or there will be a small time window in which new clients can be created after destroying them all.
2014-10-24 13:34:04 +00:00
mp_clients_destroy(mpctx);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
osd_free(mpctx->osd);
osx: move code to unset input context to the right place Setting the input context is always called, both in cplayer and libmpv, and under HAVE_COCOA. Unsetting the input context was done only the cplayer uninit call. Also it was under HAVE_COCOA_APPLICATION, so it was not unset in libmpv (dangling pointer).
2015-02-12 17:39:47 +00:00
#if HAVE_COCOA
cocoa_set_input_context(NULL);
#endif
client API: allow multiple mpv instances with terminal=yes This is simply not allowed, and doing it triggered an assertion. It's still not allowed, because the terminal and related functionality is a global resource, and there doesn't seem to be a sane way to manage the signal handlers. But be a bit nicer, and just the terminal if it's already in use. Note that terminal _output_ happens anyway. This becomes usable with this commit. To facilitate logging-only usage further, also explicitly disable terminal input, so that "terminal=yes" can be used for logging without much interference with other things. (It'll still overwrite some signal handlers, though.)
2014-12-02 19:35:18 +00:00
if (cas_terminal_owner(mpctx, mpctx)) {
terminal: some cleanups In particular, remove all the stupid debug printfs from the win code.
2014-08-21 20:13:10 +00:00
terminal_uninit();
client API: allow multiple mpv instances with terminal=yes This is simply not allowed, and doing it triggered an assertion. It's still not allowed, because the terminal and related functionality is a global resource, and there doesn't seem to be a sane way to manage the signal handlers. But be a bit nicer, and just the terminal if it's already in use. Note that terminal _output_ happens anyway. This becomes usable with this commit. To facilitate logging-only usage further, also explicitly disable terminal input, so that "terminal=yes" can be used for logging without much interference with other things. (It'll still overwrite some signal handlers, though.)
2014-12-02 19:35:18 +00:00
cas_terminal_owner(mpctx, NULL);
client API: fix terminal usage By default this is disabled. But if it's enabled, then we have to account for proper states when enabling/disabling the terminal state itself.
2014-06-06 15:28:13 +00:00
}
terminal: some cleanups In particular, remove all the stupid debug printfs from the win code.
2014-08-21 20:13:10 +00:00
mp_input_uninit(mpctx->input);
av_log: mp_msg conversion This is pretty nasty, because FFmpeg/Libav is yet another library with a global message callback. We do something with mutexes trying to get it done, but of course we can't actually solve this problem. If more than one library in a process use FFmpeg/Libav, only one of them will get log messages.
2013-12-21 19:06:36 +00:00
uninit_libav(mpctx->global);
player: don't temporarily disable terminal handling when reloading files There's no reason why we should do this. For some reason, the existing code reset terminal handling to default after unloading a file, just to initialize it again when loading a new file. Might be related to github issue #412, although I don't think it helps, since the default SIGTERM handler _should_ kill the mpv process. (It's still a nice simplification, though.)
2013-12-15 17:04:13 +00:00
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
mp_msg_uninit(mpctx->global);
command: add a way to abort asynchronous commands Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
2018-05-12 16:46:37 +00:00
assert(!mpctx->num_abort_list);
talloc_free(mpctx->abort_list);
player: rename "lock" to "abort_lock" If a struct as large as MPContext contains a field named "lock", it creates the impression that it is the primary lock for MPContext. This is wrong, the lock just protects a single field.
2018-05-12 14:51:53 +00:00
pthread_mutex_destroy(&mpctx->abort_lock);
player: change m_config to use new option handling mechanisms Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
2019-11-29 11:49:15 +00:00
talloc_free(mpctx->mconfig); // destroy before dispatch
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
talloc_free(mpctx);
}
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
static bool handle_help_options(struct MPContext *mpctx)
{
struct MPOpts *opts = mpctx->opts;
codecs: mp_msg conversion
2013-12-21 17:46:24 +00:00
struct mp_log *log = mpctx->log;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
if ((opts->demuxer_name && strcmp(opts->demuxer_name, "help") == 0) ||
(opts->audio_demuxer_name && strcmp(opts->audio_demuxer_name, "help") == 0) ||
(opts->sub_demuxer_name && strcmp(opts->sub_demuxer_name, "help") == 0)) {
demux: mp_msg conversions The TV code pretends to be part of stream/, but it's actually demuxer code too. The audio_in code is shared between the TV code and stream_radio.c, so stream_radio.c needs a small hack until stream.c is converted.
2013-12-21 19:24:20 +00:00
demuxer_help(log);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
MP_INFO(mpctx, "\n");
player: revert multiple help output 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.
2017-06-23 13:20:43 +00:00
return true;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}
ao: use a local option struct Instead of accessing MPOpts.
2018-05-21 13:11:19 +00:00
if (opts->ao_opts->audio_device &&
strcmp(opts->ao_opts->audio_device, "help") == 0)
{
audio: change internal device listing API Now we run ao_driver->list_devs on a dummy AO instance, which will probably confuse everyone. This is done for the sake of PulseAudio.
2014-10-10 16:27:21 +00:00
ao_print_devices(mpctx->global, log);
player: revert multiple help output 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.
2017-06-23 13:20:43 +00:00
return true;
audio: add device selection & listing with --audio-device Not sure how good of an idea this is. This commit doesn't add support for this to any AO yet; the AO implementations will follow later.
2014-10-09 19:21:31 +00:00
}
command: add options to property list Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
2016-09-01 18:00:43 +00:00
if (opts->property_print_help) {
property_print_help(mpctx);
player: revert multiple help output 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.
2017-06-23 13:20:43 +00:00
return true;
command: add options to property list Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
2016-09-01 18:00:43 +00:00
}
encode: make option struct local Similar to previous commits.
2014-06-11 00:04:02 +00:00
if (encode_lavc_showhelp(log, opts->encode_opts))
player: revert multiple help output 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.
2017-06-23 13:20:43 +00:00
return true;
return false;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}
m_config: add custom context to includefunc callback
2013-12-21 18:27:19 +00:00
static int cfg_include(void *ctx, char *filename, int flags)
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
{
m_config: add custom context to includefunc callback
2013-12-21 18:27:19 +00:00
struct MPContext *mpctx = ctx;
options: expand ~ for the include option Fixes #1406
2014-12-30 08:23:36 +00:00
char *fname = mp_get_user_path(NULL, mpctx->global, filename);
int r = m_config_parse_config_file(mpctx->mconfig, fname, NULL, flags);
talloc_free(fname);
return r;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}
player: move locale check to mp_create() The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
2018-03-09 03:10:28 +00:00
// We mostly care about LC_NUMERIC, and how "." vs. "," is treated,
// Other locale stuff might break too, but probably isn't too bad.
static bool check_locale(void)
{
char *name = setlocale(LC_NUMERIC, NULL);
return !name || strcmp(name, "C") == 0 || strcmp(name, "C.UTF-8") == 0;
}
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
struct MPContext *mp_create(void)
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
{
player: move locale check to mp_create() The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
2018-03-09 03:10:28 +00:00
if (!check_locale()) {
// Normally, we never print anything (except if the "terminal" option
// is enabled), so this is an exception.
fprintf(stderr, "Non-C locale detected. This is not supported.\n"
"Call 'setlocale(LC_NUMERIC, \"C\");' in your code.\n");
return NULL;
}
player: minor changes in init code Move the MPV_LEAK_REPORT env query to mp_create(), where it will also be used by the client API (it might be helpful, so why not). The same applies to MPV_VERBOSE. The prepare_playlist() call doesn't need to be in mp_initialize() and can just be in mp_play_files() to reduce the size of mp_initialize(). Also, remove wakeup_playloop(), which is 100% redundant with mp_wakeup_core_cb().
2016-09-19 17:57:31 +00:00
char *enable_talloc = getenv("MPV_LEAK_REPORT");
wscript: add --enable-ta-leak-report option Kind of more convenient because I'm lazy.
2019-11-07 23:43:46 +00:00
if (!enable_talloc)
enable_talloc = HAVE_TA_LEAK_REPORT ? "1" : "0";
if (strcmp(enable_talloc, "1") == 0)
player: minor changes in init code Move the MPV_LEAK_REPORT env query to mp_create(), where it will also be used by the client API (it might be helpful, so why not). The same applies to MPV_VERBOSE. The prepare_playlist() call doesn't need to be in mp_initialize() and can just be in mp_play_files() to reduce the size of mp_initialize(). Also, remove wakeup_playloop(), which is 100% redundant with mp_wakeup_core_cb().
2016-09-19 17:57:31 +00:00
talloc_enable_leak_report();
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
mp_time_init();
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
struct MPContext *mpctx = talloc(NULL, MPContext);
*mpctx = (struct MPContext){
client API: add chapter change event Also works for mpv_observe_property() on the "chapter" property.
2014-04-27 20:28:07 +00:00
.last_chapter = -2,
player: redo terminal OSD and status line handling The terminal OSD code includes the handling of the terminal status line, showing player OSD messages on the terminal, and showing subtitles on terminal (the latter two only if there is no video window, or if terminal OSD is forced). This didn't handle some corner cases correctly. For example, showing an OSD message on the terminal always cleared the previous line, even if the line was an important message (or even just the command prompt, if most other messages were silenced). Attempt to handle this correctly by keeping track of how many lines the terminal OSD currently consists of. Since there could be race conditions with other messages being printed, implement this in msg.c. Now msg.c expects that MSGL_STATUS messages rewrite the status line, so the caller is forced to use a single mp_msg() call to set the status line. Instead of littering print_status() all over the place, update the status only once per playloop iteration in update_osd_msg(). In audio- only mode, the status line might now be a little bit off, but it's perhaps ok. Print the status line only if it has changed, or if another message was printed. This might help with extremely slow terminals, although in audio+video mode, it'll still be updated very often (A-V sync display changes on every frame). Instead of hardcoding the terminal sequences, use terminfo/termcap to get the sequences. Remove the --term-osd-esc option, which allowed to override the hardcoded escapes - it's useless now. The fallback for terminals with no escape sequences for moving the cursor and clearing a line is removed. This somewhat breaks status line display on these terminals, including the MS Windows console: instead of querying the terminal size and clearing the line manually by padding the output with spaces, the line is simply not cleared. I don't expect this to be a problem on UNIX, and on MS Windows we could emulate escape sequences. Note that terminal OSD (other than the status line) was broken anyway on these terminals. In osd.c, the function get_term_width() is not used anymore, so remove it. To remind us that the MS Windows console apparently adds a line break when writint the last column, adjust screen_width in terminal- win.c accordingly.
2014-01-13 19:05:41 +00:00
.term_osd_contents = talloc_strdup(mpctx, ""),
player: fix initial osd progbar state This made seeking show an empty progbar if --osd-level=0 was used.
2014-01-20 18:29:15 +00:00
.osd_progbar = { .type = -1 },
player, ta: remove use of an old macro I thought that would make a nice idiom, but it ended up being useless or clunky.
2020-04-10 21:12:41 +00:00
.playlist = talloc_zero(mpctx, struct playlist),
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
.dispatch = mp_dispatch_create(mpctx),
stream: redo playback abort handling This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
2014-09-13 12:23:08 +00:00
.playback_abort = mp_cancel_new(mpctx),
command: add infrastructure for async commands This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
2018-05-06 16:27:18 +00:00
.thread_pool = mp_thread_pool_create(mpctx, 0, 1, 30),
player: fix subtle idle mode differences on early program start If the user manages to run a "loadfile x append" command before the loop in mp_play_files() is entered, then the player could start playing these. This isn't expected, because appending files to the playlist in idle mode does not normally start playback. It could happen because there is a short time window where commands are processed before the loop is entered (such as running the command when a script is loaded). The idle mode semantics are pretty weird: if files were provided in advance (on the command line), then these should be played immediately. But if idle mode was already entered, and something is appended to the playlist using "append", i.e. without explicitly triggering playback, then it should remain in idle mode. Try to follow this by redefining PT_STOP to strictly mean idle mode. Remove the playlist->current check from idle_loop(), since only the stop_play field counts now (cf. what mp_set_playlist_entry() does). This actually introduces the possibility that playlist->current, and with it playlist-pos, are set to something, even though playback is not active or being started. Previously, this was only possible during state transitions, such as when changing playlist entries. Very annoyingly, this means the current way MPV_EVENT_IDLE was sent doesn't work anymore. Logically, idle mode can be "active" even if idle_loop() was not entered yet (between the time after mp_initialize() and before the loop in mp_play_files()). Instead of worrying about this, redo the "idle-active" property, and deprecate the event. See: #7543
2020-03-21 13:01:38 +00:00
.stop_play = PT_NEXT_ENTRY,
Implement backwards playback See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
.play_dir = 1,
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
};
player: rename "lock" to "abort_lock" If a struct as large as MPContext contains a field named "lock", it creates the impression that it is the primary lock for MPContext. This is wrong, the lock just protects a single field.
2018-05-12 14:51:53 +00:00
pthread_mutex_init(&mpctx->abort_lock, NULL);
player: actually initialize/destroy MPContext.lock Seems like quite on oversight. For most of the better pthread implementations, pthread_mutex_init() on an already 0-initialized memory block is probably a no-op, but of course we should do things correctly. Also could setup analysis tools.
2017-01-22 14:23:35 +00:00
m_option, m_config: mp_msg conversions Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
2013-12-21 18:45:42 +00:00
mpctx->global = talloc_zero(mpctx, struct mpv_global);
stats: some more performance graphs Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
2020-04-08 22:27:54 +00:00
stats_global_init(mpctx->global);
m_option, m_config: mp_msg conversions Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
2013-12-21 18:45:42 +00:00
// Nothing must call mp_msg*() and related before this
mp_msg_init(mpctx->global);
mpctx->log = mp_log_new(mpctx, mpctx->global->log, "!cplayer");
player: use separate msg prefix for statusline So the user can specifically mute or unmute the status line with --msglevel. Accidentally removed with commit 5e0c4ec3.
2013-12-21 21:00:26 +00:00
mpctx->statusline = mp_log_new(mpctx, mpctx->log, "!statusline");
m_option, m_config: mp_msg conversions Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
2013-12-21 18:45:42 +00:00
player, stats: more silly debug stuff In addition to stats.c being gross, I don't think master branch code should be littered with debug code. But it's a helpful abomination.
2020-04-09 22:55:39 +00:00
mpctx->stats = stats_ctx_create(mpctx, mpctx->global, "main");
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
// Create the config context and register the options
options: get rid of GLOBAL_CONFIG hack Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
2019-11-28 23:16:52 +00:00
mpctx->mconfig = m_config_new(mpctx, mpctx->log, &mp_opt_root);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
mpctx->opts = mpctx->mconfig->optstruct;
m_config: remove m_config_create_shadow A previous commit changed m_config so that it always creates the shadow thing, and the function's only remaining purpose was to initialize mpv_global. It makes much more sense to do that at the caller, and it's only 1 line of code too.
2019-07-12 23:22:37 +00:00
mpctx->global->config = mpctx->mconfig->shadow;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
mpctx->mconfig->includefunc = cfg_include;
m_config: add custom context to includefunc callback
2013-12-21 18:27:19 +00:00
mpctx->mconfig->includefunc_ctx = mpctx;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
mpctx->mconfig->use_profiles = true;
options: don't prefix sub-options with "--" in help output Commit 0cb9227a added this to the option list help output, but it looks strange with sub-options.
2013-11-23 20:35:03 +00:00
mpctx->mconfig->is_toplevel = true;
options: handle terminal/logging settings eagerly Update msg.c state immediately if a terminal or logging setting is set. Until now, this was delayed until mp[v]_initialize() was called. When using the client API, you could easily miss logged error messages, even when logging was initialized early on by calling mpv_request_log_messages(). (Properties can't be used for this either, because properties do not work before mpv_initialize().)
2015-11-04 14:44:37 +00:00
mpctx->mconfig->global = mpctx->global;
player: use config parser for setting up pseudo-gui profile
2015-04-10 18:40:50 +00:00
m_config_parse(mpctx->mconfig, "", bstr0(def_config), NULL, 0);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
player: use better way to wait for input and dispatching commands Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
2016-09-16 12:25:50 +00:00
mpctx->input = mp_input_init(mpctx->global, mp_wakeup_core_cb, mpctx);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
screenshot_init(mpctx);
command_init(mpctx);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
init_libav(mpctx->global);
mp_clients_init(mpctx);
client API: create core thread at an earlier time Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
2016-09-01 19:55:21 +00:00
mpctx->osd = osd_create(mpctx->global);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
player: set cocoa input context at an earlier point There is not much of a reason to do this later. (Since some time ago, the input_ctx is created right at the start, so this can be done now.)
2015-05-27 15:57:24 +00:00
#if HAVE_COCOA
cocoa_set_input_context(mpctx->input);
#endif
player: minor changes in init code Move the MPV_LEAK_REPORT env query to mp_create(), where it will also be used by the client API (it might be helpful, so why not). The same applies to MPV_VERBOSE. The prepare_playlist() call doesn't need to be in mp_initialize() and can just be in mp_play_files() to reduce the size of mp_initialize(). Also, remove wakeup_playloop(), which is 100% redundant with mp_wakeup_core_cb().
2016-09-19 17:57:31 +00:00
char *verbose_env = getenv("MPV_VERBOSE");
if (verbose_env)
mpctx->opts->verbose = atoi(verbose_env);
player: "subprocess" command should stop immediately in idle mode The description of the "playback_only" field in the "subprocess" command says "you can't start it outside of playback". This did not work correctly: if the player was started in idle mode in the first place, the subprocess was allowed to run even with playback_only=yes. This is a bug, and this change fixes it. Add a test for this to command-test.lua. For #7025.
2019-10-04 14:30:48 +00:00
mp_cancel_trigger(mpctx->playback_abort);
client API: create core thread at an earlier time Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
2016-09-01 19:55:21 +00:00
return mpctx;
client API: fix playloop thread wakeup The playloop usually waits in select(), using a timeout needed for refilling audio and video buffers. This means the client API needs a separate mechanism to interrupt the select() call. This mechanism exists, but I forgot to use it. This commit fixes it. If it works, this will make the client API react faster, epsecially in audio-only mode. If video is enabled, the reaction time is capped to 50ms (or somewhat faster if the framerate is >20 fps), because the playloop stops reacting to anything in order to render and time the next video frame. (This will be fixed later by moving the VO to its own thread.)
2014-03-01 14:46:39 +00:00
}
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
// Finish mpctx initialization. This must be done after setting up all options.
// Some of the initializations depend on the options, and can't be changed or
// undone later.
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
// If options is not NULL, apply them as command line player arguments.
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
// Returns: 0 on success, -1 on error, 1 if exiting normally (e.g. help).
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
int mp_initialize(struct MPContext *mpctx, char **options)
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
{
struct MPOpts *opts = mpctx->opts;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
assert(!mpctx->initialized);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
// Preparse the command line, so we can init the terminal early.
player: get rid of mpv_global.opts This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
2018-05-21 14:25:52 +00:00
if (options) {
m_config_preparse_command_line(mpctx->mconfig, mpctx->global,
&opts->verbose, options);
}
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
path: don't access global option struct The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
2018-05-21 13:49:19 +00:00
mp_init_paths(mpctx->global, opts);
player: remove mechanisms for better logging with repl.lua As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
2019-11-17 23:44:12 +00:00
mp_msg_set_early_logging(mpctx->global, true);
player: enable reading from stdin after loading input.conf Someone requested this.
2016-09-29 14:26:54 +00:00
mp_update_logging(mpctx, true);
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
if (options) {
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
MP_VERBOSE(mpctx, "Command line options:");
for (int i = 0; options[i]; i++)
MP_VERBOSE(mpctx, " '%s'", options[i]);
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
MP_VERBOSE(mpctx, "\n");
}
mp_print_version(mpctx->log, false);
mp_parse_cfgfiles(mpctx);
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
if (options) {
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
int r = m_config_parse_mp_command_line(mpctx->mconfig, mpctx->playlist,
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
mpctx->global, options);
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
if (r < 0)
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
return r == M_OPT_EXIT ? 1 : -1;
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
}
player: allow opts in pseudo-gui set by the user to override user's default This should still allow user-set default options to override built-in pseudo-gui while respecting user-set pseudo-gui options. Pros: - user option in default profile overrides built-in pseudo-gui's options Ex: screenshot-directory overrides built-in pseudo-gui's - user can "fix" pseudo-gui if some option like "force-window=no" is set in default by setting "force-window=yes" in [pseudo-gui] - `mpv --profile=pseudo-gui` will work as before Cons: - --show-profile=pseudo-gui won't display the built-in's options Original idea from wm4. Documentation edits mostly by wm4. Signed-off-by: wm4 <wm4@nowhere>
2016-09-23 22:36:17 +00:00
if (opts->operation_mode == 1) {
m_config_set_profile(mpctx->mconfig, "builtin-pseudo-gui",
M_SETOPT_NO_OVERWRITE);
m_config_set_profile(mpctx->mconfig, "pseudo-gui", 0);
}
player: fix intended pseudo-gui behavior It's still supposed to be possible to customize the pseudo-gui section.
2016-09-23 20:35:54 +00:00
options: make input options generally runtime-settable
2016-09-21 13:56:54 +00:00
mp_get_resume_defaults(mpctx);
player: enable reading from stdin after loading input.conf Someone requested this.
2016-09-29 14:26:54 +00:00
mp_input_load_config(mpctx->input);
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
// From this point on, all mpctx members are initialized.
mpctx->initialized = true;
mpctx->mconfig->option_change_callback = mp_option_change_callback;
mpctx->mconfig->option_change_callback_ctx = mpctx;
player: change m_config to use new option handling mechanisms Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
2019-11-29 11:49:15 +00:00
m_config_set_update_dispatch_queue(mpctx->mconfig, mpctx->dispatch);
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
// Run all update handlers.
player: change m_config to use new option handling mechanisms Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
2019-11-29 11:49:15 +00:00
mp_option_change_callback(mpctx, NULL, UPDATE_OPTS_MASK, false);
player: make --terminal freetly settable at runtime So client API users don't have to care about whether to set this before or after mpv_initialize(). We still don't enable terminal at any point before mpv_initialize(), because reasons. This also subtly changes some behavior how terminal options are applied while parsing. This essentially reverts the behavior as it was reported in issue #2588. Originally, I was hoping to get rid of the pre-parse option pass, but it seems this is absolutely not possible due to the way config and command line parsing are entangled. Command line options take priority over configfile options, so they have to be applied later - but we also want to apply logging and terminal options as specified on the command-line, but _before_ parsing the config files. It has to be this way to see config file error messages on the terminal, or to hide them if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 17:54:54 +00:00
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
if (handle_help_options(mpctx))
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
return 1; // help
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
player: rearrange libav* library check No need to be nice. Also hopefully breaks idiotic distro patches.
2020-03-08 17:54:01 +00:00
check_library_versions(mp_null_log, 0);
player: fatal error if linked and compiled FFmpeg versions mismatch We don't support this anymore. This tries to exit in a controlled way after command line options are applied in order to honor logging options and, in case of libmpv, not to kill the host. Not sure if it would be better to just vomit text to stderr and call abort().
2016-07-01 18:56:59 +00:00
player: do not require dummy file arguments to use --unittest Move the test execution above the point where it checks for an empty playlist and exits if that's the case.
2019-11-08 13:29:58 +00:00
#if HAVE_TESTS
if (opts->test_mode && opts->test_mode[0])
return run_tests(mpctx) ? 1 : -1;
#endif
playlist: change from linked list to an array Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
2019-12-28 20:12:02 +00:00
if (!mpctx->playlist->num_entries && !opts->player_idle_mode) {
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
// nothing to play
mp_print_version(mpctx->log, true);
MP_INFO(mpctx, "%s", mp_help_text);
return 1;
}
player, client API: refactor cplayer init, reduce client API differences Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
2015-03-05 10:17:22 +00:00
options: make input options generally runtime-settable
2016-09-21 13:56:54 +00:00
MP_STATS(mpctx, "start init");
osx: initial Touch Bar support
2017-02-25 20:56:59 +00:00
#if HAVE_COCOA
mpv_handle *ctx = mp_new_client(mpctx->clients, "osx");
cocoa_set_mpv_handle(ctx);
#endif
encode: make option struct local Similar to previous commits.
2014-06-11 00:04:02 +00:00
if (opts->encode_opts->file && opts->encode_opts->file[0]) {
encode: rewrite half of it The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
2018-04-22 17:40:36 +00:00
mpctx->encode_lavc_ctx = encode_lavc_init(mpctx->global);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
if(!mpctx->encode_lavc_ctx) {
player: add missing \n to a message
2015-07-13 21:55:26 +00:00
MP_INFO(mpctx, "Encoding initialization failed.\n");
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
return -1;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}
player: use profiles for libmpv and encoding defaults The client API (libmpv) and encoding (--o) have slightly different defaults from the command line player. Instead of doing a bunch of calls to set the options explicitly, use profiles. This is simpler and has the advantage that they can be listed on command line (instead of possibly forcing the user to find and read the code to know all the details).
2015-05-07 19:26:11 +00:00
m_config_set_profile(mpctx->mconfig, "encoding", 0);
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
mp_input_enable_section(mpctx->input, "encode", MP_INPUT_EXCLUSIVE);
}
player: make failure to load scripts non-fatal again Restore the behavior from a few commits ago. I decided that it's strange that this is fatal, since e.g. config file errors are also non-fatal.
2020-01-20 18:58:31 +00:00
mp_load_scripts(mpctx);
player: load scripts at an earlier point This is about as early as possible.
2015-05-27 15:53:58 +00:00
player: fix another --force-window bug Will this shit ever actually work? Fixes #2339.
2015-09-23 20:03:11 +00:00
if (opts->force_vo == 2 && handle_force_window(mpctx, false) < 0)
player: make force-window in auto-profiles actually work The previous commit was incomplete (and I didn't notice due to a broken test procedure). The annoying part is that actually creating the VO was separate; redo this and merge the code for this into handle_force_window() as well. This will also make implementing proper reaction to runtime option changes easier. (Only the part for actually listening to option changes is missing.)
2015-09-20 15:58:02 +00:00
return -1;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
player: fix subtle idle mode differences on early program start If the user manages to run a "loadfile x append" command before the loop in mp_play_files() is entered, then the player could start playing these. This isn't expected, because appending files to the playlist in idle mode does not normally start playback. It could happen because there is a short time window where commands are processed before the loop is entered (such as running the command when a script is loaded). The idle mode semantics are pretty weird: if files were provided in advance (on the command line), then these should be played immediately. But if idle mode was already entered, and something is appended to the playlist using "append", i.e. without explicitly triggering playback, then it should remain in idle mode. Try to follow this by redefining PT_STOP to strictly mean idle mode. Remove the playlist->current check from idle_loop(), since only the stop_play field counts now (cf. what mp_set_playlist_entry() does). This actually introduces the possibility that playlist->current, and with it playlist-pos, are set to something, even though playback is not active or being started. Previously, this was only possible during state transitions, such as when changing playlist entries. Very annoyingly, this means the current way MPV_EVENT_IDLE was sent doesn't work anymore. Logically, idle mode can be "active" even if idle_loop() was not entered yet (between the time after mp_initialize() and before the loop in mp_play_files()). Instead of worrying about this, redo the "idle-active" property, and deprecate the event. See: #7543
2020-03-21 13:01:38 +00:00
// Needed to properly enter _initial_ idle mode if playlist empty.
if (mpctx->opts->player_idle_mode && !mpctx->playlist->num_entries)
mpctx->stop_play = PT_STOP;
player: add a --dump-stats option This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
2014-04-17 19:47:00 +00:00
MP_STATS(mpctx, "end init");
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
return 0;
}
build: add option to build a library This library will export the client API functions. Note that this doesn't allow compiling the command line player to link against this library yet. The reason is that there's lots of weird stuff required to setup the execution environment (mostly Windows and OSX specifics), as well as things which are out of scope of the client API and every application has to do on its own. However, since the mpv command line player basically reuses functions from the mpv core to implement these things, it's not very easy to separate the command line player form the mpv core.
2014-02-10 20:25:22 +00:00
int mpv_main(int argc, char *argv[])
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
{
struct MPContext *mpctx = mp_create();
player: move locale check to mp_create() The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
2018-03-09 03:10:28 +00:00
if (!mpctx)
return 1;
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
client API: cleanup mpv_handle termination This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
2018-03-09 03:46:09 +00:00
mpctx->is_cli = true;
player: fix operation if command line is empty main() being called with argc==0 is probably possible. Fix by skipping the program name early. (I already changed and reverted this once, but this time we make sure that it's less likely to confuse the skipped argv with main()'s argv by naming it "options".)
2015-03-06 09:53:49 +00:00
char **options = argv && argv[0] ? argv + 1 : NULL; // skips program name
int r = mp_initialize(mpctx, options);
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
if (r == 0)
mp_play_files(mpctx);
int rc = 0;
const char *reason = NULL;
if (r < 0) {
reason = "Fatal error";
rc = 1;
} else if (r > 0) {
// nothing
} else if (mpctx->stop_play == PT_QUIT) {
reason = "Quit";
} else if (mpctx->files_played) {
if (mpctx->files_errored || mpctx->files_broken) {
reason = "Some errors happened";
rc = 3;
} else {
reason = "End of file";
}
} else if (mpctx->files_broken && !mpctx->files_errored) {
reason = "Errors when loading file";
rc = 2;
} else if (mpctx->files_errored) {
reason = "Interrupted by error";
rc = 2;
} else {
reason = "No files played";
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
}
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
if (reason)
player: remove additional newline before exit message What was this even for? Also, most times, the cleared status line will show up as an empty new line anyway, so this commit reduces the empty new lines from 2 to 1.
2020-03-21 12:09:41 +00:00
MP_INFO(mpctx, "Exiting... (%s)\n", reason);
player: shuffle around CLI exit code handling Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
2018-03-09 03:07:34 +00:00
if (mpctx->has_quit_custom_rc)
rc = mpctx->quit_custom_rc;
mp_destroy(mpctx);
return rc;
Split mplayer.c mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
2013-10-29 21:38:29 +00:00
}