Everything else are essentially guard statements

The layout is meant to be used internally; the external interface is regular time.Time values.

It's a bit of a hack that we read one item too many from the lexer. This change modifies segment parsing by sending the already consumed lexer items and subsequent lexer items back through another channel. Maintaining the original order through a channel means we can parse a segment in a single loop. Much shorter than dealing with the first item and all other items separately. This puts off looking into any redesigns of the lexer. For now...?

So we all know where it comes from if we want to get more.

Tests fail, but at least we have exposed the bugs

Playlist from https://test-streams.mux.dev/dai-discontinuity-deltatre/manifest.m3u8 containing discontinuities exposed the bugs.

We weren't really testing whether variants we parse from a playlist were what we expect. References: https://github.com/untangledco/streaming/issues/34

We don't necessarily need to make it easier to specify Variant test cases, we can pick the already easy-to-test bits of Variant to make better. References: https://github.com/untangledco/streaming/issues/34

The idea was to have a little playground using the packages we developed. But it didn't really turn out to be useful.

Since we're just parsing an integer we can just try to parse the next token from the lexer, like how we parse the playlist version.

We'll need it later and we're a few nested for loops and if stmts down so a little cleaner once we do this a few more times.

Now we handle the tag header parameter, and all the different forms the values of To and From can have.

duh

Not ready... if ever?

Parsing the base and extension ticks of the PCR was actually incorrect. Whilst we were consistently storing and decoding values, they were incorrect values. This patch adds tests which concretely exposed the bug spotted by @kevmo314. Thanks again!