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

1308 lines
42 KiB
C
Raw Permalink 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
*/
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include <assert.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 <inttypes.h>
#include <math.h>
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include <stdbool.h>
#include <stddef.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
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "client.h"
#include "command.h"
#include "core.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"
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "screenshot.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
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "audio/out/ao.h"
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 01:39:45 +00:00
#include "common/common.h"
#include "common/encode.h"
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "common/msg.h"
#include "common/playlist.h"
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
#include "common/stats.h"
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "demux/demux.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"
audio: refactor how data is passed to AO This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
2020-08-28 18:23:54 +00:00
#include "filters/filter_internal.h"
Move mpvcore/input/ to input/
2013-12-17 00:23:09 +00:00
#include "input/input.h"
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"
player/playloop.c: reorder included headers per contribute.md This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
2020-08-31 20:45:04 +00:00
#include "options/m_config_frontend.h"
#include "options/m_property.h"
#include "options/options.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"
#include "stream/stream.h"
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
#include "sub/dec_sub.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"
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"
player, ao, vo: don't call mp_input_wakeup() directly Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
2016-09-16 12:23:54 +00:00
// Wait until mp_wakeup_core() is called, since the last time
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
// mp_wait_events() was called.
void mp_wait_events(struct MPContext *mpctx)
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +00:00
{
client API: rewrite property observation (again) I intend to rewrite this code approximately every 2 months. Last time, I did this in commit d66eb93e5d4 (and 065c307e8e7 and b2006eeb74f). It was intended to remove the roundabout synchronous thread "ping pong" when observing properties. At first, the original async. code was replaced with some nice mostly synchronous code. But then an async. code path had to be added for vo_libmpv, and finally the sync. code was dropped because it broke in other obscure cases (like the Objective-C Cocoa backend). Try again. This time, update properties entirely on the main thread. Updates get batched out on every playloop iteration. (At first I wanted it to make it every time the player goes to sleep, but that might starve API clients if the playloop get saturated.) One nice thing is that clients only get woken up once all changed events have been sent, which might reduce overhead. While this sounds simple, it's not. The main problem is that reading properties must not block the client API, i.e. no client API locks can be held while reading the property. Maybe eventually we can avoid this requirement, but currently it's just a fact. This means we have to iterate over all clients and then over all properties (of each client), all while releasing all locks when updating a property. Solve this by rechecking on each iteration whether the list changed, and if so, aborting the iteration and redo it "next time". High risk change, expect bugs such as crashes and missing property updates.
2019-12-19 10:11:51 +00:00
mp_client_send_property_changes(mpctx);
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
stats_event(mpctx->stats, "iterations");
player: fix stats-logging of sleep state
2017-02-21 14:16:38 +00:00
bool sleeping = mpctx->sleeptime > 0;
if (sleeping)
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
MP_STATS(mpctx, "start sleep");
mp_dispatch_queue_process(mpctx->dispatch, mpctx->sleeptime);
mpctx->sleeptime = INFINITY;
player: fix stats-logging of sleep state
2017-02-21 14:16:38 +00:00
if (sleeping)
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
MP_STATS(mpctx, "end sleep");
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +00:00
}
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
// Set the timeout used when the playloop goes to sleep. This means the
// playloop will re-run as soon as the timeout elapses (or earlier).
// mp_set_timeout(c, 0) is essentially equivalent to mp_wakeup_core(c).
void mp_set_timeout(struct MPContext *mpctx, double sleeptime)
{
player: remove in_dispatch field (Not sure if worth the trouble, but it does seem less awkward.)
2018-04-15 09:43:49 +00:00
if (mpctx->sleeptime > sleeptime) {
mpctx->sleeptime = sleeptime;
dispatch: change mp_dispatch_queue_process timer to nanoseconds The playloop is the only thing that adjusts the timeout with a value other than 0, so nothing else needs to be changed.
2023-10-11 19:32:48 +00:00
int64_t abstime = mp_time_ns_add(mp_time_ns(), sleeptime);
player: remove in_dispatch field (Not sure if worth the trouble, but it does seem less awkward.)
2018-04-15 09:43:49 +00:00
mp_dispatch_adjust_timeout(mpctx->dispatch, abstime);
}
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
}
player, ao, vo: don't call mp_input_wakeup() directly Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
2016-09-16 12:23:54 +00:00
// Cause the playloop to run. This can be called from any thread. If called
// from within the playloop itself, it will be run immediately again, instead
// of going to sleep in the next mp_wait_events().
void mp_wakeup_core(struct MPContext *mpctx)
{
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
mp_dispatch_interrupt(mpctx->dispatch);
player, ao, vo: don't call mp_input_wakeup() directly Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
2016-09-16 12:23:54 +00:00
}
// Opaque callback variant of mp_wakeup_core().
void mp_wakeup_core_cb(void *ctx)
{
struct MPContext *mpctx = ctx;
mp_wakeup_core(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
void mp_core_lock(struct MPContext *mpctx)
{
mp_dispatch_lock(mpctx->dispatch);
}
void mp_core_unlock(struct MPContext *mpctx)
{
mp_dispatch_unlock(mpctx->dispatch);
}
player: fix an outdated comment The client API doesn't use input_ctx anymore, and the "wakeup" flag is gone (if it even existed at all).
2019-12-14 13:18:40 +00:00
// Process any queued user input.
player: make a function static
2020-04-03 10:56:50 +00:00
static void mp_process_input(struct MPContext *mpctx)
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +00:00
{
command: add internal INPUT_PROCESSED event Fires after a non-empty input queue was processed. Currently yet unused, but the next commit will use it.
2020-07-23 12:35:56 +00:00
int processed = 0;
player: some more input refactoring Continues commit 348dfd93. Replace other places where input was manually fetched with common code. demux_was_interrupted() was a weird function; I'm not entirely sure about its original purpose, but now we can just replace it with simpler code as well. One difference is that we always look at the command queue, rather than just when cache initialization failed. Also, instead of discarding all but quit/playlist commands (aka abort command), run all commands. This could possibly lead to unwanted side-effects, like just ignoring commands that have no effect (consider pressing 'f' for fullscreen right on start: since the window is not created yet, it would get discarded). But playlist navigation still works as intended, and some if not all these problems already existed before that in some forms, so it should be ok.
2014-09-07 18:44:54 +00:00
for (;;) {
mp_cmd_t *cmd = mp_input_read_cmd(mpctx->input);
if (!cmd)
break;
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
run_command(mpctx, cmd, NULL, NULL, NULL);
command: add internal INPUT_PROCESSED event Fires after a non-empty input queue was processed. Currently yet unused, but the next commit will use it.
2020-07-23 12:35:56 +00:00
processed = 1;
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +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
mp_set_timeout(mpctx, mp_input_get_delay(mpctx->input));
command: add internal INPUT_PROCESSED event Fires after a non-empty input queue was processed. Currently yet unused, but the next commit will use it.
2020-07-23 12:35:56 +00:00
if (processed)
mp_notify(mpctx, MP_EVENT_INPUT_PROCESSED, NULL);
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +00:00
}
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
double get_relative_time(struct MPContext *mpctx)
{
player: store last_time timestamp in nanoseconds
2023-09-18 01:05:16 +00:00
int64_t new_time = mp_time_ns();
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
int64_t delta = new_time - mpctx->last_time;
mpctx->last_time = new_time;
player: store last_time timestamp in nanoseconds
2023-09-18 01:05:16 +00:00
return delta * 1e-9;
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
}
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
void update_core_idle_state(struct MPContext *mpctx)
{
bool eof = mpctx->video_status == STATUS_EOF &&
mpctx->audio_status == STATUS_EOF;
player: change the role of the "stop_play" and "playing" variable Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
2018-05-19 16:25:54 +00:00
bool active = !mpctx->paused && mpctx->restart_complete &&
player: fix core activity state check Adds the negation missed in 8816e1117ee65039dbb5700219ba3537d3e5290e when moving from a positive-is-active to positive-is-idle variable. This leads to proper updates to properties such as "eof-reached", as well as fixes screensaver state updates. Separately found and fixed by avih and wnoun. Co-authored-by: wnoun <wnoun@outlook.com>
2019-03-11 17:15:55 +00:00
!mpctx->stop_play && mpctx->in_playloop && !eof;
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
if (mpctx->playback_active != active) {
mpctx->playback_active = active;
update_screensaver_state(mpctx);
mp_notify(mpctx, MP_EVENT_CORE_IDLE, NULL);
}
}
player: fix video paused condition on VO creation Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
2020-08-27 09:43:06 +00:00
bool get_internal_paused(struct MPContext *mpctx)
{
return mpctx->opts->pause || mpctx->paused_for_cache;
}
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
// The value passed here is the new value for mpctx->opts->pause
void set_pause_state(struct MPContext *mpctx, bool user_pause)
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: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +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
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
opts->pause = user_pause;
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
player: fix video paused condition on VO creation Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
2020-08-27 09:43:06 +00:00
bool internal_paused = get_internal_paused(mpctx);
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
if (internal_paused != mpctx->paused) {
mpctx->paused = internal_paused;
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
audio: drain ao before setting pause There's an edge cause with gapless audio and pausing. Since, gapless audio works by sending an EOF immediately, it's possible to pause on the next file before audio actually finishes playing and thus the sound gets cut off. The fix is to simply just always do an ao_drain if the ao is about to set a pause on EOF and we still have audio playing. Fixes #8898.
2023-08-10 03:50:05 +00:00
if (mpctx->ao) {
bool eof = mpctx->audio_status == STATUS_EOF;
ao_set_paused(mpctx->ao, internal_paused, eof);
}
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: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
if (mpctx->video_out)
vo_set_paused(mpctx->video_out, internal_paused);
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: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
mpctx->osd_function = 0;
mpctx->osd_force_update = 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
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
mp_wakeup_core(mpctx);
video: add VO framedropping mode This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
2014-08-15 21:33:33 +00:00
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
if (internal_paused) {
mpctx->step_frames = 0;
mpctx->time_frame -= get_relative_time(mpctx);
} else {
(void)get_relative_time(mpctx); // ignore time that passed during pause
}
}
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
update_core_idle_state(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_notify_change_opt_ptr(mpctx->mconfig, &opts->pause);
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
}
client API: report pause/unpause reason Not sure about this... might redo. At least this provides a case of a broadcasted event, which requires per-event data allocation. See github issue #576.
2014-02-24 21:49:07 +00:00
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
void update_internal_pause_state(struct MPContext *mpctx)
{
set_pause_state(mpctx, mpctx->opts->pause);
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 --stop-screensaver runtime-changeable Move the screensaver enable/disable determination to a central place, and call it if the stop-screensaver property is changed. Also, do not stop the screensaver when in idle mode (i.e. no file is loaded). Fixes #3615.
2016-10-02 10:33:34 +00:00
void update_screensaver_state(struct MPContext *mpctx)
{
if (!mpctx->video_out)
return;
options: add always to stop-screensaver The stop-screensaver option is currently limited to a simple yes/no option. While the no option does always disable mpv trying to stop the screensaver, yes does not mean the screensaver is always stopped. The screensaver will be enabled again depending on certain conditions (like if the player is paused). Simply introduce a new value for this option, always, which does exactly what the name implies: the screensaver will always be disabled.
2022-02-18 20:39:25 +00:00
bool saver_state = (!mpctx->playback_active || !mpctx->opts->stop_screensaver) &&
mpctx->opts->stop_screensaver != 2;
player: reduce blocking on VO when switching pause When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These essentially wait until the video frame has been rendered. This is a problem with the opengl-cb, if GL rendering is done in the same thread as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way. Logically speaking, it's a deadlock situation, which is resolved with a timeout. This can lead to quite ugly effects, like the on-pause frame not being rendered until the timeout has passed. It has been interpreted as video continuing to play. Resolve this by simply not blocking on pause. Make the screensaver controls async, and handle sending VOCTRL_PAUSE in the VO thread. (All this could be avoided by redoing the internal VO API.) Also see #4152.
2017-02-21 13:18:30 +00:00
vo_control_async(mpctx->video_out, saver_state ? VOCTRL_RESTORE_SCREENSAVER
: VOCTRL_KILL_SCREENSAVER, NULL);
player: make --stop-screensaver runtime-changeable Move the screensaver enable/disable determination to a central place, and call it if the stop-screensaver property is changed. Also, do not stop the screensaver when in idle mode (i.e. no file is loaded). Fixes #3615.
2016-10-02 10:33:34 +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
void add_step_frame(struct MPContext *mpctx, int dir)
{
player: refactor: eliminate MPContext.d_video Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
2016-01-17 17:07:50 +00:00
if (!mpctx->vo_chain)
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
return;
if (dir > 0) {
mpctx->step_frames += 1;
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
set_pause_state(mpctx, 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
} else if (dir < 0) {
player: strictly wait until done when backstepping This fixes backstepping getting "stuck" when e.g. holding down a key bound to the backstep command. The reason is that even if the backstep itself is finished, the next backstep might not take the new video PTS as reference if the hr-seek itself isn't finished yet. The intention of not waiting for the hr-seek to finish was faster backstepping by possibly skipping audio decoding. But it probably doesn't matter enough to make the rest of the code more complex.
2016-04-27 15:01:17 +00:00
if (!mpctx->hrseek_active) {
player: allow passing flags to queue_seek() Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
2016-08-15 19:07:32 +00:00
queue_seek(mpctx, MPSEEK_BACKSTEP, 0, MPSEEK_VERY_EXACT, 0);
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
set_pause_state(mpctx, 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
}
}
}
player: split seek_reset() This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
2014-07-30 21:01:55 +00:00
// Clear some playback-related fields on file loading or after seeks.
void reset_playback_state(struct MPContext *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
{
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 10:53:44 +00:00
mp_filter_reset(mpctx->filter_root);
player: split seek_reset() This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
2014-07-30 21:01:55 +00:00
reset_video_state(mpctx);
reset_audio_state(mpctx);
reset_subtitle_state(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
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
for (int n = 0; n < mpctx->num_tracks; n++) {
struct track *t = mpctx->tracks[n];
player: ensure backward playback state is propagated on track switching Track switching doesn't run reset_playback_state(), so a track enabled at runtime during backward playback would lead to a messed up state. This commit just does a bad code monkey fix to this. It feels like there needs to be a much better way to propagate this state.
2019-06-03 00:05:52 +00:00
// (Often, but not always, this is redundant and also done elsewhere.)
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
if (t->dec)
f_decoder_wrapper: replace most public fields with setters/getters I may (optionally) move decoding to a separate thread in a future change. It's a bit attractive to move the entire decoder wrapper to there, so if the demuxer has a new packet, it doesn't have to wake up the main thread, and can directly wake up the decoder. (Although that's bullshit, since there's a queue in between, and libavcodec's multi-threaded decoding plays cross-threads ping pong with packets anyway. On the other hand, the main thread would still have to shuffle the packets around, so whatever, just seems like better design.) As preparation, there shouldn't be any mutable state exposed by the wrapper. But there's still a large number of corner-caseish crap, so just use setters/getters for them. This recorder thing will inherently not work, so it'll have to be disabled if threads are used. This is a bit painful, but probably still the right thing. Like speculatively pulling teeth.
2020-02-28 20:17:55 +00:00
mp_decoder_wrapper_set_play_dir(t->dec, mpctx->play_dir);
player: partially fix backward playback display of cached text subtitles This simply didn't set the direction flag in most situations, which meant the timestamps used in the subtitle renderer were nonsense, leading to invisible subtitles. This works only for text subtitles that are cached in the ASS_Track state. Reading new subtitles is broken because the demuxer layer has trouble returning subtitle packets backwards, and I think for rendering bitmap subtitles, the pruning direction would have to be adjusted. (Not sure if reversing the timestamps before the subtitle renderer backend is even the right thing to do. At least for sd_ass.c, it seems to make sense, because it caches subtitles with "normal" timestamps.)
2020-02-04 19:26:35 +00:00
if (t->d_sub)
sub_set_play_dir(t->d_sub, mpctx->play_dir);
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
}
player: fix missed pause state update during reset in some cases When playing a new file, if paused_for_cache was true before being reset the AO would never be unpaused because that state was thrown away, leaving it stuck. Fix this by updating the pause state before resetting that variable. Note that this does not make the second update_internal_pause_state() call redundant. This fixes the same bug fb5d976cb0 was supposed to.
2021-07-18 10:11:29 +00:00
// May need unpause first
if (mpctx->paused_for_cache)
update_internal_pause_state(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->hrseek_active = false;
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
mpctx->hrseek_lastframe = false;
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
mpctx->hrseek_backstep = false;
player: make refresh seeks slightly more robust Refresh seeks are automatically issued when changing filters, which improves user experience if these filters change buffering or such. The refresh seek could actually overwrite a previously ongoing seek: set pause yes set time-pos 10 set vf "" Here, the video code issued a refresh seek to the previous video position, which could be different from the previously triggered (and still ongoing) seek, this overwriting the seek. Factor all refresh seek handling into a new function, and make it handle ongoing seeks correctly. Remove the weird new canonical_pts field, which actually had no use. Fixes #4757.
2017-08-14 12:02:13 +00:00
mpctx->current_seek = (struct seek_params){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
mpctx->playback_pts = MP_NOPTS_VALUE;
player: reset frame step counter on seeks I suppose this wasn't done in order to keep the frame step counter active even in the next file, but actually it was reset anyway.
2014-11-28 23:24:51 +00:00
mpctx->step_frames = 0;
player: make looping slightly more seamless This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
2016-08-18 18:40:23 +00:00
mpctx->ab_loop_clip = true;
audio: change playback restart and resyncing This commit makes audio decoding non-blocking. If e.g. the network is too slow the playloop will just go to sleep, instead of blocking until enough data is available. For video, this was already done with commit 7083f88c. For audio, it's unfortunately much more complicated, because the audio decoder was used in a blocking manner. Large changes are required to get around this. The whole playback restart mechanism must be turned into a statemachine, especially since it has close interactions with video restart. Lots of video code is thus also changed. (For the record, I don't think switching this code to threads would make this conceptually easier: the code would still have to deal with external input while blocked, so these in-between states do get visible [and thus need to be handled] anyway. On the other hand, it certainly should be possible to modularize this code a bit better.) This will probably cause a bunch of regressions.
2014-07-28 18:40:43 +00:00
mpctx->restart_complete = false;
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
mpctx->paused_for_cache = false;
mpctx->cache_buffer = 100;
player: force update of cache properties even on inactive demuxer cache When the demuxer cache read until the end of the stream, and was finished and completely inactive, the cache properties were not updated anymore via MP_EVENT_CACHE_UPDATE. Unfortunately, many cache properties depend on the current playback position, such as cache-duration or fw-bytes. This is especially visible on the OSC. If everything was cached, seeking around didn't update the displayed forward cache duration. That means checking demuxer_reader_state.idle is not enough. You also need to check whether the current playback position changed. Fix this by explicitly using the current playback position, and update the properties if it changed "enough". "Enough" is 1 second of media time in this example, which may or may not be appropriate. In general, this could probably be done better. There are many other triggers that change the cache state and that are not covered. For now I'm content with getting rid of the obvious problems. I think the OSC problem in particular was caused by changing it from polling to using property change notifications.
2020-03-05 21:23:43 +00:00
mpctx->cache_update_pts = MP_NOPTS_VALUE;
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_discontinuity(mpctx->encode_lavc_ctx);
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
update_internal_pause_state(mpctx);
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
update_core_idle_state(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
}
player: remove unused return value
2016-06-08 10:04:56 +00:00
static void mp_seek(MPContext *mpctx, struct seek_params seek)
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 MPOpts *opts = mpctx->opts;
player: redo hack for video keyframe seeks with external audio If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
2018-01-17 06:07:15 +00:00
if (!mpctx->demuxer || !seek.type || seek.amount == MP_NOPTS_VALUE)
player: remove unused return value
2016-06-08 10:04:56 +00:00
return;
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
playloop: make chapter property more accurate when seeking chapters When seeking chapters, `last_chapter_seek` acts as a projection of what the current chapter will be once mpv has a chance to seek to it. This allows for more accurate results from the `chapter` property. It works by comparing the projection to the actual current chapter and returning the larger of the two indexes, but this only works when seeking forward. If we want it to work for both forward and backward chapter seeking, we can instead use a boolean called `last_chapter_flag`, which gets switched on when a chapter seek request is made, and then switched off when the seek has been performed. We should also check to ensure that we don't allow the chapter index to be set to -1 unless there is a span of time between the very beginning of the track and the start of the first chapter. Since the new approach to resetting `last_chapter_seek` no longer depends on `last_chapter_pts`, that member variable can be removed.
2023-09-27 12:00:14 +00:00
if (seek.type == MPSEEK_CHAPTER) {
mpctx->last_chapter_flag = false;
seek.type = MPSEEK_ABSOLUTE;
} else {
mpctx->last_chapter_seek = -2;
}
player: use symbolic constant for seek precision Meh.
2015-03-04 16:21:05 +00:00
bool hr_seek_very_exact = seek.exact == MPSEEK_VERY_EXACT;
player: clamp relative seek base time to nominal duration Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
2020-09-10 21:24:35 +00:00
double current_time = get_playback_time(mpctx);
player: guard against MPSEEK_RELATIVE when current pts is unknown in very rare circumstances, doing a relative seek like +1s will end up doing an absolute seek to 00:01. this guards against that possibility. so far i've only ever seen this issue when using --ad=lavc:ac3_at and doing several relative seeks in quick succession. this is likely either a bug in the audiotoolbox decoder in ffmpeg, or simply due to inherent latency in that hardware decoder which causes brief periods of time where the current audio pts is unknown.
2016-10-20 18:43:17 +00:00
if (current_time == MP_NOPTS_VALUE && seek.type == MPSEEK_RELATIVE)
return;
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
if (current_time == MP_NOPTS_VALUE)
current_time = 0;
double seek_pts = MP_NOPTS_VALUE;
int demux_flags = 0;
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
switch (seek.type) {
case MPSEEK_ABSOLUTE:
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
seek_pts = seek.amount;
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
break;
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
case MPSEEK_BACKSTEP:
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
seek_pts = current_time;
hr_seek_very_exact = true;
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
break;
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
case MPSEEK_RELATIVE:
demux: drop redundant SEEK_BACKWARD flag Seems like most code dealing with this was for setting it in redundant cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one out. Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache(). In demux_mkv_seek(), make the arbitrary decision that a video stream is not required for the subtitle prefetch logic to be active. We might want subtitles with long duration even with audio only playback, or if the file is used as external subtitle.
2017-10-23 17:05:39 +00:00
demux_flags = seek.amount > 0 ? SEEK_FORWARD : 0;
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
seek_pts = current_time + seek.amount;
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
break;
case MPSEEK_FACTOR: ;
double len = get_time_length(mpctx);
if (len >= 0)
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
seek_pts = seek.amount * len;
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
break;
various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriate In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
2023-01-10 18:26:51 +00:00
default: MP_ASSERT_UNREACHABLE();
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
}
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
double demux_pts = seek_pts;
options: make decoder options local to decoder wrapper Instead of having f_decoder_wrapper create its own copy of the entire mpv option tree, create a struct local to that file and move all used options to there. movie_aspect is used by the "video-aspect" deprecated property code. I think it's probably better not to remove the property yet, but fortunately it's easy to work around without needing special handling for this option or so. correct_pts is used to prevent use of hr-seek in playloop.c. Ignore that, if you use --no-correct-pts you're asking for trouble anyway. This is the only behavior change.
2020-02-29 23:28:09 +00:00
bool hr_seek = seek.exact != MPSEEK_KEYFRAME && seek_pts != MP_NOPTS_VALUE &&
player: dumb seeking related stuff, make audio hr-seek default Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
(seek.exact >= MPSEEK_EXACT || opts->hr_seek == 1 ||
(opts->hr_seek >= 0 && seek.type == MPSEEK_ABSOLUTE) ||
(opts->hr_seek == 2 && (!mpctx->vo_chain || mpctx->vo_chain->is_sparse)));
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
// Under certain circumstances, prefer SEEK_FACTOR.
if (seek.type == MPSEEK_FACTOR && !hr_seek &&
(mpctx->demuxer->ts_resets_possible || seek_pts == MP_NOPTS_VALUE))
player: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
{
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
demux_pts = seek.amount;
demux_flags |= SEEK_FACTOR;
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: return better guess for playback time during seeks Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
2015-08-21 13:37:07 +00:00
demux: set SEEK_HR for backstep seeks, move a hr-seek detail to playloop Just rearranging shit. Setting SEEK_HR for backstep seeks actually doesn't have much meaning, but disables the weird audio snapping for "keyframe" seeks, and I don't know it's late.
2019-05-24 00:30:44 +00:00
int play_dir = opts->play_dir;
if (play_dir < 0)
demux_flags |= SEEK_SATAN;
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
if (hr_seek) {
double hr_seek_offset = opts->hr_seek_demuxer_offset;
// Always try to compensate for possibly bad demuxers in "special"
// situations where we need more robustness from the hr-seek code, even
// if the user doesn't use --hr-seek-demuxer-offset.
// The value is arbitrary, but should be "good enough" in most situations.
if (hr_seek_very_exact)
hr_seek_offset = MPMAX(hr_seek_offset, 0.5); // arbitrary
player: offset demuxer on start/seek properly with audio/sub delay Assume you use a large value like --audio-delay=20. Then until now the player would just have seeked normally to a "too late" position, and played silence for about 20 seconds until audio in the correct time range is coming again. Change this by offsetting seeks by the right amount. This works for both external and muxed files. If a seek isn't precise, then it works only for external files. This might cause issues with very large delay options. Hr-seek skipping could take a lot of time (especially because it affects video too), the demuxer queue could overflow, and other weird corner cases could appear. But we just try this on best-effort basis, and if the user uses extreme values we don't guarantee good behavior.
2016-08-04 09:26:57 +00:00
for (int n = 0; n < mpctx->num_tracks; n++) {
double offset = 0;
if (!mpctx->tracks[n]->is_external)
offset += get_track_seek_offset(mpctx, mpctx->tracks[n]);
hr_seek_offset = MPMAX(hr_seek_offset, -offset);
}
player: fix --hr-seek-demuxer-offset with backward playback
2019-05-25 15:33:48 +00:00
demux_pts -= hr_seek_offset * play_dir;
demux: drop redundant SEEK_BACKWARD flag Seems like most code dealing with this was for setting it in redundant cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one out. Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache(). In demux_mkv_seek(), make the arbitrary decision that a video stream is not required for the subtitle prefetch logic to be active. We might want subtitles with long duration even with audio only playback, or if the file is used as external subtitle.
2017-10-23 17:05:39 +00:00
demux_flags = (demux_flags | SEEK_HR) & ~SEEK_FORWARD;
demux: set SEEK_HR for backstep seeks, move a hr-seek detail to playloop Just rearranging shit. Setting SEEK_HR for backstep seeks actually doesn't have much meaning, but disables the weird audio snapping for "keyframe" seeks, and I don't know it's late.
2019-05-24 00:30:44 +00:00
// For HR seeks in backward playback mode, the correct seek rounding
// direction is forward instead of backward.
if (play_dir < 0)
demux_flags |= SEEK_FORWARD;
demux_disc: pass seek flags to stream layer Pass through the seek flags to the stream layer. The STREAM_CTRL semantics become a bit awkward, but that's still the least awkward part about optical disc media. Make demux_disc.c request relative seeks. Now the player will use relative seeks if the user sends relative seek commands, and the demuxer announces it wants these by setting rel_seeks to true. This change probably changes seek behavior for dvd, dvdnav, bluray, cdda, and possibly makes seeking useless if the demuxer-cache is set to a high value. Will be used in the next commit. (Split to make reverting the next commit easier.)
2015-01-19 19:45:31 +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
player: allow seeking in cached parts of unseekable streams Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
2017-12-23 21:28:08 +00:00
if (!mpctx->demuxer->seekable)
demux_flags |= SEEK_CACHED;
player: add optional separate video decoding thread See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
2020-02-29 20:40:52 +00:00
demux_flags |= SEEK_BLOCK;
player: allow seeking in cached parts of unseekable streams Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
2017-12-23 21:28:08 +00:00
if (!demux_seek(mpctx->demuxer, demux_pts, demux_flags)) {
if (!mpctx->demuxer->seekable) {
player: redo hack for video keyframe seeks with external audio If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
2018-01-17 06:07:15 +00:00
MP_ERR(mpctx, "Cannot seek in this stream.\n");
player: allow seeking in cached parts of unseekable streams Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
2017-12-23 21:28:08 +00:00
MP_ERR(mpctx, "You can force it with '--force-seekable=yes'.\n");
}
return;
}
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
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
mpctx->play_dir = play_dir;
player: slightly simplify seeking in external files For some reason, this checked whether there are external tracks at all before doing any seeks. Possibly this was to avoid multiple get_main_demux_pts() calls, but calling this multiple times shouldn't be too bad.
2013-12-24 10:08:26 +00:00
// Seek external, extra files too:
player: redo demuxer stream selection Use struct track to decide what stream to select. Add a "selected" field and use that in some places instead of checking mpctx->current_track.
2013-12-23 19:14:54 +00:00
for (int t = 0; t < mpctx->num_tracks; t++) {
struct track *track = mpctx->tracks[t];
player: slightly simplify seeking in external files For some reason, this checked whether there are external tracks at all before doing any seeks. Possibly this was to avoid multiple get_main_demux_pts() calls, but calling this multiple times shouldn't be too bad.
2013-12-24 10:08:26 +00:00
if (track->selected && track->is_external && track->demuxer) {
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
double main_new_pos = demux_pts;
player: offset demuxer on start/seek properly with audio/sub delay Assume you use a large value like --audio-delay=20. Then until now the player would just have seeked normally to a "too late" position, and played silence for about 20 seconds until audio in the correct time range is coming again. Change this by offsetting seeks by the right amount. This works for both external and muxed files. If a seek isn't precise, then it works only for external files. This might cause issues with very large delay options. Hr-seek skipping could take a lot of time (especially because it affects video too), the demuxer queue could overflow, and other weird corner cases could appear. But we just try this on best-effort basis, and if the user uses extreme values we don't guarantee good behavior.
2016-08-04 09:26:57 +00:00
if (!hr_seek || track->is_external)
main_new_pos += get_track_seek_offset(mpctx, track);
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
if (demux_flags & SEEK_FACTOR)
main_new_pos = seek_pts;
player: add optional separate video decoding thread See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
2020-02-29 20:40:52 +00:00
demux_seek(track->demuxer, main_new_pos,
demux_flags & (SEEK_SATAN | SEEK_BLOCK));
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 looping slightly more seamless This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
2016-08-18 18:40:23 +00:00
if (!(seek.flags & MPSEEK_FLAG_NOFLUSH))
clear_audio_output_buffers(mpctx);
player: split seek_reset() This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
2014-07-30 21:01:55 +00:00
reset_playback_state(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
player: add optional separate video decoding thread See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
2020-02-29 20:40:52 +00:00
demux_block_reading(mpctx->demuxer, false);
for (int t = 0; t < mpctx->num_tracks; t++) {
struct track *track = mpctx->tracks[t];
if (track->selected && track->demuxer)
demux_block_reading(track->demuxer, 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
/* Use the target time as "current position" for further relative
* seeks etc until a new video frame has been decoded */
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
mpctx->last_seek_pts = seek_pts;
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: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
if (hr_seek) {
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->hrseek_active = true;
player: simplify mp_seek()
2016-02-28 18:43:07 +00:00
mpctx->hrseek_backstep = seek.type == MPSEEK_BACKSTEP;
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
mpctx->hrseek_pts = seek_pts * mpctx->play_dir;
player: add some debug output for seeking
2015-06-18 20:31:55 +00:00
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
// allow decoder to drop frames before hrseek_pts
bool hrseek_framedrop = !hr_seek_very_exact && opts->hr_seek_framedrop;
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
MP_VERBOSE(mpctx, "hr-seek, skipping to %f%s%s\n", mpctx->hrseek_pts,
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
hrseek_framedrop ? "" : " (no framedrop)",
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
mpctx->hrseek_backstep ? " (backstep)" : "");
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
for (int n = 0; n < mpctx->num_tracks; n++) {
struct track *track = mpctx->tracks[n];
struct mp_decoder_wrapper *dec = track->dec;
if (dec && hrseek_framedrop)
mp_decoder_wrapper_set_start_pts(dec, mpctx->hrseek_pts);
}
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: simplify mp_seek()
2016-02-28 18:43:07 +00:00
if (mpctx->stop_play == AT_END_OF_FILE)
mpctx->stop_play = KEEP_PLAYING;
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->start_timestamp = mp_time_sec();
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_wakeup_core(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
player: split seek_reset() This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
2014-07-30 21:01:55 +00:00
mp_notify(mpctx, MPV_EVENT_SEEK, NULL);
player: update playback position on seek If the actual PTS is not known yet right after a seek, the "time-pos" property will just return the seek target PTS. For this purpose, trigger a change event to make the client API update the "time-pos" and related properties. (MPV_EVENT_TICK triggers this update.)
2014-07-28 22:07:54 +00:00
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
player: gross hack to improve non-hr seeking with external audio tracks Relative seeks backwards with external audio tracks does not always work well: it tends to happen that video seek back further than audio, so audio will remain silent until the audio's after-seek position is reached. This happens because we strictly seek both video and audio demuxer to the approximate desirted target PTS, and then start decoding from that. Commit 81358380 removes an older method that was supposed to deal with this. It was sort of bad, because it could lead to the playback core freezing by waiting on network. Ideally, the demuxer layer would probably somehow deal with such seeks, and do them in a way the audio is seeked after video. Currently this is infeasible, because the demuxer layer assumes a single demuxer, and external tracks simply use separate demuxer layers. (MPlayer actually had a pseudo-demuxer that joined external tracks into a single demuxer, but this is not flexible enough - and also, the demuxer layer as it currently exists can't deal with dynamically removing external tracks either. Maybe some time in the future.) Instead, add a gross hack, that essentially reseeks the audio if it detects that it's too far off. The result is actually not too bad, because we can reuse the mechanism that is used for instant track switching. This way we can make sure of the right position, without having to care about certain other issues. It should be noted that if the audio demuxer is used for other tracks too, and the demuxer does not support refresh seeking, audio will probably be off by even a higher amount. But this should be rare.
2016-08-07 14:29:13 +00:00
player: modify/simplify AB-loop behavior This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
2019-05-26 23:24:22 +00:00
update_ab_loop_clip(mpctx);
player: make --lavfi-complex changeable at runtime Tends to be somewhat glitchy if subtitles are enabled, and you enable and disable tracks. On error, this will disable --lavfi-complex, which will result in whatever behavior.
2017-08-12 21:08:48 +00:00
player: make refresh seeks slightly more robust Refresh seeks are automatically issued when changing filters, which improves user experience if these filters change buffering or such. The refresh seek could actually overwrite a previously ongoing seek: set pause yes set time-pos 10 set vf "" Here, the video code issued a refresh seek to the previous video position, which could be different from the previously triggered (and still ongoing) seek, this overwriting the seek. Factor all refresh seek handling into a new function, and make it handle ongoing seeks correctly. Remove the weird new canonical_pts field, which actually had no use. Fixes #4757.
2017-08-14 12:02:13 +00:00
mpctx->current_seek = seek;
player/sub: avoid wasteful subtitle redraws This only affects two special cases: printing subtitles to the terminal and printing subtitles on a still picture. Previously, mpv was very dumb here and spammed this logic on every single loop. For terminal subtitles, this isn't as big of a deal, but for the image case this is pretty bad. The entire VO constantly redrew even when there was no need to which can be very expensive depending on user settings. Instead, let's rework sub_read_packets so that it also tells us whether or not the subtitle packets update in some way in addition to telling us whether or not to read more. Since we cache all packets thanks to the previous commit, we can leverage this information to make a guess whether or not the current subtitle packet is supposed to be visible on the screen. Because the redraw now only happens when it is needed, the mp_set_timeout_hack can be removed.
2024-01-21 23:14:39 +00:00
redraw_subs(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
}
player: handle seek delays differently The code removed from handle_input_and_seek_coalesce() did two things: 1. If there's a queued seek, stop accepting non-seek commands, and delay them to the next playloop iteration. 2. If a seek is executing (i.e. the seek was unqueued, and now it's trying to decode and display the first video frame), stop accepting seek commands (and in fact all commands that were queued after the first seek command). This logic is disabled if seeking started longer than 300ms ago. (To avoid starvation.) I'm not sure why 1. would be needed. It's still possible that a command immediately executed after a seek command sees a "seeking in progress" state, because it affects queued seeks only, and not seeks in progress. Drop this code, since it can easily lead to input starvation, and I'm not aware of any disadvantages. The logic in 2. is good to make seeking behave much better, as it guarantees that the video display is updated frequently. Keep the core idea, but implement it differently. Now this logic is applied to seeks only. Commands after the seek can execute freely, and like with 1., I don't see a reason why they couldn't. However, in some cases, seeks are supposed to be executed instantly, so queue_seek() needs an additional parameter to signal the need for immediate update. One nice thing is that commands like sub_seek automatically profit from the seek delay logic. On the other hand, hitting chapter seek multiple times still does not update the video on chapter boundaries (as it should be). Note that the main goal of this commit is actually simplification of the input processing logic and to allow all commands to be executed immediately.
2014-02-07 21:29:50 +00:00
// This combines consecutive seek requests.
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
void queue_seek(struct MPContext *mpctx, enum seek_type type, double amount,
player: allow passing flags to queue_seek() Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
2016-08-15 19:07:32 +00:00
enum seek_precision exact, 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
{
struct seek_params *seek = &mpctx->seek;
player: do not exit when a seek gets queued Seems logical. Note that if playback otherwise ends while playback is active and a seek is still queued, we still exit. Otherwise you couldn't end playback by seeking past the end of the file (which is classic MPlayer and mpv behavior).
2015-06-16 21:07:46 +00:00
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_wakeup_core(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
switch (type) {
case MPSEEK_RELATIVE:
player: allow passing flags to queue_seek() Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
2016-08-15 19:07:32 +00:00
seek->flags |= 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
if (seek->type == MPSEEK_FACTOR)
return; // Well... not common enough to bother doing better
seek->amount += amount;
seek->exact = MPMAX(seek->exact, exact);
if (seek->type == MPSEEK_NONE)
seek->exact = exact;
if (seek->type == MPSEEK_ABSOLUTE)
return;
seek->type = MPSEEK_RELATIVE;
return;
case MPSEEK_ABSOLUTE:
case MPSEEK_FACTOR:
player: simplify backstepping Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
2016-01-12 22:49:00 +00:00
case MPSEEK_BACKSTEP:
playloop: make chapter property more accurate when seeking chapters When seeking chapters, `last_chapter_seek` acts as a projection of what the current chapter will be once mpv has a chance to seek to it. This allows for more accurate results from the `chapter` property. It works by comparing the projection to the actual current chapter and returning the larger of the two indexes, but this only works when seeking forward. If we want it to work for both forward and backward chapter seeking, we can instead use a boolean called `last_chapter_flag`, which gets switched on when a chapter seek request is made, and then switched off when the seek has been performed. We should also check to ensure that we don't allow the chapter index to be set to -1 unless there is a span of time between the very beginning of the track and the start of the first chapter. Since the new approach to resetting `last_chapter_seek` no longer depends on `last_chapter_pts`, that member variable can be removed.
2023-09-27 12:00:14 +00:00
case MPSEEK_CHAPTER:
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
*seek = (struct seek_params) {
.type = type,
.amount = amount,
.exact = exact,
player: allow passing flags to queue_seek() Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
2016-08-15 19:07:32 +00:00
.flags = 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
};
return;
case MPSEEK_NONE:
*seek = (struct seek_params){ 0 };
return;
}
various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriate In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
2023-01-10 18:26:51 +00:00
MP_ASSERT_UNREACHABLE();
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
}
void execute_queued_seek(struct MPContext *mpctx)
{
if (mpctx->seek.type) {
player: cosmetically restructure a small function No actual functional changes. Just preparation for the next commit, to reduce its diff.
2019-12-14 13:15:57 +00:00
bool queued_hr_seek = mpctx->seek.exact != MPSEEK_KEYFRAME;
player: let explicitly imprecise seeks cancel precise seeks If an imprecise seek is issues while a precise seek is ongoing, don't wait up to 300ms (herustistic which usually improves user experience), but instead let it cancel the seek. Improves responsiveness of the OSC after the previous commit. Note that we don't do this on "default-precise" seeks, because we don't know if they're going to be precise or not.
2014-07-29 17:59:56 +00:00
// Let explicitly imprecise seeks cancel precise seeks:
player: cosmetically restructure a small function No actual functional changes. Just preparation for the next commit, to reduce its diff.
2019-12-14 13:15:57 +00:00
if (mpctx->hrseek_active && !queued_hr_seek)
player: let explicitly imprecise seeks cancel precise seeks If an imprecise seek is issues while a precise seek is ongoing, don't wait up to 300ms (herustistic which usually improves user experience), but instead let it cancel the seek. Improves responsiveness of the OSC after the previous commit. Note that we don't do this on "default-precise" seeks, because we don't know if they're going to be precise or not.
2014-07-29 17:59:56 +00:00
mpctx->start_timestamp = -1e9;
player: cosmetically restructure a small function No actual functional changes. Just preparation for the next commit, to reduce its diff.
2019-12-14 13:15:57 +00:00
// If the user seeks continuously (keeps arrow key down) try to finish
// showing a frame from one location before doing another seek (instead
// of never updating the screen).
if ((mpctx->seek.flags & MPSEEK_FLAG_DELAY) &&
player: handle seek delays differently The code removed from handle_input_and_seek_coalesce() did two things: 1. If there's a queued seek, stop accepting non-seek commands, and delay them to the next playloop iteration. 2. If a seek is executing (i.e. the seek was unqueued, and now it's trying to decode and display the first video frame), stop accepting seek commands (and in fact all commands that were queued after the first seek command). This logic is disabled if seeking started longer than 300ms ago. (To avoid starvation.) I'm not sure why 1. would be needed. It's still possible that a command immediately executed after a seek command sees a "seeking in progress" state, because it affects queued seeks only, and not seeks in progress. Drop this code, since it can easily lead to input starvation, and I'm not aware of any disadvantages. The logic in 2. is good to make seeking behave much better, as it guarantees that the video display is updated frequently. Keep the core idea, but implement it differently. Now this logic is applied to seeks only. Commands after the seek can execute freely, and like with 1., I don't see a reason why they couldn't. However, in some cases, seeks are supposed to be executed instantly, so queue_seek() needs an additional parameter to signal the need for immediate update. One nice thing is that commands like sub_seek automatically profit from the seek delay logic. On the other hand, hitting chapter seek multiple times still does not update the video on chapter boundaries (as it should be). Note that the main goal of this commit is actually simplification of the input processing logic and to allow all commands to be executed immediately.
2014-02-07 21:29:50 +00:00
mp_time_sec() - mpctx->start_timestamp < 0.3)
player: cosmetically restructure a small function No actual functional changes. Just preparation for the next commit, to reduce its diff.
2019-12-14 13:15:57 +00:00
{
// Wait until a video frame is available and has been shown.
if (mpctx->video_status < STATUS_PLAYING)
return;
player: make repeated hr-seeks past EOF trigger EOF as expected If you have a normal file with audio and video, and keep "spamming" forward hr-seeks, the player just kept showing the last video frame instead of exiting or playing the next file. This started happening since commit 6bcda94cb. Although not a bug per se, it was odd, and very user-noticable. The main problem was that the pending seek command was processed before the EOF was "noticed". Processing the command reset everything, so the player did not terminate playback, but repeated the seek. This commit restores the old behavior. For one, it makes video return the correct status (video.c). The parameter is a bit ugly, but better than duplicating the logic or having another MPContext field. (As a minor detail, setting r=VD_EOF makes sure have_new_frame() returns true, rather than going through another iteration or whatever the hell will happen instead, which would clobber logical_eof.) Another thing is making the seek logic actually wait until the seek outcome has been determined if audio is also active. Audio needs to wait for video in order to get the video seek target position. (Which in turn is because hr-seek still "snaps" to video frames. You can't seek in between two frames, so audio can't just use the seek target, but always has to wait on the timestamp of the video frame. This has other disadvantages and is a misdesign, but not something I'll fix today.) In theory, this might make hr-seeks less responsive, because it needs to fully decode/filter the audio too, but in practice most time is spent on video, which had to be fully decoded before this change. (In general, hr-seek could probably just show a random frame when a queued hr-seek overrides the current hr-seek, which would probably lead to a better user experience, but that's out of scope.) Fixes: #7206
2019-12-14 13:17:16 +00:00
// On A/V hr-seeks, always wait for the full result, to avoid corner
// cases when seeking past EOF (we want it to determine that EOF
// actually happened, instead of overwriting it with the new seek).
if (mpctx->hrseek_active && queued_hr_seek && mpctx->vo_chain &&
mpctx->ao_chain && !mpctx->restart_complete)
return;
player: cosmetically restructure a small function No actual functional changes. Just preparation for the next commit, to reduce its diff.
2019-12-14 13:15:57 +00:00
}
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
mp_seek(mpctx, mpctx->seek);
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->seek = (struct seek_params){0};
}
}
player: minor fix/simplification of OSD time/duration handling Always display the duration as "unknown" if the duration is known. Also fix that at least demux_lavf reported unknown duration as 0 (fix by setting the default to unknown in demux.c). Remove the dumb _u formatter function, and use a different approach to avoiding displaying "unknown" as playback time on playback start (set last_seek_pts for that).
2017-11-24 12:58:57 +00:00
// NOPTS (i.e. <0) if unknown
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
double get_time_length(struct MPContext *mpctx)
{
struct demuxer *demuxer = mpctx->demuxer;
player: minor fix/simplification of OSD time/duration handling Always display the duration as "unknown" if the duration is known. Also fix that at least demux_lavf reported unknown duration as 0 (fix by setting the default to unknown in demux.c). Remove the dumb _u formatter function, and use a different approach to avoiding displaying "unknown" as playback time on playback start (set last_seek_pts for that).
2017-11-24 12:58:57 +00:00
return demuxer && demuxer->duration >= 0 ? demuxer->duration : MP_NOPTS_VALUE;
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 --loop with backward playback Obviously should seek back to the end of the file when it loops. Also remove some minor code duplication around start times. This isn't the correct solution by the way. Rather than hoping we know a reasonable start/end time, this stuff should instruct the demuxer to seek to the exact location. It'll work with 99% of all normal files, but add an appropriate comment (that basically says the function is bullshit) to get_start_time() anyway.
2019-05-26 23:46:34 +00:00
// Return approximate PTS of first frame played. This can be completely wrong
// for a number of reasons in a number of situations.
double get_start_time(struct MPContext *mpctx, int dir)
{
double res = 0;
if (mpctx->demuxer) {
if (!mpctx->opts->rebase_start_time)
res += mpctx->demuxer->start_time;
if (dir < 0)
res += MPMAX(mpctx->demuxer->duration, 0);
}
return res;
}
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
double get_current_time(struct MPContext *mpctx)
{
player: some minor code golf
2020-09-10 21:47:59 +00:00
if (!mpctx->demuxer)
return MP_NOPTS_VALUE;
if (mpctx->playback_pts != MP_NOPTS_VALUE)
return mpctx->playback_pts * mpctx->play_dir;
return mpctx->last_seek_pts;
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 the time display relative to start PTS This commit makes the playback start time always at time 0. Signed-off-by: wm4 <wm4@nowhere>
2014-06-29 17:27:46 +00:00
double get_playback_time(struct MPContext *mpctx)
{
double cur = get_current_time(mpctx);
player: clamp display time to known time range on seeking During seeking, and there is momemtarily no new data available yet, the player will display the seek target as current time. Clamp this time to the known time range as implied by the start time and the duration of the file. This improves behavior especially when seeking in audio files, for which this for some reason triggers rather often. There were some users complaining about this. This makes behavior worse for files with timestamp resets, or incorrectly reported duration. (The latter is relatively common, e.g. libavformat shortcomings, or incomplete files.)
2015-04-28 20:03:18 +00:00
// During seeking, the time corresponds to the last seek time - apply some
// cosmetics to it.
player: some minor code golf
2020-09-10 21:47:59 +00:00
if (cur != MP_NOPTS_VALUE && mpctx->playback_pts == MP_NOPTS_VALUE) {
player: clamp display time to known time range on seeking During seeking, and there is momemtarily no new data available yet, the player will display the seek target as current time. Clamp this time to the known time range as implied by the start time and the duration of the file. This improves behavior especially when seeking in audio files, for which this for some reason triggers rather often. There were some users complaining about this. This makes behavior worse for files with timestamp resets, or incorrectly reported duration. (The latter is relatively common, e.g. libavformat shortcomings, or incomplete files.)
2015-04-28 20:03:18 +00:00
double length = get_time_length(mpctx);
if (length >= 0)
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 21:47:17 +00:00
cur = MPCLAMP(cur, 0, length);
player: clamp display time to known time range on seeking During seeking, and there is momemtarily no new data available yet, the player will display the seek target as current time. Clamp this time to the known time range as implied by the start time and the duration of the file. This improves behavior especially when seeking in audio files, for which this for some reason triggers rather often. There were some users complaining about this. This makes behavior worse for files with timestamp resets, or incorrectly reported duration. (The latter is relatively common, e.g. libavformat shortcomings, or incomplete files.)
2015-04-28 20:03:18 +00:00
}
player/playloop: force get_playback_time to be at least 0 Except for MP_NOPTS_VALUE. We keep that as is. When this was originally added in a73415584c9dbf920ec14d26d0b0629cae81b3d5, it appears like having the time always start at 0 was the intent. In cases where get_current_time returns a negative that isn't MP_NOPTS_VALUE, force this to 0.
2024-05-25 19:43:23 +00:00
// Force to 0 if this is not MP_NOPTS_VALUE.
if (cur != MP_NOPTS_VALUE && cur < 0)
cur = 0.0;
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 21:47:17 +00:00
return cur;
player: make the time display relative to start PTS This commit makes the playback start time always at time 0. Signed-off-by: wm4 <wm4@nowhere>
2014-06-29 17:27:46 +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
// Return playback position in 0.0-1.0 ratio, or -1 if unknown.
double get_current_pos_ratio(struct MPContext *mpctx, bool use_range)
{
struct demuxer *demuxer = mpctx->demuxer;
if (!demuxer)
return -1;
double ans = -1;
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 21:47:17 +00:00
double start = 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
double len = get_time_length(mpctx);
if (use_range) {
player: add get_play_start_pts Added a get_play_start_pts function to coincide with the already-existing get_play_end_pts. This prevents code duplication and also serves to make it so code that probes the start time (such as get_current_pos_ratio) will work correctly with chapters. Included is a bug fix for misc.c/rel_time_to_abs that makes it work correctly with chapters when --rebase-start-time=no is set.
2017-12-04 01:26:42 +00:00
double startpos = get_play_start_pts(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
double endpos = get_play_end_pts(mpctx);
player: modify/simplify AB-loop behavior This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
2019-05-26 23:24:22 +00:00
if (endpos > MPMAX(0, len))
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 21:47:17 +00:00
endpos = MPMAX(0, len);
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 (endpos < startpos)
endpos = startpos;
start = startpos;
len = endpos - startpos;
}
double pos = get_current_time(mpctx);
player: fallback to seek time for percent-pos property The percent-pos property normally goes by time, except for file formats like .ts or .ogg, where you can't trust the timestamps and duration info to compute the position in the overall files. These use the byte position and size instead. When the file position was unavailable (e.g. due to an ongoing seek), the percent-pos was unknown. Change it to use the time position instead. In most cases, it's actually accurate enough, and the temporary unavailability of the property can be annoying, e.g. on the terminal status line.
2015-01-14 21:14:20 +00:00
if (len > 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
ans = MPCLAMP((pos - start) / len, 0, 1);
playloop: don't read playback pos from byte stream If a file format supports PTS resets, get_current_pos_ratio calculates the ratio using the stored filepos in the demuxer struct instead of a standard query of the current time in the stream and its total length. This seems like a reasonable way to avoid weird PTS values, but in reality this just causes problems and results in inaccurate ratio values that can affect other parts of the player (most notably the osc seekbar). For libavformat formats, demux->filepos is obtained from the demux_lavf_fill_buffer function which is called on the next packet. The problem is that there is a slight delay between packets and in some cases, this delay can be relatively large. That means the obtained demuxer->filepos value will be very inaccurate since it obtains the pos from the end of the upcoming packet and not its actual current position. This is especially noticeable at the very beginning of playback where get_current_pos_ratio sometimes returns a value of well over 2% despite less than a second passing in the stream. Another telltale sign is to simply watch the osc seekbar as a stream progresses and observe how it loads in staggered steps as every packet is decoded. In contrast, the seekbar progresses smoothly on the playback of a format that does not support PTS resets. The simple solution is to instead use the query of the current time and length of a stream and calculate the ratio that way. get_current_pos_ratio will still fallback on using the byte stream position if the previous queries fail. However, get_current_time will be more accurate in the vast majority of cases and should be the preferred method of calculating the position ratio.
2019-09-21 15:03:57 +00:00
if (ans < 0) {
demux: return stream file size differently, rip out stream ctrls The stream size return was the only thing that still required doing STREAM_CTRLs from frontend through the demuxer layer. This can be done much easier, so rip it out. Also rip out the now unused infrastructure for STREAM_CTRLs via demuxer layer.
2018-09-07 19:58:46 +00:00
int64_t size = demuxer->filesize;
if (size > 0 && demuxer->filepos >= 0)
ans = MPCLAMP(demuxer->filepos / (double)size, 0, 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
}
if (use_range) {
if (mpctx->opts->play_frames > 0)
ans = MPMAX(ans, 1.0 -
mpctx->max_frames / (double) mpctx->opts->play_frames);
}
return ans;
}
// -2 is no chapters, -1 is before first chapter
int get_current_chapter(struct MPContext *mpctx)
{
player: remove weird separation between no chapters and 0 chapters For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
2014-03-25 01:10:24 +00:00
if (!mpctx->num_chapters)
return -2;
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
double current_pts = get_current_time(mpctx);
player: remove weird separation between no chapters and 0 chapters For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
2014-03-25 01:10:24 +00:00
int i;
player: don't ignore first chapter It's a mystery why this was done this way. If the first chapter starts later than the current position, we do have to return -1.
2014-07-31 20:54:57 +00:00
for (i = 0; i < mpctx->num_chapters; i++)
player: always use demux_chapter Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
2014-11-02 16:20:04 +00:00
if (current_pts < mpctx->chapters[i].pts)
player: remove weird separation between no chapters and 0 chapters For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
2014-03-25 01:10:24 +00:00
break;
playloop: make chapter property more accurate when seeking chapters When seeking chapters, `last_chapter_seek` acts as a projection of what the current chapter will be once mpv has a chance to seek to it. This allows for more accurate results from the `chapter` property. It works by comparing the projection to the actual current chapter and returning the larger of the two indexes, but this only works when seeking forward. If we want it to work for both forward and backward chapter seeking, we can instead use a boolean called `last_chapter_flag`, which gets switched on when a chapter seek request is made, and then switched off when the seek has been performed. We should also check to ensure that we don't allow the chapter index to be set to -1 unless there is a span of time between the very beginning of the track and the start of the first chapter. Since the new approach to resetting `last_chapter_seek` no longer depends on `last_chapter_pts`, that member variable can be removed.
2023-09-27 12:00:14 +00:00
return mpctx->last_chapter_flag ?
mpctx->last_chapter_seek : MPMAX(mpctx->last_chapter_seek, i - 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
}
char *chapter_display_name(struct MPContext *mpctx, int chapter)
{
char *name = chapter_name(mpctx, chapter);
player: simplify chapter display name code The display name is always recomputed, so we can always toss the input name.
2014-08-27 22:16:03 +00:00
char *dname = NULL;
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 (name) {
dname = talloc_asprintf(NULL, "(%d) %s", chapter + 1, name);
} else if (chapter < -1) {
dname = talloc_strdup(NULL, "(unavailable)");
} else {
int chapter_count = get_chapter_count(mpctx);
if (chapter_count <= 0)
dname = talloc_asprintf(NULL, "(%d)", chapter + 1);
else
dname = talloc_asprintf(NULL, "(%d) of %d", chapter + 1,
chapter_count);
}
return dname;
}
// returns NULL if chapter name unavailable
char *chapter_name(struct MPContext *mpctx, int chapter)
{
player: remove weird separation between no chapters and 0 chapters For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
2014-03-25 01:10:24 +00:00
if (chapter < 0 || chapter >= mpctx->num_chapters)
return NULL;
demux: remove redundant demux_chapter.name field Instead, force everyone to use the metadata struct and set a "title" field. This is only a problem for the timeline producers, which set up chapters manually. (They do this because a timeline is a separate struct.) This fixes the behavior of the chapter-metadata property, which never returned a "title" property for e.g. ordered chapters.
2015-08-12 09:10:45 +00:00
return mp_tags_get_str(mpctx->chapters[chapter].metadata, "title");
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: refactor chapter seek code mp_seek_chapter() had only 1 caller. Also the code was rather roundabout; the entire function can be compressed to 5 lines of code. (The new code is functionally the same - "mpctx->last_chapter_seek = -2;" was effectively a dead assingment.)
2015-07-10 10:11:14 +00:00
// returns the start of the chapter in seconds (NOPTS if unavailable)
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
double chapter_start_time(struct MPContext *mpctx, int chapter)
{
if (chapter == -1)
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 21:47:17 +00:00
return 0;
player: remove weird separation between no chapters and 0 chapters For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
2014-03-25 01:10:24 +00:00
if (chapter >= 0 && chapter < mpctx->num_chapters)
player: always use demux_chapter Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
2014-11-02 16:20:04 +00:00
return mpctx->chapters[chapter].pts;
player: let chapter_start_time() return MP_NOPTS_VALUE for unknown times
2014-03-25 01:18:12 +00:00
return MP_NOPTS_VALUE;
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 get_chapter_count(struct MPContext *mpctx)
{
player: remove demuxer chapoter API wrappers Instead, always use the mpctx->chapters array. Before this commit, this array was used only for ordered chapters and such, but now it's always populated if there are chapters.
2014-03-25 01:05:48 +00:00
return mpctx->num_chapters;
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: modify/simplify AB-loop behavior This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
2019-05-26 23:24:22 +00:00
// If the current playback position (or seek target) falls before the B
// position, actually make playback loop when reaching the B point. The
// intention is that you can seek out of the ab-loop range.
void update_ab_loop_clip(struct MPContext *mpctx)
{
double pts = get_current_time(mpctx);
double ab[2];
mpctx->ab_loop_clip = pts != MP_NOPTS_VALUE &&
get_ab_loop_times(mpctx, ab) &&
pts * mpctx->play_dir <= ab[1] * mpctx->play_dir;
}
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
static void handle_osd_redraw(struct MPContext *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
{
playloop: don't redraw without subs on quit handle_osd_redraw is called while we're in the middle of the cleanup portion of play_current_file (via kill_demuxers_reentrant and mp_idle). This happens after we've torn down the subtitle track, so we end up requesting a redraw from the vo, which results in a 1-frame flash of the video without subs before we either quit or switch to the next file (or the force-window state). This detects that condition and skips the redraw, without interfering with drawing the osd during idle (eg for pseudo-gui mode).
2024-05-19 21:19:17 +00:00
if (!mpctx->video_out || !mpctx->video_out->config_ok || (mpctx->playing && mpctx->stop_play))
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
return;
// If we're playing normally, let OSD be redrawn naturally as part of
// video display.
player: don't delay OSD redraw when paused We want this heuristic to trigger during normal playback only.
2014-08-10 11:11:46 +00:00
if (!mpctx->paused) {
if (mpctx->sleeptime < 0.1 && mpctx->video_status == STATUS_PLAYING)
return;
}
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
// Don't redraw immediately during a seek (makes it significantly slower).
player: dumb seeking related stuff, make audio hr-seek default Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
bool use_video = mpctx->vo_chain && !mpctx->vo_chain->is_sparse;
player: eagerly redraw OSD when seeking with coverart
2016-04-23 14:39:46 +00:00
if (use_video && mp_time_sec() - mpctx->start_timestamp < 0.1) {
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_set_timeout(mpctx, 0.1);
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
return;
player: properly wakeup when delaying OSD Not sure in which situations this could make a difference; probably none in practice, but it's more correct. CC: @mpv-player/stable
2014-10-03 19:57:16 +00:00
}
video: return responsibility of video redraw back to playloop When the VO was moved it its own thread, responsibility for redrawing was given to the VO thread itself. So if there was a condition that indicated that redrawing was required, like expose events or certain VOCTRLs, the VO thread was redrawing itself. This worked fine, but there are some corner cases where this works rather badly. E.g. if I fullscreen the player and hit panscan controls with mpv's default autorepeat rate, playback stops. This happens because the VO redraws itself after every panscan change command. Running each (repeated) command takes so long due to redrawing and (involuntary) waiting on vsync, that it never leaves the input processing loop while the key is held down. I suspect that in my case, redrawing in fullscreen mode just gets slow enough that it takes 2 vsyncs instead of 1 on average, and the processing time gets larger than the autorepeat delay. Fix this by taking redraw control from the VO, and instead let the playloop issue a "real" redraw command to the VO if needed. This basically reverts redraw handling to what it was before moving the VO to a thread. CC: @mpv-player/stable
2014-10-03 19:53:32 +00:00
bool want_redraw = osd_query_and_reset_want_redraw(mpctx->osd) ||
vo_want_redraw(mpctx->video_out);
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
if (!want_redraw)
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
return;
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
vo_redraw(mpctx->video_out);
player/sub: avoid wasteful subtitle redraws This only affects two special cases: printing subtitles to the terminal and printing subtitles on a still picture. Previously, mpv was very dumb here and spammed this logic on every single loop. For terminal subtitles, this isn't as big of a deal, but for the image case this is pretty bad. The entire VO constantly redrew even when there was no need to which can be very expensive depending on user settings. Instead, let's rework sub_read_packets so that it also tells us whether or not the subtitle packets update in some way in addition to telling us whether or not to read more. Since we cache all packets thanks to the previous commit, we can leverage this information to make a guess whether or not the current subtitle packet is supposed to be visible on the screen. Because the redraw now only happens when it is needed, the mp_set_timeout_hack can be removed.
2024-01-21 23:14:39 +00:00
// Even though we just redrew, it may need to be done again for certain
// cases of subtitles on an image.
redraw_subs(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
}
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
static void clear_underruns(struct MPContext *mpctx)
{
if (mpctx->ao_chain && mpctx->ao_chain->underrun) {
mpctx->ao_chain->underrun = false;
mp_wakeup_core(mpctx);
}
if (mpctx->vo_chain && mpctx->vo_chain->underrun) {
mpctx->vo_chain->underrun = false;
mp_wakeup_core(mpctx);
}
}
playloop: update cache properties in idle state This will properly notify observed properties if the player hasn't started actual playback yet, such as with --demuxer-cache-wait. This also happens to cause the main loop more often, which triggers MPV_EVENT_IDLE, and fixes the OSC display. (See previous commit message.)
2019-05-17 19:59:52 +00:00
static void handle_update_cache(struct MPContext *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
{
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
bool force_update = 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
struct MPOpts *opts = mpctx->opts;
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
player: consider audio buffer if AO driver does not report underruns AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
2020-02-13 00:28:59 +00:00
if (!mpctx->demuxer || mpctx->encode_lavc_ctx) {
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
clear_underruns(mpctx);
cache: redo options and default settings Some options change from percentages to number of kilobytes; there are no cache options using percentages anymore. Raise the default values. The cache is now 25000 kilobytes, although if your connection is slow enough, the maximum is probably never reached. (Although all the memory will still be used as seekback-cache.) Remove the separate --audio-file-cache option, and use the cache default settings for it.
2014-05-19 21:27:09 +00:00
return;
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
}
player: redo how stream caching and pausing on low cache works Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
2014-08-26 23:13:20 +00:00
player: reduce some timer calls
2016-04-20 08:50:22 +00:00
double now = mp_time_sec();
demux: simplify API for returning cache status Instead of going through those weird DEMUXER_CTRLs, query this information directly. I'm not sure which kind of brain damage made me use CTRLs for these. Since there are no other DEMUXER_CTRLs that make sense for the frontend, remove the remaining infrastructure for them too.
2018-09-07 20:26:48 +00:00
struct demux_reader_state s;
demux_get_reader_state(mpctx->demuxer, &s);
player: better cache status on status line The cache percentage was useless. It showed how much of the total stream cache was in use, but since the cache size is something huge and unrelated to the bitrate or network speed, the information content of the percentage was rather low. Replace this with printing the duration of the demuxer-cached data, and the size of the stream cache in KB. I'm not completely sure about the formatting; suggestions are welcome. Note that it's not easy to know how much playback time the stream cache covers, so it's always in bytes.
2014-08-27 20:42:28 +00:00
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
mpctx->demux_underrun |= s.underrun;
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
int cache_buffer = 100;
player: enable "pause caching" code for local playback too There isn't really a need to disable this for local playback. I think originally I did this because I was afraid the code could mess up or be annoying on local mode, but that's not really a good argument. I'd rather test this code in local mode too. In this case, it shouldn't really happen that it runs out of cache in the first place.
2019-11-14 12:51:47 +00:00
bool use_pause_on_low_cache = opts->cache_pause && mpctx->play_dir > 0;
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
if (!mpctx->restart_complete) {
// Audio or video is restarting, and initial buffering is enabled. Make
// sure we actually restart them in paused mode, so no audio gets
// dropped and video technically doesn't start yet.
use_pause_on_low_cache &= opts->cache_pause_initial &&
(mpctx->video_status == STATUS_READY ||
mpctx->audio_status == STATUS_READY);
}
bool is_low = use_pause_on_low_cache && !s.idle &&
demux: keep track of ts information per stream type Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-10-20 01:16:22 +00:00
s.ts_info.duration < opts->cache_pause_wait;
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
// Enter buffering state only if there actually was an underrun (or if
// initial caching before playback restart is used).
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
bool need_wait = is_low;
if (is_low && !mpctx->paused_for_cache && mpctx->restart_complete) {
// Wait only if an output underrun was registered. (Or if there is no
// underrun detection.)
bool output_underrun = false;
player: consider audio buffer if AO driver does not report underruns AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
2020-02-13 00:28:59 +00:00
if (mpctx->ao_chain)
output_underrun |= mpctx->ao_chain->underrun;
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
if (mpctx->vo_chain)
output_underrun |= mpctx->vo_chain->underrun;
// Output underruns could be sporadic (unrelated to demuxer buffer state
// and for example caused by slow decoding), so use a past demuxer
// underrun as indication that the underrun was possibly due to a
// demuxer underrun.
need_wait = mpctx->demux_underrun && output_underrun;
}
// Let the underrun flag "stick" around until the cache has fully recovered.
// See logic where demux_underrun is used.
if (!is_low)
mpctx->demux_underrun = false;
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
if (mpctx->paused_for_cache != need_wait) {
mpctx->paused_for_cache = need_wait;
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
update_internal_pause_state(mpctx);
force_update = true;
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
if (mpctx->paused_for_cache)
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
mpctx->cache_stop_time = now;
}
player: partially rework --cache-pause The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
if (!mpctx->paused_for_cache)
clear_underruns(mpctx);
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
if (mpctx->paused_for_cache) {
cache_buffer =
demux: keep track of ts information per stream type Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-10-20 01:16:22 +00:00
100 * MPCLAMP(s.ts_info.duration / opts->cache_pause_wait, 0, 0.99);
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
mp_set_timeout(mpctx, 0.2);
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: redo how stream caching and pausing on low cache works Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
2014-08-26 23:13:20 +00:00
client API: make "cache" property and similar observable Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
2014-07-31 02:19:41 +00:00
// Also update cache properties.
demux, stream: rip out the classic stream cache The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
2018-08-31 10:48:36 +00:00
bool busy = !s.idle;
player: force update of cache properties even on inactive demuxer cache When the demuxer cache read until the end of the stream, and was finished and completely inactive, the cache properties were not updated anymore via MP_EVENT_CACHE_UPDATE. Unfortunately, many cache properties depend on the current playback position, such as cache-duration or fw-bytes. This is especially visible on the OSC. If everything was cached, seeking around didn't update the displayed forward cache duration. That means checking demuxer_reader_state.idle is not enough. You also need to check whether the current playback position changed. Fix this by explicitly using the current playback position, and update the properties if it changed "enough". "Enough" is 1 second of media time in this example, which may or may not be appropriate. In general, this could probably be done better. There are many other triggers that change the cache state and that are not covered. For now I'm content with getting rid of the obvious problems. I think the OSC problem in particular was caused by changing it from polling to using property change notifications.
2020-03-05 21:23:43 +00:00
if (fabs(mpctx->cache_update_pts - mpctx->playback_pts) >= 1.0)
busy = true;
player: redo how stream caching and pausing on low cache works Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
2014-08-26 23:13:20 +00:00
if (busy || mpctx->next_cache_update > 0) {
client API: make "cache" property and similar observable Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
2014-07-31 02:19:41 +00:00
if (mpctx->next_cache_update <= now) {
player: redo how stream caching and pausing on low cache works Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
2014-08-26 23:13:20 +00:00
mpctx->next_cache_update = busy ? now + 0.25 : 0;
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
force_update = true;
client API: make "cache" property and similar observable Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
2014-07-31 02:19:41 +00:00
}
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
if (mpctx->next_cache_update > 0)
mp_set_timeout(mpctx, mpctx->next_cache_update - now);
client API: make "cache" property and similar observable Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
2014-07-31 02:19:41 +00:00
}
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
if (mpctx->cache_buffer != cache_buffer) {
player: slightly refactor/simplify cache pausing logic The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
2018-01-06 14:49:32 +00:00
if ((mpctx->cache_buffer == 100) != (cache_buffer == 100)) {
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
if (cache_buffer < 100) {
player: add more logging around buffering state
2018-05-02 19:34:43 +00:00
MP_VERBOSE(mpctx, "Enter buffering (buffer went from %d%% -> %d%%) [%fs].\n",
demux: keep track of ts information per stream type Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-10-20 01:16:22 +00:00
mpctx->cache_buffer, cache_buffer, s.ts_info.duration);
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
} else {
player: reduce some timer calls
2016-04-20 08:50:22 +00:00
double t = now - mpctx->cache_stop_time;
player: add more logging around buffering state
2018-05-02 19:34:43 +00:00
MP_VERBOSE(mpctx, "End buffering (waited %f secs) [%fs].\n",
demux: keep track of ts information per stream type Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-10-20 01:16:22 +00:00
t, s.ts_info.duration);
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
}
player: add more logging around buffering state
2018-05-02 19:34:43 +00:00
} else {
MP_VERBOSE(mpctx, "Still buffering (buffer went from %d%% -> %d%%) [%fs].\n",
demux: keep track of ts information per stream type Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-10-20 01:16:22 +00:00
mpctx->cache_buffer, cache_buffer, s.ts_info.duration);
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
}
mpctx->cache_buffer = cache_buffer;
force_update = true;
}
player: add prefetching of the next playlist entry Since for mpv CLI, the player state is a singleton, full prefetching is a bit tricky. We do it only on the demuxer layer. The implementation reuses the old "open thread". This means there is significant potential for regressions even if the new option is not used. This is made worse by the fact that I barely tested this code. The generic mpctx_run_reentrant() wrapper is also removed - this was its only user, and its remains become part of the new implementation.
2017-01-18 18:02:50 +00:00
if (s.eof && !busy)
prefetch_next(mpctx);
player: force update of cache properties even on inactive demuxer cache When the demuxer cache read until the end of the stream, and was finished and completely inactive, the cache properties were not updated anymore via MP_EVENT_CACHE_UPDATE. Unfortunately, many cache properties depend on the current playback position, such as cache-duration or fw-bytes. This is especially visible on the OSC. If everything was cached, seeking around didn't update the displayed forward cache duration. That means checking demuxer_reader_state.idle is not enough. You also need to check whether the current playback position changed. Fix this by explicitly using the current playback position, and update the properties if it changed "enough". "Enough" is 1 second of media time in this example, which may or may not be appropriate. In general, this could probably be done better. There are many other triggers that change the cache state and that are not covered. For now I'm content with getting rid of the obvious problems. I think the OSC problem in particular was caused by changing it from polling to using property change notifications.
2020-03-05 21:23:43 +00:00
if (force_update) {
mpctx->cache_update_pts = mpctx->playback_pts;
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
mp_notify(mpctx, MP_EVENT_CACHE_UPDATE, NULL);
player: force update of cache properties even on inactive demuxer cache When the demuxer cache read until the end of the stream, and was finished and completely inactive, the cache properties were not updated anymore via MP_EVENT_CACHE_UPDATE. Unfortunately, many cache properties depend on the current playback position, such as cache-duration or fw-bytes. This is especially visible on the OSC. If everything was cached, seeking around didn't update the displayed forward cache duration. That means checking demuxer_reader_state.idle is not enough. You also need to check whether the current playback position changed. Fix this by explicitly using the current playback position, and update the properties if it changed "enough". "Enough" is 1 second of media time in this example, which may or may not be appropriate. In general, this could probably be done better. There are many other triggers that change the cache state and that are not covered. For now I'm content with getting rid of the obvious problems. I think the OSC problem in particular was caused by changing it from polling to using property change notifications.
2020-03-05 21:23:43 +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
}
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
int get_cache_buffering_percentage(struct MPContext *mpctx)
command: add cache-buffering-state property
2014-10-07 20:07:07 +00:00
{
player: simplify an aspect of buffering determination Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
2016-04-19 20:01:30 +00:00
return mpctx->demuxer ? mpctx->cache_buffer : -1;
command: add cache-buffering-state property
2014-10-07 20:07:07 +00:00
}
player: avoid busy looping during reinit_sub If the player is paused, switching subtitle track requires us to read subs packets for an indefinite amount of time in order to actually display the subtitles. The problem with this is that it puts a blocking loop in the play thread which can be slow in cases where it takes a long time to fetch the subtitle (e.g. over a network). 9e27b1f523071db184443d78f7144cb599dd0829 alleviates this when a pause happens because of buffering, but it's not complete. One could encounter this if the user pauses the video first manually and then switches the subtitle track. To solve this better, make it so the loop has a time out (totally arbitrary number) so the player isn't blocked forever. If subtitles are not fetched within that time, we flag the track and try again later in the playloop.
2024-04-14 21:37:32 +00:00
static void handle_update_subtitles(struct MPContext *mpctx)
{
if (mpctx->video_status == STATUS_EOF) {
update_subtitles(mpctx, mpctx->playback_pts);
return;
}
for (int n = 0; n < mpctx->num_tracks; n++) {
struct track *track = mpctx->tracks[n];
if (track->type == STREAM_SUB && !track->demuxer_ready) {
update_subtitles(mpctx, mpctx->playback_pts);
break;
}
}
}
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 void handle_cursor_autohide(struct MPContext *mpctx)
{
struct MPOpts *opts = mpctx->opts;
struct vo *vo = mpctx->video_out;
if (!vo)
return;
bool mouse_cursor_visible = mpctx->mouse_cursor_visible;
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
double now = mp_time_sec();
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
unsigned mouse_event_ts = mp_input_get_mouse_event_counter(mpctx->input);
if (mpctx->mouse_event_ts != mouse_event_ts) {
mpctx->mouse_event_ts = mouse_event_ts;
Revert "options: move cursor autohiding opts to mp_vo_opts" This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
2020-01-12 00:32:13 +00:00
mpctx->mouse_timer = now + opts->cursor_autohide_delay / 1000.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
mouse_cursor_visible = true;
}
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
if (mpctx->mouse_timer > now) {
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_set_timeout(mpctx, mpctx->mouse_timer - now);
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
} else {
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
mouse_cursor_visible = false;
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +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
Revert "options: move cursor autohiding opts to mp_vo_opts" This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
2020-01-12 00:32:13 +00:00
if (opts->cursor_autohide_delay == -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
mouse_cursor_visible = true;
Revert "options: move cursor autohiding opts to mp_vo_opts" This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
2020-01-12 00:32:13 +00:00
if (opts->cursor_autohide_delay == -2)
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
mouse_cursor_visible = false;
Revert "options: move cursor autohiding opts to mp_vo_opts" This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
2020-01-12 00:32:13 +00:00
if (opts->cursor_autohide_fs && !opts->vo->fullscreen)
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
mouse_cursor_visible = true;
if (mouse_cursor_visible != mpctx->mouse_cursor_visible)
vo_control(vo, VOCTRL_SET_CURSOR_VISIBILITY, &mouse_cursor_visible);
mpctx->mouse_cursor_visible = mouse_cursor_visible;
}
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 19:26:51 +00:00
static void handle_vo_events(struct MPContext *mpctx)
{
struct vo *vo = mpctx->video_out;
video/out: minor simplification to event query function The "clear" parameter is confusing and useless.
2014-11-09 09:00:21 +00:00
int events = vo ? vo_query_and_reset_events(vo, VO_EVENTS_USER) : 0;
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 19:26:51 +00:00
if (events & VO_EVENT_RESIZE)
mp_notify(mpctx, MP_EVENT_WIN_RESIZE, NULL);
command: add window-minimized property (X11 only) More or less requested by #1237. Should be simple to extend this to other backends.
2014-11-02 19:48:45 +00:00
if (events & VO_EVENT_WIN_STATE)
mp_notify(mpctx, MP_EVENT_WIN_STATE, NULL);
command, vo: add a mechanism for runtime DPI scale changes Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
2020-01-08 19:23:12 +00:00
if (events & VO_EVENT_DPI)
mp_notify(mpctx, MP_EVENT_WIN_STATE2, NULL);
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 16:22:25 +00:00
if (events & VO_EVENT_FOCUS)
mp_notify(mpctx, MP_EVENT_FOCUS, NULL);
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 19:26:51 +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
static void handle_sstep(struct MPContext *mpctx)
{
struct MPOpts *opts = mpctx->opts;
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
if (mpctx->stop_play || !mpctx->restart_complete)
return;
if (opts->step_sec > 0 && !mpctx->paused) {
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
set_osd_function(mpctx, OSD_FFW);
player: allow passing flags to queue_seek() Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
2016-08-15 19:07:32 +00:00
queue_seek(mpctx, MPSEEK_RELATIVE, opts->step_sec, MPSEEK_DEFAULT, 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: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
player: fix weird behavior when framestepping over format changes When video format changes, the frame before the frame with the new format sets video_status briefly to STATUS_DRAINING. This caused the code to handle the EOF case to kick in, which just pauses the player when trying to step past the last frame. As a result, trying to framestep over format changes resulted in pausing the player. Fix by testing against the correct status.
2014-08-26 18:45:41 +00:00
if (mpctx->video_status >= STATUS_EOF) {
player: never overwrite stop_play field This is a real pain: if a quit command is received, it's set to PT_QUIT. And then other code could overwrite it, making it not quit. The annoying bit is that stop_play is written and read in many places. Just not overwriting it unconditionally seems to be the best course of action.
2015-07-08 19:31:31 +00:00
if (mpctx->max_frames >= 0 && !mpctx->stop_play)
player: fix --frames This could produce an extra frame, because reaching the maximum merely signals the playloop to exit, without strictly enforcing the limit. Fixes #1181. CC: @mpv-player/stable
2014-10-14 11:29:38 +00:00
mpctx->stop_play = AT_END_OF_FILE; // force EOF even if audio left
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
if (mpctx->step_frames > 0 && !mpctx->paused)
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
set_pause_state(mpctx, true);
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +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
}
player: add a --loop-file option Unlike --loop, loops a file instead of the playlist.
2014-04-17 21:55:04 +00:00
static void handle_loop_file(struct MPContext *mpctx)
{
player: remove some duplication between normal looping and ab-loops Not sure if this is better or worse. Some minor behavior changes.
2019-05-26 23:33:35 +00:00
if (mpctx->stop_play != AT_END_OF_FILE)
return;
double target = MP_NOPTS_VALUE;
enum seek_precision prec = MPSEEK_DEFAULT;
player: modify/simplify AB-loop behavior This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
2019-05-26 23:24:22 +00:00
double ab[2];
player: remove some duplication between normal looping and ab-loops Not sure if this is better or worse. Some minor behavior changes.
2019-05-26 23:33:35 +00:00
if (get_ab_loop_times(mpctx, ab) && mpctx->ab_loop_clip) {
player: don't decrement --ab-loop-count=N and add remaining-ab-loops Follow up to the previous commit. Stop decreasing --ab-loop-count=N on each iteration so it is preserved across different loops. In particular it is preserved between different files without adding it to --reset-on-next-file. Add a property to expose the remaning A-B loop count instead. The current behavior of --ab-loop-count=N is even worse than --loop-file since it also doesn't reset when defining a new A-B loop in the same file. Defining it has no effect after --ab-loop-count has decreased to 0, and this can't be fixed by adding it to --reset-on-next-file. This commit also resets remaining-ab-loops every time --ab-loop-a and --ab-loop-b are set to fix this.
2024-07-04 20:07:10 +00:00
if (mpctx->remaining_ab_loops > 0) {
mpctx->remaining_ab_loops--;
mp_notify_property(mpctx, "remaining-ab-loops");
player: add ab-loop-count option/property As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
2020-02-08 13:57:45 +00:00
}
player: remove some duplication between normal looping and ab-loops Not sure if this is better or worse. Some minor behavior changes.
2019-05-26 23:33:35 +00:00
target = ab[0];
prec = MPSEEK_EXACT;
player: don't decrement --loop-file=N and add remaining-file-loops This stops decreasing numerical values of --loop-file on each iteration so that loop-file=N loops every playlist entry without having to add --loop-file to --reset-on-next-file. The current behavior confuses users as seen in: https://github.com/mpv-player/mpv/issues/2481 https://github.com/mpv-player/mpv/issues/5943 https://github.com/mpv-player/mpv/issues/11291 https://github.com/mpv-player/mpv/issues/13860 https://www.reddit.com/r/mpv/comments/rcwnrw/looping_each_file_n_times_in_a_playlist/ Also options are supposed to reflect the value configured by the user and not change on their own. A remaining-file-loops property is exposed as a replacement to check how many loops are left.
2024-06-04 19:51:03 +00:00
} else if (mpctx->remaining_file_loops) {
if (mpctx->remaining_file_loops > 0) {
mpctx->remaining_file_loops--;
mp_notify_property(mpctx, "remaining-file-loops");
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
}
player: fix --loop with backward playback Obviously should seek back to the end of the file when it loops. Also remove some minor code duplication around start times. This isn't the correct solution by the way. Rather than hoping we know a reasonable start/end time, this stuff should instruct the demuxer to seek to the exact location. It'll work with 99% of all normal files, but add an appropriate comment (that basically says the function is bullshit) to get_start_time() anyway.
2019-05-26 23:46:34 +00:00
target = get_start_time(mpctx, mpctx->play_dir);
player: make looping slightly more seamless This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
2016-08-18 18:40:23 +00:00
}
player: remove some duplication between normal looping and ab-loops Not sure if this is better or worse. Some minor behavior changes.
2019-05-26 23:33:35 +00:00
if (target != MP_NOPTS_VALUE) {
player: do not loop if there's nothing to loop This can happen if a file contains headers only, or if decoding of all data failed, and such. Interestingly, it also happened when doing "mpv --loop emptyfile.png", because demux_mf still detects file formats by file extension. In this situation, the player burned a lot of CPU by restarting playback after doing nothing. Although such "degenerate" behavior can't be avoided in all situations (what if you loop a file with 1 audio sample?), detecting this seems to make sense. For now, this actually decrements the loop count by 1, and then errors out with a warning. Works for --loop and --ab-loop, while --loop-playlist already avoids this situation with an existing mechanism.
2020-08-22 18:43:15 +00:00
if (!mpctx->shown_aframes && !mpctx->shown_vframes) {
MP_WARN(mpctx, "No media data to loop.\n");
return;
}
player/playloop.c: Revert --loop-file and --start interaction This reverts commit 9513165c99c2ab3a945620b260823440f8ad125d and commit 4efe330efba296f6f07089d60087ef4e054bfe04. I had changed --loop-file to interact with --start to work the same way that --loop-playlist does. (That is, --loop-file seeks to the --start time upon looping, not the beginning of the file.) However, the consensus is that the old behavior is preferred and the interaction with --loop-playlist is the one that is incorrect. In addition, this change introduced a bug in the interaction between Quit-Watch-Later and --loop-file, where upon reaching playback end it would seek to the resume timestamp, not the start of the file. As a result, this commit reverts that change.
2017-12-28 15:23:12 +00:00
mpctx->stop_play = KEEP_PLAYING;
set_osd_function(mpctx, OSD_FFW);
player: remove some duplication between normal looping and ab-loops Not sure if this is better or worse. Some minor behavior changes.
2019-05-26 23:33:35 +00:00
mark_seek(mpctx);
// Assumes execute_queued_seek() happens before next audio/video is
// attempted to be decoded or filtered.
queue_seek(mpctx, MPSEEK_ABSOLUTE, target, prec, MPSEEK_FLAG_NOFLUSH);
player: add a --loop-file option Unlike --loop, loops a file instead of the playlist.
2014-04-17 21:55:04 +00:00
}
}
player: make chapter seek to end jump to last frame with --keep-open There were complaints that a chapter seek past the last chapter was quitting the player. Change the behavior to what is expected: the last frame. If no chapters are available, this still does nothing.
2014-12-08 16:27:07 +00:00
void seek_to_last_frame(struct MPContext *mpctx)
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
{
player: refactor: eliminate MPContext.d_video Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
2016-01-17 17:07:50 +00:00
if (!mpctx->vo_chain)
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
return;
player: hack against --keep-open misbehaving with broken files If a file (or a demuxer) is broken, seeking close to the end of the file doesn't work, and seek_to_last_frame() will be called over and over again, burning CPU for no reason. Observed with incomplete mp4 files. That this can happen was already mentioned in commit 090f6cfc, but I guess now I'll do something against it. hrseek_lastframe is cleared by reset_playback_state(), so it's only set if seek_to_last_frame() was called, and no other seek happened since then. If finding the last frame succeeds, no EOF will happen (unless the user unpauses, but then it will simply remain at the last frame). If it fails, then it will return immediately, without retrying.
2014-12-24 14:12:11 +00:00
if (mpctx->hrseek_lastframe) // exit if we already tried this
return;
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
MP_VERBOSE(mpctx, "seeking to last frame...\n");
// Approximately seek close to the end of the file.
// Usually, it will seek some seconds before end.
player: partially fix seek_to_last_frame in backward mode Another shitty obscure feature that usually nobody notices. Unsurprisingly, it doesn't go well with backward playback mode. If you use --keep-open in forward playback mode, and seek past the end of the file, it tries to seek to the very last frame. The demuxer will seek to the last "keyframe" before the end (i.e. some frames to go in most cases), and trying to hr-seek to the file duration often won't cut it, so this requires some special code. The function at hand seeks "close" to the end, and then stops hr-seek when the last frame us encountered (simple enough and very effective). In backward playback mode, start and end are reversed, and we need to seek "close" to the start of the file instead. Simple enough to do, and it works. One problem is that command.c has some weird logic to make going beyond the last chapter either end playback (--keep-open=no), or jump to the last frame. Now this will jump to the first frame, which is weird, but let's ignore this. Another problem is that seeking before playback start position hits EOF in backward playback mode, which is a demuxer bug, and has nothing to do with this code. But it triggers this code, so seeking before the start will show the "last" frame. (My description is a mess with directions. Figure it out yourself.)
2019-05-27 00:12:26 +00:00
double end = MP_NOPTS_VALUE;
if (mpctx->play_dir > 0) {
end = get_play_end_pts(mpctx);
if (end == MP_NOPTS_VALUE)
end = get_time_length(mpctx);
} else {
end = get_start_time(mpctx, 1);
}
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
mp_seek(mpctx, (struct seek_params){
.type = MPSEEK_ABSOLUTE,
.amount = end,
player: use symbolic constant for seek precision Meh.
2015-03-04 16:21:05 +00:00
.exact = MPSEEK_VERY_EXACT,
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
});
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
// Make it exact: stop seek only if last frame was reached.
if (mpctx->hrseek_active) {
player: partially fix seek_to_last_frame in backward mode Another shitty obscure feature that usually nobody notices. Unsurprisingly, it doesn't go well with backward playback mode. If you use --keep-open in forward playback mode, and seek past the end of the file, it tries to seek to the very last frame. The demuxer will seek to the last "keyframe" before the end (i.e. some frames to go in most cases), and trying to hr-seek to the file duration often won't cut it, so this requires some special code. The function at hand seeks "close" to the end, and then stops hr-seek when the last frame us encountered (simple enough and very effective). In backward playback mode, start and end are reversed, and we need to seek "close" to the start of the file instead. Simple enough to do, and it works. One problem is that command.c has some weird logic to make going beyond the last chapter either end playback (--keep-open=no), or jump to the last frame. Now this will jump to the first frame, which is weird, but let's ignore this. Another problem is that seeking before playback start position hits EOF in backward playback mode, which is a demuxer bug, and has nothing to do with this code. But it triggers this code, so seeking before the start will show the "last" frame. (My description is a mess with directions. Figure it out yourself.)
2019-05-27 00:12:26 +00:00
mpctx->hrseek_pts = INFINITY * mpctx->play_dir;
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
mpctx->hrseek_lastframe = 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
static void handle_keep_open(struct MPContext *mpctx)
{
struct MPOpts *opts = mpctx->opts;
player: change --keep-open semantics By popular request.
2014-09-23 23:56:53 +00:00
if (opts->keep_open && mpctx->stop_play == AT_END_OF_FILE &&
player: fix parentheses warning with && Was tripping -Wparantheses as the && after the || was not explicitly wrapped. However, due to operator precedence the intended effect was still correct.
2022-01-17 15:02:19 +00:00
(opts->keep_open == 2 ||
(!playlist_get_next(mpctx->playlist, 1) && opts->loop_times == 1)))
player: change --keep-open semantics By popular request.
2014-09-23 23:56:53 +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
mpctx->stop_play = KEEP_PLAYING;
player: refactor: eliminate MPContext.d_video Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
2016-01-17 17:07:50 +00:00
if (mpctx->vo_chain) {
player: set EOF when seeking to end with keep-open Normally with the keep-open option, mpv is supposed to set the eof-reached property to true so clients can possibly do interesting things at this step. However, there was actually an edge case where this property notification did not occur. If you use keep-open and then seek in the file past the end (so mpv stops), property notification is not actually sent in this case. Internally, mpv does a very exact seek at this step which also ends playback, but it does not set STATUS_EOF to the ao and vo before the core idle state is updated. To fix this edge case, it's simply just a matter of explictly setting STATUS_EOF after seek_to_last_frame in handle_keep_open. This logic will only ever trigger if keep-open is being used and the seek goes past the end of the file, so we know that there will always be an EOF here.
2022-05-13 02:58:12 +00:00
if (!vo_has_frame(mpctx->video_out)) { // EOF not reached normally
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
seek_to_last_frame(mpctx);
player: set EOF when seeking to end with keep-open Normally with the keep-open option, mpv is supposed to set the eof-reached property to true so clients can possibly do interesting things at this step. However, there was actually an edge case where this property notification did not occur. If you use keep-open and then seek in the file past the end (so mpv stops), property notification is not actually sent in this case. Internally, mpv does a very exact seek at this step which also ends playback, but it does not set STATUS_EOF to the ao and vo before the core idle state is updated. To fix this edge case, it's simply just a matter of explictly setting STATUS_EOF after seek_to_last_frame in handle_keep_open. This logic will only ever trigger if keep-open is being used and the seek goes past the end of the file, so we know that there will always be an EOF here.
2022-05-13 02:58:12 +00:00
mpctx->audio_status = STATUS_EOF;
mpctx->video_status = STATUS_EOF;
}
player: when seeking past EOF with --keep-open, seek to last frame It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
2014-12-07 01:47:09 +00:00
}
audio: block ao buffer for keep-open This prevents the pause state from triggering before the audio output is finished playing back audio. This is particularly helpful for gapless audio.
2019-08-30 18:11:39 +00:00
if (opts->keep_open_pause) {
audio: refactor how data is passed to AO This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
2020-08-28 18:23:54 +00:00
if (mpctx->ao && ao_is_playing(mpctx->ao))
return;
player: unmess pause state handling Merge the pause_player() and unpause_player() functions. Make sure the pause events are emitted properly. We can now set the internal pause state based on a predicate, instead of e.g. handle_pause_on_low_cache() making a mess to trigger the internal pause state as wanted. Preparation for some more changes.
2017-04-14 16:22:45 +00:00
set_pause_state(mpctx, true);
audio: block ao buffer for keep-open This prevents the pause state from triggering before the audio output is finished playing back audio. This is particularly helpful for gapless audio.
2019-08-30 18:11:39 +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
}
}
client API: add chapter change event Also works for mpv_observe_property() on the "chapter" property.
2014-04-27 20:28:07 +00:00
static void handle_chapter_change(struct MPContext *mpctx)
{
int chapter = get_current_chapter(mpctx);
if (chapter != mpctx->last_chapter) {
mpctx->last_chapter = chapter;
player: make deprecated track/chapter/metadata events internal We still need these to track or notify of modifications to certain properties, but they're now gone from the libmpv ABI.
2021-12-02 16:19:39 +00:00
mp_notify(mpctx, MP_EVENT_CHAPTER_CHANGE, NULL);
client API: add chapter change event Also works for mpv_observe_property() on the "chapter" property.
2014-04-27 20:28:07 +00:00
}
}
player: some more --force-window fixes Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
2015-09-21 19:22:20 +00:00
// Execute a forceful refresh of the VO window. This clears the window from
// the previous video. It also creates/destroys the VO on demand.
// It tries to make the change only in situations where the window is
// definitely needed or not needed, or if the force parameter is set (the
// latter also decides whether to clear an existing window, because there's
// no way to know if this has already been done or not).
int handle_force_window(struct MPContext *mpctx, bool force)
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: some more --force-window fixes Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
2015-09-21 19:22:20 +00:00
// True if we're either in idle mode, or loading of the file has finished.
// It's also set via force in some stages during file loading.
player: change the role of the "stop_play" and "playing" variable Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
2018-05-19 16:25:54 +00:00
bool act = mpctx->stop_play || mpctx->playback_initialized || force;
player: some more --force-window fixes Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
2015-09-21 19:22:20 +00:00
player: honor --force-window if video is selected, but inactive If a video track is selected, but no video is decoded from it (mostly with broken files), then create the window anyway.
2016-02-24 21:19:00 +00:00
// On the other hand, if a video track is selected, but no video is ever
// decoded on it, then create the window.
bool stalled_video = mpctx->playback_initialized && mpctx->restart_complete &&
mpctx->video_status == STATUS_EOF && mpctx->vo_chain &&
player: fix --force-window behavior _Of course_ the previous commit broke --force-window behavior (like it does every single time I touch it). vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a file and going to the next by keeping the seek key down will enter a short moment without video at the end of the first file, which will set the stalled_video variable to true. Prevent it by using the indication whether the window was properly created (which is probably exactly what we want here). This function is also responsible for destroying the window when needed, and obviously we should never do that while video is active. (This is the actual bug, although the other change in this commit already hides the common breakage it caused.)
2016-02-25 10:21:54 +00:00
!mpctx->video_out->config_ok;
player: honor --force-window if video is selected, but inactive If a video track is selected, but no video is decoded from it (mostly with broken files), then create the window anyway.
2016-02-24 21:19:00 +00:00
// Don't interfere with real video playback
if (mpctx->vo_chain && !stalled_video)
return 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
if (!mpctx->opts->force_vo) {
player: fix --force-window behavior _Of course_ the previous commit broke --force-window behavior (like it does every single time I touch it). vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a file and going to the next by keeping the seek key down will enter a short moment without video at the end of the first file, which will set the stalled_video variable to true. Prevent it by using the indication whether the window was properly created (which is probably exactly what we want here). This function is also responsible for destroying the window when needed, and obviously we should never do that while video is active. (This is the actual bug, although the other change in this commit already hides the common breakage it caused.)
2016-02-25 10:21:54 +00:00
if (act && !mpctx->vo_chain)
player: do not destroy VO prematurely when initializing playback If --force-window wasn't used, this would destroy the VO while a file is still being loaded, resulting in flicker and other interruptions when switching from one playlist entry to another. Recent regression. The condition used here is pretty tricky, but it boils down to that it should trigger either in idle mode, or when loading has been fully done (at these points we definitely know whether the VO will be needed).
2015-09-20 21:03:00 +00:00
uninit_video_out(mpctx);
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 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: some more --force-window fixes Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
2015-09-21 19:22:20 +00:00
if (mpctx->opts->force_vo != 2 && !act)
return 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
if (!mpctx->video_out) {
struct vo_extra ex = {
.input_ctx = mpctx->input,
.osd = mpctx->osd,
.encode_lavc_ctx = mpctx->encode_lavc_ctx,
player, ao, vo: don't call mp_input_wakeup() directly Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
2016-09-16 12:23:54 +00:00
.wakeup_cb = mp_wakeup_core_cb,
.wakeup_ctx = mpctx,
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
};
mpctx->video_out = init_best_video_out(mpctx->global, &ex);
if (!mpctx->video_out)
goto err;
mpctx->mouse_cursor_visible = true;
}
player: some more --force-window fixes Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
2015-09-21 19:22:20 +00:00
if (!mpctx->video_out->config_ok || force) {
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
struct vo *vo = mpctx->video_out;
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
// Pick whatever works
int config_format = 0;
video: batch query_format calls There are currently 568 pixel formats (actually fewer, but the namespace is this big), and for each format elaborate synchronization was done to call it synchronously on the VO. This is completely unnecessary, and we can do with just a single call.
2015-01-03 16:23:01 +00:00
uint8_t fmts[IMGFMT_END - IMGFMT_START] = {0};
vo_query_formats(vo, fmts);
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
for (int fmt = IMGFMT_START; fmt < IMGFMT_END; fmt++) {
video: batch query_format calls There are currently 568 pixel formats (actually fewer, but the namespace is this big), and for each format elaborate synchronization was done to call it synchronously on the VO. This is completely unnecessary, and we can do with just a single call.
2015-01-03 16:23:01 +00:00
if (fmts[fmt - IMGFMT_START]) {
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
config_format = fmt;
break;
}
}
playloop: use a 16:9 ratio with --force-window ca2b05c0fb changed the window size with --force-window and no video tracks to be closer to 16:9, but I don't see why we shouldn't have an actual 16:9 ratio. The advantage is that subtitles with fullscreen and no video tracks will have the same size and position (depending on the values of --sub-scale-with-window and --sub-use-margins) as with 16:9 videos, because there will be no (invisible) black bars.
2023-11-29 08:05:18 +00:00
// Use a 16:9 aspect ratio so that fullscreen on a 16:9 screen will not
// have vertical margins, which can lead to a different size or position
// of subtitles than with 16:9 videos.
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 w = 960;
playloop: use a 16:9 ratio with --force-window ca2b05c0fb changed the window size with --force-window and no video tracks to be closer to 16:9, but I don't see why we shouldn't have an actual 16:9 ratio. The advantage is that subtitles with fullscreen and no video tracks will have the same size and position (depending on the values of --sub-scale-with-window and --sub-use-margins) as with 16:9 videos, because there will be no (invisible) black bars.
2023-11-29 08:05:18 +00:00
int h = 540;
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 mp_image_params p = {
.imgfmt = config_format,
.w = w, .h = h,
video: switch from using display aspect to sample aspect MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
2015-12-19 19:04:31 +00:00
.p_w = 1, .p_h = 1,
mp_image: add force_window field It's useful for some VOs (dmabuf-wayland) to know if the image params are actually real or fake ones sent by the core for the purpose of force_window.
2023-09-20 18:18:26 +00:00
.force_window = 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
};
video/out: remove an unused parameter This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
2015-10-03 16:20:16 +00:00
if (vo_reconfig(vo, &p) < 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
goto err;
player/video: add VOCTRL_CONTENT_TYPE mpv's core already keeps track of whether or not it thinks a track is an image. Some VOs (i.e. wayland) would benefit from knowing if what is currently being displayed is an image or not so add a new VOCTRL that signals this anytime we load a new file with a VO. Additionally, let's add a helper enum for signaling the kind of content that is being displayed. There is now MP_CONTENT_NONE (strictly for force window being used on a track with no image/video), MP_CONTENT_IMAGE, and MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with wayland).
2022-11-15 21:50:38 +00:00
struct track *track = mpctx->current_track[0][STREAM_VIDEO];
update_content_type(mpctx, track);
player: consistently initialize screensaver state with --force-window Whether this is a good or a bad thing, make sure it's consistent.
2016-10-26 18:35:12 +00:00
update_screensaver_state(mpctx);
player: reset some VO state when video is terminated Useful for idle mode or if video is switched off during playback, and --force-window is used.
2014-09-08 22:54:34 +00:00
vo_set_paused(vo, true);
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
vo_redraw(vo);
client API: add events for video and audio reconfig
2014-02-17 01:52:26 +00:00
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
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 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 0;
err:
mpctx->opts->force_vo = 0;
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_notify_change_opt_ptr(mpctx->mconfig, &mpctx->opts->force_vo);
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
uninit_video_out(mpctx);
MP_FATAL(mpctx, "Error opening/initializing the VO window.\n");
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: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
// Potentially needed by some Lua scripts, which assume TICK always comes.
static void handle_dummy_ticks(struct MPContext *mpctx)
{
player: send MPV_EVENT_TICK during init for the sake of the osc The OSC's (osc.lua) event handling is fundamentally broken. It waits for MPV_EVENT_TICK to update the UI, and MPV_EVENT_TICK has become entirely meaningless, except as a hack for the OSC. There are many situations where the OSC doesn't properly update because the TICK event it expects isn't sent. Fix one of them: it doesn't update the cache state if the VO window is forced and --demuxer-cache-wait is used. Make it so that the tick event is sent even if playback initialization is taking time. This is still slightly broken, because it works only if the mainloop is actually run, which depends on random circumstances (such as moving the mouse over the VO window). The next commit will add another such circumstance which will make it appear to work, although it's still conceptually broken. If we "fixed" it and strictly woke up the player if the idle timer ran out, we'd send tick events all the time, even if nothing is going on, which we don't want. Fucking shitshow.
2019-05-17 19:53:55 +00:00
if ((mpctx->video_status != STATUS_PLAYING &&
mpctx->video_status != STATUS_DRAINING) ||
mpctx->paused)
{
player: increase tick event update frequency 500ms is a bit too high. Change it to 50ms. This improves client API (and Lua) playback state update frequency. Updating absolutely every time the audio PTS changes would be possible, but is not helpful. Audio samplerates are high to trigger a wakeup feedback loop, so the process would waste CPU time on updating the playback position all the time. (If a client application wants to ensure smooth update of the playback position, it should update the position manually using a timer and by reading the property - the application can make a much better decision at how often the playback has to happen.)
2015-06-23 17:21:20 +00:00
if (mp_time_sec() - mpctx->last_idle_tick > 0.050) {
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
mpctx->last_idle_tick = mp_time_sec();
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
}
}
}
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
// Update current playback time.
static void handle_playback_time(struct MPContext *mpctx)
{
demux, player: fix playback of sparse video streams (w/ still images) Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
2018-05-03 02:29:11 +00:00
if (mpctx->vo_chain &&
!mpctx->vo_chain->is_sparse &&
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
mpctx->video_status >= STATUS_PLAYING &&
mpctx->video_status < STATUS_EOF)
{
mpctx->playback_pts = mpctx->video_pts;
} else if (mpctx->audio_status >= STATUS_PLAYING &&
mpctx->audio_status < STATUS_EOF)
{
mpctx->playback_pts = playing_audio_pts(mpctx);
player: set playback_pts in hr-seek past EOF case Hr-seek past the last frame instantly enters EOF, which means handle_playback_time() will not set playback_pts to the video PTS (as all video frames are skipped), which leads to the playback time being taken from the last seek target. This results in confusing behavior, especially since the seek time will be clipped to the file duration for display, but not for further relative seeks. Obviously, the time should be set to the last video frame, so use the last video frame as fallback if both audio and video have ended. Also, since the same problem exists with audio-only playback, add a fallback for audio PTS too. We don't know which was the "last" fragment of media played (to decide whether to use the audio or video PTS as the fallback), but it doesn't matter since the maximum works. This could lead to some undesired effects. In particular the audio PTS is basically a bad guess, and is for example not clipped against --end. (But the ridiculous way audio syncing and clamping currently works, I'm not going to touch that shit unless I rewrite it completely.) The cover art case is slightly broken: using --keep-open with keyframe seeks will result in 0 as playback PTS (the video PTS). OK, who cares, it got late. Also casually get rid of last_vo_pts, since that barely made any sense at all. Fixes: #7487
2020-02-28 00:37:41 +00:00
} else if (mpctx->video_status == STATUS_EOF &&
mpctx->audio_status == STATUS_EOF)
{
player: use audio pts corresponding to playing audio on EOF We should account for ao queue when setting playback position on EOF, previously we were using the pts value corresponding to the start of the ao queue, rather than the currently playing audio. This fixes time-remaining being a negative number when mpv seeks to EOF while playback is paused.
2023-08-25 21:45:14 +00:00
double apts = playing_audio_pts(mpctx);
player: set playback_pts in hr-seek past EOF case Hr-seek past the last frame instantly enters EOF, which means handle_playback_time() will not set playback_pts to the video PTS (as all video frames are skipped), which leads to the playback time being taken from the last seek target. This results in confusing behavior, especially since the seek time will be clipped to the file duration for display, but not for further relative seeks. Obviously, the time should be set to the last video frame, so use the last video frame as fallback if both audio and video have ended. Also, since the same problem exists with audio-only playback, add a fallback for audio PTS too. We don't know which was the "last" fragment of media played (to decide whether to use the audio or video PTS as the fallback), but it doesn't matter since the maximum works. This could lead to some undesired effects. In particular the audio PTS is basically a bad guess, and is for example not clipped against --end. (But the ridiculous way audio syncing and clamping currently works, I'm not going to touch that shit unless I rewrite it completely.) The cover art case is slightly broken: using --keep-open with keyframe seeks will result in 0 as playback PTS (the video PTS). OK, who cares, it got late. Also casually get rid of last_vo_pts, since that barely made any sense at all. Fixes: #7487
2020-02-28 00:37:41 +00:00
double vpts = mpctx->video_pts;
double mpts = MP_PTS_MAX(apts, vpts);
if (mpts != MP_NOPTS_VALUE)
mpctx->playback_pts = mpts;
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
}
}
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
// We always make sure audio and video buffers are filled before actually
// starting playback. This code handles starting them at the same time.
player: minor simplification No need to pass endpts down in such a dumb way. Also remove an outdated comment somewhere.
2016-02-27 19:02:51 +00:00
static void handle_playback_restart(struct MPContext *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
{
struct MPOpts *opts = mpctx->opts;
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
if (mpctx->audio_status < STATUS_READY ||
mpctx->video_status < STATUS_READY)
return;
playloop: update cache properties in idle state This will properly notify observed properties if the player hasn't started actual playback yet, such as with --demuxer-cache-wait. This also happens to cause the main loop more often, which triggers MPV_EVENT_IDLE, and fixes the OSC display. (See previous commit message.)
2019-05-17 19:59:52 +00:00
handle_update_cache(mpctx);
player: add --cache-pause-initial option to start in buffering state Reasons why you'd want this see manpage additions. Disabled by default, because it would increase latency of live streams by default. (Or well, at least it would be another problem when trying getting lower latency.)
2018-01-03 20:48:42 +00:00
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
if (mpctx->video_status == STATUS_READY) {
mpctx->video_status = STATUS_PLAYING;
get_relative_time(mpctx);
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_wakeup_core(mpctx);
player: dumb seeking related stuff, make audio hr-seek default Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
MP_DBG(mpctx, "starting video playback\n");
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
}
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
if (mpctx->audio_status == STATUS_READY) {
// If a new seek is queued while the current one finishes, don't
// actually play the audio, but resume seeking immediately.
if (mpctx->seek.type && mpctx->video_status == STATUS_PLAYING) {
handle_playback_time(mpctx);
player: make repeated hr-seeks past EOF trigger EOF as expected If you have a normal file with audio and video, and keep "spamming" forward hr-seeks, the player just kept showing the last video frame instead of exiting or playing the next file. This started happening since commit 6bcda94cb. Although not a bug per se, it was odd, and very user-noticable. The main problem was that the pending seek command was processed before the EOF was "noticed". Processing the command reset everything, so the player did not terminate playback, but repeated the seek. This commit restores the old behavior. For one, it makes video return the correct status (video.c). The parameter is a bit ugly, but better than duplicating the logic or having another MPContext field. (As a minor detail, setting r=VD_EOF makes sure have_new_frame() returns true, rather than going through another iteration or whatever the hell will happen instead, which would clobber logical_eof.) Another thing is making the seek logic actually wait until the seek outcome has been determined if audio is also active. Audio needs to wait for video in order to get the video seek target position. (Which in turn is because hr-seek still "snaps" to video frames. You can't seek in between two frames, so audio can't just use the seek target, but always has to wait on the timestamp of the video frame. This has other disadvantages and is a misdesign, but not something I'll fix today.) In theory, this might make hr-seeks less responsive, because it needs to fully decode/filter the audio too, but in practice most time is spent on video, which had to be fully decoded before this change. (In general, hr-seek could probably just show a random frame when a queued hr-seek overrides the current hr-seek, which would probably lead to a better user experience, but that's out of scope.) Fixes: #7206
2019-12-14 13:17:16 +00:00
mpctx->seek.flags &= ~MPSEEK_FLAG_DELAY; // immediately
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
execute_queued_seek(mpctx);
return;
}
audio: refactor how data is passed to AO This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
2020-08-28 18:23:54 +00:00
audio_start_ao(mpctx);
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
}
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
if (!mpctx->restart_complete) {
mpctx->hrseek_active = false;
mpctx->restart_complete = true;
player: make refresh seeks slightly more robust Refresh seeks are automatically issued when changing filters, which improves user experience if these filters change buffering or such. The refresh seek could actually overwrite a previously ongoing seek: set pause yes set time-pos 10 set vf "" Here, the video code issued a refresh seek to the previous video position, which could be different from the previously triggered (and still ongoing) seek, this overwriting the seek. Factor all refresh seek handling into a new function, and make it handle ongoing seeks correctly. Remove the weird new canonical_pts field, which actually had no use. Fixes #4757.
2017-08-14 12:02:13 +00:00
mpctx->current_seek = (struct seek_params){0};
player: make looping slightly more seamless This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
2016-08-18 18:40:23 +00:00
handle_playback_time(mpctx);
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
mp_notify(mpctx, MPV_EVENT_PLAYBACK_RESTART, NULL);
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
update_core_idle_state(mpctx);
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
if (!mpctx->playing_msg_shown) {
player: allow unsetting --term/osd-playing-msg Treat an empty string as unset. The fact that the option values can be NULL is merely weirdness due to how the option parser works (it unfortunately doesn't initialize string fields to non-NULL).
2015-02-18 20:10:08 +00:00
if (opts->playing_msg && opts->playing_msg[0]) {
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
char *msg =
mp_property_expand_escaped_string(mpctx, opts->playing_msg);
player: put --term-playing-msg in a separate log category Fixes #1983.
2015-07-13 11:06:09 +00:00
struct mp_log *log = mp_log_new(NULL, mpctx->log, "!term-msg");
mp_info(log, "%s\n", msg);
talloc_free(log);
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
talloc_free(msg);
}
player: allow unsetting --term/osd-playing-msg Treat an empty string as unset. The fact that the option values can be NULL is merely weirdness due to how the option parser works (it unfortunately doesn't initialize string fields to non-NULL).
2015-02-18 20:10:08 +00:00
if (opts->osd_playing_msg && opts->osd_playing_msg[0]) {
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
char *msg =
mp_property_expand_escaped_string(mpctx, opts->osd_playing_msg);
options: add osd-playing-msg-duration
2022-04-07 22:00:00 +00:00
set_osd_msg(mpctx, 1, opts->osd_playing_msg_duration ?
opts->osd_playing_msg_duration : opts->osd_duration,
"%s", msg);
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
talloc_free(msg);
}
}
mpctx->playing_msg_shown = true;
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_wakeup_core(mpctx);
player: modify/simplify AB-loop behavior This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
2019-05-26 23:24:22 +00:00
update_ab_loop_clip(mpctx);
player: add pause state to playback start message Now the player tells you that audio or video are playing while paused, or something.
2020-09-21 17:36:25 +00:00
MP_VERBOSE(mpctx, "playback restart complete @ %f, audio=%s, video=%s%s\n",
player: fix swapped debug output Such failure.
2020-08-27 09:34:53 +00:00
mpctx->playback_pts, mp_status_str(mpctx->audio_status),
player: add pause state to playback start message Now the player tells you that audio or video are playing while paused, or something.
2020-09-21 17:36:25 +00:00
mp_status_str(mpctx->video_status),
get_internal_paused(mpctx) ? " (paused)" : "");
player: attempt to fix playback end on hr-seeking past EOF again This tries to fix #7206 (hr-seeking past EOF does not stop playback) again. Commit 57fbc9cd76f7 should have fixed this, but trying it again (using that git revision), it often did not work. Whatever the fuck. So add another dumb special case that will break within weeks. Note that the check in handle_eof() had no effect, since execute_queued_seek() is called later, which cancels EOF in the same case.
2020-02-28 14:41:45 +00:00
player: clamp relative seek base time to nominal duration Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
2020-09-10 21:24:35 +00:00
// To avoid strange effects when using relative seeks, especially if
// there are no proper audio & video timestamps (seeks after EOF).
double length = get_time_length(mpctx);
if (mpctx->last_seek_pts != MP_NOPTS_VALUE && length >= 0)
mpctx->last_seek_pts = MPCLAMP(mpctx->last_seek_pts, 0, length);
player: attempt to fix playback end on hr-seeking past EOF again This tries to fix #7206 (hr-seeking past EOF does not stop playback) again. Commit 57fbc9cd76f7 should have fixed this, but trying it again (using that git revision), it often did not work. Whatever the fuck. So add another dumb special case that will break within weeks. Note that the check in handle_eof() had no effect, since execute_queued_seek() is called later, which cancels EOF in the same case.
2020-02-28 14:41:45 +00:00
// Continuous seeks past EOF => treat as EOF instead of repeating seek.
if (mpctx->seek.type == MPSEEK_RELATIVE && mpctx->seek.amount > 0 &&
mpctx->video_status == STATUS_EOF &&
mpctx->audio_status == STATUS_EOF)
mpctx->seek = (struct seek_params){0};
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
}
}
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
static void handle_eof(struct MPContext *mpctx)
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
{
player: make unpausing directly after seek work with --keep-open (again) Commit fcf0b80dc9dd3 fixed this the first time. Commit 85576f31a9cc2 "accidentally" removed this code again. The commit message justifying the removal is correct, except it doesn't take other side-effects of the state machine into account. I obviously didn't remember what exactly this was about. So add a comment explaining it this time. Just apply it again; the thing the latter commit fixed still works. Fixes: #7819
2020-06-10 09:43:19 +00:00
if (mpctx->seek.type)
return; // for proper keep-open operation
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
/* Don't quit while paused and we're displaying the last video frame. On the
* other hand, if we don't have a video frame, then the user probably seeked
* outside of the video, and we do want to quit. */
bool prevent_eof =
playloop: don't loop when seeking to the end of cover art while paused Fix the bug that seeking to the end of cover art while paused goes back to the beginning of the file because of this condition meant for videos. This doesn't check mpctx->vo_chain->is_sparse because prevent_eof should be true with actual sparse videos.
2024-05-25 21:26:50 +00:00
mpctx->paused && mpctx->video_out && vo_has_frame(mpctx->video_out) &&
!mpctx->vo_chain->is_coverart;
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
/* It's possible for the user to simultaneously switch both audio
* and video streams to "disabled" at runtime. Handle this by waiting
* rather than immediately stopping playback due to EOF.
*/
player: refactor: eliminate MPContext.d_audio
2016-01-21 21:24:20 +00:00
if ((mpctx->ao_chain || mpctx->vo_chain) && !prevent_eof &&
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
mpctx->audio_status == STATUS_EOF &&
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
mpctx->video_status == STATUS_EOF &&
!mpctx->stop_play)
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
{
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
mpctx->stop_play = AT_END_OF_FILE;
player: move more code out of central playloop function ...into its own functions. The central playloop function is still too big, but looks much cleaner now. No changes in functionality. The code moved to handle_playback_restart() is unindented by 1 level and moving it out of the if condition around. The if condition is inverted and early-exits from the function. Also some comments are changed.
2015-01-29 11:37:10 +00:00
}
}
void run_playloop(struct MPContext *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
if (encode_lavc_didfail(mpctx->encode_lavc_ctx)) {
encode: propagate errors to exit status properly Don't just let mpv CLI return 0 (success) as exit status if encoding failed somehow.
2020-09-03 13:44:35 +00:00
mpctx->stop_play = PT_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
return;
}
demux: add a demuxer thread This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
2014-07-16 20:40:21 +00:00
update_demuxer_properties(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
player: move video display code out of the playloop Basically move the code from playloop.c to video.c. The new function write_video() now contains the code that was part of run_playloop(). There are no functional changes, except handling "new_frame_shown" slightly differently. This is done so that we don't need new a new MPContext field or a return value for write_video() to signal this condition. Instead, it's handled indirectly.
2014-07-30 21:24:08 +00:00
handle_cursor_autohide(mpctx);
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 19:26:51 +00:00
handle_vo_events(mpctx);
player: fix audio-device-list updates The way the AO wakes up the playloop has nothing to do with events; instead we must query the events on the AO once the playloop was woken up. Querying the events in every playloop iteration is thus the correct way to do this.
2015-02-14 14:13:58 +00:00
handle_command_updates(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
player: replace old lavfi wrapper with new filter code lavfi.c is not necessary anymore, because f_lavfi.c (which was actually converted from it) can be used now.
2018-01-26 03:36:47 +00:00
if (mpctx->lavfi && mp_filter_has_failed(mpctx->lavfi))
mpctx->stop_play = AT_END_OF_FILE;
player: add complex filter graph support See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
2016-02-05 22:19:56 +00:00
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
fill_audio_out_buffers(mpctx);
write_video(mpctx);
player: minor simplification No need to pass endpts down in such a dumb way. Also remove an outdated comment somewhere.
2016-02-27 19:02:51 +00:00
handle_playback_restart(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
player: restore usual seeking behavior Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
2016-05-09 20:54:49 +00:00
handle_playback_time(mpctx);
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
handle_dummy_ticks(mpctx);
audio: change playback restart and resyncing This commit makes audio decoding non-blocking. If e.g. the network is too slow the playloop will just go to sleep, instead of blocking until enough data is available. For video, this was already done with commit 7083f88c. For audio, it's unfortunately much more complicated, because the audio decoder was used in a blocking manner. Large changes are required to get around this. The whole playback restart mechanism must be turned into a statemachine, especially since it has close interactions with video restart. Lots of video code is thus also changed. (For the record, I don't think switching this code to threads would make this conceptually easier: the code would still have to deal with external input while blocked, so these in-between states do get visible [and thus need to be handled] anyway. On the other hand, it certainly should be possible to modularize this code a bit better.) This will probably cause a bunch of regressions.
2014-07-28 18:40:43 +00:00
update_osd_msg(mpctx);
player: avoid busy looping during reinit_sub If the player is paused, switching subtitle track requires us to read subs packets for an indefinite amount of time in order to actually display the subtitles. The problem with this is that it puts a blocking loop in the play thread which can be slow in cases where it takes a long time to fetch the subtitle (e.g. over a network). 9e27b1f523071db184443d78f7144cb599dd0829 alleviates this when a pause happens because of buffering, but it's not complete. One could encounter this if the user pauses the video first manually and then switches the subtitle track. To solve this better, make it so the loop has a time out (totally arbitrary number) so the player isn't blocked forever. If subtitles are not fetched within that time, we flag the track and try again later in the playloop.
2024-04-14 21:37:32 +00:00
handle_update_subtitles(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
player: make screenshot each-frame mode more accurate Due to asynchronicity, we generally can't guarantee that a video frame matches up with other events such as playback time change exactly (since decoding, presentation, and property update all happen at different times). This is a complaint in the referenced bug report, where screenshot filenames in each-frame screenshot did not use the correct timestamp, and instead was lagging behind by 1 frame. But in this case, synchronicity was already pretty much forced with wait calls. The only problem was that the playback time was updated at a later time, which results in the observed 1 frame lag. Fix this by moving the place where the screenshot is triggered in this mode. Normal screenshots may still have the old problem. There is no effort made to guarantee the timestamps absolutely line up, same as with the OSD. (If you want a guarantee, you need to use a video filter, such as libavfilter's drawtext. These will obviously use the proper timestamp, instead of going through the somewhat asynchronous property etc. system in the player frontend.) Fixes: #7433
2020-02-07 12:32:07 +00:00
handle_each_frame_screenshot(mpctx);
player: remove old timeline/ordered chapters support
2016-02-15 20:03:51 +00:00
handle_eof(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
player: --loop-file takes precedence before --keep-open
2014-09-23 23:31:45 +00:00
handle_loop_file(mpctx);
player: fix time display wheen seeking past EOF with --keep-open Regression since commit 261506e3. Internally speaking, playback was often not properly terminated, and the main part of handle_keep_open() was just executed once, instead of any time the user tries to seek. This means playback_pts was not set, and the "current time" was determined by the seek target PTS. So fix this aspect of video EOF handling, and also remove the now unnecessary eof_reached field. The pause check before calling pause_player() is a lazy workaround for a strange event feedback loop that happens on EOF with --keep-open.
2014-07-29 22:22:25 +00:00
handle_keep_open(mpctx);
player: some further playloop cleanups Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
2014-08-03 18:25:03 +00:00
handle_sstep(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
player: fix core-idle and eof-reached update notifcations Make mpv_observe_property() work correctly on them even with --keep-open-pause=no. This also changes the situations in which the screensaver is enabled/disabled subtly.
2017-04-14 16:56:03 +00:00
update_core_idle_state(mpctx);
player: move point at which queued seeks are applied Do it after decoding etc., but before waiting for input. This seems to make more sense, because whether a queued seek can be applied depends on the playback state. So it sounds like a good idea to apply the seek first thing, but it's a bad idea to go to sleep if there's still a queued seek pending (that couldn't be processed earlier). Also add an empty line before mp_wait_events(); it doesn't really have to do with the filter bullshit.
2019-12-14 13:18:10 +00:00
execute_queued_seek(mpctx);
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
if (mpctx->stop_play)
player: make quit exit immediately Stopping playback canceled waiting, but executed the remainder of the playloop, including things like executing pointless seeks.
2014-08-03 17:14:30 +00:00
return;
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
player: allow redrawing screen during seeks If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
2014-08-03 17:09:22 +00:00
handle_osd_redraw(mpctx);
player: remove the last instances of polling Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
2014-07-18 13:04:46 +00:00
filter: minor cosmetic naming issue Just putting some more lipstick on the pig, maybe it looks a bit nicer now.
2020-03-08 18:37:20 +00:00
if (mp_filter_graph_run(mpctx->filter_root))
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 10:53:44 +00:00
mp_wakeup_core(mpctx);
player: move point at which queued seeks are applied Do it after decoding etc., but before waiting for input. This seems to make more sense, because whether a queued seek can be applied depends on the playback state. So it sounds like a good idea to apply the seek first thing, but it's a bad idea to go to sleep if there's still a queued seek pending (that couldn't be processed earlier). Also add an empty line before mp_wait_events(); it doesn't really have to do with the filter bullshit.
2019-12-14 13:18:10 +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
mp_wait_events(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
playloop: update cache properties in idle state This will properly notify observed properties if the player hasn't started actual playback yet, such as with --demuxer-cache-wait. This also happens to cause the main loop more often, which triggers MPV_EVENT_IDLE, and fixes the OSC display. (See previous commit message.)
2019-05-17 19:59:52 +00:00
handle_update_cache(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
player: minor refactoring Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
2014-09-06 14:57:46 +00:00
mp_process_input(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
client API: add chapter change event Also works for mpv_observe_property() on the "chapter" property.
2014-04-27 20:28:07 +00:00
handle_chapter_change(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
handle_force_window(mpctx, false);
}
player: open stream and demuxer asynchronously Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
2014-10-06 19:20:38 +00:00
void mp_idle(struct MPContext *mpctx)
{
handle_dummy_ticks(mpctx);
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
mp_wait_events(mpctx);
player: open stream and demuxer asynchronously Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
2014-10-06 19:20:38 +00:00
mp_process_input(mpctx);
player: handle hotplug events in idle mode too
2015-05-02 15:53:25 +00:00
handle_command_updates(mpctx);
playloop: update cache properties in idle state This will properly notify observed properties if the player hasn't started actual playback yet, such as with --demuxer-cache-wait. This also happens to cause the main loop more often, which triggers MPV_EVENT_IDLE, and fixes the OSC display. (See previous commit message.)
2019-05-17 19:59:52 +00:00
handle_update_cache(mpctx);
player: don't mess up cursor visibility state Manually setting can break things forever, because it puts the VO cursor state out of sync with the remembered state by handle_cursor_autohide(). Use the normal autohide code during idle mode too instead. (Originally the idea was to make the cursor always visible in idle mode, but not so important.) Regression since e1e8b07c. Fixes #1166. CC: @mpv-player/stable
2014-10-10 16:51:44 +00:00
handle_cursor_autohide(mpctx);
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 19:26:51 +00:00
handle_vo_events(mpctx);
player: open stream and demuxer asynchronously Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
2014-10-06 19:20:38 +00:00
update_osd_msg(mpctx);
handle_osd_redraw(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
// Waiting for the slave master to send us a new file to play.
void idle_loop(struct MPContext *mpctx)
{
// ================= idle loop (STOP state) =========================
bool need_reinit = true;
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
while (mpctx->opts->player_idle_mode && mpctx->stop_play == PT_STOP) {
client API: don't send MPV_EVENT_IDLE when not entering idle mode For simplicity, this was sent before actually checking the idle condition, which meant that we'd send it even of the idle loop is never entered.
2014-02-26 19:45:24 +00:00
if (need_reinit) {
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);
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
handle_force_window(mpctx, true);
player: litter code with explicit wakeup calls This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
2016-09-16 12:24:15 +00:00
mp_wakeup_core(mpctx);
player: deliver IDLE event after uninitializing state A client API user might count on the fact that audio and video outputs have already been uninitialized. (They remain uninitialized before entering idle mode in order to allow smooth transition to the next playlist entry.) Since event delivery is asynchronous, this has to happen after actually doing the uninitialization, or the client will essentially run into a race condition.
2015-08-20 13:25:32 +00:00
mp_notify(mpctx, MPV_EVENT_IDLE, NULL);
player: fix idle mode event handling Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing, until the next event happened. This was because it directly went to sleep after processing commands. What we should do instead is rechecking all state after processing commands, redraw OSD, and then go to sleep. This also fixes some strange OSD-related behavior. Also move some other code around to separate idle mode initialization from the normal run loop.
2014-09-12 23:13:36 +00:00
need_reinit = false;
client API: don't send MPV_EVENT_IDLE when not entering idle mode For simplicity, this was sent before actually checking the idle condition, which meant that we'd send it even of the idle loop is never entered.
2014-02-26 19:45:24 +00:00
}
player: open stream and demuxer asynchronously Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
2014-10-06 19:20:38 +00:00
mp_idle(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
}
}