diff options
| author | wm4 <wm4@nowhere> | 2019-05-26 01:56:48 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2019-09-19 20:37:05 +0200 |
| commit | 2363e15eeef4064f95eeec1b487c438b62dc7a02 (patch) | |
| tree | bd7774030946f5ce0cc05bf54adc49b462701a0f /player/playloop.c | |
| parent | 23a73938fa67e3c342e1124ad6fd4a8025f062b6 (diff) | |
| download | mpv-2363e15eeef4064f95eeec1b487c438b62dc7a02.tar.bz2 mpv-2363e15eeef4064f95eeec1b487c438b62dc7a02.tar.xz | |
player: simplify/fix --start/--end handling with --rebase-start-time=no
The get_play_start_pts() function was supposed to return "rebased"
(relative to 0) timestamps. This was roundabout, because one of 2
callers just added the offset back, and the other caller actually
expected an absolute timestamp.
Change rel_time_to_abs() (whose return value get_play_start_pts()
returns without further changes) to return absolute times.
This should fix that absolute and relative times passed to --start and
--end were treated the same, which can't be right. It probably also
fixes --end if --rebase-start-time=no is used (which can't have been
correct either).
All in all I'm not sure why --rebase-start-time=no or absolute vs.
relative times in --start/--end even exist, when they were incorrectly
implemented for years.
Untested, because no sample file and I don't care. However, if anyone
cares, and I got it wrong, I hope it's simple to fix.
Diffstat (limited to 'player/playloop.c')
0 files changed, 0 insertions, 0 deletions