Exposed uri in PKPlaybackInfo

[naveen-c]

Description of the Changes

This is an enhancement to add playback item URI to the standard PlayKit Playback Info.

CheckLists

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• test are passing in local environment
• Travis tests are passing (or test results are not worse than on master branch :))
• Docs have been updated

[kaltura-hooks]

Hi @naveen-c,
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

[OrenMe]

@naveen-c the URI is the playback URI you set for the asset, what is the use case for it? don;t you already have it?

[naveen-c]

@OrenMe In the case of HLS video, the URI in AVPlayerItemAccessLogEvent represents the URI of the currently selected HLS stream (entries in .m3u8 file).
I could not find that information in any place other than AVPlayerItemAccessLogEvent.
We need this information to track which quality stream is being played.

[OrenMe]

Got it, thanks.
For this we expose the indicatedBitrate so you can know exactly which rendition is being played.

[OrenMe]

We also expose this as a track change event so analytics can track this data:

playkit-ios/Classes/Player/AVPlayerEngine/AVPlayerEngine+Observation.swift

Line 81 in 89a7c7f

self.post(event: PlayerEvent.VideoTrackChanged(bitrate: lastEvent.indicatedBitrate))

[naveen-c]

Got it.
So maybe we should expose this URI field in VideoTrackChanged event so that the consumer doesn't need to parse the .m3u8 file to get the URI from indicatedBitrate

[naveen-c]

@OrenMe shall I go ahead and make these changes in VideoTrackChanged event?

[OrenMe]

Thanks @naveen-c , please let us check as the model needs to fit between various SDKs we expose and it is usually not common to identify a stream by its url also in ends that support this.
What do you do in web and android? We do not expose the urls there as well.

[x-NR-x]

Hi @naveen-c,

Did you have the time to check what is done on your side for the Web and Android implementation for this case?

Thanks,
Nilit

[naveen-c]

@OrenMe , @x-NR-x sorry for the delay in response.
On Android, we are using DASH files (.mpd) and consume onDecoderInputFormatChanged event of Exoplayer, which has information of the selected track id

[OrenMe]

@naveen-c are you patching your copy of playkit-android to get this? or using the profiler interface?

[naveen-c]

On Android we are using exoplayer directly, and not kaltura's sdk

[OrenMe]

Thanks @naveen-c, as we need to have compatibility in data model across SDKs we first will need to standardise this across them.
I do not have a date for this, but thank you for raising this so we know this data is required.
In general I would recommend building on the video metadata like bitrates and resolution and not necessarily urls.

[naveen-c]

@OrenMe thanks for the update. For some reason, bitrate is not enough for our analytics.
As you mentioned resolution, is that information exposed in the SDK?

Also, until you make a decision on standardizing the data across SDKs and expose the requested data, is it fine if I use my fork of the repository in my project?

[OrenMe]

Hi @naveen-c , so resolution data will solve your issue? Is that the important info for your case?
And in general you can use your fork, but it will require you to sync the upstream every new release.
Is this for FK project? You mentioned you are not using the android sdk as well, any reason not to but yes for iOS?

[naveen-c]

@OrenMe I think resolution can help, I will check with the team on this.

So the FK project has multiple sub-projects in itself, and on Android, we are using Kaltura SDK for some parts, and Exoplayer directly in older flows.
While on iOS we have recently taken a decision to use this SDK in legacy flows as well.