Age | Commit message (Collapse) | Author |
|
The ImsMediaAudioPlayer will be crashed by null pointer exception when invokes stop method after openSession is failed. I added initialization of class member parameters to avoid null pointer exception.
Bug: 277535685
Bug: 277536259
Test: Verified simulation condition to test the audio player is in
exceptional state, atest ImsMediaNativeTests
Change-Id: I9f09cdbc44e8acdefbc05e60c76efdf408edbb58
|
|
being updated to undefined" into udc-dev
|
|
updated to undefined
This CL also fixes CVO operation was not working due to the incorrect list logic in the SetCvoExtension method in RtpEncoderNode
Bug: 242261687
Test: atest ImsMediaNativeTests, Verified with VZW TC RCS 2.27, Video Call simulation test using ImsMediaTestingApp to verify the CVO operation
Change-Id: I42b8a676d4face581ccfa8d68900cc035c987cf8
|
|
IAudioPlayerNode to avoid timing issue on AoC side when SID packets are flowing every 160ms when there is silence in call." into udc-dev
|
|
|
|
|
|
1) Add UT for AudioRtpPayloadEncoder/Decoder
2) Define default CMR for EVS codec
3) Refactoring debug logs
Bug: 272299058
Test: atest ImsMediaNativeTests, Verified voice call of AMR/AMR-WB/EVS codec using ImsMediaTestingApp
Change-Id: Id34764633a45cc35bb77cbac9676966824b83fdf
|
|
Video encoder input format has stride not equal to the image width which caused distorted video encoder output.
Enhanced image rotation utility and pause image source to accept output image stride and added padding in output buffers.
Bug: 266388412
Test: atest ImsMediaNativeTests, tested for all standard resolutions using Media Test App.
Change-Id: I1d8ed477e4cb7d4746a32b0f52e64e4660a0014a
|
|
The current code could not recover lost packet from the redundant packets by the code skip the empty payload in TextRtpPayloadDecoderNode. Therefore, I change the below point to pass the empty redundant payload to recover the text payload when the packet is lost.
1) Modify TextRtpPayloadDecoder to send empty redundant payload to next node
2) Move the setting the flag in TextJitterBuffer from first frame received to the first frame processed.
3) Remove the code ignoring the empty frames in TextRendererNode
Bug: 274881848
Test: Verified packet loss simulation in RTT call using ImsMediaTestingApp, atest ImsMediaNativeTests, Pass the TC LTE_BTR_5_9439.
Change-Id: I09afff3eb288a0d0318eadcaa53966c0745931f9
|
|
IAudioPlayerNode to avoid timing issue on AoC side when SID packets are flowing every 160ms when there is silence in call.
Fix: 275528243
Test: Tested with device and confirmed from logs that decoder is called
even no data in jitter buffer
Change-Id: I4bf874a8567504e085c40ade426f1aadc2c2bc71
|
|
|
|
|
|
Flaky test failure due to different looper being used. Logic is modified
to use the same looper while performing UT.
Bug: 275030625
Test: atest -c ImsMediaJavaUnitTests --iterations 100
Basic functionality is verified manually
Change-Id: Ie17c820c8454117b109796c909e9b387da8e7241
|
|
|
|
There is an issue when the AudioJitterBuffer invoke resync method if the time difference is not fix to any statement in the loop in condition of the audio frame is SID and the time difference lower than current jitter buffer size minus 20msec.
I fix the infinite loop problem to add escape.
Bug: 275635779
Test: Verified multiple voice call test in live network
Change-Id: I0a6a47f81444219b1fdf561fa69d080dba4ac5d1
|
|
1) Change the mutex logic to cover the ImsMediaSourceNode Stop method and ImageReader, Codec and Camera callback.
2) Remove the mutex in IVideoSourceNode to prevent the thread block between Stop() and OnUplinkEvent() invoked after Stop called.
3) Remove the direct frame delivery using recording surface buffer between camera and encoder.
Bug: 270023503
Test: Verified Video Call using ImsMediaTestingApp, atest ImsMediaNativeTests
Change-Id: Ib5fbdb26c44ecb483cfcfb21602a7e38c3c80664
|
|
|
|
Bug: 272299058
Test: atest ImsMediaNativeTests
Change-Id: I29af6ba0b4f2ca643df83a70841d63110f538f63
|
|
|
|
Bug: 275012161
Test: Verified video call with ImsMediaTestingApp
Change-Id: I129c7be68604c70506d724b4462b89e384897b56
|
|
1) Add statement to check the direction in Rtp, Rtcp, Jitter and packet loss notification
2) Modify to reset the statistics status when the direction changed in the MediQualityAnalzyer
3) Modify to check rtcp enabled to reset the inactivity counter for rtcp
Bug: 272068717
Test: atest ImsMediaNativeTests, Verified Voice Call hold/resume case in live network. Verified VZW VoWIFI 10.3 which includes hold/resume operation.
Change-Id: I61b0b9cce09139e0a9599c4ca4a07e3899b62276
|
|
|
|
Move the MediaQualityAnalyzer stop invoked at the beginning of the session closing.
Bug: 272143186
Test: Verified with voice call in live network, atest ImsMediaNativeTests
Change-Id: Ie8a9997c4f0eb92207bd9ddcce1dab49e01dc295
|
|
The AudioJitterBuffer is used to store audio frames from multiple threads. One thread stacks audio frames, while another thread retrieves them every 20 milliseconds. When the AudioJitterBuffer starts, it calculates the time delay of the stacked audio frames and discards the old ones, which causes the frames to be resynced to maintain a constant latency as configured in the jitter buffer size. When the resync is done, the jitter buffer decides the playing timestamp and increases it every time a frame is retrieved.
The problem is that the AudioJitterBuffer does not increase the playing timestamp when the queue is empty. This causes the discard of audio frames when the audio frame changes from SID to normal frame because the SID interval is 160 milliseconds but audio frames are 20 milliseconds. To fix this, I added a checking condition to increase the playing timestamp for the next interval to correctly get the playable audio frame and prevent the incorrect audio frame discarding.
Bug: 271808260
Test: Voice Call in live network checking the SID and normal sound switching period, atest ImsMediaNativeTests
Change-Id: I1a08244d03d8cbfb941c68db7bd49e9577ca04e7
|
|
This reverts commit d48560af47c40dd0259a3b5e233a3d8d1bc211ab.
Reason for revert: atest failure
Bug: 274715723
Change-Id: I681fc792f219467557355e5fe73d6fdb032e37f6
|
|
The AudioJitterBuffer is used to store audio frames from multiple threads. One thread stacks audio frames, while another thread retrieves them every 20 milliseconds. When the AudioJitterBuffer starts, it calculates the time delay of the stacked audio frames and discards the old ones, which causes the frames to be resynced to maintain a constant latency as configured in the jitter buffer size. When the resync is done, the jitter buffer decides the playing timestamp and increases it every time a frame is retrieved.
The problem is that the AudioJitterBuffer does not increase the playing timestamp when the queue is empty. This causes the discard of audio frames when the audio frame changes from SID to normal frame because the SID interval is 160 milliseconds but audio frames are 20 milliseconds. To fix this, I added a checking condition to increase the playing timestamp for the next interval to correctly get the playable audio frame and prevent the incorrect audio frame discarding.
Bug: 271808260
Test: Voice Call in live network checking the SID and normal sound switching period, atest ImsMediaNativeTests
Change-Id: I5e3fd176725b26d176c7a58e46fbd4f95e16ade3
|
|
|
|
|
|
1) The TextSourceNode was sending data to the UTF-8 chunk unit, which was slowing down the performance. I remove the logic splits the text string to UTF-8 unit and send the text string as same as it was received to speed up the performance.
2) Remove the own text list and use the member of data queue in base class instead in the TextSourceNode.
Bug: 271626757
Test: 1 to 1 MO/MT RTT test case with device, atest ImsMediaNativeTests
Change-Id: Ie4ab8e189e4fc231d6b11707f6adae4fa563d936
|
|
|
|
1) The StreamScheduler calls the ProcessData method of the non-runtime node in the RunRegisteredNode method. There used to be a routine that removed nodes if the ProcessData method was invoked once, but it was removed by the change of StreamScheduler before which causes side effect in the video call not playing the video frames and RtpEncoderNode invokes ProcessData without time gap. I have improved that routine and made it more efficient to resolve the side effect.
2) Modify calling ProcessData interval to 1ms
Bug: 270524661
Bug: 272724778
Test: Verified Voice Call, Video call and RTT call using loopback mode using the ImsMediaTestingApp, atest ImsMediaNativeTests
Change-Id: I8c99cbf367e105a84c0f5dcd6644ffc90729f698
|
|
|
|
Bug: 267802258
Test: Live network testing and verified the AudioExt HAL message
Change-Id: If8994c944d53f5736a6024fa3700609f49862333
|
|
Bug: 272299057
Test: atest ImsMediaNativeTests
Change-Id: I5324935dad859de281ca05b1b13ea46814c9f52a
|
|
|
|
into udc-dev
|
|
Fix: 269100741
Test: Tested with device and dtx and octetaligned configuration setting dynamically
Change-Id: I4d55f8efe71f347b05557cd3fac8b6afb5baee67
|
|
|
|
set to RTCP XR Loss RLE Report Block type." into udc-dev
|
|
The CL modifies that the RTCP packets are no longer sent in the NO_FLOW direction. The BaseStreamGraph class's Start method was overridden to ensure that each Audio/Text StreamRtcp instance does not send RTCP packets in the NO_FLOW direction
Bug: 270893749
Test: atest ImsMediaNativeTests, Verified Voice Call, Video Call and RTT call direction changing cases in loopback mode using ImsMediaTestingApp
Change-Id: I361155a4b06cc1fb067844583ebd72371cf7f661
|
|
|
|
Wrong value was set to RTCP XR Loss RLE Report Block type.
Bug: 260563971
Test: atest ImsMediaNativeTests, checked Rtcp packets in call
Change-Id: I5a77c6c4ed8aa9cf36b86ba5e8af4e11c993e8a2
|
|
Add mutex to prevent the crash by accessing the same memory in different threads in the JitterNetworkAnalyzer.
Bug: 271800584
Test: Verified in long voice call test in live network over 1 hours multiple times, atest ImsMediaNativeTests
Change-Id: I48c39987d00d0ad65ef834758334f80b2c3fef23
|
|
1) Fix the incorrect lost packet count
2) Modify to run jitter/loss notification checking routine before checking the other notificaiton condition
3) Add jitter reset operation when the ssrc changed
Bug: 268602328
Test: atest ImsMediaNativeTests, Verified with the test case LTE_BTR_5_7160-4. Verified voice call in live network.
Change-Id: I5eb5c2a10be5722c988d05b3828eca6c08d47f58
|
|
1) The jitter buffer starting delay is fixed by removing the old audio frames stayed longer than the time of the jitter buffer size. This will ensure that the jitter buffer only contains the most recent audio frames, and will not cause delays over the intended time in the audio playback.
2) Modify SID checking logic in AudioJitterBuffer to filter the SID correctly.
Bug: 268364437
Test: Verified Voice Call with loopback mode using ImsMediaTestingApp,
verified voice call in live network, atest ImsMediaNativeTests
Change-Id: Ib050afdbb61c0be63dd0c8bc8804db57beba532b
|
|
1) Add a null check to prevent the crash in the ImsMediaCamera
2) Add size check to prevent the crash in RtpEncoderNode
Bug: 270524661
Test: Verified Video Call with loopback mode using ImsMediaTestingApp,atest ImsMediaNativeTests, Verified video crash is resolved by testing L_IR94_396001_1 case.
Change-Id: I06e609e1737df61228baa3595890ae7354f65cf7
|
|
Revert submission 21080423-MediaQualityStatus
Reason for revert: <api is deprecated>
Reverted changes: /q/submissionid:21080423-MediaQualityStatus
Bug: 271057457
Change-Id: I2f6328c891a4cbdc3708c233b4e3d7a5ef9e6dd8
|
|
|
|
The current code does not invoke the ProcessData method of non-runtime source nodes, as it lacks the routine to check the SourceNode in the registered nodes in StreamScheduler. This causes TextSourceNode to not invoke the method to send the text frames to the next node. I fixed it by adding a routine to check the SourceNode in StreamScheduler to invoke the ProcessData method to send data frames to the next node in TextSourceNode to make RTT packets.
Bug: 270895153
Test: Verified with RTT call in loopback mode in ImsMediaTestingApp,
atest ImsMediaNativeTests
Change-Id: I071e42303c816377f7e62e482ddf2af5b5e64945
|
|
The issue is caused by rx audio stream started after the tx audio stream start finished not starting simultaneously. It causes latency in audio playing time. It is because both tx and rx audio stream started in main thread sequentially. Therefore, I change the audio stream started in the StreamScheduler thread which is a individual thread created for each tx and rx stream instance. It makes remove the audio starting latency in AudioPlayer.
Bug: 268364437
Test: verified with loopback voice call using ImsMediaTestingApp, atest
ImsMediaNativeTests, Verified voice call in live network.
Change-Id: I2a9dd073c883b47d3bb7f4e17e2c76c654eaf6aa
|