الموشن والفيديو

صيغ الفيديو والكودك

الحاوية والكودك شيئان مختلفان: MP4 اسم العلبة، وH.264 اسم الطريقة التي ضُغطت بها الصورة. وهذا التمييز وحده يحسم معظم مشكلات «لماذا لا يُفتح هذا الملف»، لأن المشغّل عليه أن يعرف العلبة والكودك بداخلها معاً.

الدرس 3 من 10
مبتدئ
مجاني، دون تسجيل

ملف فيديو واحد، أربع طبقات

من ما تراه نزولاً إلى الملف على القرص. كل طبقة قرار مستقل، والطبقتان السفليان هما اللتان يخلط الناس بينهما.

الدقة ومعدل الإطاراتكم بكسلاً في الإطار وكم إطاراً في الثانية. وهذا ما تراه العين. 1080p أو 4K
معدل البتكم بياناً يُنفق في الثانية. ودقة أعلى بلا معدل بت أعلى تعني صورة أسوأ. ثابت أو جودة ثابتة
الكودكطريقة الضغط. والترخيص ودعم العتاد يتحددان هنا. H.264، H.265، VP9، AV1
الحاويةالملف على القرص الذي يحفظ كل شيء معاً. وتغييره لا يحتاج عادةً إعادة ترميز. MP4، MKV، WebM

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

آخر مراجعة: ٢٤ أكتوبر ٢٠٢٦ تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.

الحاوية أم الكودك: أيهما أيّ

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

إذن MP4 اسم علبة وH.264 اسم كودك. وطلب «أرسل لي ملف MP4» لا يقول شيئاً يُذكر عن الملف، لأن العلبة نفسها قد تحمل H.264 أو AV1، ولهذين مصيران مختلفان تماماً على نصف أجهزة العالم.

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

لماذا يتوقف التشغيل على الاثنين

الحاوية

العلبة: MP4، MKV، WebM

يحفظ الصورة والصوت والترجمة معاً
يحمل المدة ومعدل الإطارات في بياناته الوصفية
كل علبة لا تقبل إلا قائمة قصيرة من الكودكات

شيئان منفصلان

الكودك

الطريقة: H.264، H.265، VP9، AV1

يضغط الصورة ثم يفكها
الترخيص والإتاوات يخصان هذه الطبقة
وفاكّ الترميز العتادي إما يعرفه أو لا

على المشغّل أن يعرف الاثنين؛ واحد لا يكفي.

المشغّل أو المتصفح

حيث يُتخذ القرار الحقيقي

لا يعرف العلبة: لن يُفتح الملف أصلاً
لا يعرف الكودك: يُفتح الملف والصورة سوداء
يعرف الاثنين لكن بلا عتاد: يُشغَّل ويتقطع

هذا الرسم يخبرك هل يُشغَّل الملف أم لا. ولا يقول شيئاً عن كونه يبدو جيداً.

العلب الثلاث التي تصادفها فعلاً

MP4 هي علبة التسليم. فكل جهاز ومتصفح ومنصة تقريباً يقبلها، ولهذا هي ما تسلّمه للعميل وما ترفعه على الشبكات الاجتماعية. وMDN يقول الشيء نفسه: إن لم تستطع تقديم إلا صيغة واحدة فقدّم MP4.

وMKV هي علبة العمل. تقبل أي كودك تقريباً، وتحمل عدة مسارات صوتية وعدة ترجمات بلا شكوى، ولهذا تشيع في الأرشفة والتنزيل. والمتصفحات لا تشغّلها، وهذا ليس عيباً في MKV؛ فـ MKV لم تُبنَ للويب.

وWebM هي علبة الويب، وقليلة المتطلبات عن قصد: قائمة MDN لا تعطيها للصورة إلا AV1 وVP8 وVP9، وللصوت Opus وVorbis. وهذا القيد بالذات هو ما سينفعك لاحقاً في هذا الدرس.

وهناك MOV أيضاً، علبة أبل، وتصادفها كثيراً في المونتاج. وللتسليم إلى العالم الخارجي تُحوَّل عادةً إلى MP4 أولاً، وذلك التحويل يكاد يكون دائماً تغيير علبة لا إعادة ترميز. وهذا التمييز هو ما وضعنا له رقماً في قسم تجربتنا.

الكودكات الأربعة التي تراها في كل مكان

الأعمدة أدناه مقروءة من دليل كودكات الفيديو في MDN لا من تجربة شخصية، لأن هذه وقائع ولها عمر صلاحية.

الكودك	الترخيص	دعم المتصفحات	الحاوية المعتادة	ادعاء الضغط
H.264 (AVC)	مملوك وعليه براءات؛ الاستعمال التجاري يتطلب ترخيصاً	كل المتصفحات	MP4، 3GP	خط الأساس
H.265 (HEVC)	مملوك، وعدة تجمعات براءات؛ الرسوم تُحصَّل من المطورين لا من منتجي المحتوى	يعتمد على نظام التشغيل ووجود فاكّ ترميز عتادي	MP4، MPEG-TS، QuickTime	نظرياً نصف حجم AVC بجودة مماثلة
VP9	مفتوح وبلا إتاوات	كل المتصفحات، بلا شفافية ألفا في سفاري	WebM، MP4، Ogg	جودة قريبة من HEVC عند معدلات بت مشابهة
AV1	معيار مفتوح بلا إتاوات	كل المتصفحات؛ وفي سفاري على الأجهزة ذات فاكّ الترميز العتادي فقط	WebM، MP4، MPEG-TS	أفضل من VP9 وHEVC، وحتى ٥٠٪ أفضل من AVC

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

وخانة سفاري الخاصة بـ AV1 هي التي تعضّ في مشروع حقيقي. يكتب MDN أن دعم سفاري محصور بالأجهزة التي تملك فاكّ ترميز عتادياً، أي حواسيب MacBook من M3 فصاعداً، وiPhone 15 Pro، وiPhone 16 فما بعد. فجملة «AV1 موجود في كل المتصفحات» غير جملة «AV1 يعمل على هاتف عميلي».

ما الفرق بين معدل البت والدقة

الدقة هي عدد بكسلات كل إطار، مثل 1080p أو 4K. أما معدل البت فهو مقدار البيانات المسموح للكودك بإنفاقه في الثانية. والاثنان مستقلان، وهنا تُصنع أسوأ عمليات التصدير.

ارفع الدقة وثبّت معدل البت فتسوء الصورة لا تتحسن: فالقدر نفسه من البيانات صار عليه أن يتوزع على بكسلات أكثر. وتصدير 4K بمعدل بت مضبوط لـ 1080p هو ملف أكبر بصورة أنعم وأكثر تبقعاً. وترى ذلك في كل مكان، وأوضح ما يكون في المشاهد التي يتحرك فيها شيء بسرعة.

وعملياً هناك طريقتان لضبط معدل البت. الأولى تسمية رقم ثابت، وهو ما تفعله حين يكون للوجهة سقف. والثانية الجودة الثابتة، وتُضبط في ffmpeg عبر CRF: تطلب من المرمِّز أن يحافظ على الجودة وينفق ما يلزم من بتات. وللملف الذي سيجلس على موقع، الجودة الثابتة هي الخيار الأفضل غالباً، لأن المشهد الساكن يأخذ بتات أقل والمشهد المزدحم يأخذ أكثر، وهذا بالضبط ما تتوقعه العين.

لماذا لا يُفتح هذا الملف على هاتف العميل

ثلاثة أمور تجيب عن هذا السؤال، وثلاثتها تعود إلى الكودك لا إلى العلبة.

أولاً العتاد. معظم الأجهزة تفك ترميز H.264 في شريحة مخصصة، ولذا يبقى تشغيله بارداً وزهيداً. أما الكودكات الأحدث فتريد شرائح أحدث، وعلى جهاز قديم تسقط إلى البرمجيات، أي أن المعالج يتولى العمل: تنفد البطارية أسرع، وعلى جهاز ضعيف تسقط الإطارات. وMDN يعلّق قيد العتاد نفسه على AV1 وHEVC معاً.

ثانياً الترخيص. H.264 وH.265 عليهما براءات، وAV1 وVP9 لا، وهذا وحده يفسّر لماذا يشحن كل متصفح ما يشحنه. ويضيف MDN أن تجمّع براءات Via LA لا يطالب برسوم ترخيص لبث فيديو الإنترنت بصيغة AVC ما دام الفيديو مجانياً للمستخدم النهائي، وأن رسوم HEVC تُحصَّل من المطورين لا من منتجي المحتوى وموزعيه. ولهذا دعم HEVC في المتصفحات مرقّع إلى هذا الحد.

ثالثاً العلبة نفسها. لن يشغّل المتصفح MKV ولو عرف الكودك بداخلها. وهنا فخ حقيقي: WebM لا تقبل تدفق H.264 أصلاً، فـ «حوّل الـ MP4 إلى WebM» غير ممكن دون تغيير الكودك. ويمكنك اختبار ذلك، وقد فعلناه في قسم تجربتنا.

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

أي تركيبة أختار عند التصدير

أمامنا ثلاث وجهات ولكل منها جوابها. والأجوبة تخرج مما قرأته حتى الآن لا من قائمة اعتباطية.

التسليم إلى عميل أو الرفع على شبكة اجتماعية: H.264 مع صوت AAC داخل MP4. أنت هنا لا تتحكم بالطرف الآخر، فالتوافق يتقدم على الحجم. وMDN يسمّي هذه التركيبة بالذات خياراً آمناً، مع تذكير بأن التحقق من امتثالك لشروط الترخيص مسؤوليتك أنت.

العرض على موقعك أنت: AV1 أو VP9 مع صوت Opus داخل WebM، وMP4 بديلاً. ووسم video يسمح بإدراج عدة مصادر فيأخذ المتصفح أول ما يعرفه. وتوصية MDN نفسها هي هذان المصدران بهذا الترتيب: WebM مع AV1 وOpus أولاً، ثم MP4.

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

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

سؤال واحد يحسم التصدير

هل تقرر أنت أين يُشغَّل هذا الملف أم يقرر غيرك؟

يقرر غيرك

التوافق أولاً: H.264 وAAC داخل MP4

تسليم لعميل، رفع على شبكة اجتماعية، مرفق بريد
كل جهاز يفك ترميزه، غالباً بالعتاد
الحجم أكبر، وهذا ثمن اليقين

تقرر أنت

حجم أصغر: AV1 أو VP9 وOpus داخل WebM

فيديو على موقعك، بوسم video وعدة مصادر
وضع MP4 بديلاً كذلك، دائماً
الترميز أبطأ؛ احسب ذلك في جدولك

هذا التفرع عن التسليم لا عن الأرشفة. فالنسخة الأم تبقى دائماً كما هي، وكل تصدير جديد يُؤخذ منها.

المسار السريع مع الذكاء الاصطناعي

الطريق المعتاد أن تفتح الملف في برنامج وتصدّره من جديد. أما الطريق السريع فيبدأ بسؤال مختلف: هل يحتاج شيء إلى إعادة ترميز أصلاً؟ فنصف الأعمال المسماة «تحويل فيديو» ليست إلا تغيير علبة، وتغيير العلبة لا يكلّف جودة ولا وقتاً. والنموذج اللغوي يجيد هنا أمرين: قراءة مخرَج ffprobe الخام، وكتابة سطر أوامر ffmpeg الذي يكفي عبوسه لأن يهرب الناس منه. ونموذج سريع رخيص من فئة Flash يكفي لهذا، واختيارنا الحالي مدرج في قسم الذكاء الاصطناعي بهذا الموقع.

اعرف أولاً ما داخل الملف لا ما يقوله امتداده. سطر واحد يكفي: ffprobe -v error -show_entries stream=codec_type,codec_name,profile,width,height,r_frame_rate,bit_rate:format=format_name,duration,size -of default=nw=1 input.mp4
اذكر الوجهة وقيودها صراحةً. فبدونها سيبدي النموذج رأياً في الكودكات وهو يجهل سقف الحجم أو الدقة المقبولة، فيصير جوابه عاماً.
املأ الوصفة أدناه وشغّلها. وبيت القصيد بندها الثاني: إن كانت العلبة وحدها الخطأ فالجواب أمر واحد بـ c copy ويتوقف عنده.
وبعد التشغيل افحص أمرين. إن كنت تتوقع تغيّر العلبة وحدها فيجب أن يكون تدفق الصورة هو نفسه بايتاً ببايت؛ وأمر ffmpeg -i out -map 0:v -c copy -f md5 - على الملفين يثبت ذلك. وإن جرت إعادة ترميز فعلاً فشاهد المخرَج على الجهاز نفسه الذي سيشغّله.

وصفة جاهزة للنسخ

الدور: مهندس فيديو. مهمتك أن تقرر الحاوية والكودك، لا أن تعطي نصائح عامة. ولا تنتج أي رقم غير موجود في مخرَج ffprobe أو في مواصفات الوجهة.

وجهة هذا الملف:
{مثلاً: العرض على موقعنا بوسم video | الرفع على إنستغرام | التسليم لعميل | الأرشيف}

القيود التي أعلنتها الوجهة:
{مثلاً سقف الحجم، أقصى دقة، الكودكات المقبولة. واكتب «غير معلن» لكل ما لم يُعلن}

مخرَج ffprobe:
{ضع المخرَج هنا}

أجب بهذا الترتيب:
١. ما داخل هذا الملف: الحاوية، كودك الصورة، كودك الصوت، الدقة، معدل الإطارات، المدة.
٢. هل تتطلب هذه الوجهة إعادة ترميز أصلاً؟ إن كانت الحاوية وحدها خاطئة فأعطِ أمر تغيير الحاوية بـ c copy وتوقف هنا.
٣. إن وجب تغيير الكودك فأعطِ أمر ffmpeg واحداً بالضبط، وتحته سطر واحد يقول ماذا يفعل كل خيار.
٤. إن لم تعلن الوجهة شيئاً فاكتب «غير معلن» واقترح الخيار الآمن. ولا تخمّن.
٥. واختم بما يجب أن أفحصه بعيني بعد التشغيل.

قبل أن تثق بالناتج: النموذج لا يرى صورتك. يستطيع أن يقول إن الملف H.264 داخل MP4؛ ولا يستطيع أن يقول إن المخرَج يبدو سيئاً. فالبند الخامس في الوصفة ليس مجاملة: افحص الجودة بنفسك دائماً وعلى جهاز الوجهة. وثمة مهمة لا تُسلَّم له أبداً، مذكورة في قسم المخاطر أدناه.

الذكاء الاصطناعي في هذا العمل

اختيار الكودك ليس مهمة يضيف فيها الذكاء الاصطناعي جديداً؛ فقواعده مكتوبة وهي في هذه الصفحة. أما حيث يحرر النموذج وقتاً فعلاً فهو سطر الأوامر: لـ ffmpeg أكثر من مئة خيار ولا أحد يحفظها. وحيث يفسد كل شيء فهو أدوات «التحسين الذكي» للصورة.

أدوات تساعد فعلا

Claude لكتابة سطر أوامر ffmpeg وشرح كل خيار، لأن الشرح يمكن الاعتراض عليه ومقارنته بالتوثيق. وإيران ليست في قائمة الدول المدعومة لدى أنثروبيك ولا يوجد مسار دفع رسمي منها.
Gemini للتمرير الآلي على مخرَج ffprobe لمجلد كامل، بنموذجه السريع الرخيص. وصفحة غوغل نفسها تقول إن تطبيق Gemini على الويب يعمل في أكثر من ٢٣٠ دولة وإقليماً، وإيران ليست في تلك القائمة.
FFmpeg ليست أداة ذكاء اصطناعي، ووجودها في القائمة مقصود. فالجزء المتكرر فعلاً في هذا الدرس ينجزه سطر أوامر واحد ولا يحتاج أي نموذج. النموذج يقرر ويقترح، والأداة تنفّذ.
RGB طبقة الوصول والدفع لإيران، منفصلة عن الأدوات نفسها.

اين ينقلب ضدك

ثلاثة مخاطر، وأولها الأخطر. أدوات تحسين الفيديو لا تستعيد تفاصيل لم تُسجَّل في الملف أصلاً؛ بل تخترع تفاصيل محتملة. وهذا لا يهم كثيراً في إعلان تشويقي أو عمل زخرفي، لكن حين يُراد للفيديو أن يكون دليلاً، أي مقابلة أو شهادة عميل أو لقطة كاميرا مراقبة، فالنسخة «المحسّنة» لم تعد ما سُجّل، وتقديمها بدل المصدر تحريف. والخطر الثاني: إعادة الترميز لا تمحو علامة الذكاء الاصطناعي المائية. تكتب غوغل عن SynthID أن علامتها مصممة لتصمد أمام القص والفلاتر وتغيير معدل الإطارات والضغط مع الفقد، وأن لديها أداة كشف خاصة بها. والخطر الثالث أصغر لكنه يومي: لا تسأل نموذجاً أي متصفح يدعم أي كودك اليوم. سيجيب، وستبدو الإجابة واثقة، وهي آتية من بيانات تدريب لا يخبرك بتاريخها. اقرأ ذلك من MDN أو caniuse، لا من نموذج ولا من الصفحة التي تقرؤها.

المصادر: MDN: Web video codec guide MDN: Media container formats Google DeepMind: SynthID

حدود هذه النصيحة

الكودك رافعة صغيرة. فالملف الذي دقته أربعة أضعاف المكان الذي يُعرض فيه هو الملف الخاطئ بأي كودك بنيته؛ فالمدة والدقة تتفوقان على اختيار الكودك في كل مرة تقريباً. وعمود دعم المتصفحات له عمر صلاحية أيضاً: كل ما في جدول هذه الصفحة مقروء من MDN في التاريخ المطبوع أعلاه، والطريق الصحيح اليوم أن تفتح ذلك الدليل أو caniuse، لا أن تثق بهذه الصفحة. وثمة شيء لا تستطيع أي صفحة أن تخبرك به: ما الذي يعرفه فاكّ الترميز العتادي في جهاز عميلك. والاختبار الحقيقي الوحيد أن تشغّل ذلك الملف على ذلك الجهاز.

من عملنا نحن

قِسنا دعوى «الحاوية ليست إلا علبة» على هذا الخادم، بـ ffmpeg الإصدار 6.1.1 وفي التاريخ المطبوع أعلى هذه الصفحة. صنعنا كليباً بعشر ثوانٍ بدقة 1280x720 بـ H.264 ثم صببناه في علبتين أخريين دون إعادة ترميز أي شيء. فخرجت الملفات الثلاثة بـ 3776719 و3775504 و3776666 بايت، أي أن الثلاثة تقع ضمن أقل من كيلوبايت واحد من بعضها، واستغرق العمل كله أقل من عُشر ثانية. والأدل من الحجم هو هذا: md5 لتدفق الصورة نفسه واحد تماماً في الملفات الثلاثة، 93dc8bd0df89a3adff8aa9233b8bbb46. أي لم يتغير بايت واحد من الصورة، وإنما تغيرت التعبئة وحدها. ثم صببنا التدفق نفسه في WebM بالأمر نفسه فرفض ffmpeg: Could not write header (incorrect codec parameters ?). وهاتان النتيجتان معاً هما ما افتتح به هذا الدرس.

اسئلة متابعة حقيقية

أيهما أفضل، MP4 أم MKV؟

هما مهمتان مختلفتان. MKV تحمل أي كودك تقريباً وأي عدد من مسارات الصوت والترجمة، وهذا جيد للأرشفة والتنزيل؛ والمتصفحات لا تشغّلها. وMP4 هي صيغة التسليم لأنها تُفتح في كل مكان. وتحويل إحداهما إلى الأخرى ليس غالباً إلا تغيير علبة ولا يكلّف جودة.

لماذا كبر حجم الفيديو بعد التحويل؟

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

هل أستخدم AV1 الآن؟

على موقعك أنت نعم، بشرط أن تضع MP4 بديلاً كذلك. وله كلفتان تستحقان المعرفة: ترميزه أبطأ بوضوح، وفي سفاري لا يعمل إلا على الأجهزة التي تملك فاكّ ترميز عتادياً لـ AV1. أما الملف الذي تسلّمه لعميل فـ H.264 لا يزال الخيار الأقل إزعاجاً.