Maximum Framerate and Bitrate configuration

[OOOllie]

When using encoders such as H264 and MediaStreamTracks, the framerate is hard coded to be a maximum of 30FPS seen in h264.py
The same with bitrate means there is a bottleneck when trying to do real time high quality streaming. This should be added as a configuration option to suggest a maximum framerate and bitrate for users rather than these being static variables.

I currently have cloned the library and manually edited these values but this seems like a very bad work around, please add this as a feature to allow fast and configurable streaming.

Framerate at 60 after manually adjusting the variables which proves it is possible.
{
"id": "IT01V2421866841",
"timestamp": 1699286043229.511,
"type": "inbound-rtp",
"codecId": "CIT01_102_level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f",
"kind": "video",
"mediaType": "video",
"ssrc": 2421866841,
"transportId": "T01",
"jitter": 0.002,
"packetsLost": 0,
"packetsReceived": 1143,
"bytesReceived": 1062001,
"firCount": 0,
"frameHeight": 720,
"frameWidth": 1280,
"framesAssembledFromMultiplePackets": 105,
"framesDecoded": 105,
"framesDropped": 0,
"framesPerSecond": 60,
"framesReceived": 105,
"freezeCount": 0,
"headerBytesReceived": 27432,
"jitterBufferDelay": 0.8890619999999999,
"jitterBufferEmittedCount": 106,
"jitterBufferMinimumDelay": 1.622598,
"jitterBufferTargetDelay": 1.622598,
"keyFramesDecoded": 1,
"lastPacketReceivedTimestamp": 1699286043221.458,
"mid": "0",
"nackCount": 0,
"pauseCount": 0,
"pliCount": 0,
"qpSum": 2888,
"totalAssemblyTime": 0.030449999999999998,
"totalDecodeTime": 0.260561,
"totalFreezesDuration": 0,
"totalInterFrameDelay": 1.737,
"totalPausesDuration": 0,
"totalProcessingDelay": 1.146289,
"totalSquaredInterFrameDelay": 0.031158999999999985,
"trackIdentifier": "32b73e58-3533-4408-b4e2-cedadbd79b2c"
}

Before filing an issue please verify the following:

• Check whether there is already an existing issue for the same topic.
  I could not find any issue regarding this, the closest being one about the recv method not being called frequently enough or one suggested finding a hacky work around
• Ensure you are actually reporting an issue related to aiortc. The goal
  of the issue tracker is not to provide general guidance about WebRTC or free
  debugging of your code.
  This is a feature request related to aiortc rather than an issue with my code or debugging
• Clearly state whether the issue you are reporting can be reproduced with one
  of the examples provided with aiortc without any changes.
  Feature request rather than a bug
• Be considerate to the maintainers. aiortc is provided on a best-effort,
  there is no guarantee your issue will be addressed.

[jlaine]

Hacking the framerate in h264.py is only the tip of the iceberg here. A more fundamental issue is that:

• we have no idea what the actual framerate of the source (i.e. the MediaStreamTrack we're reading) is
• our bandwidth estimates are off if the actual framerate does not match the supposed 30fps
• we have no way of adjusting the source's framerate based on what was negociated

Do you have any pointers to what other implementations are doing to guide our overall architecture?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.