Raise Cast Streaming mirroring to 1080p, retune bitrate range to match
User is moving to a faster (150 Mbps) network and wants 1080p. Raised build_video_pipeline_for_streaming and VideoParams::default() together (they must agree -- see caststream.rs's doc comment on why a resolution mismatch there is a protocol violation, not just soft video). Left build_video_pipeline (the HLS/DLNA path) at 720p -- that one's 1280x720 choice is about an older Default Media Receiver's decoder profile/level, unrelated to what's changing here. Bitrate ceiling raised from 4-8x scaling but deliberately not straight back up to the old 8 Mbps: real testing tonight showed the AIMD probe pins to whatever MAX_BITRATE_KBPS is for the entire session once estimated_bandwidth_bps() reports (unreliably -- flat ~20 Mbps most of a session that was visibly stuttering) that there's headroom, and 8 Mbps sustained was more than the previous network+receiver could hold. 6 Mbps is a solid target for 1080p30 on its own merits. MIN_BITRATE_KBPS bumped 1000->1500 to match (1080p needs more of a floor than 720p did before it's a wall of blocking artifacts).
This commit is contained in:
parent
1ee607b5e9
commit
a058482b39
3 changed files with 38 additions and 12 deletions
|
|
@ -29,14 +29,23 @@ use crate::daemon::DaemonCommand;
|
|||
/// `vah264enc` with, since [`bitrate_control_step`] treats it as the value
|
||||
/// already in effect at t=0.
|
||||
const INITIAL_BITRATE_KBPS: u32 = 4000;
|
||||
/// Never encode below this. 720p30 below roughly 1 Mbps is a wall of
|
||||
/// Never encode below this. 1080p30 below roughly 1.5 Mbps is a wall of
|
||||
/// blocking artifacts -- if the link genuinely can't carry that, dropping
|
||||
/// frames is a better failure mode than shipping unwatchable video.
|
||||
const MIN_BITRATE_KBPS: u32 = 1000;
|
||||
const MIN_BITRATE_KBPS: u32 = 1500;
|
||||
/// Never encode above this, regardless of how much headroom the estimator
|
||||
/// reports. Matches `VideoParams::default().max_bitrate_bps`, i.e. what the
|
||||
/// OFFER told the receiver to expect.
|
||||
const MAX_BITRATE_KBPS: u32 = 8000;
|
||||
/// OFFER told the receiver to expect -- see that constant's doc comment for
|
||||
/// why this is 6 Mbps and not higher: real hardware testing showed the AIMD
|
||||
/// probe below pinning to whatever this ceiling is for the *entire* session
|
||||
/// (the estimator it trusts read a suspiciously flat ~20 Mbps almost the
|
||||
/// whole time), and 8 Mbps sustained was more than the previous
|
||||
/// network+receiver could actually hold without repeated multi-second
|
||||
/// freezes. 6 Mbps is a solid target for 1080p30 on its own merits, not
|
||||
/// just a defensive number -- revisit upward only with real evidence this
|
||||
/// specific link+receiver can sustain more, not just because the estimator
|
||||
/// claims there's headroom.
|
||||
const MAX_BITRATE_KBPS: u32 = 6000;
|
||||
|
||||
pub struct CastMirrorSession {
|
||||
pipeline: gst::Pipeline,
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue