Proper Duration and Position Support

[tralph]

Ticket to track development for proper duration and position support.

The object of this feature is to provide accurate duration and total frame count for the recorder and commercial flagger. This will address the long standing issues with incorrect duration/position for variable frame rate and frame repeats.

For videos with a position map we will use the generated duration/frame count to generate duration/position. If no position map exists we will use the timestamp and duration provided by libav.

[Github]

dtvrecorder: update MPEG-2 parser to properly generate repeat_pict values

This is going to be used for generating correct video duration.

Refs #10104

Branch: master Changeset: be8919faf54b9c0384f44acbee3950c79e6230a8

[tralph]

There isn't much left to do to support this. Just not enough time to work on it anymore.

[stichnot]

1. Mythcommflag --rebuild produces MARK_DURATION_MS marks in recordedseek or filemarkup, mapping keyframes to time offsets relative to the beginning of the recording.

2. Recorders produce this same information.

3. New command added to myth protocol - "QUERY_RECORDER FILL_DURATION_MAP" - similar to FILL_POSITION_MAP, to send updated duration info for playback of an in-progress recording.

4. Use the duration map during playback to provide more accurate display and seeking with durations and time offsets, by linear interpolation between close values in the duration map. Avoid using naive framerate based calculations, or inaccurate/noisy/discontinuous display timecodes from the recording. Also take the cutlist into account.

[Jim Stichnoth <jstichnoth@…>]

In 49dbed5be0729b04a5f0fd0426a32fceb2dd7935/mythtv:

Provide accurate position/duration/seeking with non-constant framerates.

The recordedseek and filemarkup tables are enhanced to hold timestamp
data in addition to the existing file offset data. The millisecond
timestamps are produced by all recorders that subclass DTVRecorder, as
well as mythtranscode and mythcommflag --rebuild. These timestamps
are relative to the start of the recording/video.

A new command is added to the myth protocol, "QUERY_RECORDER
FILL_DURATION_MAP", modeled after FILL_POSITION_MAP, to send updated
timestamp info for playback of an in-progress recording.

The timestamp markup is used during playback to give accurate position
and duration information in the OSD wherever possible, and to provide
accurate time-based seeking, such as "skip forward 30 seconds" or
"jump to the 5-minute mark". Timestamps are linearly interpolated
from a frame's nearest neighbors in the map, and extrapolated based on
the current frame rate when the map is missing (e.g. legacy
recordings) or incomplete (e.g. in-progress recordings). Other than
that, the frame rate is not used for seeking or duration calculations.
(With the exception of a handful of areas that still need some
attention, including seeking based on commskipmap, seeking across
program boundaries during Live TV, and the watched flag calculation.)

The cutlist continues to be taken into account for seeking and
displaying timestamps, for the most part making cutlists
indistinguishable from the result of lossless transcoding.

Note that to get the benefit of these changes for preexisting
recordings, it may be necessary to run "mythcommflag --rebuild" on
such recordings.

Bumps the ABI and protocol versions. "make distclean" is recommended.

Fixes #10104.

[Karl Dietz <dekarl@…>]

In 4995830547a1852ea46c42f3d9d5ff6a2fc490e5/mythtv:

split position and duration map in mythtranscode

after [49dbed5b] a lossless transcode would run into untested code and
fail to insert the new position map

factor 1000 adjustment by Jim Stichnoth

Refs #10104