"Incorrect" Video Resolution Detection in WebRTC Streams via Browser (OvenLiveKit) compared to OBS

[leporel]

Sunject:

When streaming via WebRTC through a browser (using OvenLiveKit with WSS or WHIP), the incoming video resolution is incorrectly detected as 640x360, even though the browser reports the source resolution as 1920x1080 (verified via getSettings()). However, when using OBS with WHIP, the resolution is detected correctly.

Key Details:

1. Browser Stream Info:

   • Track settings:

     JSON.stringify(ovenkit.inputStream.getVideoTracks()[0].getConstraints())
     // Output: '{"deviceId":{"exact":"..."}, "frameRate":{"exact":30}, "height":{"max":1080,"ideal":1080}, "width":{"max":1920,"ideal":1920}}'

   • Actual resolution from getSettings(): 1920x1080.
   • OME logs:

     Video Track #17: Public Name(Video_17) Variant Name(Video) Bitrate(1.30Mb) Codec(1,H264,none:0) BSF(H264_RTP_RFC_6184) Resolution(640x360) Framerate(25.00) KeyInterval(1/frame) SkipFrames(-1) BFrames(0) timebase(1/90000)
         Data  Track #18: Public Name(Data_18) Variant Name(Data) Codec(0,Unknown,none) BSF(Unknown) timebase(1/1000)
     

2. OME Encoding Configuration:

    	<Video>
    		<Name>video_normal_h264</Name>
    		<Codec>h264</Codec>
    		<Bitrate>5000000</Bitrate>
    		<Preset>medium</Preset>
    		<Profile>high</Profile>
    		<Modules>x264</Modules>
    	</Video>
    	<Video>
    		<Name>video_low_h264</Name>
    		<Codec>h264</Codec>
    		<Width>1600</Width>
    		
    		<Bitrate>2200000</Bitrate>
    		<Framerate>30.0</Framerate>
    		<Preset>medium</Preset>
    		<Modules>x264</Modules>
    	</Video>

   • Without explicit <Width>, the first encoded track defaults to 640x360 with poor quality.
   • Adding <Width>1920</Width> resolves the issue, but hardcoding is undesirable. And it seems to me that the quality is still worse.

3. Encoded Stream Output:

   Video Track #0: Resolution(640x360)  
   Video Track #1: Resolution(1600x900)  // Explicit `<Width>` in second profile  
   

4. Similar Issue: OvenLiveKit-Web #6 suggests SDP negotiation might misreport resolution.

Questions:

• How can we ensure the source resolution (1920x1080) is preserved without hardcoding <Width> in OME profiles?
• Client-side fixes: Has anyone successfully modified SDP offers (e.g., appendFmtp, imageattr) to enforce correct resolution?
• Despair: Is this a browser negotiation issue?

Any insights or workarounds are appreciated!

[leporel]

I also logged ovenkit.peerConnection -> getStats() -> reports and noticed that initially, the outbound-rtp has a resolution of 640x360, followed immediately by media-source with 1920x1080:

{
    "id": "OTsouq3v1V789268016",
    "timestamp": 1740886702808.764,
    "type": "outbound-rtp",
    "codecId": "COTsouq3v1_100_;level-asymmetry-allowed=1;max-fr=30;max-fs=8160;packetization-mode=1;profile-level-id=4D0029",
    "kind": "video",
    "mediaType": "video",
    "ssrc": 789268016,
    "transportId": "Tsouq3v1",
    "bytesSent": 373114,
    "packetsSent": 367,
    "active": true,
    "encoderImplementation": "OpenH264",
    "firCount": 0,
    "frameHeight": 360,
    "frameWidth": 640,
    "framesEncoded": 45,
    "framesPerSecond": 30,
    "framesSent": 45,
    "headerBytesSent": 14735,
    "hugeFramesSent": 1,
    "keyFramesEncoded": 1,
    "mediaSourceId": "SV114",
    "mid": "souq3v",
    "nackCount": 0,
    "pliCount": 0,
    "powerEfficientEncoder": false,
    "qpSum": 744,
    "qualityLimitationDurations": {
        "bandwidth": 1.947,
        "cpu": 0,
        "none": 0.02,
        "other": 0
    },
    "qualityLimitationReason": "bandwidth",
    "qualityLimitationResolutionChanges": 0,
    "remoteId": "RIV789268016",
    "retransmittedBytesSent": 0,
    "retransmittedPacketsSent": 0,
    "scalabilityMode": "L1T1",
    "targetBitrate": 5000000,
    "totalEncodeTime": 0.077,
    "totalEncodedBytesTarget": 0,
    "totalPacketSendDelay": 1.111802
}

...

{
    "id": "SV114",
    "timestamp": 1740886702808.764,
    "type": "media-source",
    "kind": "video",
    "trackIdentifier": "37f98d43-e15b-43a1-917b-e27ebae43aaa",
    "frames": 59,
    "framesPerSecond": 31,
    "height": 1080,
    "width": 1920
}

Over the time of 10-15 seconds, the outbound-rtp resolution gradually increases from 360p -> 540p -> 720p -> 1080p. However, OME does not react to this change, and the stream remains at the initial outbound-rtp resolution (640x360).

Is there a way to ensure OME updates the stream resolution in real-time as the outbound-rtp resolution improves or prevent this resolution grow and send first properly resolution?

PS:
After many hours of investigation, i found that during a screen capture stream - then outbound-rtp has "contentType": "screenshare", it also sets "qualityLimitationReason": "none" and uses the screen's native resolution in first time when get connected.

[getroot]

OME's encoder does not dynamically change the Output Resolution. This is fine for WebRTC playback, but not so good for HLS. If you really want it, you'll have to Bypass the encoding.

[leporel]

Found some solutions:

1. if set x-google-max-bitrate=5000;x-google-min-bitrate=2500;x-google-start-bitrate=4500; chrome start stream with native resolution
2. if set track.contentHint = "detail" or "text" (but in this case fps suffers)