ضغط الفيديو
استهدف حجمًا بعينه — 10 ميجابايت لديسكورد، و25 للبريد — أو اخفض الجودة فحسب. كل الحساب يجري على جهازك، فلا حدّ للحجم ولا طابور انتظار.
متصفحك هو الذي يقرأ الملف ويعيد ترميزه. لا يُرسَل في أي طلب إلى أي مكان — فهذه الصفحة لا تملك خادمًا يُرفع إليه.
أسئلة
هل يصيب الحجم المطلوب فعلًا؟
لهذا وُجد وضع «اضبط على حجم». وزن الملف هو معدّل البت مضروبًا في المدة، فمتى عُرفت المدة صار معدّل البت المطلوب مسألة حسابية. المرمّزات لا تلتزم بمعدّل البت المطلوب تمامًا — إذ يتذبذب التحكم بالمعدّل تبعًا للمادة — فإن أخطأت التمريرة الأولى بأكثر من بضعة بالمئة، يُقاس الخطأ ويُعاد الترميز مرة واحدة بالرقم المصحَّح. عمليًا تستقر النتيجة على بُعد نقطتين مئويتين من الهدف.
لماذا 10 و16 و25 ميجابايت؟
لأنها الجدران التي يصطدم بها الناس فعلًا: 10 ميجابايت حدّ الرفع المجاني في ديسكورد، و16 في واتساب، و25 في جيميل ومعظم خوادم البريد، و50 في ديسكورد نيترو بيسك. تستهدف الأداة ما دون الحدّ مباشرة لا الحدّ نفسه، لأن ملفًا حجمه 10.0 ميجابايت يظل مرفوضًا أمام حدّ العشرة.
وإن كان الهدف مستحيلًا؟
تقول ذلك قبل أن تبدأ، وتذكر أصغر حجم صادق لذلك الفيديو. عصر ساعة من اللقطات في 10 ميجابايت يعني معدّل بت لا تصمد أمامه أي دقة: أداة تُخرج ملفًا لا يُشاهَد ثم تسمّي ذلك نجاحًا أسوأ من أداة ترفض.
كم سيصغر ملفي؟
يظهر التقدير قبل أن تضغط أي شيء، انطلاقًا من الإعدادات والمدة. اللقطات الخارجة توًّا من هاتف أو كاميرا تُسجَّل عادةً فوق حاجتها بكثير، وتقليصها بنسبة 60–90% أمر معتاد. أما ما ضُغط مرة من قبل فلم يبقَ لديه الكثير، والأداة تقارن ملفك بما تتطلبه دقته منطقيًا وتحذّرك حين تكون إعادة الترميز ستكبّره لا غير.
ما الذي يصغّر الفيديو حقًا؟
بكسلات أقل وبتات أقل لكل بكسل. الدقة هي الرافعة الفظة الموثوقة: النزول من 4K إلى 1080p يزيل ثلاثة أرباع البكسلات قبل الحديث عن الجودة أصلًا. ثم يقرّر معدّل البت كم من التفاصيل سينجو. إزالة الصوت تساعد قليلًا؛ فهو نادرًا ما يتجاوز بضعة بالمئة من ملف فيديو.
هل يُرفع إلى أي مكان؟
لا. كل شيء يعمل عبر WebCodecs في متصفحك، وهذا بالضبط ما يجعل الأمر عمليًا: رفع جيجابايت كي يعيد لك خادم 200 ميجابايت أبطأ من إنجاز العمل محليًا، ويترك لقطاتك في الطريق على قرص شخص آخر. لا حدّ للحجم ولا طابور ولا علامة مائية — لأنه لا يوجد خادم يفرضها.
الأدوات الأخرى
أضف هذا إلى مشروعك
Compressing video to a target file size — the same way this page does it, on the user's machine, with no server. Take the code, or hand the prompt to a coding agent.
// npm i mediabunny
import { Input, Output, Conversion, BlobSource, BufferTarget, Mp4OutputFormat, ALL_FORMATS } from 'mediabunny';
// Size is bitrate x duration, so a target size fixes the bitrate.
const OVERHEAD = 0.04; // container headers and packaging
const AUDIO_BITRATE = 128_000;
export async function compressToSize(file, targetBytes, { width } = {}) {
const input = new Input({ source: new BlobSource(file), formats: ALL_FORMATS });
const duration = await input.computeDuration();
// Aim under the wall: a file of exactly 10.00 MB is still refused by a 10 MB limit.
const aim = targetBytes * 0.96;
const videoBitrate = Math.max(
90_000,
Math.round((aim * 8 * (1 - OVERHEAD) - AUDIO_BITRATE * duration) / duration),
);
const output = new Output({ format: new Mp4OutputFormat(), target: new BufferTarget() });
const conversion = await Conversion.init({
input,
output,
video: {
...(width ? { width } : {}),
bitrate: videoBitrate,
hardwareAcceleration: 'prefer-hardware', // 180 fps vs 34 on an M5 at 1080p
},
audio: { bitrate: AUDIO_BITRATE },
});
if (!conversion.isValid) throw new Error('Cannot convert this file');
await conversion.execute();
return new Blob([output.target.buffer], { type: 'video/mp4' });
}
// Encoders drift, so measure and correct once if the first pass missed.
const blob = await compressToSize(file, 10 * 1024 * 1024);
console.log(blob.size / 1048576, 'MB'); Build me a video compressor that runs entirely in the browser — no upload, no server.
Requirements:
- Use the "mediabunny" npm package, which wraps WebCodecs. Do not use ffmpeg.wasm: it is ~30 MB and
needs SharedArrayBuffer, which requires COOP/COEP headers that break third-party scripts.
- Let the user target a file size (presets: 10 MB Discord, 16 MB WhatsApp, 25 MB email) as well as
picking a quality.
- To hit a size: size = bitrate x duration, so videoBitrate = (targetBytes * 8 * 0.96 - audioBitrate
* duration) / duration. Aim at 96% of the limit, because a file of exactly 10.00 MB is still
rejected by a 10 MB limit.
- Encoders do not obey a requested bitrate exactly. Measure the result; if it missed by more than 4%
or broke the limit, re-encode once with bitrate * (target / actual), damped to at most a halving
or doubling. Stop at two passes.
- Pass hardwareAcceleration: 'prefer-hardware'. Measured on an M5 at 1080p: 180 fps against 34 fps
for software, and the software encoder also overshot the requested bitrate by 3.5x.
- Show the estimated output size before encoding, and the real before/after afterwards.
- Refuse impossible targets up front: below about 90 kbps video is unwatchable, so if the target
cannot be met at that floor, say so and give the smallest honest size instead of producing junk.
- Warn when the source is already compressed below what its resolution needs — re-encoding it will
make it larger, and only reducing the resolution will help.
Reference implementation: https://life2film.com/tools/video-compressor/
The engine is documented for agents, and every tool page is available as
markdown by adding .md to its address.