Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SDL-0296] Possibility to update video streaming capabilities during ignition cycle #3468

Conversation

LitvinenkoIra
Copy link
Contributor

@LitvinenkoIra LitvinenkoIra commented Jul 31, 2020

Fixes #3465

This PR is [ready] for review.

Risk

This PR makes [minor] API changes.

Testing Plan

smartdevicelink/sdl_atf_test_scripts#2437

Summary

  1. New additionalVideoStreamingCapabilities parameter of VideoStreamingCapability processing
  • Store additionalVideoStreamingCapabilities from UI.GetCapabilities response
  • Send additionalVideoStreamingCapabilities to the mobile app via GetSystemCapabilities
  • Resend additionalVideoStreamingCapabilities to the mobile app via OnSystemCapabilityUpdated notification from HMI
  1. OnSystemCapabilityUpdated with videoStreamingCapabilities processing
  • The notification from HMI which contains appID parameter must be re-sent to appropriate mobile application only if it had been subscribed on it else it must be ignored
  • The notification from HMI which does not contain appID parameter must be ignored
  1. OnAppCapabilityUpdated notification processing
  • The notification from the mobile must be re-sent to the HMI

Rpc_spec

smartdevicelink/rpc_spec#272

CLA

IGapchuk and others added 12 commits July 23, 2020 11:26
Currently InterfaceGenerator is not able to generate recursive structures
i.e. one or several structure attributes have its own type e.g.:
struct VideoStreamingCapability {
  ...
    VideoStreamingCapability
    additionalVideoStreamingCapabilities;
}
because structure type
fully defined only when all of it attributes are defined.
Otherwise param with type of structure will have AlwaysFalseSchema for
validation so this param will never be validated successfully.

With this commit InterfaceGenerator is able to handle such
problem.
Add the checking of the SystemCapabilityType::VIDEO_STREAMING in the message
and setting it into the HMICapabilities.
@LitvinenkoIra
Copy link
Contributor Author

@atiwari9 please review this PR

Copy link

@atiwari9 atiwari9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved changed with below commits:

Logs:
2020-08-19_15-57-51.zip


TOTAL: 44
PASSED: 42
FAILED: 0
ABORTED: 0
SKIPPED: 2

SDL Core: 36f2f377929c52f84cb4b4216795fcc5c96f58b4
RPC Spec: 4d1312648b78b69f881d97b4b9fd0d8291736750
SDL HMI: 788499f2078e522d710dce3f413045277b278785
Test Scripts: e6d7f578d52c3b932bc2c5ed9465e9d0c8fd8979

Please resolve conflicts before merging.

LitvinenkoIra added 2 commits December 1, 2020 12:47
@LitvinenkoIra LitvinenkoIra force-pushed the feature/0296_possibility_to_update_video_streaming_capabilities branch 2 times, most recently from d61e005 to 618658a Compare December 5, 2020 12:10
@jordynmackool
Copy link

@LitvinenkoIra, please advise when this PR is ready for Livio review. Thanks!

@LitvinenkoIra LitvinenkoIra force-pushed the feature/0296_possibility_to_update_video_streaming_capabilities branch 2 times, most recently from ad9c15e to 9fbb67f Compare December 15, 2020 09:37
@LitvinenkoIra LitvinenkoIra force-pushed the feature/0296_possibility_to_update_video_streaming_capabilities branch from 9fbb67f to 5393355 Compare December 15, 2020 14:58
…bility_to_update_video_streaming_capabilities
@LitvinenkoIra
Copy link
Contributor Author

@jordynmackool @JackLivio This PR is ready for Livio review. Thank you!

@dboltovskyi
Copy link
Contributor

@JackLivio Please notice all required updates are made and this PR is ready for a new iteration of review.

@@ -3556,9 +3556,7 @@ void ApplicationManagerImpl::ForbidStreaming(
}

void ApplicationManagerImpl::OnAppStreaming(
uint32_t app_id,
protocol_handler::ServiceType service_type,
const Application::StreamingState new_state) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the old OnAppStreaming should be marked deprecated with functionality left as is. A new OnAppStreaming method can be created with the new signature/functionality.

This is to prevent a major version change for Core since OnAppStreaming is a public method in application manager.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 3d6a459

@Jack-Byrne
Copy link
Collaborator

@dboltovskyi @AKalinich-Luxoft @LitvinenkoIra

Thank you for the update. The commit history is a little muddy with the different merges. Was the fix to revert the changes from #3488 ?

Do we need to reexamine the issue here? #3160

@dboltovskyi
Copy link
Contributor

@JackLivio
Initial fix for #3160 was reverted since it introduced #3603.
Another version of fix has been implemented in a6a06d4 and 89e27c5 which covers both these issues altogether.

We have re-tested both of them and it looks they were fixed properly.

@AKalinich-Luxoft
Copy link
Contributor

@dboltovskyi @AKalinich-Luxoft @LitvinenkoIra

Thank you for the update. The commit history is a little muddy with the different merges. Was the fix to revert the changes from #3488 ?

Do we need to reexamine the issue here? #3160

@JackLivio let me bring some clarity here.
As we noticed, fix #3488 provided in release 7.0 is causing an issue #3603. That fix itself was to replace a similar fix #3057 with a new one. Both fixes are doing the same - hold the connection channel (pipe or socket) opened even if there is no data received from mobile. But the logic is different - old fix is doing this by guessing a playback time of received audio data and holds the connection opened for the calculated time. The new fix is just holds the connection opened until mobile explicitly sends StopService, however such approach is not always working. Especially for the audio streaming where reconnect is necessary. That's why there was decided to revert #3488 and return back the old version of the fix. From the point of view of #3160 that is fine because an old fix (#3057) solves that issue too. Just a small adjustments were done in a6a06d4 to apply the old fix for all transport types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants