2013-10-29 21:38:29 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2013-10-29 21:38:29 +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
|
|
|
* 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.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
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
|
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
|
|
|
* GNU Lesser General Public License for more details.
|
2013-10-29 21:38:29 +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
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2013-10-29 21:38:29 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdbool.h>
|
2017-01-21 16:19:01 +00:00
|
|
|
#include <errno.h>
|
2013-10-29 21:38:29 +00:00
|
|
|
#include <assert.h>
|
|
|
|
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
#include "osdep/io.h"
|
|
|
|
#include "osdep/timer.h"
|
2014-10-19 21:32:34 +00:00
|
|
|
#include "osdep/threads.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/options.h"
|
|
|
|
#include "options/m_property.h"
|
2014-10-06 19:20:38 +00:00
|
|
|
#include "options/m_config.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
2014-10-06 19:20:38 +00:00
|
|
|
#include "common/global.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/encode.h"
|
|
|
|
#include "common/playlist.h"
|
2013-12-17 00:23:09 +00:00
|
|
|
#include "input/input.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-11-09 23:49:13 +00:00
|
|
|
#include "audio/out/ao.h"
|
2013-11-23 21:08:42 +00:00
|
|
|
#include "demux/demux.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "stream/stream.h"
|
|
|
|
#include "video/out/vo.h"
|
|
|
|
|
2013-12-17 00:08:53 +00:00
|
|
|
#include "core.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "command.h"
|
|
|
|
|
2020-04-15 15:03:37 +00:00
|
|
|
const int num_ptracks[STREAM_TYPE_COUNT] = {
|
|
|
|
[STREAM_VIDEO] = 1,
|
|
|
|
[STREAM_AUDIO] = 1,
|
|
|
|
[STREAM_SUB] = 2,
|
|
|
|
};
|
|
|
|
|
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 rel_time_to_abs(struct MPContext *mpctx, struct m_rel_time t)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
double length = get_time_length(mpctx);
|
2019-05-25 23:56:48 +00:00
|
|
|
// Relative times are an offset to the start of the file.
|
|
|
|
double start = 0;
|
|
|
|
if (mpctx->demuxer && !mpctx->opts->rebase_start_time)
|
|
|
|
start = mpctx->demuxer->start_time;
|
|
|
|
|
2013-10-29 21:38:29 +00:00
|
|
|
switch (t.type) {
|
|
|
|
case REL_TIME_ABSOLUTE:
|
|
|
|
return t.pos;
|
2014-06-29 17:44:32 +00:00
|
|
|
case REL_TIME_RELATIVE:
|
|
|
|
if (t.pos >= 0) {
|
2019-05-25 23:56:48 +00:00
|
|
|
return start + t.pos;
|
2014-06-29 17:44:32 +00:00
|
|
|
} else {
|
2014-10-29 20:54:59 +00:00
|
|
|
if (length >= 0)
|
2019-05-25 23:56:48 +00:00
|
|
|
return start + MPMAX(length + t.pos, 0.0);
|
2014-06-29 17:44:32 +00:00
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
break;
|
|
|
|
case REL_TIME_PERCENT:
|
2014-10-29 20:54:59 +00:00
|
|
|
if (length >= 0)
|
2019-05-25 23:56:48 +00:00
|
|
|
return start + length * (t.pos / 100.0);
|
2013-10-29 21:38:29 +00:00
|
|
|
break;
|
|
|
|
case REL_TIME_CHAPTER:
|
2019-05-25 23:56:48 +00:00
|
|
|
return chapter_start_time(mpctx, t.pos); // already absolute time
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2019-05-25 23:56:48 +00:00
|
|
|
|
2014-03-25 01:32:24 +00:00
|
|
|
return MP_NOPTS_VALUE;
|
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
|
|
|
static double get_play_end_pts_setting(struct MPContext *mpctx)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2019-05-25 23:24:29 +00:00
|
|
|
double end = rel_time_to_abs(mpctx, opts->play_end);
|
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 length = rel_time_to_abs(mpctx, opts->play_length);
|
|
|
|
if (length != MP_NOPTS_VALUE) {
|
2017-12-04 01:26:42 +00:00
|
|
|
double start = get_play_start_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 (end == MP_NOPTS_VALUE || start + length < end)
|
2014-09-25 18:42:59 +00:00
|
|
|
end = start + length;
|
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
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return absolute timestamp against which currently playing media should be
|
|
|
|
// clipped. Returns MP_NOPTS_VALUE if no clipping should happen.
|
|
|
|
double get_play_end_pts(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
double end = get_play_end_pts_setting(mpctx);
|
|
|
|
double ab[2];
|
|
|
|
if (mpctx->ab_loop_clip && get_ab_loop_times(mpctx, ab)) {
|
|
|
|
if (end == MP_NOPTS_VALUE || end > ab[1])
|
|
|
|
end = ab[1];
|
2016-08-18 18:40:23 +00:00
|
|
|
}
|
2014-09-25 18:42:59 +00:00
|
|
|
return end;
|
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
|
|
|
// Get the absolute PTS at which playback should start.
|
|
|
|
// Never returns MP_NOPTS_VALUE.
|
2017-12-04 01:26:42 +00:00
|
|
|
double get_play_start_pts(struct MPContext *mpctx)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
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 res = rel_time_to_abs(mpctx, opts->play_start);
|
2019-05-26 23:46:34 +00:00
|
|
|
if (res == MP_NOPTS_VALUE)
|
|
|
|
res = get_start_time(mpctx, mpctx->play_dir);
|
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
|
|
|
return res;
|
2017-12-04 01:26:42 +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
|
|
|
// Get timestamps to use for AB-loop. Returns false iff any of the timestamps
|
|
|
|
// are invalid and/or AB-loops are currently disabled, and set t[] to either
|
|
|
|
// the user options or NOPTS on best effort basis.
|
|
|
|
bool get_ab_loop_times(struct MPContext *mpctx, double t[2])
|
2017-12-04 03:19:16 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
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
|
|
|
int dir = mpctx->play_dir;
|
|
|
|
|
|
|
|
t[0] = opts->ab_loop[0];
|
|
|
|
t[1] = opts->ab_loop[1];
|
|
|
|
|
2020-02-08 13:57:45 +00:00
|
|
|
if (!opts->ab_loop_count)
|
|
|
|
return false;
|
|
|
|
|
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 (t[0] == MP_NOPTS_VALUE || t[1] == MP_NOPTS_VALUE || t[0] == t[1])
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (t[0] * dir > t[1] * dir)
|
|
|
|
MPSWAP(double, t[0], t[1]);
|
|
|
|
|
|
|
|
return true;
|
2017-12-04 03:19:16 +00:00
|
|
|
}
|
|
|
|
|
2016-08-04 09:26:57 +00:00
|
|
|
double get_track_seek_offset(struct MPContext *mpctx, struct track *track)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
if (track->selected) {
|
|
|
|
if (track->type == STREAM_AUDIO)
|
|
|
|
return -opts->audio_delay;
|
|
|
|
if (track->type == STREAM_SUB)
|
2023-11-23 03:13:57 +00:00
|
|
|
{
|
|
|
|
for (int n = 0; n < num_ptracks[STREAM_SUB]; n++) {
|
|
|
|
if (mpctx->current_track[n][STREAM_SUB] == track)
|
2023-12-13 21:36:58 +00:00
|
|
|
return -opts->subs_shared->sub_delay[n];
|
2023-11-23 03:13:57 +00:00
|
|
|
}
|
|
|
|
}
|
2016-08-04 09:26:57 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-14 12:02:13 +00:00
|
|
|
void issue_refresh_seek(struct MPContext *mpctx, enum seek_precision min_prec)
|
|
|
|
{
|
|
|
|
// let queued seeks execute at a slightly later point
|
|
|
|
if (mpctx->seek.type) {
|
|
|
|
mp_wakeup_core(mpctx);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// repeat currently ongoing seeks
|
|
|
|
if (mpctx->current_seek.type) {
|
|
|
|
mpctx->seek = mpctx->current_seek;
|
|
|
|
mp_wakeup_core(mpctx);
|
|
|
|
return;
|
|
|
|
}
|
2018-05-17 11:16:26 +00:00
|
|
|
queue_seek(mpctx, MPSEEK_ABSOLUTE, get_current_time(mpctx), min_prec, 0);
|
2017-08-14 12:02:13 +00:00
|
|
|
}
|
|
|
|
|
2022-11-15 21:50:38 +00:00
|
|
|
void update_content_type(struct MPContext *mpctx, struct track *track)
|
|
|
|
{
|
|
|
|
enum mp_content_type content_type;
|
|
|
|
if (!track || !track->vo_c) {
|
|
|
|
content_type = MP_CONTENT_NONE;
|
|
|
|
} else if (track->image) {
|
|
|
|
content_type = MP_CONTENT_IMAGE;
|
|
|
|
} else {
|
|
|
|
content_type = MP_CONTENT_VIDEO;
|
|
|
|
}
|
|
|
|
if (mpctx->video_out)
|
2023-02-25 04:53:42 +00:00
|
|
|
vo_control(mpctx->video_out, VOCTRL_CONTENT_TYPE, &content_type);
|
2022-11-15 21:50:38 +00:00
|
|
|
}
|
|
|
|
|
2015-11-15 22:03:48 +00:00
|
|
|
void update_vo_playback_state(struct MPContext *mpctx)
|
|
|
|
{
|
2016-09-02 13:01:09 +00:00
|
|
|
if (mpctx->video_out && mpctx->video_out->config_ok) {
|
2015-11-15 22:03:48 +00:00
|
|
|
struct voctrl_playback_state oldstate = mpctx->vo_playback_state;
|
|
|
|
struct voctrl_playback_state newstate = {
|
2016-08-30 21:50:57 +00:00
|
|
|
.taskbar_progress = mpctx->opts->vo->taskbar_progress,
|
2015-11-22 10:40:20 +00:00
|
|
|
.playing = mpctx->playing,
|
2015-11-15 22:03:48 +00:00
|
|
|
.paused = mpctx->paused,
|
|
|
|
.percent_pos = get_percent_pos(mpctx),
|
|
|
|
};
|
|
|
|
|
2016-05-05 05:56:21 +00:00
|
|
|
if (oldstate.taskbar_progress != newstate.taskbar_progress ||
|
|
|
|
oldstate.playing != newstate.playing ||
|
2015-11-22 10:40:20 +00:00
|
|
|
oldstate.paused != newstate.paused ||
|
2016-05-05 05:56:21 +00:00
|
|
|
oldstate.percent_pos != newstate.percent_pos)
|
|
|
|
{
|
|
|
|
// Don't update progress bar if it was and still is hidden
|
|
|
|
if ((oldstate.playing && oldstate.taskbar_progress) ||
|
|
|
|
(newstate.playing && newstate.taskbar_progress))
|
|
|
|
{
|
2016-08-20 12:46:38 +00:00
|
|
|
vo_control_async(mpctx->video_out,
|
|
|
|
VOCTRL_UPDATE_PLAYBACK_STATE, &newstate);
|
2016-05-05 05:56:21 +00:00
|
|
|
}
|
2015-11-15 22:03:48 +00:00
|
|
|
mpctx->vo_playback_state = newstate;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
mpctx->vo_playback_state = (struct voctrl_playback_state){ 0 };
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-09 23:49:13 +00:00
|
|
|
void update_window_title(struct MPContext *mpctx, bool force)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2013-11-09 23:49:13 +00:00
|
|
|
if (!mpctx->video_out && !mpctx->ao) {
|
|
|
|
talloc_free(mpctx->last_window_title);
|
2014-05-11 14:15:42 +00:00
|
|
|
mpctx->last_window_title = NULL;
|
2013-10-29 21:38:29 +00:00
|
|
|
return;
|
2013-11-09 23:49:13 +00:00
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
char *title = mp_property_expand_string(mpctx, mpctx->opts->wintitle);
|
2013-11-09 23:49:13 +00:00
|
|
|
if (!mpctx->last_window_title || force ||
|
|
|
|
strcmp(title, mpctx->last_window_title) != 0)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2013-11-09 23:49:13 +00:00
|
|
|
talloc_free(mpctx->last_window_title);
|
|
|
|
mpctx->last_window_title = talloc_steal(mpctx, title);
|
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
if (mpctx->video_out)
|
2013-11-09 23:49:13 +00:00
|
|
|
vo_control(mpctx->video_out, VOCTRL_UPDATE_WINDOW_TITLE, title);
|
|
|
|
|
|
|
|
if (mpctx->ao) {
|
|
|
|
ao_control(mpctx->ao, AOCONTROL_UPDATE_STREAM_TITLE, title);
|
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
} else {
|
|
|
|
talloc_free(title);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-23 16:31:43 +00:00
|
|
|
void error_on_track(struct MPContext *mpctx, struct track *track)
|
|
|
|
{
|
2016-02-05 20:15:47 +00:00
|
|
|
if (!track || !track->selected)
|
2014-10-23 16:31:43 +00:00
|
|
|
return;
|
|
|
|
mp_deselect_track(mpctx, track);
|
2016-02-05 20:15:47 +00:00
|
|
|
if (track->type == STREAM_AUDIO)
|
|
|
|
MP_INFO(mpctx, "Audio: no audio\n");
|
|
|
|
if (track->type == STREAM_VIDEO)
|
|
|
|
MP_INFO(mpctx, "Video: no video\n");
|
|
|
|
if (mpctx->opts->stop_playback_on_init_failure ||
|
2024-04-16 06:30:14 +00:00
|
|
|
(!mpctx->current_track[0][STREAM_AUDIO] &&
|
|
|
|
!mpctx->current_track[0][STREAM_VIDEO]))
|
2016-02-05 20:15:47 +00:00
|
|
|
{
|
|
|
|
if (!mpctx->stop_play)
|
|
|
|
mpctx->stop_play = PT_ERROR;
|
|
|
|
if (mpctx->error_playing >= 0)
|
|
|
|
mpctx->error_playing = MPV_ERROR_NOTHING_TO_PLAY;
|
2014-10-23 16:31:43 +00:00
|
|
|
}
|
2016-09-16 12:24:15 +00:00
|
|
|
mp_wakeup_core(mpctx);
|
2014-10-23 16:31:43 +00:00
|
|
|
}
|
|
|
|
|
2015-07-02 12:02:32 +00:00
|
|
|
int stream_dump(struct MPContext *mpctx, const char *source_filename)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
stream_t *stream = stream_create(source_filename,
|
|
|
|
STREAM_ORIGIN_DIRECT | STREAM_READ,
|
|
|
|
mpctx->playback_abort, mpctx->global);
|
2015-07-02 12:02:32 +00:00
|
|
|
if (!stream)
|
|
|
|
return -1;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2015-08-17 22:10:54 +00:00
|
|
|
int64_t size = stream_get_size(stream);
|
2014-05-24 12:04:09 +00:00
|
|
|
|
2017-01-21 16:19:01 +00:00
|
|
|
FILE *dest = fopen(opts->stream_dump, "wb");
|
|
|
|
if (!dest) {
|
|
|
|
MP_ERR(mpctx, "Error opening dump file: %s\n", mp_strerror(errno));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ok = true;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2017-01-21 16:19:01 +00:00
|
|
|
while (mpctx->stop_play == KEEP_PLAYING && ok) {
|
2013-10-29 21:38:29 +00:00
|
|
|
if (!opts->quiet && ((stream->pos / (1024 * 1024)) % 2) == 1) {
|
2014-05-24 12:03:07 +00:00
|
|
|
uint64_t pos = stream->pos;
|
player: redo terminal OSD and status line handling
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
2014-01-13 19:05:41 +00:00
|
|
|
MP_MSG(mpctx, MSGL_STATUS, "Dumping %lld/%lld...",
|
2014-05-24 12:04:09 +00:00
|
|
|
(long long int)pos, (long long int)size);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2019-10-26 17:21:37 +00:00
|
|
|
uint8_t buf[4096];
|
|
|
|
int len = stream_read(stream, buf, sizeof(buf));
|
|
|
|
if (!len) {
|
2017-01-21 16:19:01 +00:00
|
|
|
ok &= stream->eof;
|
|
|
|
break;
|
|
|
|
}
|
2019-10-26 17:21:37 +00:00
|
|
|
ok &= fwrite(buf, len, 1, dest) == 1;
|
2016-09-16 12:24:15 +00:00
|
|
|
mp_wakeup_core(mpctx); // don't actually sleep
|
|
|
|
mp_idle(mpctx); // but process input
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2015-07-02 12:02:32 +00:00
|
|
|
|
2017-01-21 16:19:01 +00:00
|
|
|
ok &= fclose(dest) == 0;
|
2015-07-02 12:02:32 +00:00
|
|
|
free_stream(stream);
|
2017-01-21 16:19:01 +00:00
|
|
|
return ok ? 0 : -1;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2013-11-19 21:36:33 +00:00
|
|
|
|
|
|
|
void merge_playlist_files(struct playlist *pl)
|
|
|
|
{
|
2019-12-28 20:12:02 +00:00
|
|
|
if (!pl->num_entries)
|
2013-11-19 21:36:33 +00:00
|
|
|
return;
|
|
|
|
char *edl = talloc_strdup(NULL, "edl://");
|
2019-12-28 20:12:02 +00:00
|
|
|
for (int n = 0; n < pl->num_entries; n++) {
|
|
|
|
struct playlist_entry *e = pl->entries[n];
|
|
|
|
if (n)
|
2013-11-19 21:36:33 +00:00
|
|
|
edl = talloc_strdup_append_buffer(edl, ";");
|
|
|
|
// Escape if needed
|
|
|
|
if (e->filename[strcspn(e->filename, "=%,;\n")] ||
|
|
|
|
bstr_strip(bstr0(e->filename)).len != strlen(e->filename))
|
|
|
|
{
|
|
|
|
// %length%
|
2013-11-20 17:12:14 +00:00
|
|
|
edl = talloc_asprintf_append_buffer(edl, "%%%zd%%", strlen(e->filename));
|
2013-11-19 21:36:33 +00:00
|
|
|
}
|
|
|
|
edl = talloc_strdup_append_buffer(edl, e->filename);
|
|
|
|
}
|
|
|
|
playlist_clear(pl);
|
2024-02-04 18:58:09 +00:00
|
|
|
playlist_append_file(pl, edl);
|
2013-11-19 21:36:33 +00:00
|
|
|
talloc_free(edl);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
const char *mp_status_str(enum playback_status st)
|
|
|
|
{
|
|
|
|
switch (st) {
|
|
|
|
case STATUS_SYNCING: return "syncing";
|
|
|
|
case STATUS_READY: return "ready";
|
|
|
|
case STATUS_PLAYING: return "playing";
|
|
|
|
case STATUS_DRAINING: return "draining";
|
|
|
|
case STATUS_EOF: return "eof";
|
|
|
|
default: return "bug";
|
|
|
|
}
|
|
|
|
}
|