BANDWIDTH / AVERAGE-BANDWIDTH #946

[sannies]

Hi @erankor,

I got a very early proof of concept here. It works for my single test file - not enough but a start.
The code that creates the i-frame playlist was transformed to compute segment sizes and (AVERAGE-)BANDWIDTH.
I believe I added a few too many things to the hls_master_request in ngx_http_vod_hls.c - that might introduce a performance penalty. But it's hard for me to understand which REQUEST and PARSE flags are actually required.

As I don't have a lot of experience with the plugin: Is this approach something you'd support?

[kaltura-hooks]

Hi @sannies,
Thank you for contributing this pull request!
Please sign the Kaltura CLA so we can review and merge your contribution.
Learn more at http://bit.ly/KalturaContrib

[sannies]

Hi @erankor , any comment on my code? Is it the correct approach?

[sannies]

The numbers in BANDWIDTH and AVG_BANDWIDTH are now right with a single quality e.g.:

TOS_,1000000,.mp4.urlset/master.m3u8 gives the right result
TOS_,1000000,1400000,.mp4.urlset/master.m3u8 doesn't as it calculates the values for a stream that contains both qualities' bitstreams.

The new hls_muxer_simulate_get_segment_sizes in hls_muxer.c doesn't select the current track for simulation but the entire media_set. It looks like I got to create a media_set from the request_context's media_set that only contains the tracks required for this variant.

(If anyone wants to chime in please do so otherwise this is a note to myself)

[sannies]

I now restrict the media_set via

media_set->filtered_tracks = cur_track_ptr[0];
media_set->filtered_tracks_end = cur_track_ptr[0];
media_set->total_track_count = 1;

and everything seems to work. I don't believe the approach is 100% right but I couldn't find a better way

[sannies]

@erankor Hi, any comment? AMA!