Put real segment duration into .m3u8 manifest on the broadcaster

[darkdarkdragon]

Is your feature request related to a problem? Please describe.
Currently HTTP ingest relies on the sender to determine segment duration (duration being sent
using HTTP header). In case duration was not sent (and Mist server do not sends duration) default
value of 2 seconds used.
Segment duration value is not used in the transcoding pipeline, but it being set to the .m3u8
manifest. And .m3u8 manifest is only way we can get statistical data out of broadcaster.
In Livepeer API we want to count segments transcoded by the broadcaster and also we want to
get duration of each segment. We can get number of segments passed through broadcaster by
constantly retrieving stream manifest and counting segments in them, but there is no accurate
duration information in them.

Possible solutions

1. Probe incoming segment at broadcaster
   1.1. Add probing functino to LPMS
   1.2. Probe using joy4 - quicker to implement, but less compatibility
2. Return duration from the transcoding function, same as pixels returned right now.
   With this variant there will be no duration information for the source segment at
   the time it gets inserted in the playlist, but this will not add additional compute.

[j0sh]

(and Mist server do not sends duration)

They should add it.

With this variant there will be no duration information for the source segment at
the time it gets inserted in the playlist

In theory we could also update the duration after insertion. Probably not good for playback, but maybe OK for metrics.

We could also reset the "default" duration after the first segment is transcoded, or set the default duration to the largest seen so far. This helps with the actual reasons we track durations on the node: latency calculations, segment timeout and fee estimation. Might be okay if the duration is somewhat consistent.

Yet another approach would be to formalize HLS ingest by taking m3u8s and parsing the segmemt duration out of that. But that doesn't work if HLS is not being used (eg, MP4 sources), and won't do us any favors with latency or internal complexity.

[darkdarkdragon]

They should add it.

Yes, this will solve our immediate problem, but generally we shouldn't be relying on the information provided by sender.

We could also reset the "default" duration after the first segment is transcoded, or set the default duration to the largest seen so far.

Love this idea!
So, we're leaning toward returning duration information from transcode function?

Yet another approach would be to formalize HLS ingest by taking m3u8s and parsing the segmemt duration out of that.

Can you explain this please? I don't understand.

[j0sh]

generally we shouldn't be relying on the information provided by sender.

If it's there we should be able to trust it (absent obviously outrageous values which we already check for), because that's the fastest method of getting everything to work reliably. If they send us incorrect values, they are only hurting their own success rate.

We could still use a post-transcode fixup as a form of double-checking the duration; it's not mutually exclusive with a user-supplied duration.

So, we're leaning toward returning duration information from transcode function?

Perhaps; I hadn't thought of it until now. The initial duration would still be incorrect (might affect timeouts, for example), and I think we'd have similar issues if the duration has a tendency to fluctuate between segments. But as a data point, receiving the duration from the transcoder could still be helpful.

Yet another approach would be to formalize HLS ingest by taking m3u8s and parsing the segmemt duration out of that.

Can you explain this please? I don't understand.

We can do HLS ingest, eg ffmpeg -re -i input -f hls http://localhost:8935/live/stream/name/ and that'll also post the m3u8 after the segment is posted. This works today with ffmpeg. Right now we just ignore anything non-{ts,mp4}, but we could make use of the m3u8 in those cases. There are lots of reasons why it's not a great idea though. It's slower (need to wait for the m3u8), more complex (due to the additional bookkeeping to store segments while m3u8s are pending, and we want to continue supporting the old workflow) and less versatile (most m3u8 tooling is going to be limited to taking mpegts / fmp4). For reasons I don't understand, the industry is also gravitating towards HLS/DASH ingest. Anyway, just wanted to mention the option of formalizing HLS ingest just for completeness, even though I don't think it's something we should be spending a lot of energy on right now.

[darkdarkdragon]

We could still use a post-transcode fixup as a form of double-checking the duration; it's not mutually exclusive with a user-supplied duration.

Totally agree.

Perhaps; I hadn't thought of it until now. The initial duration would still be incorrect (might affect timeouts, for example), and I think we'd have similar issues if the duration has a tendency to fluctuate between segments. But as a data point, receiving the duration from the transcoder could still be helpful.

Filed livepeer/lpms#195

We can do HLS ingest, eg ffmpeg -re -i input -f hls http://localhost:8935/live/stream/name/ and that'll also post the m3u8 after the segment is posted. This works today with ffmpeg.

Got it, thanks. I know that ffmpeg send .m3u8 manifests, but didn't think anyone really uses this. Anyway, supporting such thing is really out of scope for us.