Commit Graph

10 Commits

Author SHA1 Message Date
Andy Grundman
e356b2cfde Change presentationTimeMs to presentationTimeUs: retain more resolution when dealing with RTP video timestamps from Sunshine. Include raw rtpTimestamp value for use with integer time APIs. 2025-11-06 20:27:01 -06:00
Andy Grundman
a3ebaaf015 Use uint64_t for DECODE_UNIT presentationTimeMs
This still holds a millisecond value sourced from RTP timestamp, but since we're changing the API anyway, now is a good time to future-proof this field.
2025-11-06 20:27:01 -06:00
Andy Grundman
82ee2d6590 Improve support for high-resolution stats
* This patch adds a new microsecond-resolution function call, LiGetMicroseconds(), to complement
the existing LiGetMillis(). Many variables used by stats have been updated to work at this
higher resolution and now provide better results when displaying e.g. sub-millisecond frametime stats.
To try and avoid confusion, variables that now contain microseconds have been renamed with a suffix
of 'Us', and those ending in 'Ms' contain milliseconds. I originally experimented with nanoseconds but it
felt like overkill for our needs.

Public API in Limelight.h:
uint64_t LiGetMicroseconds(void);
uint64_t LiGetMillis(void);
const RTP_AUDIO_STATS* LiGetRTPAudioStats(void);  // provides access to RTP data for the overlay stats
const RTP_VIDEO_STATS* LiGetRTPVideoStats(void);

Note: Users of this library may need to make changes. If using LiGetMillis() to track the duration of
something that is shown to the user, consider switching to LiGetMicroseconds(). Remember to divide by
1000 at time of display to show in milliseconds.
2025-11-06 20:27:01 -06:00
Cameron Gutman
e8113f0e66 Use the spare field in the encrypted video header as the frame number
This allows us to skip decrypting extra FEC shards after a frame was reassembled.
2024-01-24 18:36:37 -06:00
Cameron Gutman
1be56269a3 Fix handling of duplicate packets when OOS data was also received
It's possible for a sequence of packets seqnums like 2, 0, 1, 2 to end up hitting the fast path
again after filling in gap of OOS packets. The fast path assumes duplicate packets are caught
by the next contiguous sequence number check, but this is only true if that value is kept updated.

Since the slow path doesn't update the next contiguous sequence number, it's no longer safe to
use the fast path for the remaining packets in the frame because duplicate packets would be
mishandled.

Queuing duplicate packets violates all sorts of queue assumptions and can cause us to return
corrupt data to the decoder or attempt an FEC recovery without enough shards.
2023-09-23 12:08:16 -04:00
Cameron Gutman
05a925b801 Simplify speculative RFI tracking by looking at missing shards of any type 2022-10-22 14:45:19 -05:00
Cameron Gutman
73f1ec64a8 Suppress speculative RFI for 5 minutes after OOS data is detected 2022-10-06 21:20:44 -05:00
Cameron Gutman
9091238861 Add another predictive RFI detection technique 2022-10-06 01:17:37 -05:00
Cameron Gutman
5e1be51b84 Implement predictive RFI to recover more quickly from frame loss
With predictive RFI, we can recover from a lost frame as soon as the next frame
by predicting whether we will have enough FEC data to be be able to recover a
frame based on the sequence numbers of the received packets.
2022-10-05 22:04:22 -05:00
Cameron Gutman
9361c325bb Rename RtpFecQueue to RtpVideoQueue to match RtpAudioQueue 2021-06-01 22:57:26 -05:00