Repository navigation
Conversation
4419c97 to
16bedd1
Compare
16bedd1 to
a8875ca
Compare
| 4. Filter the returned list of Flows to remove any that do not meet requirements, such as codecs, containers or bitrates that are not readable by this system. | ||
| 5. If constructing an adaptive bitrate (ABR) ladder for a suitable player, use this list to set quality steps in the player and stop here. | ||
| 6. If `generation` is present, sort the list by `generation` in ascending order. | ||
| 7. If `avg_bit_rate` is present, for each Flow with the same `generation` (or every Flow if `generation` is not present), sort the list by `avg_bit_rate` in descending order. |
There was a problem hiding this comment.
I'm wondering if 6 & 7 should be the other way around? You could have a Flow with a higher generation, but 10x the bit rate. I'm also wondering if these should be framed as "filter by the lowest generation/highest bitrate" to avoid un-necessary sorting?
There was a problem hiding this comment.
If the generation is higher, doesn't that mean it's got 10x the bitrate because something invented some more bits (or used a less efficient codec)? Going up a generation means something lossy happened to get there. I figure if you wanted a specifically higher bitrate (or if you had a minimum) you'd have filtered out Flows that don't qualify in step 4.
I've had another go at the wording for this: I think it's useful to be specific that you sort by generation and then for equal generation sort by bitrate - is my change any clearer?
There was a problem hiding this comment.
I think my specific concern is that you could have multiple Flows with the same generation number in a branching structure. You could have a generation 10 that has only been through visually lossless processes, and a generation 5 thats only been through visually lossy processes.
There was a problem hiding this comment.
TSC 2026-10-16
Discussed the points above
SMG: Is this using generation incorrectly
JS: Docs just say you increment the generation if you go through a lossy transcode
JB: If that's the case, there's something odd in your workflow. Would lean towards bitrate first, then generation
JS: Inferring quality from parameters that are an indicator, not a guarantee
JB: Proxy is somewhat difficult: how do you determine between various lower-bitrate options. In some ways query-by-profile is easier
JE: Not necessarily all about generation - if you did a couple of rounds of framerate conversion, you'd struggle to use the TAMS data to support that workflow. It's not a MAM.
JS: Need to include words to the effect of "it's an estimate" - this is not a definitive quality statement, it's a way to resolve a selection of near-equal options
JB: Call out that it works in simple scenarios.
SMG: Will swap 6 and 7, suggest a size of generation discrepancy to trigger a rethink, and make clearer this is a "best guess"
Co-authored-by: James Sandford <james.sandford@bbc.co.uk>
a477227 to
af27310
Compare
Details
Adds a AppNote describing how to find Flows from a Source ID
Issue (if relevant)
GitHub Issue: #197
Related PRs
Submitter PR Checks
(tick as appropriate)
Reviewer PR Checks
(tick as appropriate)
Info on PRs
The checks above are guidelines. They don't all have to be ticked, but they should all have been considered.