search

smartdevicelink / sdl_evolution

Tracking and proposing changes to SDL's public APIs.
https://smartdevicelink.github.io/sdl_evolution/
BSD 3-Clause "New" or "Revised" License
33 stars 122 forks source link

[Withdrawn] SDL 0070 - Notification of iAP transport type #201

Closed theresalech closed 6 years ago

theresalech commented 7 years ago

Hello SDL community,

The review of "Notification of iAP transport type" begins now and runs through June 27, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0070-iap-transport-type-notification.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/201

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

joeygrover commented 7 years ago

This proposal aims to notify underlying transport type to iOS SDL apps.

Why not include this in Android as well?

The apps can use such notification to control, for example, the bitrate of video stream when running navigation.

Are there any examples of the values that are optimized for each transport type?

I'm not opposed to adding this information, but I want to be sure the additions have a clear goal and use so that we aren't just adding extra information that's never used that we have to maintain.

brandon-salahat-tm commented 7 years ago

This proposal aims to notify underlying transport type to iOS SDL apps. The apps can use such notification to control, for example, the bitrate of video stream when running navigation.

I believe on iOS that the proxy does most of the video stream encoding. Is there added value in exposing this additional information to app developers, versus having the proxy automatically adjust video streaming performance based on transport type/available bandwidth and keeping the information private to the proxy?

shoamano83 commented 7 years ago

Hi @joeygrover,

Why not include this in Android as well?

My understanding is that in Android proxy, transport configs for Bluetooth and USB are different. So I think Android SDL app should be aware which transport SDL communication is running on. (If it specifies a transport config then it knows the transport. If it doesn't specify then Bluetooth is chosen.)

Are there any examples of the values that are optimized for each transport type?

For USB, I think CarPlay's specification can be an example. Looking at "Accessory Interface Specification R23", I found max. bitrate for wired in table 23-10. I am not sure whether I can share the value here, so let me talk in the call.

For Bluetooth, I didn't find a good English article. I found a Japanese one which states that max. throughput for Bluetooth 3.X+EDR is 2178.1 kbps while the data rate is 3 Mbps. Since we have some overhead for iAP protocol, our max. video streaming throughput should be less than the value. http://micro.rohm.com/jp/techweb_iot/knowledge/iot02/s-iot02/01-s-iot02/39

I'm not opposed to adding this information, but I want to be sure the additions have a clear goal and use so that we aren't just adding extra information that's never used that we have to maintain.

We hear a request from an OEM that they want to provide flexibility to app developers to change app's behavior based on transport type, such as adjusting bitrate.

shoamano83 commented 7 years ago

Hi @Toyota-BSalahat,

Is there added value in exposing this additional information to app developers, versus having the proxy automatically adjust video streaming performance based on transport type/available bandwidth and keeping the information private to the proxy?

Yes, I think exposing the information should give more flexibility to app developers. For example, an app may switch to simpler graphics when running video streaming over Bluetooth, since encoded videos in low bitrate usually looks like "low-res" pictures. An navi app with very complicated graphics may even choose to run navigation only when the phone is connected over USB; it shows a notification message when connected over Bluetooth, to request the user to switch to USB.

By the way, while I agree that SDLStreamingMediaLiecycleManager class (in feature/streaming_media_manager branch) does most of the things for video encoding, I think it is up to each SDL apps to configure encoding bitrate. This makes sense to me since required bitrate for encoding varies between video types. If the app shows very complicated pictures, usually the app should specify high bitrate. I didn't want to change this design principle with my proposal. Please correct me if I'm mistaken.

brandon-salahat-tm commented 7 years ago

Yes, I think exposing the information should give more flexibility to app developers. For example, an app may switch to simpler graphics when running video streaming over Bluetooth, since encoded videos in low bitrate usually looks like "low-res" pictures. An navi app with very complicated graphics may even choose to run navigation only when the phone is connected over USB; it shows a notification message when connected over Bluetooth, to request the user to switch to USB.

@shoamano83 From what I am reading it sounds like there could be added value from informing the app what the current maximum bandwidth is, and if that value changes. However, I think from an app perspective I should not need to know what the underlying transport is, I should just care that I am connected via SDL. I am not sure it would be correct for an application to prompt the user to switch to USB since that could potentially be a driver distraction.

My understanding is that in Android proxy, transport configs for Bluetooth and USB are different. So I think Android SDL app should be aware which transport SDL communication is running on. (If it specifies a transport config then it knows the transport. If it doesn't specify then Bluetooth is chosen.)

I think this could potentially be a pro for just providing information on the maximum bandwidth as well, I think we should try to keep the proxy interfaces consistent between Android and iOS as much as we can.

shoamano83 commented 7 years ago

Hi @Toyota-BSalahat, thanks for your comment.

From what I am reading it sounds like there could be added value from informing the app what the current maximum bandwidth is, and if that value changes.

Indeed, informing the maximum bandwidth sounds better. But so far, I don't come up with solid idea to detect the max. bandwidth. It heavily depends on the implementation of the head unit system, and also on the air condition in the case of Bluetooth. We may even get less Bluetooth bandwidth if another app is playing music over A2DP.

I am not sure it would be correct for an application to prompt the user to switch to USB since that could potentially be a driver distraction.

My example wasn't good. My intention was that the app can change its behavior based on USB/Bluetooth and was not to give a driver distraction.

I think we should try to keep the proxy interfaces consistent between Android and iOS as much as we can.

I agree, but at the same time I want to give same capability to both iOS and Android SDL apps. Android apps can distinguish physical transport type (BT or USB) while iOS apps cannot. Since detecting the max. bandwidth seems difficult, I think notifying the transport type is the second-best plan.

brandon-salahat-tm commented 7 years ago

Indeed, informing the maximum bandwidth sounds better. But so far, I don't come up with solid idea to detect the max. bandwidth. It heavily depends on the implementation of the head unit system, and also on the air condition in the case of Bluetooth. We may even get less Bluetooth bandwidth if another app is playing music over A2DP.

In my mind, I was thinking the head unit could set these values, so each OEM can designate a maximum bandwidth for the transport mode. I think this would allow apps to take the same actions, while still obfuscating the actual transport method from them (So they don't try to do things like prompt the user to connect to USB).

I agree, but at the same time I want to give same capability to both iOS and Android SDL apps. Android apps can distinguish physical transport type (BT or USB) while iOS apps cannot. Since detecting the max. bandwidth seems difficult, I think notifying the transport type is the second-best plan.

Agreed that Android can probably already do this, however if we add a specific interface or notification to iOS for this, I think we should also update the Android proxy in a similar fashion. Even if it is a little redundant in the Android proxy, I think it prevents further fragmentation in how the two are utilized, which makes it easier for app developers.

theresalech commented 7 years ago

When reviewing this proposal, the Steering Committee had much discussion about the use cases for this proposal and the value added from making the changes outlined. Ultimately, it was decided that this proposal should be Returned for Revisions. The author of this proposal will revise based on the comments provided, including MTU in the startServiceACK for RPC service and other streaming services, allowing each hardware implementation to define their best MTU based on their situation, and also notifying the Proxy of the maximum bandwidth.

Additionally, the Steering Committee agreed that any changes made to iOS should also be reflected in the Android proxy, to keep the libraries as consistent as possible for App Developers.

theresalech commented 6 years ago

@shoamano83 do you have an update on these revisions?

shoamano83 commented 6 years ago

Hi @theresalech ,

So far I do not have update on this proposal. We are focusing on running video streaming over high-bandwidth transport, rather than adjusting bitrate of the stream to make it work with Bluetooth. So the priority of this proposal has been low. I am OK to close this ticket since it has been open for a long time. If anyone wants to take over the proposal and revise it, that's fine.

Thanks.

theresalech commented 6 years ago

The author has requested to withdraw this proposal as they do not have plans to revise this proposal in the near future. If another SDLC member would like to continue the efforts of this proposal, they can become the author.