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.
* 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.
Add fall back logic to prevent edge case where SPS SPP is not included in the same packet and key IDR frame is mislabeled as P frame causing assertion error at validation.
* Use pthread for vita thread managment
* Add thread name to pthread and remove ipv6 from vita
* Fix inclusion of pthread.h so that it is only included on specific platforms (__vita__)
* Fix memory release in ThreadProc for psvita platform
---------
Co-authored-by: MetalfaceScout <logan.mathis@utahtech.edu>
Co-authored-by: Logan Mathis <33127568+MetalfaceScout@users.noreply.github.com>
The Wii U socket implementation has limited memory available. To support larger receive buffers, application memory needs to be provided.
To make sockets use this user memory the `SO_RUSRBUF` option needs to be set on the socket.
The `AsyncTerm` thread is never joined but its handle is immediately closed. This works fine on Windows, but causes issues on other platforms where threads need to be explicitly detached if never joined (pthread, wiiu).
This adds a new `PltDetachThread` function, which can be used instead of `PltCloseThread` to explictly detach a thread, requiring it to no longer be closed.
- Simplifies thread priority setup
- Sets a max socket buffer size of 0x20000 for the 3DS
- Fixes a bug with polling timeouts taking longer than intended
- Removes 3DS global socket definition
This allows the host to provide a 32-bit integer that will be sent
in the data of the ENet connect event, similar to X-SS-Ping-Payload
for video and audio.
The host can use this data to uniquely identify a client when IP
addresses are not stable across the various separate connections,
such as when the client is behind a Carrier-Grade NAT.
We currently scale bitrate based on both remote vs local, SDR vs HDR, and H.264 vs
HEVC vs AV1. This has led to a lot of user confusion wondering why the bitrate
doesn't seem to match their selection in some configurations.
In H.264 local streams, we will currently overshoot the selected bitrate by about
20% due to FEC, while remote streams will be right around the selected bitrate due
to remote-specific FEC bitrate adjustments.
HEVC and AV1 streams (as configured by most clients) basically behave similarly
between local and remote, since the codec bitrate adjustment factor of 75% is nearly
the same as the FEC bitrate adjustment factor of 80%. However, this adjustment was
only performed for SDR streams so local HDR streams would overshoot like H.264.
This change cleans up all this mess by using a single non-codec-specific video
bitrate adjustment for FEC in all cases. It also allows Sunshine to perform the FEC
adjustment on its end if the default FEC value of 20% has been overridden by the
user or if we implement dynamic FEC support in the future.
The net result is HEVC and AV1 SDR streams will only see a tiny bitrate increase,
but HDR and H.264 may see noticable 20% bitrate reductions that may require the
user to adjust their bitrate setting to reach the effective value they got before.
However, the new behavior should be more intuitive for users going forward since
changing codecs, using a VPN, or enabling HDR won't cause significant changes to the
video bitrate.
