andrey/retina
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix redundancy in Timestamp docs

Browse Source
This commit is contained in:
Scott Lamb 2022-05-11 12:36:28 -07:00
parent a33ba9b8af
commit 200a93e905
1 changed files with 7 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/lib.rs
View File

@ -61,17 +61,18 @@ struct ReceivedMessage {
///
/// This couples together three pieces of information:
///
/// * The timestamp as an `i64`. In client use, its top bits should be inferred from wraparounds
/// of 32-bit RTP timestamps. The Retina client's policy is that timestamps that differ by more
/// than `i32::MAX` from previous timestamps are treated as backwards jumps.
///
/// * The codec-specific clock rate.
///
/// * The stream's starting time. In client use, this is often as received in the RTSP
/// `RTP-Info` header but may be controlled via [`crate::client::InitialTimestampPolicy`].
/// According to [RFC 3550 section 5.1](https://datatracker.ietf.org/doc/html/rfc3550#section-5.1), "the initial
/// value of the timestamp SHOULD be random".
///
/// * The codec-specific clock rate.
///
/// * The timestamp as an `i64`. In client use, its top bits should be inferred from wraparounds
/// of 32-bit RTP timestamps. The Retina client's policy is that timestamps that differ by more
/// than `i32::MAX` from previous timestamps are treated as backwards jumps. It's allowed for
/// a timestamp to indicate a time *before* the stream's starting point.
///
/// In combination, these allow conversion to "normal play time" (NPT): seconds since start of
/// the stream.
///
@ -80,11 +81,6 @@ struct ReceivedMessage {
/// many RTP servers violate this. The Retina client allows such violations unless
/// [`crate::client::PlayOptions::enforce_timestamps_with_max_jump_secs`] says otherwise.
///
/// In client use, the top bits should be inferred from wraparounds of 32-bit RTP timestamps.
/// The Retina client's policy is that timestamps that differ by more than `i32::MAX` from
/// previous timestamps are treated as backwards jumps. It's allowed for a timestamp to
/// indicate a time *before* the stream's starting point.
///
/// [`Timestamp`] can't represent timestamps which overflow/underflow `i64` can't be constructed or
/// elapsed times (`elapsed = timestamp - start`) which underflow `i64`. The client will return
/// error in these cases. This should rarely cause problems. It'd take ~2^32 packets (~4 billion)