Skip to content

Update AppNote0001#171

Open
j616 wants to merge 9 commits intomainfrom
jamessa-qualityLadder
Open

Update AppNote0001#171
j616 wants to merge 9 commits intomainfrom
jamessa-qualityLadder

Conversation

@j616
Copy link
Contributor

@j616 j616 commented Feb 5, 2026

Details

This PR updates AppNote0001 in the following ways:

  • Link to referenced NMOS data model
  • Explain Flow Segments, and Objects
  • Add Objects to basic diagram
  • Updates some terminology
  • Call out that references to Sources should normally be preferred in workflows
  • Call out Source collections
  • Call out the benefits of mono-essence more strongly
  • Explain why empty mono-essence Flows are still useful against populated multi-essence Flows
  • Added quality ladder examples
  • Added clipping example
  • Added edit-by-reference example
  • Replaced PNG diagrams with mermaid diagrams
    • This removes tooling requirements on contributers
    • This allows changes to be tracked in version control
  • Replaces non-standard "note" boxes with standard "note" alert-boxes

Jira Issue (if relevant)

Jira URL: https://jira.dev.bbc.co.uk/browse/CLOUDFIT-5510

Related PRs

Where appropriate. Indicate order to be merged.

Submitter PR Checks

(tick as appropriate)

  • PR completes task/fixes bug
  • API version has been incremented if necessary
  • ADR status has been updated, and ADR implementation has been recorded
  • Documentation updated (README, etc.)
  • PR added to Jira Issue (if relevant)
  • Follow-up stories added to Jira

Reviewer PR Checks

(tick as appropriate)

  • PR completes task/fixes bug
  • Design makes sense, and fits with our current code base
  • Code is easy to follow
  • PR size is sensible
  • Commit history is sensible and tidy

Info on PRs

The checks above are guidelines. They don't all have to be ticked, but they should all have been considered.

@j616 j616 requested a review from a team as a code owner February 5, 2026 16:48
Copy link
Contributor

@GeorginaShippey GeorginaShippey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Largely very happy with this :D

These Media Objects are typically short (on the order of seconds) and independently decodable to allow for efficient random access of content.
Media Objects are mapped to a Flow's timeline via Flow Segments.
Once the media is in the store, it is considered immutable and never modified directly.
It's `Flow ID` and relationship to the timeline never changes, ensuring that when you request a particular `Flow ID` and timerange via the API, you always get the same media Segments back.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: It's -> Its

These Media Objects are typically short (on the order of seconds) and independently decodable to allow for efficient random access of content.
Media Objects are mapped to a Flow's timeline via Flow Segments.
Once the media is in the store, it is considered immutable and never modified directly.
It's `Flow ID` and relationship to the timeline never changes, ensuring that when you request a particular `Flow ID` and timerange via the API, you always get the same media Segments back.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like media Segments here, feels like mashing Media Objects and Flow Segments together. Either I'd go with 'you always get the same media back' or 'you always get the same Flow Segments back'.

@@ -28,22 +37,86 @@ By extension, content can be referenced independent of its encoding by using the

The TAMS content model provides a `collection` mechanism for grouping several mono-essence `Flow` entities together under a multi-essence `Flow ID`.
Mono-essence `Flows` can be referenced by any number of multi-essence `Flow collections`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like there is a bit of back and forth over naming generally over the document - multi-essence flows, multi-essence sources and Multi-Sources.
Mono-essence Flows can be collected into any number of multi-essence Flows (Multi-Flow)?


![Graphic showing ingest of an AV stream to create a set of TAMS Flows and Sources, stored as multi-essence](./images/0001-multi-mono-essence-flows-sources-fig4.png)
> [!NOTE]
> Mono-essence `Flows` are often still be useful for conveying the technical properties of the tracks within the multiplex stream.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence doesn't quite make sense. Do you think there could be need for another little ADR in the future where we explore multipexed data storage?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants