search

ekumenlabs / AndroidStreamingClient

Library that receives UDP packets wrapped into RTP and coded in H264, decodes the corresponding frames and plays the resulting stream in an Android SurfaceView
Apache License 2.0
129 stars 45 forks source link

Listen to Ssrc changes and restart #28

Closed FlyingPumba closed 9 years ago

FlyingPumba commented 9 years ago

This way, you don't need to restart video client in Mission Control by hand. It's restarted automatically. @ashyonline @adamantivm @manzato NOT tested yet with the S4.

FlyingPumba commented 9 years ago

@adamantivm Test 1: How many packets are received with wrong SSRC in a normal run ?

Conclusion: not a single spurious packet with wrong SSRC was detected during the whole test (~45 min). Are you completely sure you have seen this kind of packets ? Take into account that although i was using the VPN, it was not stressed using the special script. I'd suggest to modify current code in this PR to restart the decoder if it has received more than x packets with wrong SSRC, and receiving a good one would reset this counter. This would ensure that a single a spurious packet won't restart the whole session. Thoughts ?

adamantivm commented 9 years ago

Thank you very much for the thorough testing, Ivan. This is very useful. Can I ask you to include disconnecting and reconnecting the VPN as part of the test?

I agree with your proposed SSRC restart strategy.

Julian (mobile) | +54(911)3169-5590 On Jan 30, 2015 6:43 AM, "Ivan Arcuschin" notifications@github.com wrote:

@adamantivm https://github.com/adamantivm Test 1: How many packets are received with wrong SSRC in a normal run ?

  • Mission Control and Video Publisher version: 4.4.5, with Toast messages (commit 2c727f8c3703a98aca23bf5dde6576fed15c4b28)
  • RtpMediaPlayer version: The one in 4.4.5 version
  • S4 and Samsung Tablet connected through Creativa's VPN
  • Started VP in S4
  • Started MC in Samsung Tablet
  • Video starts to show automatically. (alhtough zoomed, don't know why, clicking the minimizing video fragment seems to solve it)
  • Delay looks consistent of 5s
  • Image looks very good, even when the image is moving fast
  • Filtering log by "Ssrc" yields: "First packet received from remote source, updated SSRC to 3092867996" which seems ok.
  • 5 minutes later: delay is less than 1 second, and image looks still very good.
  • Accidentally long clicked video in MC (a.k.a resetted video client), there is delay again of 5s, image is very good.
  • Filtering log by "Ssrc" yields: "First packet received from remote source, updated SSRC to 3092867996", again.
  • Note: it seems that client get's better by "skipping" video, achieving again delay < 1s.
  • after 10 minutes from begining: the log shows there weren't any packet with wrong SSRC.
  • Accidentally, again, long clicked video in MC (a.k.a resetted video client), there is delay of 3s, image is very good.
  • Filtering log by "Ssrc" yields: "First packet received from remote source, updated SSRC to 3092867996", again.
  • Shutted down MC
  • Started again MC
  • Video starts to show automatically. (alhtough zoomed, don't know why, clicking the minimizing video fragment seems to solve it)
  • Delay seems greater thatn 5s (~10s), image is very good.
  • Accidentally, again, long clicked video in MC (a.k.a resetted video client), there is delay of 6s, image is very good.
  • 3 minutes later: delay is ~8s
  • 10 minutes later: delay is ~20s
  • Stopped VP
  • MC keeps playing until it reaches end
  • Staterd VP
  • Video in MC starts automatically, delay is ~5s
  • Delay keeps oscilating aroung 5s.
  • Closed VP
  • Started VP
  • MC log starts yielding: "Discarded packet from unexpected SSRC: 1849531929 (expected was 3092867996)." and video is freezed.
  • Resetted video client in MC, delay is ~5s.
  • Filtering log by "Ssrc" yields: "First packet received from remote source, updated SSRC to 1849531929" which seems ok.

Conclusion: not a single spurious packet with wrong SSRC was detected during the whole test (~45 min). Are you completely sure you have seen this kind of packets ? Take into account that although i was using the VPN, it was not stressed using the special script. I'd suggest to modify current code in this PR to restart the decoder if it has received more than x packets with wrong SSRC, and receiving a good one would reset this counter. This would ensure that a single a spurious packet won't restart the whole session. Thoughts ?

— Reply to this email directly or view it on GitHub https://github.com/creativa77/RtpMediaPlayer/pull/28#issuecomment-72211065 .

FlyingPumba commented 9 years ago

Test 2: Similar to Test 1, but manually shutting down the VPN network

No spurious packets detected. However, I'll try to re-do the last part of this test to check video reliability.

FlyingPumba commented 9 years ago

Test 3: idem Test 2, but with longer network shutdown time.

FlyingPumba commented 9 years ago

@adamantivm merging