Add program segmentation to Ingestion Appliances

[slifty]

Task

Description

When building the SRT generator appliance (#58) there was some exploration about how to handle the way that SRT timecodes are designed to be relative to the start of a program. For instance the first caption in a program starting at the beginning of a program might be considered 00:00:00,000.

Payloads have a position field, but for live video streams that contain multiple isolated videos (e.g. TV) what does position mean?

The (proposed / developing) philosophy is that appliances should not be responsible for caring about the context of the payloads it receives, but rather the payload should represent its own context. Keep in mind that payloads already have the concept of absolute time (the timestamp field is intended to cover this) -- payload is intended to be about contextual (e.g. within-a-program) time.

This is a long way of saying that we should think of position as program position -- and that a given video source or streams might contain multiple programs. It also might not, of course! Indeed, the default assumption will be that a source is just one large program.

We should provide some core functionality / utilities for ingestion appliances to make it easier to segment the content into programs. Each program would have (1) new program metadata and (2) reset the position counter.

The logic for if and when a program segmentation might split would be defined by the TVK implementation.

We should support things like segmentation on a regular cadence (e.g. every 30m represents a new program).

As we get more advanced, we may want to move In terms of a list of time blocks (day-based, week-based, or other-time-span-based). for instance: 1:00 AM to 3:00 AM on Mondays is {program blahblahblah}.

All of this logic would be based on the value of timestamp of a given payload.

IMPORTANT CONSIDERATION: It is possible this logic should be handled by the countertop, as opposed to by the ingestion appliance itself.

[slifty]

I started a thread in the countertop repo since I think this needs to be thought through at a higher level than just appliances.

[slifty]

Closing this since it was more deeply explored in that countertop#121 issue.

We'll make a new segmentation appliance -- it won't affect payloads, but rather will be a new payload type.