Viblast

Noticed very low PDN participation while testing a new encoder(teradek w/ VBR)/transcoder(nimble transcoder for ABR) solution. It appears the reported bitrate (BANDWIDTH) within the ABR playlist is highly dynamic. For example three consecutive ABR playlist request results in different reported bitrates for all streams:

$ curl -k https://transcoderprdsd.example.com/live/abr_cube/playlist.m3u8

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:BANDWIDTH=2268786,RESOLUTION=858x480,CODECS="avc1.64001e,mp4a.40.2"

live/cube_480p/chunks.m3u8?nimblesessionid=17

#EXT-X-STREAM-INF:BANDWIDTH=1750605,RESOLUTION=1280x720,CODECS="avc1.640020,mp4a.40.2"

live/cube_source/chunks.m3u8?nimblesessionid=17

#EXT-X-STREAM-INF:BANDWIDTH=1214859,RESOLUTION=432x240,CODECS="avc1.640015,mp4a.40.2"

live/cube_240p/chunks.m3u8?nimblesessionid=17

$ curl -k https://transcoderprdsd.example.com/live/abr_cube/playlist.m3u8

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:BANDWIDTH=2801408,RESOLUTION=858x480,CODECS="avc1.64001e,mp4a.40.2"

live/cube_480p/chunks.m3u8?nimblesessionid=18

#EXT-X-STREAM-INF:BANDWIDTH=2114367,RESOLUTION=1280x720,CODECS="avc1.640020,mp4a.40.2"

live/cube_source/chunks.m3u8?nimblesessionid=18

#EXT-X-STREAM-INF:BANDWIDTH=1514728,RESOLUTION=432x240,CODECS="avc1.640015,mp4a.40.2"

live/cube_240p/chunks.m3u8?nimblesessionid=18

$ curl -k https://transcoderprdsd.example.com/live/abr_cube/playlist.m3u8

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:BANDWIDTH=2422767,RESOLUTION=858x480,CODECS="avc1.64001e,mp4a.40.2"

live/cube_480p/chunks.m3u8?nimblesessionid=19

#EXT-X-STREAM-INF:BANDWIDTH=1725735,RESOLUTION=1280x720,CODECS="avc1.640020,mp4a.40.2"

live/cube_source/chunks.m3u8?nimblesessionid=19

#EXT-X-STREAM-INF:BANDWIDTH=1323850,RESOLUTION=432x240,CODECS="avc1.640015,mp4a.40.2"

live/cube_240p/chunks.m3u8?nimblesessionid=19

Is it possible to associate PDN groups/swarms via RESOLUTION as an alternative to BANDWIDTH? 

Hi Lael,

Currently the only supported option is to use the BANDWIDTH to distinguish between different qualities. The problem is that in some cases it is possible to have two different qualities with the same resolution and there is no clear solution to this problem. Even using the stream URL for the selected quality (e.g live/cube_240p/chunks.m3u8?nimblesessionid=19) is problematic because sometimes the session id is included in the URL. In this case we can strip the part after the "?", but sometimes the URL is something like live/cube_240p/sessionid/chunks.m3u8. 

We will discuss it internally and try to find some solution that works all the time (or at least most of the time).

Best regards,

Nikolay Dimitrov

Hi Nikolay,

This issue is appears similar to how CDNs identify a unique resource as cacheable or secure, for example one of the leading CDNs creates a cachekey (x-cache-key) for all resources. By default the cachekey is the complete URL  (including query args), however to improve reuse/cacheability the CDN allows the customer to define the cachekey matching rules. For example all/some query args (nimblesessionid) are not included within the cachekey and/or ignore/include parts of the URL path (*sessionid*), etc. Maybe something similar will work for ABR based streams, such as a streamkey (x-stream-key=live/cube_240p/). 

For now it appears ABR streams that utilize VBR are not compatible with the PDN.  

Thanks,

Lael

Update: It appears nimble provides a method to overwrite the BANDWIDTH value to a static value within the ABR playlist. PDN participation is now successful for VBR enabled ABR streams. However this solution is only valid for encoders that utilize nimble for transmuxing. Also I noticed an odd behavior with the Viblast player when switching between ABR streams that utilize VBR; I'll start a new question.

Thanks,

Lael