> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# مفاهيم الفيديو: الحاوية والترميز Codec ومعدل البت
- URL: https://arabroot.io/articles/مفاهيم-الفيديو-للمبتدئين/
- Published: 2026-10-09T15:15:00.000Z
- Updated: 2026-10-14T07:41:33.000Z
- Description: ما الذي يحدد حجم ملف الفيديو وجودته، ولماذا يعمل ملف في متصفح ولا يعمل في آخر، مع تجربة حقيقية تقيس الفرق بين الترميزات.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, مجالات متخصصة, هوم لاب, الاستضافة الذاتية

يسجل هاتفك مقطع فيديو مدته دقيقة واحدة فتجد حجمه 150 ميغابايت، ثم ترسله في تطبيق محادثة فيصل إلى صديقك بحجم 10 ميغابايت ويبدو تقريباً بنفس الجودة، وترفع ملفاً آخر إلى موقعك فيعمل في Chrome ولا يعمل في Safari، أو يعمل الصوت وتبقى الشاشة سوداء. وقد يتساءل البعض: أليس الفيديو ملفاً واحداً بامتداد معروف مثل mp4؟ والإجابة أن الامتداد لا يقول لك إلا القليل، فداخل الملف عدة طبقات، وكل طبقة لها اسمها وإعداداتها، والمشكلة في الأمثلة أعلاه تأتي غالباً من طبقة لا يظهرها الامتداد.

في دليل [أنواع كاميرات المراقبة](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/#codec-lab) قارنا بسرعة بين H.264 وH.265 على مقطع موقف سيارات، وهنا نبني الصورة كاملة من البداية، وهذا المقال هو الأول في مرحلة [الفيديو والبث المباشر](https://arabroot.io/start/#stage-special)، وكل ما يأتي بعده من بث وتحويل ومنصات فيديو يعتمد على المفاهيم التي فيه. وسوف نناقش في هذا المقال ما يلي:

- ما هو الإطار Frame والدقة Resolution ومعدل الإطارات Frame Rate، وكم يبلغ حجم الفيديو قبل الضغط.
- معدل البت Bitrate وطرق التحكم فيه: الثابت CBR والمتغير VBR والجودة الثابتة CRF.
- الفرق بين الحاوية Container مثل MP4 وMKV وWebM وTS، والترميز Codec مثل H.264 وH.265 وVP9 وAV1 للصورة وAAC وOpus للصوت.
- الإطارات المفتاحية Keyframes ومجموعة الصور GOP، ولماذا يتأخر القفز إلى منتصف الفيديو أحياناً.
- تقليل دقة الألوان Chroma Subsampling باختصار، ثم الرخص وبراءات الاختراع، ودعم المتصفحات.
- تجربة عملية بأداة ffmpeg على مقطع من وكالة NASA في الملكية العامة: نقرأ مخرج ffprobe سطراً سطراً، ونضغط المقطع بعدة ترميزات ونقيس الحجم والجودة بمقياسي SSIM وVMAF، ونغير الفاصل بين الإطارات المفتاحية ونرى أثره على الحجم والقفز.

## الإطار والدقة ومعدل الإطارات

الفيديو في أبسط صوره هو صور ثابتة تعرض بسرعة واحدة بعد الأخرى، وكل صورة منها اسمها إطار Frame، والعين تراها حركة متصلة إذا كانت سريعة بما يكفي. ولكل إطار ثلاثة أرقام تحدد حجمه وشكله:

- **الدقة Resolution:** عدد البكسلات Pixels في عرض الإطار وارتفاعه، فدقة 1920×1080 التي تسمى 1080p أو Full HD فيها 2,073,600 بكسل، ودقة 3840×2160 التي تسمى 4K فيها أربعة أضعاف ذلك. وقد شرحنا البكسل والبكسلات الفرعية وكثافة الشاشة في [كيف تعمل الشاشة من الداخل](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%B4%D8%A7%D8%B4%D8%A9-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/).
- **معدل الإطارات Frame Rate:** عدد الإطارات في الثانية واختصاراً fps، وأشهر القيم 24 للسينما و25 و30 للتلفزيون و60 للألعاب والرياضة، وستجد كثيراً القيمة 29.97 وهي 30000/1001 من بقايا التلفزيون الأمريكي القديم، وهي القيمة الموجودة في المقطع الذي سوف نستخدمه في التجربة. ولا تخلط بينه وبين معدل التحديث Refresh Rate للشاشة، فالأول خاصية الملف والثاني خاصية الشاشة.
- **عمق اللون Bit Depth:** عدد البتات لكل قيمة لون، و8 بت هي الشائعة، و10 بت تستخدم مع HDR، وقد شرحنا البت والبايت في [الأنظمة العددية للمبرمجين](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%B9%D8%AF%D8%AF%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%AB%D9%86%D8%A7%D8%A6%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86/).

والآن لنحسب حجم الفيديو قبل أي ضغط، أي الفيديو الخام Raw Video. المقطع الذي سوف نستخدمه مدته 20 ثانية بدقة 1920×1080 و29.97 إطاراً في الثانية، أي 600 إطار، وكل بكسل يحتاج في الصيغة الشائعة yuv420p بايتاً ونصف بايت في المتوسط كما سيأتي في قسم الألوان، وبالتالي:

```text
bytes per frame  = 1920 × 1080 × 1.5      = 3,110,400 bytes (about 3.1 MB)
bytes per second = 3,110,400 × 29.97      = 93,218,688 bytes (about 93 MB/s, 746 Mbps)
20 seconds       = 3,110,400 × 600 frames = 1,866,240,000 bytes (about 1.87 GB)
```

أي أن عشرين ثانية فقط تأخذ قرابة 1.87 جيجابايت، ودقيقة واحدة أكثر من 5.5 جيجابايت، ولا يوجد اتصال انترنت منزلي يحمل 746 ميغابت في الثانية لكل مشاهد. وفي التجربة سوف نرى أن نفس العشرين ثانية تصبح 8.87 ميغابايت بترميز H.264، و2.01 ميغابايت بترميز AV1، دون فرق تلاحظه العين في أغلب المشاهد، وهذا هو عمل الترميز Codec. والصورة التالية تبين الفكرة:

![شريط فيلم من خمسة إطارات بأزمنة 0 و33 و67 و100 و133 ملي ثانية، وبجانبه إطار مكبر عليه شبكة البكسلات وأبعاده 1920 في 1080 أي 2,073,600 بكسل، وتحته حساب الحجم الخام 3.1 ميغابايت للإطار و93 ميغابايت للثانية و1.87 جيجابايت لعشرين ثانية، مقابل 8.87 ميغابايت بعد الضغط بترميز H.264 و2.01 ميغابايت بترميز AV1](https://arabroot.io/content/images/2026/10/video-basics-01-frames.webp)

الفيديو إطارات متتالية، وحجمها الخام أكبر من أن يرسل أو يخزن دون ضغط

## الترميز Codec: كيف يصغر الفيديو مئات المرات؟

الترميز Codec هو اختصار Coder/Decoder، أي الطريقة التي يضغط بها الفيديو عند الحفظ ويفك عند العرض، والفكرة الأساسية فيه أن أغلب ما في الإطار موجود في الإطار الذي قبله: السماء نفسها، والمبنى نفسه، والذي تغير جزء صغير يتحرك. لذلك لا يحفظ المرمز Encoder كل إطار كاملاً، وإنما يحفظ إطاراً كاملاً كل فترة، ثم يحفظ لما بعده الفرق فقط: هذه الكتلة من البكسلات انتقلت 4 بكسلات إلى اليمين، وهذه تغير لونها قليلاً. ثم يحذف من التفاصيل ما لا تلاحظه العين، وهذا هو الضغط مع الفقد Lossy Compression، ولذلك لا يعود الفيديو المضغوط مطابقاً للأصل أبداً، والسؤال دائماً هو كم فقدنا وهل يلاحظه المشاهد.

وأشهر ترميزات الصورة اليوم أربعة:

- [**H.264**](https://www.itu.int/rec/T-REC-H.264?ref=arabroot.io) واسمه أيضاً AVC، من الاتحاد الدولي للاتصالات ITU ومجموعة MPEG، وهو الأقدم والأوسع دعماً، فيعمل في كل متصفح وكل هاتف تقريباً، ولذلك ما زال الخيار الآمن عندما لا تعرف جهاز المشاهد.
- [**H.265**](https://www.itu.int/rec/T-REC-H.265?ref=arabroot.io) واسمه HEVC، وهو خليفة H.264 ويعطي حجماً أصغر بنفس الجودة، ولكن دعمه في المتصفحات غير ثابت كما سيأتي، ورخصه معقدة.
- [**VP9**](https://www.webmproject.org/vp9/?ref=arabroot.io) من Google، مفتوح ودون رسوم، وتستخدمه YouTube كثيراً، ويعمل في كل المتصفحات الحديثة.
- [**AV1**](https://aomediacodec.github.io/av1-spec/?ref=arabroot.io) من تحالف [Alliance for Open Media](https://aomedia.org/about/story/?ref=arabroot.io) واختصاراً AOMedia، الذي تأسس في 2015 لتطوير معايير مفتوحة بسياسة براءات اختراع دون رسوم Royalty-Free، ونشر AV1 في 2018 كأول مشاريعه، وهو الأحدث والأكفأ ضغطاً، وضغطه على المعالج أبطأ من H.264 بكثير كما سوف نرى.

وللصوت ترميزاته أيضاً، وأشهرها [AAC](https://www.mpeg.org/standards/MPEG-4/3/?ref=arabroot.io) من MPEG، وهو الصوت المعتاد مع H.264 في ملفات MP4، و[Opus](https://www.rfc-editor.org/rfc/rfc6716?ref=arabroot.io) المعرف في RFC 6716، وهو مفتوح ويستخدم في WebRTC وفي ملفات WebM، وفي التجربة سوف نرى أن Opus أعطى ملفاً أصغر من AAC بمعدل بت أقل.

## معدل البت Bitrate: الرقم الذي يحدد الحجم

معدل البت Bitrate هو كمية البيانات التي يحتاجها الفيديو لكل ثانية، ويقاس بالكيلوبت أو الميغابت في الثانية kbps وMbps، والعلاقة بينه وبين الحجم مباشرة: الحجم بالبايت يساوي معدل البت بالبت في الثانية مضروباً في المدة ومقسوماً على 8، فملف مدته 20 ثانية بمعدل 3.55 Mbps حجمه قرابة 8.87 ميغابايت. والسؤال الذي يجيب عنه كل إعداد ضغط هو: كيف نوزع هذه البتات على الثواني؟

الطريقة البسيطة هي أن نعطي كل ثانية نفس الكمية، وهذا هو معدل البت الثابت Constant Bitrate واختصاراً CBR. والمشكلة أن الثواني ليست متساوية في صعوبتها، فلقطة سماء زرقاء ثابتة لا تحتاج شيئاً تقريباً، ولحظة تغير المشهد Scene Cut تحتاج إطاراً كاملاً جديداً، فإذا أعطيت الاثنتين نفس الكمية فإما أن تهدر البتات على السماء أو تخنق لحظة التغيير فتظهر فيها المربعات Blocking. ولذلك ظهرت طريقتان أخريان:

- **معدل البت المتغير Variable Bitrate واختصاراً VBR:** تحدد متوسطاً وحداً أعلى، والمرمز يعطي المشاهد الصعبة أكثر من المتوسط والسهلة أقل منه، والحجم النهائي قريب من المتوسط الذي طلبته.
- **الجودة الثابتة Constant Rate Factor واختصاراً CRF:** لا تحدد معدل بت إطلاقاً، وإنما تحدد مستوى الجودة برقم، والمرمز يعطي كل مشهد ما يحتاجه ليصل إلى هذه الجودة، فالرقم الأصغر جودة أعلى وملف أكبر. وفي x264 القيمة الافتراضية 23، وفي [SVT-AV1](https://ffmpeg.org/ffmpeg-codecs.html?ref=arabroot.io) المدى من 0 إلى 63 والافتراضية 35، ولا تقارن رقم CRF بين ترميزين، فالرقم 30 في AV1 لا يعني ما يعنيه 30 في H.264.

متى تستخدم كل واحدة؟ CRF هي الأنسب عندما تحفظ ملفاً يشاهد لاحقاً، مثل مكتبة فيديو أو أرشيف، لأنك تهتم بالجودة ولا يهمك أن يختلف الحجم من مقطع إلى آخر. أما عندما يمر الفيديو في قناة محدودة، مثل بث مباشر إلى سيرفر أو شبكة اتصال معروفة السعة، فتحتاج CBR أو VBR بحد أعلى، والسبب أن ثانية واحدة تحتاج 5 ميغابت لا تمر في قناة سعتها 3 ميغابت مهما كانت جودتها. وسوف نرى الفرق بين الاثنين بالأرقام في التجربة.

## الحاوية Container: الصندوق الذي يحمل كل شيء

الحاوية Container هي صيغة الملف نفسه، أي الصندوق الذي توضع فيه المسارات Tracks: مسار الصورة المرمز بترميز ما، ومسار أو أكثر للصوت، وربما ترجمة Subtitles، ومعها بيانات وصفية Metadata مثل المدة والفهرس Index الذي يقول أين يبدأ كل جزء داخل الملف. والفرق بين الحاوية والترميز يشبه الفرق بين صندوق الشحن واللغة المكتوبة بها الأوراق داخله: تستطيع أن تنقل نفس الأوراق إلى صندوق آخر دون أن تترجمها، وهذا ما يسمى إعادة التغليف Remux، وتستطيع أن تترجمها إلى لغة أخرى وهذا إعادة الترميز Transcode، وهو أبطأ بكثير ويفقد شيئاً من الجودة في كل مرة.

![صندوق كبير مكتوب عليه Container ويحمل الامتدادات MP4 وMKV وWebM وTS، وداخله ثلاثة مسارات: مسار الصورة بترميز H.264 أو H.265 أو VP9 أو AV1، ومسار الصوت بترميز AAC أو Opus، ومسار الترجمة، وفوقها البيانات الوصفية والفهرس، وعلى اليمين سهمان: Remux ينقل المسارات إلى صندوق آخر في ثوان دون تغيير، وTranscode يعيد ضغط الصورة ببطء ويفقد شيئاً من الجودة](https://arabroot.io/content/images/2026/10/video-basics-02-container-codec.webp)

الحاوية صندوق والترميز لغة ما بداخله، وتغيير الصندوق أسرع بكثير من تغيير اللغة

وأشهر الحاويات التي سوف تقابلها:

| الحاوية | المعيار                                                                           | أين تستخدم                        | ما يجب أن تعرفه                                                                 |
| ------- | --------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------- |
| MP4     | [ISO/IEC 14496-14](https://www.mpeg.org/standards/MPEG-4/14/?ref=arabroot.io)     | الهواتف والمتصفحات ومنصات الفيديو | الأوسع دعماً، ونسختها المقسمة Fragmented MP4 تستخدم في البث                     |
| MKV     | [Matroska، RFC 9559](https://www.rfc-editor.org/rfc/rfc9559?ref=arabroot.io)      | الأرشيف والتحميل ومشغلات الوسائط  | تقبل تقريباً أي ترميز وأي عدد من المسارات، ودعمها في المتصفحات محدود            |
| WebM    | [مبنية على Matroska](https://www.webmproject.org/docs/container/?ref=arabroot.io) | الويب                             | تقبل VP8 وVP9 وAV1 للصورة وVorbis وOpus للصوت فقط                               |
| TS      | [MPEG-TS، ITU-T H.222.0](https://www.itu.int/rec/T-REC-H.222.0?ref=arabroot.io)   | البث التلفزيوني وHLS              | مصممة لبث لا نهاية له يمكن الدخول إليه من أي نقطة، وسوف نعود إليها في مقال البث |

ولاحظ أن المشكلة في المثال الذي بدأنا به، الملف الذي يعمل في متصفح ولا يعمل في آخر، غالباً ليست في الحاوية وإنما في الترميز داخلها، فملف MP4 فيه H.265 قد لا يعمل في متصفح يعمل فيه ملف MP4 آخر فيه H.264، والامتداد نفسه في الحالتين.

## الإطارات المفتاحية Keyframes ومجموعة الصور GOP

ذكرنا أن المرمز يحفظ إطاراً كاملاً كل فترة ثم الفروق بعده، وهذه الإطارات لها أسماء:

- **الإطار I أو الإطار المفتاحي Keyframe:** صورة كاملة لا تعتمد على أي إطار آخر، وفي H.264 يسمى الإطار المفتاحي الذي يبدأ منه الفك من الصفر IDR. وهو أكبر الإطارات حجماً.
- **الإطار P:** يحفظ الفرق عن إطار سابق، وهو أصغر بكثير.
- **الإطار B:** يحفظ الفرق عن إطار سابق وإطار لاحق معاً، وهو الأصغر، ولذلك ترتيب فك الإطارات في الملف ليس دائماً هو ترتيب عرضها.

والمسافة من إطار مفتاحي إلى الذي بعده تسمى مجموعة الصور Group of Pictures واختصاراً GOP، أو الفاصل بين الإطارات المفتاحية Keyframe Interval. وهنا نصل إلى سؤال يواجهه كل من بنى مشغل فيديو: لماذا يتأخر الفيديو عندما تقفز إلى الدقيقة 10؟ والإجابة أن المشغل لا يستطيع أن يعرض إطار P أو B وحده، لأنه مجرد فرق عن إطار آخر، فيجب أن يرجع إلى آخر إطار مفتاحي قبل النقطة التي طلبتها ويفك كل الإطارات من هناك حتى يصل إليها. فإذا كان الفاصل 10 ثوان وقفزت إلى الثانية 9.9، فقد يفك المشغل قرابة 300 إطار قبل أن يعرض لك الإطار الذي تريده.

![خطان زمنيان لنفس الفيديو مدته 20 ثانية: الأول فيه إطار مفتاحي I كل ثانيتين عند 0 و2 و4 و6 و8 و10 وما بعدها، والثاني فيه إطار مفتاحي عند 0 و10 فقط، وبينها إطارات P وB صغيرة. سهم يقفز إلى الثانية 9.9: في الخط الأول يبدأ الفك من الثانية 8 أي 57 إطاراً، وفي الثاني من الثانية 0 أي 297 إطاراً. وتحتهما الثمن: ملف الفاصل القصير 10.27 ميغابايت والطويل 8.76 ميغابايت](https://arabroot.io/content/images/2026/10/video-basics-03-gop.webp)

القفز يبدأ من آخر إطار مفتاحي قبل النقطة المطلوبة، فالفاصل الطويل يعني فكاً أطول

إذاً لماذا لا نجعل كل إطار مفتاحياً؟ لأن الإطار المفتاحي كبير، فكلما قصر الفاصل كبر الملف، وسوف نرى في التجربة أن الفاصل نصف ثانية جعل الملف أكبر بنحو 62% من الفاصل 10 ثوان. ولذلك القيمة المناسبة توازن بين الاثنين، وفي البث تحديداً لها قاعدة واضحة: توصية [مواصفات Apple لتأليف HLS](https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices?ref=arabroot.io) أن يكون هناك إطار مفتاحي كل ثانيتين، وأن يبدأ كل جزء من أجزاء البث بإطار IDR، وسوف نفهم السبب في مقال البث.

ويجدر الإشارة هنا إلى أن x264 يضع إطاراً مفتاحياً إضافياً عندما يتغير المشهد Scene Cut، حتى لو لم يصل إلى نهاية الفاصل، لأن الإطار الجديد مختلف تماماً عما قبله فلا فائدة من حفظه كفرق، وهذا يجعل أماكن الإطارات المفتاحية غير منتظمة، وهو أمر جيد للملف المحفوظ وسيئ للبث الذي يحتاج أجزاء متساوية، ولذلك يغلق الخيار `-sc_threshold 0` هذا السلوك كما سوف نرى.

## تقليل دقة الألوان Chroma Subsampling

العين البشرية أحسن في رؤية الإضاءة من رؤية الألوان، والترميزات تستغل ذلك: فبدل أن تحفظ لكل بكسل ثلاث قيم أحمر وأخضر وأزرق RGB، تحفظ الصورة بصيغة YUV أو YCbCr، أي قيمة إضاءة Luma واختصاراً Y لكل بكسل، وقيمتي لون Chroma واختصاراً Cb وCr تشترك فيهما مجموعة من البكسلات. وتكتب النسبة بثلاثة أرقام:

- **4:4:4:** لكل بكسل قيمة إضاءة وقيمتا لون، أي 3 بايتات للبكسل بعمق 8 بت، وهي مهمة لمشاركة الشاشة والنصوص الدقيقة.
- **4:2:2:** كل بكسلين متجاورين أفقياً يشتركان في قيمتي اللون، أي بايتان للبكسل، وتستخدم في الإنتاج التلفزيوني.
- **4:2:0:** كل أربعة بكسلات في مربع 2×2 تشترك في قيمتي اللون، أي بايت ونصف للبكسل، وهي الصيغة الشائعة في كل فيديو تشاهده تقريباً، واسمها في ffmpeg هو `yuv420p`، ومنها جاء الرقم 1.5 في حسابنا أعلاه.

![ثلاث شبكات من 4 في 2 بكسل: في 4:4:4 كل بكسل له نقطة إضاءة ونقطة لون، أي 3 بايتات للبكسل، وفي 4:2:2 كل بكسلين أفقيين يشتركان في نقطة لون واحدة، أي بايتان، وفي 4:2:0 كل مربع من أربعة بكسلات يشترك في نقطة لون واحدة، أي بايت ونصف، وتحتها أن yuv420p هي الصيغة الشائعة](https://arabroot.io/content/images/2026/10/video-basics-04-chroma.webp)

الإضاءة لكل بكسل، واللون مشترك بين البكسلات، وهذا وحده يوفر نصف البيانات قبل أي ضغط

وفي الغالب لن تغير هذا الإعداد، ولكن إذا ظهر لك نص أحمر رفيع على خلفية زرقاء بحواف مشوشة في تسجيل شاشة، فالسبب غالباً 4:2:0 وليس الترميز نفسه.

## الرخص وبراءات الاختراع: من يدفع لمن؟

الترميز ليس برنامجاً فقط وإنما مجموعة أفكار عليها براءات اختراع Patents، وأصحاب هذه البراءات يجمعونها في مجمعات براءات Patent Pools تبيع رخصاً لمن يصنع المرمزات والأجهزة. وهذا الأمر لا يهم المشاهد، ولكنه يهم من يبني تطبيقاً أو جهازاً أو منصة، وهو أحد أسباب اختلاف دعم المتصفحات:

| الترميز | الرخصة                                                                                                                                                         | ماذا يعني لك                                                                                                                                                                                                                                                  |
| ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| H.264   | براءات مملوكة، أشهر مجمعاتها [Via LA](https://www.via-la.com/licensing-programs/avc-h-264/?ref=arabroot.io)                                                    | بحسب [دليل MDN](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Video%5Fcodecs?ref=arabroot.io) لا يطلب مجمع Via LA رسوماً لبث فيديو H.264 على الانترنت إذا كان مجانياً للمشاهد، والرسوم على صانعي المرمزات والأجهزة، وقد تنطبق مجمعات أخرى |
| H.265   | أكثر من مجمع، منها [Via LA](https://www.via-la.com/licensing-programs/hevc-vvc/?ref=arabroot.io) و[Access Advance](https://accessadvance.com/?ref=arabroot.io) | الوضع أعقد، وهذا أحد أسباب تأخر دعمه في المتصفحات                                                                                                                                                                                                             |
| VP9     | مفتوح دون رسوم                                                                                                                                                 | تستخدمه دون رخصة                                                                                                                                                                                                                                              |
| AV1     | رخصة براءات AOMedia دون رسوم                                                                                                                                   | صمم ليكون بديلاً حديثاً لا يحتاج رسوماً، والشركات الأعضاء في التحالف من أكبر أصحاب البراءات                                                                                                                                                                   |
| AAC     | براءات مملوكة                                                                                                                                                  | بحسب [MDN](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio%5Fcodecs?ref=arabroot.io) لا تحتاج رخصة لبث محتوى AAC أو توزيعه، والرخصة على من يطور المرمز                                                                                |
| Opus    | مفتوح دون رسوم                                                                                                                                                 | تستخدمه دون رخصة                                                                                                                                                                                                                                              |

ولاحظ أن هذا الجدول ملخص للفهم وليس استشارة قانونية، فإذا كنت تبني منتجاً تجارياً يضغط الفيديو أو يصنع أجهزة، فارجع إلى صفحات المجمعات نفسها وإلى محاميك.

## أي ترميز يعمل في أي متصفح؟

هذا هو السؤال العملي الذي يحدد ما ترفعه إلى موقعك، والجدول التالي من [دليل ترميزات الفيديو في MDN](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Video%5Fcodecs?ref=arabroot.io) وصفحة [AV1 في Can I use](https://caniuse.com/av1?ref=arabroot.io) و[HEVC في Can I use](https://caniuse.com/hevc?ref=arabroot.io) وقت كتابة المقال:

| الترميز | الدعم                                                                                                                                                                                              |
| ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| H.264   | كل إصدارات Chrome وEdge وFirefox وSafari، وFirefox يعتمد على الترميز الموجود في نظام التشغيل                                                                                                       |
| VP9     | كل المتصفحات الحديثة                                                                                                                                                                               |
| AV1     | Chrome من الإصدار 70 وFirefox من 67 وEdge من 121، وSafari من الإصدار 17 دعماً جزئياً فقط على الأجهزة التي فيها فك AV1 بالعتاد، مثل أجهزة Mac بمعالج M3 وما بعده وiPhone 15 Pro وiPhone 16 وما بعده |
| H.265   | يختلف بحسب المتصفح ونظام التشغيل ووجود فك بالعتاد، فـ Chrome يدعمه على أجهزة فيها فك بالعتاد في Windows وLinux وChromeOS، وعلى كل الأجهزة في macOS وAndroid                                        |

والخلاصة العملية أن H.264 مع AAC في MP4 يعمل في كل مكان، فإذا أردت ملفاً واحداً لكل المشاهدين فهذا هو. وإذا أردت توفير الحجم فقدم AV1 أولاً مع نسخة H.264 احتياطية، والمتصفح يختار الأولى التي يستطيع تشغيلها من عنصر `<video>` بعدة مصادر `<source>`، وهذه هي الفكرة التي تتوسع في البث لتصبح عدة نسخ بعدة جودات.

## التجربة العملية: نفس المقطع بعدة ترميزات

سوف نستخدم [ffmpeg](https://ffmpeg.org/?ref=arabroot.io) وأداة الفحص [ffprobe](https://ffmpeg.org/ffprobe.html?ref=arabroot.io) داخل Container، والمقطع لقطات لصاروخ Artemis II على منصة الإطلاق 39B من [صفحة الملف في Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Sun%5Fsets%5Fon%5FFull%5FArtemis%5FII%5FStack%5Fat%5FLaunch%5FPad%5F39B%5Fbroll%5F%28SLS%5FKSC%5F01292026%5FART%5FII%5Fat%5FPad%5Fsunsetting%5Fbroll%29.webm?ref=arabroot.io)، وهو من وكالة NASA ومصنف في الملكية العامة Public Domain، و[إرشادات NASA للوسائط](https://www.nasa.gov/nasa-brand-center/images-and-media/?ref=arabroot.io) تذكر أن محتواها غير خاضع لحقوق النشر في الولايات المتحدة عموماً، مع ذكرها كمصدر وعدم استخدامه بشكل يوحي بتأييدها لمنتج، وشعارها نفسه محمي.

### تجهيز الأدوات والمقطع

نبني Docker Image صغيرة من Debian وننسخ إليها ffmpeg وffprobe المبنيين بشكل ثابت Static Build من [wader/static-ffmpeg](https://github.com/wader/static-ffmpeg?ref=arabroot.io) بالإصدار 9.0.2، لأنها تأتي مع المرمزات x264 وlibvpx وSVT-AV1 ومكتبة VMAF في ملف واحد. ملف `Dockerfile`:

```dockerfile
FROM debian:13.1
COPY --from=mwader/static-ffmpeg:9.0.2 /ffmpeg /ffprobe /usr/local/bin/
RUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates python3 bc fonts-dejavu-core && rm -rf /var/lib/apt/lists/*
WORKDIR /media
```

ثم نبني ال Image ونتأكد أن المرمزات والمقاييس التي نحتاجها موجودة:

```bash
docker build -t lab-video-tools:1 .
docker run --rm --name lab-video-check lab-video-tools:1 sh -c 'ffmpeg -hide_banner -version | head -1
ffmpeg -hide_banner -encoders 2>/dev/null | grep -E "libx264|libsvtav1|libvpx-vp9|libopus|aac "
ffmpeg -hide_banner -filters 2>/dev/null | grep -E "libvmaf|ssim "'
```

والمخرج سوف يكون كما يلي:

```text
ffmpeg version 9.0.2 Copyright (c) 2000-2026 the FFmpeg developers
 V....D libsvtav1            SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1)
 V....D libx264              libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
 V....D libvpx-vp9           libvpx VP9 (codec vp9)
 A....D aac                  AAC (Advanced Audio Coding)
 A....D libopus              libopus Opus (codec opus)
 .. libvmaf           VV->V      Calculate the VMAF between two video streams.
 TS ssim              VV->V      Calculate the SSIM between two video streams.
```

ثم نحمل المقطع الأصلي، وحجمه قرابة 162 ميغابايت:

```bash
mkdir -p media
curl -L -o media/artemis-src.webm "https://upload.wikimedia.org/wikipedia/commons/3/3a/Sun_sets_on_Full_Artemis_II_Stack_at_Launch_Pad_39B_broll_%28SLS_KSC_01292026_ART_II_at_Pad_sunsetting_broll%29.webm"
```

### قراءة مخرج ffprobe سطراً سطراً

قبل أن تضغط أي ملف، اسأل ffprobe عما بداخله:

```bash
docker run --rm --name lab-video-probe -v "$PWD/media:/media" lab-video-tools:1 ffprobe -hide_banner artemis-src.webm
```

والمخرج سوف يكون كما يلي:

```text
Input #0, matroska,webm, from 'artemis-src.webm':
  Metadata:
    COMPATIBLE_BRANDS: mp42mp41
    creation_time   : 2026-02-03T19:21:43.000000Z
    MAJOR_BRAND     : mp42
    MINOR_VERSION   : 0
    ENCODER         : Lavf61.7.100
  Duration: 00:05:24.55, start: 0.000000, bitrate: 3993 kb/s
  Stream #0:0(eng): Video: av1 (libdav1d) (Main), yuv420p(tv, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : ?Mainconcept Video Media Handler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc61.19.101 libsvtav1
      DURATION        : 00:05:24.524000000
  Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      HANDLER_NAME    : #Mainconcept MP4 Sound Media Handler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc61.19.101 libopus
      DURATION        : 00:05:24.552000000
```

في المخرج أعلاه لاحظ التالي:

- `Input #0, matroska,webm`: الحاوية، وffprobe يكتب matroska وwebm معاً لأن WebM مبنية على Matroska كما ذكرنا.
- `Metadata` الأولى بيانات الملف كله، و`MAJOR_BRAND: mp42` و`Mainconcept` في الأسفل تقول إن الملف كان في الأصل MP4 خرج من برنامج تحرير، ثم أعيد ترميزه إلى WebM قبل رفعه إلى Commons، والسطر `ENCODER` في كل مسار يقول بماذا: `libsvtav1` للصورة و`libopus` للصوت.
- `Duration: 00:05:24.55` المدة، و`bitrate: 3993 kb/s` متوسط معدل البت للملف كله، صورة وصوتاً، أي قرابة 4 Mbps.
- `Stream #0:0 ... Video: av1` مسار الصورة بترميز AV1، و`(libdav1d)` اسم مكتبة الفك التي سيستخدمها ffmpeg، و`(Main)` هو ال Profile، أي مجموعة الأدوات المسموحة من المعيار.
- `yuv420p(tv, bt709, progressive)`: صيغة البكسل 4:2:0 بعمق 8 بت، و`tv` تعني أن القيم في المدى المحدود للتلفزيون من 16 إلى 235 وليس من 0 إلى 255، و`bt709` هو معيار الألوان للفيديو عالي الدقة، و`progressive` أن الإطار يرسم كاملاً وليس بنصفين متداخلين Interlaced.
- `3840x2160 [SAR 1:1 DAR 16:9]`: الدقة 4K، ونسبة البكسل Sample Aspect Ratio واحد إلى واحد أي بكسلات مربعة، ونسبة العرض Display Aspect Ratio هي 16:9.
- `29.97 fps, 29.97 tbr, 1k tbn`: معدل الإطارات، وال tbn هو وحدة الزمن Time Base في الحاوية، أي أن الأزمنة مخزنة بالملي ثانية.
- `Stream #0:1 ... Audio: opus, 48000 Hz, stereo`: الصوت بترميز Opus بمعدل عينات 48 كيلوهرتز وقناتين، و`fltp` أن العينات بعد الفك أرقام عشرية Floating Point في مستويات منفصلة لكل قناة.

وقد يتساءل البعض: إذا كان الملف 4K بمعدل 4 Mbps فقط، فكيف يبدو بهذه الجودة؟ والسبب أنه AV1، وأن أغلب اللقطات من حامل ثابت والسماء صافية، وسوف نرى بالأرقام كم يوفر AV1 بعد قليل.

### تغيير الحاوية دون إعادة الترميز

نأخذ 20 ثانية من الدقيقة الأولى، ثم ننقل نفس المسارين إلى MKV وMP4 بالخيار `-c copy`، أي دون إعادة ترميز، ثم نحاول وضع ملف H.264 في WebM عمداً. ملف `remux.sh`:

```bash
#!/bin/sh
# Change the container without touching the codec (-c copy), then try a pair WebM does not accept
cd /media
ffmpeg -hide_banner -v error -y -ss 66 -t 20 -i artemis-src.webm -c copy clip.webm
ffmpeg -hide_banner -v error -y -i clip.webm -c copy clip.mkv
ffmpeg -hide_banner -v error -y -i clip.webm -c copy clip.mp4
for f in clip.webm clip.mkv clip.mp4; do
  printf "%-10s %9d bytes  " $f $(stat -c %s $f)
  ffprobe -v error -show_entries stream=codec_name -of csv=p=0 $f | tr '\n' ' '; echo
done
ffmpeg -hide_banner -v error -y -i h264-crf23.mp4 -c copy wrong.webm
```

والمخرج سوف يكون كما يلي (ملف `h264-crf23.mp4` من الخطوة التالية):

```text
clip.webm   35279160 bytes  av1 opus
clip.mkv    35279267 bytes  av1 opus
clip.mp4    35288815 bytes  av1 opus
[webm @ 0x7fc5b5b5d840] Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM.
[out#0/webm @ 0x7fc5b5b5c440] Could not write header (incorrect codec parameters ?): Invalid argument
```

في المخرج أعلاه لاحظ التالي:

- الملفات الثلاثة بنفس الحجم تقريباً، والفرق بضعة كيلوبايتات هي ترويسات كل حاوية وفهرسها، والمساران `av1 opus` كما هما، وتمت العملية في ثوان لأن ffmpeg لم يفك أي إطار، وإنما نقل البيانات من صندوق إلى صندوق.
- محاولة وضع H.264 في WebM فشلت، والرسالة تقول بالضبط ما تقبله WebM: VP8 أو VP9 أو AV1 للصورة وVorbis أو Opus للصوت، فإذا رأيت هذه الرسالة فلا تغير الامتداد، وإنما غير الحاوية إلى MP4 أو أعد الترميز.
- الخيار `-ss 66 -t 20` مع `-c copy` يقص من أقرب إطار مفتاحي، وليس من الثانية 66 بالضبط، وسوف نفهم السبب في قسم الإطارات المفتاحية من التجربة.

### نفس العشرين ثانية بخمسة إعدادات

حتى تكون المقارنة عادلة نحتاج مرجعاً بلا فقد، فنصغر المقطع إلى 1920×1080 ونحفظه بترميز FFV1 الذي لا يفقد شيئاً Lossless، مع 600 إطار بالضبط، وهذا هو الملف الذي نقيس عليه كل نسخة:

```bash
docker run --rm --name lab-video-ref -v "$PWD/media:/media" lab-video-tools:1 sh -c 'ffmpeg -hide_banner -v error -y -ss 66 -i artemis-src.webm -frames:v 600 -t 20.02 -vf scale=1920:1080:flags=lanczos -fps_mode cfr -r 30000/1001 -c:v ffv1 -level 3 -c:a flac ref.mkv && ffprobe -v error -count_frames -select_streams v -show_entries stream=nb_read_frames,start_time -of compact ref.mkv'
```

```text
stream|start_time=0.000000|nb_read_frames=600
```

وحجم هذا المرجع 382 ميغابايت، أي أن FFV1 دون فقد ضغط الفيديو الخام من 1.87 جيجابايت إلى الخمس تقريباً، وهذا هو أقصى ما تصل إليه دون أن تحذف شيئاً. ثم نضغط المرجع خمس مرات، ونقيس لكل نسخة الحجم ومعدل البت ومقياسين للجودة:

- **SSIM:** مقياس التشابه البنيوي Structural Similarity، من 0 إلى 1، و1 تعني تطابقاً تاماً.
- [**VMAF**](https://github.com/Netflix/vmaf?ref=arabroot.io)**:** مقياس إدراكي Perceptual طورته Netflix من 0 إلى 100، صمم ليقترب من حكم المشاهد على الجودة، لذلك هو أقرب إلى ما تراه العين من SSIM.

ملف `codecs.sh`:

```bash
#!/bin/sh
# The same 20 s clip, video only, with different codecs and quality settings
cd /media
enc() {
  name=$1; shift
  start=$(date +%s.%N)
  ffmpeg -hide_banner -v error -y -i ref.mkv -an "$@" "$name"
  end=$(date +%s.%N)
  size=$(stat -c %s "$name")
  m=$(ffmpeg -hide_banner -i "$name" -i ref.mkv -lavfi "[0:v]setpts=N/FRAME_RATE/TB,split[a1][a2];[1:v]setpts=N/FRAME_RATE/TB,split[b1][b2];[a1][b1]libvmaf=n_threads=8;[a2][b2]ssim" -f null - 2>&1)
  vmaf=$(echo "$m" | grep -o "VMAF score: [0-9.]*" | cut -d" " -f3)
  ssim=$(echo "$m" | grep -o "All:[0-9.]*" | cut -d: -f2)
  printf "%-15s %6.2f MB %5.2f Mbps  SSIM %.4f  VMAF %5.2f  %4.0f s\n" "$name" \
    $(echo "$size/1000000" | bc -l) $(echo "$size*8/20/1000000" | bc -l) "$ssim" "$vmaf" $(echo "$end-$start" | bc -l)
}
enc h264-crf23.mp4 -c:v libx264 -preset medium -crf 23
enc vp9-crf33.webm -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 -cpu-used 2
enc av1-crf30.mp4  -c:v libsvtav1 -preset 6 -crf 30
enc av1-crf38.mp4  -c:v libsvtav1 -preset 6 -crf 38
enc av1-crf46.mp4  -c:v libsvtav1 -preset 6 -crf 46
```

```bash
docker run --rm --name lab-video-codecs -v "$PWD/media:/media" lab-video-tools:1 sh -c 'sh /media/codecs.sh 2>/dev/null'
```

والمخرج سوف يكون كما يلي:

```text
h264-crf23.mp4    8.87 MB  3.55 Mbps  SSIM 0.9928  VMAF 95.84   116 s
vp9-crf33.webm   10.41 MB  4.16 Mbps  SSIM 0.9927  VMAF 96.73   269 s
av1-crf30.mp4     8.78 MB  3.51 Mbps  SSIM 0.9942  VMAF 97.31   198 s
av1-crf38.mp4     3.62 MB  1.45 Mbps  SSIM 0.9923  VMAF 96.32   207 s
av1-crf46.mp4     2.01 MB  0.80 Mbps  SSIM 0.9905  VMAF 95.59   173 s
```

![رسم أعمدة لحجم الملف بالميغابايت لخمس نسخ من نفس المقطع، وفوق كل عمود درجة VMAF: H.264 بقيمة CRF 23 حجمه 8.87 ودرجته 95.84، وVP9 بقيمة CRF 33 حجمه 10.41 ودرجته 96.73، وAV1 بقيمة CRF 30 حجمه 8.78 ودرجته 97.31، وAV1 بقيمة CRF 38 حجمه 3.62 ودرجته 96.32، وAV1 بقيمة CRF 46 حجمه 2.01 ودرجته 95.59، مع خط يبين أن آخر نسخة بنفس جودة H.264 تقريباً وبربع حجمها](https://arabroot.io/content/images/2026/10/video-basics-05-codec-results.webp)

نفس الجودة تقريباً بربع الحجم: AV1 بقيمة CRF 46 مقابل H.264 بقيمة CRF 23 على هذا المقطع

في المخرج أعلاه لاحظ التالي:

- ملف AV1 بقيمة CRF 46 حجمه 2.01 ميغابايت ودرجته 95.59، وملف H.264 بقيمة 23 حجمه 8.87 ميغابايت ودرجته 95.84، أي نفس الجودة تقريباً بأقل من ربع الحجم، وملف AV1 بقيمة 38 أصغر من H.264 بنحو 59% وجودته أعلى.
- رقم CRF لا يقارن بين الترميزات، فقيمة 30 في AV1 أعطت حجماً قريباً من 23 في H.264 بجودة أعلى، و33 في VP9 أعطت الملف الأكبر، وكل ترميز يحتاج أن تجرب عليه عدة قيم وتقيس.
- بين AV1 بقيمة 30 و46 ضاعت 1.7 درجة VMAF مقابل توفير أكثر من 75% من الحجم، وهذا ما يجعل الفيديو تجارة بين الحجم والجودة، والمقياس يساعدك أن تختار النقطة المناسبة لمحتواك بدل التخمين.
- الوقت في العمود الأخير للضغط فقط، على جهاز واحد مشغول بأعمال أخرى، لذلك هو للمقارنة النسبية فقط، والواضح منه أن VP9 وAV1 أبطأ من H.264 بكثير على المعالج، وأن هذا الثمن تدفعه مرة واحدة عند الضغط، والتوفير في الحجم تكسبه في كل مشاهدة.
- المقطع لقطات هادئة من حامل ثابت، والنتائج على محتوى آخر، مثل مباراة كرة قدم أو لعبة سريعة، ستكون مختلفة، لذلك قس على عينة من محتواك أنت قبل أن تختار.

⚠️

عند حساب VMAF أو SSIM يجب أن يقارن المقياس كل إطار بنظيره بالضبط، فإذا اختلفت أزمنة الإطارات بين الملفين قارن إطاراً بإطار آخر، وسوف تحصل على أرقام منخفضة جداً لا معنى لها. لذلك أضفنا `setpts=N/FRAME_RATE/TB` لكلا الملفين، وهو يعيد ترقيم الأزمنة من رقم الإطار، وتأكدنا أن المرجع فيه 600 إطار بالضبط.

### الفاصل بين الإطارات المفتاحية: الحجم مقابل القفز

الآن نثبت كل شيء ونغير الفاصل فقط: إطار مفتاحي كل 15 إطاراً أي نصف ثانية، وكل 60 أي ثانيتين، وكل 300 أي 10 ثوان، ونسخة رابعة بإعداد x264 الافتراضي. ملف `keyframes.sh`:

```bash
#!/bin/sh
# Keyframe interval: the same clip and CRF, with a keyframe every 15, 60 and 300 frames, and x264's default
cd /media
for g in 15 60 300; do
  ffmpeg -hide_banner -v error -y -i ref.mkv -an -c:v libx264 -preset medium -crf 23 \
    -g $g -keyint_min $g -sc_threshold 0 gop$g.mp4
done
ffmpeg -hide_banner -v error -y -i ref.mkv -an -c:v libx264 -preset medium -crf 23 gopdefault.mp4
for f in gop15.mp4 gop60.mp4 gop300.mp4 gopdefault.mp4; do
  keys=$(ffprobe -v error -select_streams v -skip_frame nokey -show_entries frame=pts_time -of default=nw=1:nk=1 $f)
  printf "%-15s %5.2f MB  keyframes %2d  at: %s\n" $f $(echo "$(stat -c %s $f)/1000000" | bc -l) \
    $(echo "$keys" | wc -l) "$(echo $keys | cut -c1-60)"
done
```

والمخرج سوف يكون كما يلي:

```text
gop15.mp4       14.15 MB  keyframes 40  at: 0.000000 0.500500 1.001000 1.501500 2.002000 2.502500 3.0030
gop60.mp4       10.27 MB  keyframes 10  at: 0.000000 2.002000 4.004000 6.006000 8.008000 10.010000 12.01
gop300.mp4       8.76 MB  keyframes  2  at: 0.000000 10.010000
gopdefault.mp4   8.87 MB  keyframes  4  at: 0.000000 4.938267 13.279933 18.752067
```

في المخرج أعلاه لاحظ التالي:

- نفس CRF ونفس المقطع، والفرق في الحجم كله من الإطارات المفتاحية: 40 إطاراً مفتاحياً جعلت الملف 14.15 ميغابايت، وإطاران فقط جعلاه 8.76، أي أن الفاصل نصف ثانية كلف قرابة 62% زيادة في الحجم.
- الخيار `-skip_frame nokey` يجعل ffprobe يقرأ الإطارات المفتاحية فقط، وهي طريقة سريعة لتعرف أين يمكن القفز في أي ملف.
- الإعداد الافتراضي وضع إطارات مفتاحية عند 4.94 و18.75، وهما لحظتا تغير المشهد في المقطع، وهذا ما يسمى الكشف عن تغير المشهد Scene Cut Detection، لذلك الأماكن غير منتظمة، وهذا ما أغلقناه بالخيار `-sc_threshold 0` في النسخ الثلاث الأولى، وهو ما يحتاجه البث.

ثم نقيس ثمن الفاصل الطويل، فنطلب من ffmpeg الإطار عند الثانية 9.9 بالضبط من كل ملف، خمس مرات، ونقرأ الوقت الحقيقي من الخيار `-benchmark`. ملف `seek.sh`:

```bash
#!/bin/sh
# How long does it take to show the frame at 9.9 s? (accurate seek, 5 runs each)
cd /media
for f in gop15.mp4 gop60.mp4 gop300.mp4; do
  t=""
  for i in 1 2 3 4 5; do
    r=$(ffmpeg -hide_banner -benchmark -ss 9.9 -i $f -frames:v 1 -f null - 2>&1 | grep -o "rtime=[0-9.]*" | cut -d= -f2)
    t="$t $r"
  done
  echo "$f seconds:$t"
done
```

والمخرج سوف يكون كما يلي:

```text
gop15.mp4 seconds: 0.648 0.496 0.412 0.284 0.254
gop60.mp4 seconds: 0.611 1.627 0.692 0.811 0.677
gop300.mp4 seconds: 1.889 2.317 2.342 2.248 3.075
```

في الملف الأول يرجع ffmpeg إلى الإطار المفتاحي عند 9.51 ويفك قرابة 12 إطاراً، وفي الثاني يرجع إلى 8.01 ويفك قرابة 57، وفي الثالث يرجع إلى البداية ويفك قرابة 297 إطاراً، لذلك احتاج قرابة ثانيتين أو أكثر في كل مرة. والأرقام تتذبذب لأن الجهاز كان يشغل أعمالاً أخرى، ولكن الترتيب ثابت في كل محاولة، وهو نفس ما يحدث في مشغل المتصفح عندما تسحب شريط التقدم.

### CBR مقابل CRF: كم بتاً تأخذ كل ثانية؟

نضغط المقطع بمعدل ثابت 3500 kbps، وهو قريب من متوسط ملف CRF 23، ثم نجمع حجم الحزم Packets في كل ثانية للملفين. ملف `rate.sh`:

```bash
#!/bin/sh
# Constant bitrate against CRF at about the same average: how many kilobits does each second carry?
cd /media
ffmpeg -hide_banner -v error -y -i ref.mkv -an -c:v libx264 -preset medium -b:v 3500k \
  -maxrate 3500k -bufsize 1750k -x264-params nal-hrd=cbr cbr.ts
for f in h264-crf23.mp4 cbr.ts; do
  ffprobe -v error -select_streams v -show_entries packet=dts_time,size -of csv=p=0 $f |
    awk -F, -v f=$f 'NR==1 {t0=$1} {s=int($1-t0); b[s]+=$2*8} END {printf "%-15s", f; for (i=0;i<20;i++) printf " %4d", b[i]/1000; print ""}'
done
```

والمخرج سوف يكون كما يلي، وكل رقم هو الكيلوبت في ثانية من الثانية 0 إلى 19:

```text
h264-crf23.mp4  2971 1548 1960 1847 4043 3933 5330 4355 5010 3972 4472 3582 3245 4698 3265 4080 3776 4193 3050 1578
cbr.ts          3495 3338 3659 3350 4663 2346 3635 3374 3660 3349 3672 3358 3600 3573 3319 3773 3236 3711 3931 2880
```

![رسم بخطين لمعدل البت في كل ثانية من الثانية 0 إلى 19: خط CRF 23 يتحرك من 1548 kbps في اللقطة الهادئة إلى 5330 kbps في اللقطة الصعبة، وخط CBR بقيمة 3500 kbps يبقى قريباً من 3300 إلى 3900 مع قفزة واحدة إلى 4663 عند تغير المشهد في الثانية 4.94](https://arabroot.io/content/images/2026/10/video-basics-06-cbr-crf.webp)

CRF يعطي كل ثانية ما تحتاجه، وCBR يبقي القناة قريبة من نفس المعدل

في المخرج أعلاه لاحظ التالي:

- ملف CRF أعطى الثواني الهادئة في البداية والنهاية قرابة 1500 kbps، وأعطى الثانية السادسة 5330، أي أنه وزع البتات بحسب صعوبة المشهد، وهذا سبب جودته الأعلى بنفس المتوسط.
- ملف CBR بقي بين 3236 و3931 في أغلب الثواني، ما عدا الثانية الرابعة 4663 والخامسة 2346، وهي لحظة تغير المشهد عند 4.94: المرمز أخذ أكثر من المعدل للإطار الجديد ثم عوضه في الثانية التالية، فالمعدل الثابت ثابت على مدى المخزن المؤقت Buffer الذي حددناه بالخيار `-bufsize`، وليس على كل ثانية بالضبط.
- حفظنا ملف CBR بحاوية TS، وهي الحاوية المعتادة في البث بمعدل ثابت، والخيار `nal-hrd=cbr` يجعل x264 يضيف بيانات حشو Filler حتى يبقى المعدل ثابتاً عندما لا يحتاج المشهد كل البتات.

### والصوت: AAC مقابل Opus

آخر خطوة سريعة: نفس العشرين ثانية من الصوت دون ضغط WAV، ثم AAC بمعدل 128 kbps، ثم Opus بمعدل 96 kbps:

```bash
docker run --rm --name lab-video-audio -v "$PWD/media:/media" lab-video-tools:1 sh -c 'ffmpeg -hide_banner -v error -y -i ref.mkv -vn -c:a aac -b:a 128k a.m4a; ffmpeg -hide_banner -v error -y -i ref.mkv -vn -c:a libopus -b:a 96k a.opus; ffmpeg -hide_banner -v error -y -i ref.mkv -vn -c:a pcm_s16le a.wav; for f in a.wav a.m4a a.opus; do printf "%-7s %8d bytes  " $f $(stat -c %s $f); ffprobe -v error -show_entries stream=codec_name,sample_rate,channels -of csv=p=0 $f; done'
```

```text
a.wav    3843918 bytes  pcm_s16le,48000,2
a.m4a     232464 bytes  aac,48000,2
a.opus    178366 bytes  opus,48000,2
```

الصوت الخام 48000 عينة في الثانية لقناتين بحجم 2 بايت للعينة، أي 192,000 بايت في الثانية، و3.84 ميغابايت في عشرين ثانية، وAAC جعله 232 كيلوبايت وOpus جعله 178 كيلوبايت. ولاحظ أن الصوت بعد الضغط أصغر بكثير من الصورة، فهو قرابة 2% من حجم ملف H.264 نفسه، لذلك لا يستحق أن توفر فيه على حساب الجودة.

### تنظيف التجربة

كل Container في التجربة كان بالخيار `--rm` فحذف نفسه عند انتهائه، وبقي ال Image والملفات، فنحذفهما بالاسم:

```bash
docker image rm lab-video-tools:1 mwader/static-ffmpeg:9.0.2
rm -rf media
```

## أخطاء شائعة

- **الحكم على الملف من امتداده:** ملف `.mp4` قد يكون فيه H.264 أو H.265 أو AV1، فإذا لم يعمل في جهاز ما فابدأ بالأمر `ffprobe` وانظر إلى سطر `Video:` قبل أي شيء.
- **إعادة الترميز عندما يكفي تغيير الحاوية:** إذا كان الترميز مدعوماً والمشكلة في الحاوية فقط، فالخيار `-c copy` ينهي المهمة في ثوان دون أي فقد، أما إعادة الترميز فتفقد شيئاً من الجودة في كل مرة.
- **رفع معدل البت لتحسين ملف سيئ أصلاً:** ما فقد في الضغط الأول لا يعود، وإعادة ضغط ملف سيئ بمعدل أعلى تعطيك ملفاً أكبر بنفس العيوب، فارجع دائماً إلى أفضل نسخة أصلية عندك.
- **مقارنة رقم CRF بين ترميزين:** كما رأينا، 30 في AV1 ليست 30 في H.264، فقارن بالحجم والمقياس على نفس المقطع.
- **فاصل إطارات مفتاحية طويل في فيديو يحتاج القفز أو البث:** القفز يصبح بطيئاً، والبث لا يستطيع تقسيم الفيديو إلى أجزاء متساوية، والقيمة المعتادة ثانيتان.
- **الاعتماد على AV1 وحده لكل المشاهدين:** الدعم واسع ولكنه ليس كاملاً، خاصة على أجهزة Apple الأقدم، فقدم معه نسخة H.264.

## تدريب عملي

- صور مقطعاً بهاتفك، واقرأه بالأمر `ffprobe`، وحدد الحاوية والترميز والدقة ومعدل الإطارات ومعدل البت، ثم اضغطه بترميز AV1 بقيمتين مختلفتين لـ CRF وقارن الحجم ودرجة VMAF كما فعلنا.
- استخرج من ملف `gopdefault.mp4` المقطع من الثانية 7 إلى 12 مرة بالخيار `-c copy` ومرة بإعادة الترميز، وقارن المدة الفعلية لكل ملف بالأمر `ffprobe`، ثم فسر الفرق بأماكن الإطارات المفتاحية في المخرج أعلاه.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- الفيديو إطارات متتالية، والدقة ومعدل الإطارات تحدد حجمه الخام، وعشرون ثانية بدقة 1080p تأخذ قرابة 1.87 جيجابايت قبل الضغط.
- الحاوية Container هي الصندوق، مثل MP4 وMKV وWebM وTS، والترميز Codec هو طريقة ضغط ما بداخله، مثل H.264 وH.265 وVP9 وAV1 للصورة وAAC وOpus للصوت، وتغيير الحاوية بالخيار `-c copy` سريع ودون فقد.
- معدل البت يحدد الحجم، وCRF يحفظ الجودة ويترك الحجم يتغير، وCBR يثبت المعدل لقناة محدودة، وVBR بينهما.
- الإطار المفتاحي صورة كاملة، والقفز يبدأ من آخر إطار مفتاحي، والفاصل القصير يسرع القفز ويكبر الملف، وثانيتان هي القيمة المعتادة في البث.
- في تجربتنا أعطى AV1 نفس جودة H.264 تقريباً بأقل من ربع الحجم، مقابل ضغط أبطأ بكثير، وH.264 مع AAC في MP4 يبقى الملف الذي يعمل في كل مكان.
- H.264 وH.265 وAAC عليها براءات مملوكة، وVP9 وAV1 وOpus مفتوحة دون رسوم، وهذا يؤثر على دعم المتصفحات وعلى ما تختاره لمنتجك.

وفي المقال التالي بإذن الله نأخذ هذه الملفات إلى المشاهد: كيف يقسم الفيديو إلى أجزاء بعدة جودات، وكيف يختار المشغل بينها بحسب سرعة الاتصال، ولماذا يتأخر البث المباشر.

[![](https://arabroot.io/content/images/2026/10/streaming-concepts-cover-cover.webp)دليلكيف يعمل بث الفيديو المباشر وعند الطلب؟كيف يصل الفيديو إلى كل مشاهد بجودة تناسب سرعة اتصاله، ولماذا يتأخر البث المباشر عشرين ثانية أحياناً وأقل من ثانية أحياناً أخرى.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A8%D8%AB-%D8%A7%D9%84%D9%81%D9%8A%D8%AF%D9%8A%D9%88/)[![](https://arabroot.io/content/images/2026/10/camera-types-cover-cover.webp)دليلأنواع كاميرات المراقبة وكيف تختار بينهاما الفرق بين أنواع كاميرات المراقبة، وما الذي تحتاجه في الكاميرا حتى تسجلها على جهازك، وكم قرصاً تحتاج للتسجيلات.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/frigate-cover-cover.webp)دليلFrigate: تسجيل كاميرات المراقبة على سيرفرك مع كشف الأجسامكيف تثبت Frigate على سيرفرك، وتسجل به كاميرات المراقبة محلياً، ويكشف لك الأشخاص والسيارات دون أن يخرج الفيديو من بيتك.](https://arabroot.io/articles/frigate-%D8%AA%D8%B3%D8%AC%D9%8A%D9%84-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/)[![](https://arabroot.io/content/images/2026/10/display-internals-cover-cover.webp)دليلكيف تعمل الشاشة من الداخل: من بطاقة الرسومات إلى عينككيف يصل الإطار من بطاقة الرسومات إلى البكسل، وما الفرق بين LCD وOLED، ولماذا قد تعمل شاشتك بنصف ترددها بسبب الكابل.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%B4%D8%A7%D8%B4%D8%A9-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/)[![](https://arabroot.io/content/images/2026/10/number-systems-cover-cover.webp)دليلالأنظمة العددية للمبرمجين: من Binary إلى Floating Pointلماذا يظهر القرص 465 بدل 500، ويصبح العداد سالباً فجأة، ولا يساوي 0.1 + 0.2 القيمة 0.3؟ الإجابة في طريقة تخزين الأرقام.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%B9%D8%AF%D8%AF%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%AB%D9%86%D8%A7%D8%A6%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، وتنفيذ التجربة بأداة ffmpeg 9.0.2 من wader/static-ffmpeg مع x264 core 165 وSVT-AV1 4.2.0 وlibvpx وlibvmaf، على مقطع Artemis II من NASA في الملكية العامة، وDocker Engine 29.8.0 على Windows 11 مع Docker Desktop.