mirror of
https://github.com/TheFunny/TelegramTwitterMediaBot.git
synced 2026-10-06 01:22:16 +00:00
feat(upload): give videos and animations Telegram's real 50 MB cap
One MAX_UPLOAD_BYTES (10 MiB) bounded every upload, but that is the *photo* limit: Telegram's own docs say sendVideo/sendAnimation/sendDocument take up to 50 MB, and RequestEntityTooLarge is "larger than 50 MB". So a 10-50 MB video that Telegram refused to fetch by URL was refused a download too, and a video has no smaller variant — the post was lost. The non-photo cap is now MAX_MEDIA_UPLOAD_BYTES, and such a body charges the process-wide budget for the length of the preparation (one 64 MiB unit covers the cap), since PREP_SLOTS alone no longer bounds their added RAM. A const test pins both caps against Telegram's numbers.
This commit is contained in:
@@ -23,8 +23,10 @@ use tempfile::NamedTempFile;
|
||||
pub const PHOTO_MAX_DIMENSION_SUM: u32 = 10000;
|
||||
/// Resize target with a safety margin so rounding cannot cross the cap.
|
||||
pub const PHOTO_TARGET_DIMENSION_SUM: u32 = 9900;
|
||||
/// Upload cap (bytes): files above this are not uploaded; the bot falls back
|
||||
/// to a smaller media URL instead.
|
||||
/// Photo upload cap (bytes): Telegram rejects a larger `sendPhoto`, so the bot
|
||||
/// falls back to a smaller media URL instead. Videos and animations have their
|
||||
/// own, larger cap — `send::upload::MAX_MEDIA_UPLOAD_BYTES` — and never become
|
||||
/// photos.
|
||||
pub const MAX_UPLOAD_BYTES: u64 = 10 * 1024 * 1024;
|
||||
/// Decode budget (bytes): a larger intermediate buffer is not worth the peak
|
||||
/// memory; the photo degrades to the smaller URL instead.
|
||||
@@ -32,9 +34,9 @@ pub(crate) const MAX_DECODE_BYTES: u64 = 512 * 1024 * 1024;
|
||||
/// Cap for *downloading* a photo in the send fallback, kept separate from the
|
||||
/// decode budget above: the whole body is buffered before it is processed, once
|
||||
/// per download slot in flight, while the decode budget is about a single
|
||||
/// buffer. Telegram's upload cap is 10 MiB, so a photo this large can only be
|
||||
/// sent after a downscale that its reduced variant serves just as well — over
|
||||
/// the cap the item degrades to the smaller URL
|
||||
/// buffer. Telegram's *photo* upload cap is 10 MiB, so a photo this large can
|
||||
/// only be sent after a downscale that its reduced variant serves just as
|
||||
/// well — over the cap the item degrades to the smaller URL
|
||||
/// (`FallbackError::MediaTooLarge`), it is never an error.
|
||||
pub(crate) const MAX_PHOTO_DOWNLOAD_BYTES: u64 = 32 * 1024 * 1024;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user