[i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
Give a man a fish and you feed him for a day. Learn him how to fish and you feed him for a lifetime
تحذير: الموضوع يحتوي على الكثير من التفاصيل، تستطيع الاستفادة منه حتى بتجاهلها. أساساً حاولت الإجابة عن هذه الأسئلة:
كيف تعمل الإعدادات ؟ ما وظيفتها ؟ كيف أستعملها ؟ الموضوع لا يتحدث عن الفانسب فقط بل يأخذ بالحسبان من ينتج من فيديو الحياة الواقعية ومن ينتج للمشاهدة المباشرة والـ iPhone.
الإعدادات التي تهم الفانسب ملونة بالأزرق، لا تلق بالاً لبقية الإعدادات إن كنت تنتج الأنيمي.
بسم الله الرحمـن الرحيم
السلام عليكم ورحمة الله وبركاته.
فسترغب في قراءته قبل هذا الذي بين أيدينا. في الموضوع السابق تناولتُ المفاهيم الأساسية (الأساسية جداً) للكوديك H.264 بالشرح. من أهم ما حققناه في الموضوع السابق هو نسف الاعتقاد بأن الفيديو هو سلسلة من الصور الـ Jpeg أو أياً كان وترسيخ فكرة أنه bitstream.
أما في هذا الموضوع فسنتعرف معاً -إن شاء الله- على جميع إعدادات الانكودر x264 وفائدتها وكيفية استخدامها. كنت أنوي كتابة نسخة مختصرة في نهاية الموضوع (TL;DR) لكن يبدو أن هذا سيتطلب جهداً لهذا سألوّن المعلومات التي يستطيع المستخدم العادي أن يستغني عنها باللون الذهبي. يعني لا تقرأ ما كتب بالذهبي ولا تفتح السبويلرات إن كنت لست مهتماً بحقيقة سيرورة الأمور داخياً.
وقبل أن أبدأ الشرح التفصيلي، أود أن أقول إن هناك معاييرَ عامة يخضع لها تقييم أي إنتاج، وهي كما يلي:
- جودة الفيديو: مفهوم فضفاض جداً، يمكن تعريفه بمحافظة الفيديو المضغوط على خصائص المصدر (مع مراعاة اختلاف أجهزة التشغيل بينهما؛ يعني لا تقل لن أعالج التداخل في الـ ts كي أحافظ على خصائص المصدر في حين أنك تنتج للمشاهدة على حاسب عادي) وإضافة أقل قدر ممكن من العيوب. - سرعة الإنتاج: إنتاج أبطئ لا يعني بالضرورة جودة أفضل ! - فعالية الضغط: عدم تبذير بترايت ورفع الحجم بلا فائدة. - قابلية وسلاسة تشغيل الفيديو المضغوط على الجهاز. كل منتج يجب أن يكون له ترتيبه الخاص به لهذه المعايير الأربع حسب أهميتها بالنسبة له.
شيء آخير قبل أن نبدأ، الإجابة الصحيحة عن استطلاع الموضوع السابق هي عدم الإجابة عنه. فمن أجاب فقد أخطأ ومن لم يجب فعلى الأغلب أنه لم يدرِ ماذا يختار (لا يمكنك الفوز مع أكيبودن-سنباي). > لماذا كلتا الإجابتين خاطئتين ؟ لأنني لم أذكر إن كان السؤال عن نهاية الـ GOP حسب الـ coding order أو الـ temporal order.
2 – إعدادات عامة:
الجميع جاهزون للانطلاق الآن: - اربطوا أحزمة الأمان - اتجهو إلى مسار المجلد الذي يحتوي الملف x264.exe الذي حملتموه في الخطوة السابقة: للحصول على المساعدة الكاملة المضمنة مع الانكودر أدخل الأمر: x264 --fullhelp للحصول على مساعدة مختصرة أدخل x264 --help ملاحظة: جميع الإعدادات تكتب على هذا الشكل : setting value-- أي الخيار ثم القيمة؛ بعض الإعدادات لا يلزمها إدخال قيمة مثلi--no-fast-pskip
i--output
يكتب هذا الأمر هكذا: i--output encoded.ext1rawvideo.ext2
encoded هو اسم ومسار الملف بعد الإنتاج. إن لم تضع المسار فستجده في نفس المجلد الذي يحتوي على الملف x264.exe.
ext1 هي صيغة الملف بعد الإنتاج.
rawvideo هو اسم ومسار المصدر. إن لم تضع المسار فستجده في نفس المجلد الذي يحتوي على الملف x264.exe.
ext2 هي صيغة المصدر. يمكن أن تكون صيغة ملف فيديو أو سكربت avs.
--profile يُستعمل هذا الأمر من إجل التطابق مع أحد بروفيلات الكوديك التي تكلمنا عنها في الموضوع السابق. اختيار بروفايل معين يرتبط بنوع استخدام الفيديو؛ يعني هناك بروفايلات مناسبة للبث التلفزي، أخرى تناسب المشاهدة المباشرة (streaming) وبروفايلات تتلائم مع تخزين الفيديو على بلو راي أو ديفيدي... الجماعة الذين حددوا معايير ضغط الفيديو بالـ H.264 وضعوا 17 بروفايل والانكودر x264 يسمح لك باستعمال 4 منهم فقط. يجدر بالذكر أن تحديد بروفايل معين يعني عدم القدرة على انتاج لوسلس (فيديو غير مضغوط ومطابق للمصدر). كما أن الإعدادات الافتراضية للبروفايل تلغي أي إعدادات تضعها يدوياً ! المزيد من المعلومات في هذه الصفحة: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
القيم الممكنة لهذا الأمر هي: baseline : البروفايل الموجه للاستعمال في المحادثات المصورة (videoconference) وتطبيقات الهاتف الخلوي. خاصيته الأساسية هي "التصدي" لضياع بيانات الفيديو. اسمه المعتمد هو Constrained Baseline Profile (CBP)i الإعدادات التي يفرضها الانكودر لهذا البروفايل هي: i--no-8x8dct --bframe 0 --no-cabac --cqm flat --weightp 0 + لا يمكنك أن تنتج به فيديو متداخل (على العموم، أرجو ألا يفكر أحدكم في إنتاج أنيمي متداخل على أي حال).
main: بروفايل موجه للاستعمال في البث التلفزي الرقمي العادي (يعني ليس HD). اسمه المعتمد هو : Main Profile (MP)i الإعدادات التي يفرضها الانكودر لهذا البروفايل هي: i--no-8x8dct --cqm flat high: بروفايل موجه للبث التلفزي الرقمي ذي التعريف العالي HD ولتخزين الفيديو ذي التعريف العالي أيضاً. هذا هو البروفايل المعتمد في الـ Blu-ray مثلاً. اسمه المعتمد هو High Profile (HiP) high10: نفس البروفايل high أضفنا له دعم دقة عرض الفيديو بشكل أكبر. كل البروفايلات السابقة تدعم عمق خانات جداول الصورة بـ 8 bits أما هذا فيدعمها بـ 10 bits. لا تستعمله إلا إذا كنت تعلم يقيناً أنك تحتاجه. لا تستعمله في الفانسب. اسمه المعتمد هو High 10 Profile (Hi10P)i يجدر بالذكر أن البروفايلان الأخيران غير مدعومان كلياً من طرف الـ x264، يعني لهما خصائص لا يستعملها الانكودر. لا تلمس هذا الخيار profile-- إلا إذا كنت تعلم أن استعمالك للفيديو بعد الانتاج يتطلب بروفايل معين. لا تستخدم هذا الأمر أيضاً إذا كنت تنوي إنتاج لوسلس.
level-- يحدد لك الـ level الذي ستنتج عليه. تحدثنا عن هذا الـ level في الموضوع السابق. الخيارات المتاحة هي: 1 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 5.1 -1 عليك بزيارة هذه الصفحة كي تختار الـ level المناسب لك حسب البترايت الأقصى الذي يمكن أن تبلغه، عدد الفريمات المرجعية الأقصى الذي يُسمح لك باستعمالها، أبعاد الفيديو، عدد الماكروبلوك الأقصى في كل ثانية وفي كل فريم وأخيراً حسب سرعة الفريمات والبروفايل الذي تعمل عليه. كلما ارتفعت في الـ level تقلصت قدرتك على ضغط الفيديو وزادت قدرتك على الوصول إلى بترايت أعلى وجودة أعلى. وكلما نزلت في الـ level زادت قدرتك على الحصول على حجم أقل وتقلصت حظوظك في الوصول إلى بترايت عالي وجودة عالية. من المهم جداً أن تحدد هذا الخيار يدويا ولا تعول على الانكودر ليختاره لك ويحد بالتالي من قدرتك على الوصول إلى جودة عالية لأن مبرمجي الانكودر يهتمون بفاعلية وسرعة الضغط أكثر من الجودة. عندما تتجاوز الـ level 4.1 ستجد صعوبات في تشغيل الفيديو على الحواسب العادية ولن تتمكن من تخزينه على قرص بلوراي فارغ أو مشاهدته على 360 xbox. لذا من المستحسن عدم تجاوز تلك القيمة لأنها كافية جداً. القيمة الافتراضية هي -1 أي أن يتكفل الانكودر باختيار ما يراه مناسباً.
preset-- يحدد لك هذا الأمر مجموعة من الإعدادات الافتراضية التي اختارها مبرمجو الانكودر لتسهيل العملية على المنتجين. المسألة هنا مسألة "جودة" vs سرعة. هذه الإعدادات الافتراضية تتغير إذا غيرت أحدها يدوياً. الخيارات المتاحة هي : ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo في العادة، من المستحسن أن تختار أبطئ ما يمكنك تحمله، لكن أحيانا تزيد في وقت الانتاج بلا فائدة. لذا عليك أن تلقي نظرة على هذا الجدول بعد أن تنهي قراءة الموضوع كي تعرف ما يناسبك.
سواء صدقتم أم لم تفعلوا، لقد صممت هذا الجدول كله وحدي (لم أجد شيئاً محدثاً)
إذا اختار المنتج قيمة مختلفة عن أحد الخيارات المبينة في الجدول فإن خياره يأخذ مكان الاعدادات الافتراضية (عكس i--profile الذي لا يبالي بخيارات المنتج الافتراضية). القيمة الافتراضية هي medium --tune أمر آخر لتسهيل كتابة الاعدادات لكن هذه المرة حسب طبيعة المصدر الذي بحوزتك. الخيارات المتاحة: touhou, film, animation, grain, stillimage, psnr, ssim, fastdecode, zerolatency film: يُستخدم في فيديو من الحياة الواقعية؛ يعني مباراة كرة قدم، فلم وثائقي... لكن هذا لا يعني أنه لا ينفع لاستخدامات أخرى. إعداداته الافتراضية هي: i--deblock -1 :-1 --psy-rd -:0.15 animation: مجموعة من الإعدادات التي رأى مبرمجو الانكودر أنها مناسبة للأنيمي. شخصياً لا أوافقهم الرأي. الإعدادات الافتراضية هي: الـ i--bframe تأخذ قيمتها السابقة + 2 الـ i--ref إن كانت 1 فستبقى واحد. إذا لم تكن 1 فستأخذ الأقل بين ضعف قيمتها السابقة و16. i--psy-rd 0.4:- --aq-strength 0.6 --deblock 1:1 grain: يُستخدم مع مصادر فيديو الحياة الواقعية التي تحتوي على grain (حبيبات) كما في هذه الصورة. الإعدادات الافتراضية هي:
stillimage: يستعمل مع الصور المتحركة كالـ Jpeg، يعني مثل بنرات المواضيع. الإعدادات الافتراضة هي
i--aq-strength 1 .2 --deblock -3:-3 psy-rd 2:0.7
psnr: يحسب معدل مستوى التشابه بين كل فريم من المصدر والفريم المضغوط الموافق له ويضعه في تقرير عند نهاية الانتاج. كلما زادت القيمة التي تحصل عليها كانت الفريمات أكثر شبهاً للمصدر، لكن هذا في حالة أنك لم تستعمل i--psy-rd الإعدادات الافتراضية هي:
i--aq-mode 0 --no-psy
ssim: مثل psnr باستثناء أن الـ psnr يعمل على كل خانة من جداول الصورة في حين أن الـ ssim يعمل على الفريم كله. كلما اقتربت أكثر من 1 كان الفريمات أكثر شبها لفريمات المصدر. الإعدادات الافتراضية هي : i--aq-mode 2 --no-psy fastdecode: يتيح تشغيل سلس للفيديو. يستحب استعماله عند إنتاج اللوسلس كي يكون الإنتاج النهائي أسرع، لكن الحجم سيكون أكبر لأن هذا الأمر يعطل 2 من أهم ميزات الكوديك H.264: الـ CABAC والـ In-Loop filter الإعدادات الافتراضية هي : i--no-cabac --no-deblock --no-weightb --weightp 0 zerolatency: لم أجد معلومات تستحق الذكر. الإعدادات الافتراضية هي: i--bframe 0 --force-cfr --no-mbtree --sync-lookahead 0 --slices-threads --rc-lookahead 0 touhou: يُستعمل عند إنتاج الفيديو المسجل من الألعاب الإعدادات الافتراضية هي : الـ i--ref إن كانت 1 فستبقى واحد. إذا لم تكن 1 فستأخذ الأقل بين ضعف قيمتها السابقة و16. deblock -1:-1 --aq-strength 1.3 --psy-rd -:0.2-- ---- يُذكر أنه يمكن تحديد أكثر من خيار والفصل بينهم بفاصلة أعجمية؛ مثال: i--tune film,ssim لكن لا يمكنك أن تختار أكثر من واحد بين من بين الخيارات التي تؤثر على i--psy-rd ------------------ عند كتابة الأوامر في الـ CLI يفضل أن تبدأ بتحديد الـ preset فالـ tune ثم الـ profile يعني أن يكون الترتيتب : i--preset <speed> --tune <content type> --profile <profile> -------------------
--slow-firstpass يستعمل هذا الخيار عند استخدام --pass 2 أو --pass 3 فقط. الإعدادات الافتراضية هي: i--subme تأخذ القيمة الأقل بين 2 وقيمتها السابقة. i--partition تأخذ i4x4 إذا كانت مفعَّلة مسبقاً، وإلا فإنها تأخذ none --ref 1 --no-8x8dct --me dia --trellis 0
3 – إعدادات متعلقة بالفريمات
i--keyint يحدد الطول الأقصى للـ GOP. القيمة المنصوح بها هي 10 أضغاف معدل سرعة الفريمات لديك ولا يُستحب رفعها أكثر لأن هذا يؤثر على سلاسة تشغيل الفيديو دون أي إضافة تستحق الذكر على مستوى الجودة أو الحجم النهائي. أما حين الانتاج للبلو راي، للبث الفضائي أو للمشاهدة المباشرة فقد يفيدك تخفيض الـ keyint وربما تحتاج إلى عدد يساوي معدل سرعة الفريمات لديك. عندما أقول الانتاج للبلوراي فهذا يعني الانتاج من أجل تخزين الفيديو على قرص بلو راي لا الإنتاج من مصدر بلو راي ! القيمة الافتراضية هي 250.
i--min-keyint يحدد الطول الأدنى للـ GOP. قيمة صغيرة للـ min-keyint يمكن أن ينتج عنها تأثير وميض في الصورة. القيمة التي ينصح بها الخبراء هي القيمة الافتراضية. أما أقصى حد مسموح به فهو i(keyint/2) + 1 القيمة الافتراضية هي keyint/10
--scenecut يحدد القيمة التي على أساسها يقرر الانكودر ما إن حصل تغير في المشهد (يعني keyframe). الانكودر x264 يحسب نسبة تشابه كل فريم عن الذي قبله. إذا كانت نسبة التشابه أقل من scenecut فهذا يعني أن الفريم الحالي هو I-frame (هذا الكلام ليس دقيقاً جداً، المسألة أعقد من هذا، اسأل إن كنت تود معرفة كيف يجري الأمر بالضبط). فإذا كان طول الـ GOP الحالي أكبر من min-keyint فإن الانكودر سيضع هذا الفريم على شكل keyframe. كلما زادت قيمة الـ scenecut زادت فرصة اكتشاف تغير المشاهد. القيمة الافتراضية هي 40 ولا يُستحب تغييرها.
i--no-scencut يعطل الأمر السابق. لا تستعمله إلا إذا كنت تعلم ماذا تفعل. القيمة الافتراضية له هي "غير مفعّل"
i--intra-refresh يعطل استخدام الـ keyframes. بدل إدراج الـ keyframes، يستعمل الانكودر أسلوب ضغط داخلي لكل macroblock (يعني كل macroblock يُضغط وحده دون الاستعانة ببيانات بقية الـ macroblocks) عند بداية كل GOP. هذا الأسلوب مفيد مع الفيديو الموجه للمشاهدة المباشرة أو المحادثات الهاتفية المصوة ... لأنه يجعل أحجام الفريمات متقاربة (بسبب التخلي عن الـkeyframes) لكنه يخفض من فعالية الضغط. لا تستعمله إلا إذا كنت تحتاجه. القيمة الافتراضية هي "غير مفعّل"
i--bframes يحدد أكبر عدد من الـ P-frames المتتالية التي يُسمح للانكودر باستبدالها بالـ B-frames. بلا B-frames تكون الـ GOP على هذا الشكل: IPPPPP...i، مع bframe 2 يمكن أن تصبح الـ GOP هكذا : IPBBPPPBPPBBPP...i لكن لا يمكنها أن تصبح IPBBBPBBP...i. يُذكر أن الـ B-frames أفضل من الـ P-frames يعني ستود استبدال أكبر عدد ممكن من الـ P-frames بالـ B-frames. لكن من ناحية أخرى، هذا الأمر هو عامل أساسي في تحديد سرعة الإنتاج. كلما زادت قيمة الـ bframes زاد وقت الإنتاج. المسلي في الأمر هو أن هذه الزيادة في الوقت قد تكون بلا فائدة ! الحل الأفضل لاختيار قيمة الـ bframes هو ... سنتكلم عنه لاحقاً xD مصادر الأنيمي تستفيد من الـ B-frames بشكل جيد لذا يُنصح بقيمة أكبر أو تساوي 5 أما المصادر الأخرى فعلى الأرجح أنك لن ترغب في تجاوز القيمة السابقة. عند استخدام الانتاج بالـ i--pass يجب الحفاظ على نفس قيمة الـ i--bframes في جميع الـ passes.
القيمة الافتراضية هي 3.
i--b-adapt يحدد خوارزمية اختيار مكان الـ B-frames.يعني هذا الأمر هو الذي يحدد الطريقة التي يتبعها الانكودر في اختيار المكان الذي يدرج فيه الـ B-frames. الخيارات المتاحة هي: 0 : يعطل الاختيار التناسبي لمكان الـ B-frames. يعني كلما وضع الانكودر B-frame فإنه سيضع سلسلة من B-frames طولها bframes. في هذه الحالة من الأفضل ألا تزيد قيمةالـ i--bframes عن 1، وإلا فإن مشاهد الحركة والقتال و... ستتأثر بطريقة تضر بالجودة. 1 : خوارزمية سريعة لاختيار مكان الـ B-frames لكن تنقصها الدقة العالية.باستعمال هذا الخيار فإن سرعة الانتاج مع i--bframes 3 لن تختلف بشيء يستحق الذكر عن سرعته مع i--bframes 16 2 : خوارزمية تتميز بدقة عالية (الخبراء يصفونها بالمثالية) في اختيار الـ b-frames لكنها بطيئة جداً مقارنة مع الخوازمية السابقة (1). عند استعمال هذا الخيار فإن سرعة الإنتاج ستنخفض بشكل مستقر (linear) مع زيادة قيمة الـ i--bframes يعني إن كان الانتقال من i--bframes 2 إلى i--bframes 3 يكلف 6% إضافية لوقت الانتاج، فإن الانتقال من i--bframes 3 إلى i--bframes 4 سيكلف هو أيضاً 6% إضافية لوقت الإنتاج. سرعة i--bframes 5 --b-adapt 2 عادة لا تختلف (ربما تزيد) عن سرعة i--b-frames 16 --b-adapt 1 لكن فاعلية الضغط مع الحالة الأولى تكون أفضل في العادة. اختر i--bframes 16 --b-adapt 2 إن كنت مهووساً بالانتظار للأبد. إن كنت لا تحتاج قيمة عالية من i--bframes فالأفضل أن تختار i--b-adapt 2 يزداد احتمال الحاجة للـ B-frames عند الاختفاء التدريجي للصورة، المشاهد الساكنة، الحركة البطيئة، حركة المشهد أفقياً (pan) أو عمودياً (scroll) حيث تظهر مقاطع جديدة من الصورة لم تكن موجودة من قبل فنستغل قدرة الـ B-frames على استعارة البيانات من الفريمات المستقبلية... حسب كلام المطورين فإن i--b-adapt 2 تعطي زيادة في فعالية الضغط بين 3% و15% مقارنة بـ i--b-adapt 1 مع نفس قيمة الـ i--bframes القيمة الافتراضية لـ b-adapt هي 1. لا تحتاج لهذا الأمر سوى في الباس الأول عند استخدام i--pass
--b-bias يحدد مدى "استعداد" الانكودر لاستبدال P-frame بـ B-frame. القيم المتاحة تمتد بين -100 إلى +100. من 1 إلى 100 يكون الانكودر أكثر "استعداداً" لاستبدال P-frame بـ B-frame والعكس فيما سوى هذه الحالة. i--b-adapt 100 لا تعني أن جميع الـ P-frames سيصبحون B-frames بل تعني أن الانكودر سيكون "مستعداًّ" جداً لاستبدال الـ P-frames بـ B-frames. --b-adapt -100 لا تعني أن الانكودر لن يدرج أي B-frame. القيمة الافتراضية هي 0. غيرها إن كنت تعتقد أنك تجيد التحكم في الجودة أكثر من الانكودر.
i--b-pyramid في البداية يجب أن نعلم أن الانكودر يفرق بين نوعين من B-frame. النوع الأول هو الذي يقع استعماله على شكل فريم مرجعي، أي أن بقية الفريمات تستعير منه البيانات المكررة؛ هذا النوع نرمز له بـ B. والنوع الثاني هو الذي ليس مستعملاً على شكل فريم مرجعي؛ هذا النوع نرمز له بـ b. حسنٌ، i--b-pyramid يتيح لك اختيار إن كنت تود استعمال B وكيف تريد استعمالها. الخيارات المتاحة هي: none: الانكودر لن يسمح باستعمال B. strict: يسمح باستعمل B واحد فقط كل minigop. مطابق لمتطلبات أقراص البلو راي. normal: يسمح باستعمال أكثر من B واحد كل minigop. غير مطابق لأقراص البلوراي لكنه أكثر فعالية من strict. يذكر أنه حين تفعيل التفريق بين b وB فإن الانكودر يرفع حجم الـ B التي تكون فريماً مرجعياً أكثر مما لو أنها لم تكن كذلك لكن بدرجة أقل مما لو حولها إلى P-frame. كما يُذكر أن b-pyramid لن يكون لها أي تأثير إلا إذا زاد عدد الـ B-frames المتتالية عن 2.
i--open-gop closed-gop = مجموعة صور مغلقة.
open-gop = مجموعة صور مفتوحة.
عند استعمال closed-gop فإن كل gop تبدأ بـ IDR-Frame، مما يعني أنه لا يستطيع أي فريم ينتمي إلى GOP معين أن يكون فريماً مرجعياً لفريم ينتمي إلى GOP آخر (لأن الـ IDR-frames تحذف الفريمات المرجعية السابقة من الـ DPB). عند استعمال الـ open-gop، يسقط شرط بداية جميع الـ GOPs بـ IDR-frame مما يعني قدرة الفريمات في الـ GOP عدد "س" على استعارة بيانات من عند فريمات تنتمي إلى الـ GOP عدد "س+1" والعكس. يمكن فعل هذا عن طريق اعتماد ترتيب فريمات مختلف بين الـ Coding order والـ Temporal order. مثال: لنفترض أن لدينا الترتيب التالي: Temporal order : PBBBIb PBBBينتمون للـ GOP عدد "س" وIb تنتميان للـ GOP عدد "س+1". الـ BBB يستعيرون بيانات من الـ P الذي قبلهم والـ I الذي بعدهم، الـ b يستطيع استعارة بيانات من الـ BBB. لكن ماذا إن أردت بدأ تشغيل الفيديو من الـ I ؟ في هذه الحالة، سيعرض لك الديكودر الفريمات بشكل سليم بدءً من الـ I لكن... كيف ؟؟ لأن ترتيب الفريمات في الـ bitstream مختلف عن ترتيبها الزمني. في حالة المثال السابق سيكون ترتيب الفريمات في الـ bitstream كما يلي: coding order : PIBBBbقلنا إن الـ BBB يحتاجون للـ I والـ P كي يستعملوهم على شكل فريمات مرجعية، صحيح ؟ حسن، فكينا تشفير الـ P ثم الـ I قبل الـ BBB، لذا فـ I وP موجودان في الـ DPB مما يعني قدرتك على استعمالهم على شكل فريمات مرجعية للـ BBB بما في ذلك الـ Iالتي تنتمي إلى GOP آخر. الآن، الـ b تستطيع استعمال أي فريم من بين PIBBB على شكل فريم مرجعي، بما في ذلك الـ BBB الذين ينتمون إلى GOP آخر. الأمر i--open-gop يسمح لك باستعمال الـ open-gop بدل closed-gop. هذا الأمر يمكن أن يأخذ ثلاث قيم: none: يعطل استعمال الـ open-gop. يعني لن يحتوي الفيديو سوى على closed-gop. normal: يفعل استعمال الـ open-gop. يُذكر أن بعض الديكودرات ليست مبرمجة على أن تقبل بالـ open-gop لذا فقد تواجه مشاكل عند تشغيل الفيديو بواسطتهم (هذا خطأ مبرمجي الديكودر لأنهم لم يدعموا خصائص الكوديك H.264 بالكامل). عند استعمال هذا الخيار فإن نتيجة الضغط لن تكون متوافقة مع خصائص البلوراي. bluray: يفعل الـ open-gop لكن بدرجة أقل فاعلية من normal. إن كنت تريد الانتاج للبلوراي بالاستفادة من الـ open-gop فيجب أن تستعمل هذا الخيار. تفعيل الـ open-gop يزيد في فعالية الضغط والجودة. لكن قد يسبب لك مشاكل في تشغيل الفيديو على بعض الأجهزة. الديكودر ffdshow يدعم الـ open-gop، فإن كنت تنتج للمشاهدة على الحاسب فمن المفيد جداً أن تفعل الـ open-gop. أيضاً، إن كنت تنوي تحرير الفيديو (editing) فلا تستعمل هذا الخيار. تحرير الفيديو هي عملية يختص بها المحترفون عبر "التلاعب" بهيكلة الـ bitstream. ملاحظة: أنا متأكد من أن x264 يسمح لآخر b-frame من استعمال فريمات مرجعية من الـ GOP الموالي، لكنني لست متأكدا من أنه يسمح للـ b-frame باستعمال فريمات مرجعية من الـ GOP الذي قبله. القيمة الافتراضية هي "غير مفعل"
i--no-cabac الـ CABAC (Context Adaptive Binary Arithmetic Coder)i هو نوع قوي وفعال من Entropy Encode/Decode لكنه يعد بطيئاً نوعاً ما خاصة على مستوى الديكودر (عموماً، أي Pentium 3 لن يواجه مشاكل معه في أبعاد الـ HD وبسرعة فريمات 24). الـ CABAC من أبرز ميزات الكوديك H.264 لأنه يتيح زيادة في ضغط الفيديو بنسبة بين 10 و20 بالمئة(دون خسارة أي جودة، يعني في نفس البترايت يعطيك جودة أفضل وبنفس الجودة يعطيك حجماً أقل). الأمر i--no-cabac يعطل هذه الخاصية. لا تستعمله إلا إذا كانت سلاسة تشغيل الفيديو أهم لديك من الحجم/الجودة. متى قد تحتاجه ؟ عند الانتاج للأجهزة ذات المعالجات الضعيفة كالـ iPhone، عند الانتاج للمشاهدة المباشرة، المحادثات المصورة (videoconference)، اللوسلس...
إن فعّلت هذا الخيار فيستخدم الانكودر الـ CAVLC (Context Adaptive Variable Length Coder)iوهو نفس نوع الـ Entropy encode الذي يستعمله كوديك Xvid. رجاءً، لا تستعملوا هذا الأمر في الفانسب وشكراً على حسن المتابعة والاهتمام.
القيمة الافتراضية هي "غير مفعل".
i--ref يحدد لك أقصى عدد ممكن من الفريمات المرجعية التي يمكن أن تخزنها في الـ DPB.
القيم الممكنة تمتد من 1 إلى 16. كلما استحملت فريمات مرجعية أكثر كان بامكانك ضغط الفيديو أكثر وزادت حاجتك لجهاز أقوى.
كلما استخدمت فريمات مرجعية أقل تقلصت قدرتك على ضغط الفيديو بشكل أفضل وتقلصت حاجتك للذاكرة العشوائية.
عدد الفريمات المرجعية التي يمكنك استعمالها مرتبط بالـ level. إن تجاوزته فقد خرجت عن استعمال الكوديك H.264 وقد تواجه مشاكل في تشغيل الفيديو!
القيمة الافتراضية هي 3. i--deblock
يفعّل استخدام الـ in-loop filter المعروف أيضاً بـ deblocking filter (عرفناه في الموضوع السابق بفلتر التلطيف) ويحدد عوامله (parameters). فلتر التلطيف هذا من أهم خصائص الكوديك H.264 ووظيفته هي التخلص أو الحد من المربعات التي لا تبدو منسجمة مع بقية الصورة. أيضاً، فلتر التلطيف يعمل على مستوى الديكودر والانكودر معاً، إن لم تفعله عند الانتاج فلن يستعمله الديكودر. تأثير فلتر التلطيف تناسبي (adaptative) يختلف من فريم إلى آخر كما أنه يعمل على ثلاث مستويات:
- مستوى الشريحة (slice): في هذا المستوى يقع تحديد طريقة عامة لكيفية تأثير الفلتر على الشريحة وعلى نظائرها من الشرائح المنتمية إلى فريمات تستغل الفريم الذي تنتمي إليه الشريحة الأولى على شكل فريم مرجعي (لهذا فإن ظهور المربعات في الصورة يبدأ ويختفي مع بداية ونهاية الـ GOP). تظهر فائدة هذا المستوى، مثلا، عندما يكون لديك فريم فيه مقاطع مظلمة ومقاطع غير مظلمة؛ فيضع الانكودر المقاطع المظلمة في شريحة (أو مجموعة شرائح) ويطبق عليها تلطيفاً أقوى.
-مستوى حدود البلوكات: في هذا المستوى، يقارب الانكودر بين مستويات قوة التلطيف في البلوكات المتجاورة.
مستوى الخانات: هنا تزداد الإثارة؛ سأضع المختصر المفيد في نهاية الشرح، توجه إليه إن كنت لا تريد وجع الرأس.
كنا قد تحدثنا في الموضوع السابق عن أن الـ quantization تباعد بين قيم عناصر الـ DCT. من المهم جداً للانكودر أن يميز بين تباعد هذه القيم الناتج عن وجود حدود لشكل معين فيحافظ على هذا التباعد (يعني لا يطبق الفلتر أو يطبقه بأقل قدر ممكن)، والتباعد الناتج عن تطبيق الـ quantization فيقلص منه (يعني يطبق الفلتر). ومن أجل التفريق بين الحالتين، يحلل الانكودر قيم الخانات المجاورة للحدود. وكي نشرح طريقة التحليل هذه، سنأخذ مثالاً لمجموعتين رباعيتين من قيم خانات تنتمي إلى بلوكين متجاورين.
p0, p1, p2, p3 هي قيم أربعة خانات موجودة ضمن بلوك واحد وq0, q1, q2, q3 هي قيم أربعة خانات موجودة ضمن بلوك آخر.
كي يكون السطر الأسود حداً (يعني لا يطبق الفلتر)، يجب أن تكون القيمة المطلقة لنتيجة عملية طرح p0 من q0 أكبر من عدد يسمى alpha وهو الذي رمزنا إليه في الصورة بـ a. في هذه الحالة، الانكودر يرفع القيمة المطلقة لنتيجة عملية الطرح بين كل قيمتين متتاليتين موجودتين على طرفي الحد إلى أكثر من عدد آخر يسمى Beta وهو الذي رمزنا له في الصورة بـ B.
كي لا يُعد السطر الأسود حداً (يعني أنه ناتج عن الـ quantization وبالتالي يُطبق الفلتر)، يجب أن تكون القيمة المطلقة لنتيجة عملية طرح p0 من q0 أقل من a. في هذه الحالة، الانكودر يخفض القيمة المطلقة لنتيجة عملية الطرح بين كل قيمتين متتاليتين موجودتين على طرفي الحد إلى أقل من B.
...
السطر الأسود في الصورة السابقة لا يُعد حداً وبالتالي سيطبق عليه الفلتر.
المختصر المفيد:
i--deblock
يأخذ قيمتين ليكون على هذا الشكل: i--deblock alpha:beta
alpha: هي درجة قوة تطبيق الفلتر؛ كلما ازدادت تقلص وجود المربعات في الفيديو وظهر بلور أكثر وكلما انخفضت ازدادت امكانية ظهور المربعات في الفيديو وتقلص البلور (مما يعني أن التفاصيل تكون أوضح).
beta: هي الحد الذي على أساسه يقرر الانكودر ما إن كان جزء من الصورة ينتمي إلى التفاصيل (التي من المهم الحفاظ عليها) أو لا. كلما ازدادت قيمة الـ Beta طبق الانكودر الفلتر بشكل أقوى على البلوكات المسطحة التي تحتوي على تفاصيل (يعني تضر بالتفاصيل). كلما انخفضت قيمة الـ Beta طبق الانكودر الفلتر بشكل أضعف على البلوكات المسطحة التي تحتوي على تفاصيل (يعني تحافظ على التفاصيل) وفي نفس الوقت يطبق الفلتر بشكل أقوى على البلوكات الأخرى (يعني التسبب في بلور).
البلوكات المسطحة هي البلوكات التي تكون قيم خاناتها متقاربة، أي أن جميع الخانات تنتمي إلى نفس الجسم.
في الأنيمي، تخفيض الـ Beta لا يؤدي إلى الكثير من البلور ويحافظ على التفاصيل. قيمة مرتفعة للـ alpha تتسبب في بلور قبيح (في بعض الأحيان يبدو الفيديو كأن عليه طبقة من البلاستيك الشفاف).
تأثير فلتر التلطيف على سرعة الإنتاج ضعيف لأن العمليات الحسابية التي يجريها المعالج لا تتعدى أن تكون جمعاً أو shift دون استعمال الضرب والقسمة (وهما أعقد العمليات). تأثير فلتر التلطيف على سرعة الديكودر أقل من تأثيره على سرعة الانكودر.
القيمة الافتراضية هي 0:0
i--no-deblock
يعطل استخدام فلتر التلطيف. لا تستعمله في الفانسب. تعطيل فلتر التلطيف والـ cabac معاً يحرمك من 60% على الأقل من مميزات الكوديك H.264.
استعمال هذا الأمر يؤدي إلى خسارة فادحة على مستوى الجودة وزيادة طفيفة على مستوى السرعة.
القيمة الافتراضية هي "غير مفعل".
i--slice
يحدد عدد الشرائح (تكلمنا عنهم في الموضوع السابق) في كل فريم ويفرض شكل المستطيل لجميع الشرائح.
استعمل هذا الأمر بقيمة 4 إذا كنت تنتج للبلو راي وإلا فلا تعبث به إلا إذا كنت تدرك ما تفعله جيداً.
القيمة الافتراضية هي 0
i--slice-max-size
يحدد أعلى حجم يمكن أن تأخذه كل شريحة بالبايت. لا تعبث به إلا إذا كنت تدرك ما تفعله جيداً.
القيمة الافتراضية هي 0
i--slice-max-mbs
يحدد أكبر عدد من الماكروبلوكات التي يمكن أن تحتوي عليها كل شريحة. لا تعبث به إلا إذا كنت تدرك ما تفعله جيداً.
القيمة الافتراضية هي 0
i--tff
ينتج لك فيديو متداخل يبدأ بالحقل العلوي أولاً. إنتاج الفيديو المتداخل يتيح ضغطاً أقل فعالية من الفيديو المتتابع (فريم بعد فريم بدل حقل بعد حقل). لا تستعمله إلا إذا كان جهاز التشغيل يتطلب فيديو متداخل. إياك أن تستعمله في الفانسب، سيضحك عليك سكان الانترنت.
القيمة الافتراضية هي "غير مفعّل"
i--bff
مثل الأمر السابق إلا أن الحقل الأول في الفيديو المتداخل سيكون الحقل السفلي.
القيمة الافتراضية هي "غير مفعّل"
i--constrained-intra
لا أحد يستعمل، لا داعي لأن تستعمله أنت أيضاً.
القيمة الافتراضية هي "غير مفعّل"
i--pulldown
يطبق soft telecine على فيديو متتابع (progressive)، شرحها يتطلب وقتاً؛ ادخل هنا إن أردت:wiki, Handbrake, mplayerhq, Demokid
none:لا يطبق الـ soft telecine
22:لا تحتاج إلى شرح
32:لا تحتاج إلى شرح
64:لا تحتاج إلى شرح
double:------
triple:------
euro:------
القيمة الافتراضية هي none
i--fake-interlaced
يضع علامة في الـ bitstream تشير إلى أن الفيديو متداخل حتى وإن لم يكن كذلك. يُستعمل حين الإنتاج للبلو راي.
القيمة الافتراضية هي "غير مفعّل"
4 - إعدادات التحكم في ضغط الفيديو
قبل أن ندخل إلى هذه الغابة الاستوائية المسماة بـ "التحكم بتوزيع البترايت" سنراجع بعض المفاهيم النظرية. أعلم أن بعضكم ربما مل من النظريات and all.. لكن، معذرة، هذه سياستي في إعطاء المستخدم أكبر قدر ممكن من التحكم بدل تلبيسه العِمّة.
كنا قد تحدثنا في الموضوع السابق عن الـ quantization. صراحة، لا زلت غير واثق من أنكم فهمتموها جيداً، لذا سأشرحها أكثر. فلنأخذ مثال التحكم في حرارة فرن صَهر الحديد.
>> lol wut فرن صَهر الحديد ؟؟؟
نعم، حرارة فرن صهر الحديد، والتي تمثل إشارة تماثلية (analog signal)، أي أننا يمكننا في كل لحظة أن نعرف قيمتها بالضبط؛ مثال: في اللحظة t تكون درجة الحرارة 1200 ثم في اللحظة t + 1 جزء من الثانية تكون 1200,3. الفرق بين القيمتين قليل ويمكننا أن نستغني عنه على مستوى التحكم في درجة الحرارة من أجل توفير وقت معالجة قيم متقاربة بنفس الطريقة ومن أجل توفير المساحة اللازمة لتخزين ومعالجة البيانات ومن أجل توفير الباندويدث اللازم لإرسال البيانات نحو وحدة المعالجة.الاستغناء عن هذا الفرق يمكن أن يكون عبر رقمنة الإشارة. مثال: بدل أن نأخذ قيمة الحرارة كل لحظة، نأذها كل ثانية أو كل دقيقة. هذه العملية تسمى sampling
الإشارة التماثلية (أو المتواصلة عبر الزمن إن شئتم) تحتوي على كم هائل من البيانات التي تتطلب معالجتها الكثير من الوقت والكثير من الجهد من طرف المعالج إضافة إلى سعة تخزين كبيرة. الإشارة الرقمية تحتوي على عدد محدود من البيانات المتقطعة زمنياً والتي يمكنها تعبر على مضمون الإشارة التماثلية دون خسارة شيء يذكر منه. يمكننا تشبيه الـ sampling بالـ DCT.
بعد الـ sampling نحصل على عدد كبير من القيم. ومن أجل تقليص حجم الإشارة أكثر، نحد من عدد الأخيرة (يعني من عدد القيم) عبر تطبيق الـ quantization.
في هذه الصورة طبقنا الـ quantization بعامل(quantization parameter) كبير فنتج عن هذا خسارة ملحوظة للبيانات.
في هذه الصورة طبقنا الـ quantization بعامل صغير. كما ترون، الفرق بين شكل الإشارة قبل وبعد الـ quantization أقل مما في الحالة السابقة. لكن في المقابل، أصبحت لدينا قيم أكثر من الحالة السابقة مما يعني حجماً أكبر للإشارة.
أرجو أن مسألة الـ quantization صارت واضحة الآن. مجال الاستفسارات يبقى مفتوحاً.
تلخيص عام لأهم المبادئ النظرية التي ترتكز عليها خوارزميات التحكم في الجودة بواسطة الانكودر x264.
- أنت ترغب في أن يكون الفيديو الناتج عن عملية الضغط ذا جودة ثابتة. لكن، الجودة الثابتة لا تعني QP ثابت ولا تعني psnr ثابت؛ تصعب رؤية التفاصيل في مشاهد الحركة والسرعة مما يعني أنه يمكنك أن تنتج بـ QP أعلى لنفس الجودة المرئية في هذه المشاهد وهذا ما يفعله الانكودر: يرفع الـ QP في مشاهد الحركة.
- في المقابل، يمكنك أن تحصل على جودة مرئية أكبر عندما تركز البترايت (أي عندما تخفض الـ QP) في المشاهد التي يعمل فيها تعويض الحركة (motion compensation) بشكل جيد. في مشاهد الحركة البطيئة، يمكن أن يستمر ظهور العيوب لعدة ثواني في حين أن كل ما عليك فعله هو معاجته (بزيادة الحجم) في فريم واحد (I-frame غالباً) كي تتخلص منه في المشهد كله.
فيما يخص ضغط الفيديو بالانكودر x264 فإن الـ quantization تعمل على عناصر الـ DCT حسب خوارزميات محددة ومتقدمة (تناسبية).
يجب أن تعلموا أن التحكم في توزيع الجودة يقع على 3 مستويات وفي كل مستوى يختار الانكودر عامل الـ quantization المناسب (quantization parameter : QP)الذي يحد من تباعد قيم عناصر الـ DCT. كلما كانت قيمة الـ QP صغيرة تقلص التباعد بين قيم عناصر الـ DCT (quantization step)i وزاد الحجم وزادت الجودة. كلما كانت قيمة الـ QP كبيرة زاد التباعد بين قيم عناصر الـ DCT وتقلص الحجم وانخفضت الجودة. المستويات الذكورة سابقاً هي:
- مستوى الـ GOP.
- مستوى الصورة (فريم، حقل أو نتيجة طرح صورتين).
- مستوى الماكروبلوك.
i--qp
يطبق أسلوب quantization متماثل (uniform) على الفيديو. لا يتأثر هذا الأسلوب سوى بطبيعة الفريم. أي أنه يقع تطبيق نفس الـ quantization على جميع الـ I-frame ونفس الـ quantization على جميع الـ P-frames ونفس الـ quantization على جميع الـ B-frame. القيمة التي يأخذها هذا الأمر هي قيمة عامل الـ quantization (QP)i التي تـُطبق على الـ P-frames ثم من خلال أوامر أخرى سنتعرض إليها لاحقاً يحدد الانكودر الـ qp الخاص ببقية أنواع الفريمات. عند استعمال الـ i--qp فإن الحجم النهائي للفيديو المضغوط يكون مجهولاً. القيم التي يمكن أن يأخذها هذا الأمر تمتد من 0 إلى 51. القيمة صفر تنتج لكل لوسلس (إن التزمت ببعض الشروط) والقيمة 51 تنتج لك فيديو بأسوء "جودة" ممكنة.
إن كنت ستستعمل هذا الأمر فالخبراء ينصحون باستعمال i--crf بدله.
القيمة الافتراضية "غير مفعل"
i--bitrate
ينتج لك فيديو بحجم محدد مسبقاً. أسلوب الـ quantization هنا تناسبي، لكن ليس من أجل الوصول إلى جودة أعلى، بل من أجل الالتزام بحجم معلوم مسبقاً. عند استخدام هذا الأسلوب تكون الجودة النهائية للفيديو غير معلومة. القيمة التي يأخذها هذا الأمر هي البترايت المرغوب فيه بالكيلوبت في الثانية (1 بايت = 8 بت، 1 كيلوبايت = 8×1024 بت). لم يعد أحد يستعمل هذا الأسلوب في 2010، لا داعي لأن تستخدمه في الفانسب. القيمة الافتراضية "غير مفعّل"
i--crfi أسلوب التحكم في الجودة الأكثر تقدما. قلنا أن qp يطبق أسلوب quantization متماثل (uniform)، الـ crf يطبق أسلوب quantization تناسبي (adaptative) فيخفض من قيمة الـ QP بالنسبة للفريمات التي تحتوي تفاصيل معقدة ويزيد منها في الفريمات التي تنتمي إلى مشاهد الحركة والفريمات الفقيرة من التفاصيل. الـ crf يعطي نفس جودة الـ qp عند استعمال نفس القيمة لكليهما، لكن بحجم أقل. القيم التي يمكن أن يأخذها هذا الأمر تمتد من 0 (لوسلس~) إلى 51. قيم بين 23 و18 تعطي عادة جودة لا بأس بها مع حجم مناسب لجميع المصادر. القيمة الافتراضية هي "مفعّل بقيمة 23"
i--vbv-bufsize
الـ vbv (Video Buffering Verifier) i هو "ديكودر افتراضي" على مستوى الانكودر، وظيفته هي وضع قيود على درجة تغير معدل البيانات التي يسمح للانكودر بإنتاجها. فائدته تظهر عند البث التلفزي أو المحادثات المصورة المباشرة (videoconference) وحين تود الإنتاج من أجل المشاهدة على جهاز محدد (عادة تجد المعلومات المتعلقة بالـ vbv في دليل الاستخدام أو على الجهاز ..). لا تستخدم هذا الأمر إن كنت تريد الإنتاج للمشاهدة على الحاسب لأنه يضر بالجودة.
قيمة الـ vbv-bufsize تكون بالكيلوبت.
القيمة الافتراضية هي 0.
i--vbv-maxrate
يحدد لك المعدل الأقصى الذي يمكن تدخل به البيانات إلى الـ Buffer. هذه القيمة تكون مساوية لسرعة الاتصال بالنسبة للمشاهدة المباشرة، سرعة قارئ الأقراص (disk read speed). هذا الأمر لا يحد من معدل البترايت في الفيديو إلا إذا لم يعد الـ buffer يحتوي على مساحة كافية لتخزين البيانات، أي إلا إذا اقتربت من قيمة vbv-bufsize. كما هو الحال مع الأمر السابق، لا تستخدم هذا الأمر إن كنت تريد الإنتاج للمشاهدة على الحاسب لأنه يضر بالجودة.لن يُفعّل الـ vbv إلا إذا فعلت هذا الأمر وسابقه معاً.
قيمة الـ vbv-maxrate تكون بالكيلوبت في الثانية.
القيمة الافتراضية هي 0.
i--vbv-init
يحدد القدر الذي يجب أن يكون الـ buffer ممتلئاً به قبل أن يُسمح ببداية عرض الفيديو. قيمة صفر تعني أنك يمكنك أن تبدأ مباشرة حتى وإن كان الـ buffer فارغاً. قيمة 1 تعني أنك لا يمكنك أن تبدأ عرض الفيديو إلا بعد امتلاء الـ buffer بالكامل. قيمة 0.9 تعني أنه لا يمكنك بدأ عرض الفيديو إلا بعد امتلاء الـ buffer بنسبة 90%... وهكذا.
القيمة الافتراضية هي 0.9. لا يعمل هذا الأمر سوى إن فعلت vbv-bufsiz وvbv-maxrate معاً.
i--pass
ينتج الفيديو عبر المرور على المصدر كذا مرة لاستخراج البيانات ووضعها في ملف. لا فائدة له مع الـ crf والـ qp، يستعمل حين الإنتاج بـ --bitrate فقط. لم يعد أحد يستعمل هذا الأسلوب في الفانسب، على العموم إن أعطيته القيمة 1 فسيضع المعلومات في الملف stats وإن أعطيته 2 فسينتج لك الفيديو بالاعتماد على المعلومات في ملف الـ stats وإن أعطيته 3 فسيحدث لك ملف الـ stats.
القيمة الافتراضية هي "غير مفعّل".
i--stats
يحدد المسار الذي سيكتب/يقرأ منه الانكودر ملف الـ stats. ملف الـ stats يكون بامتداد log.
القيمة الافتراضية هي :’ x264_2pass.log’
i--qpmin
يحدد أدنى قيمة يمكن أن يأخذها الـ QP. تخفيض الـ qpmin يؤدي إلى زيادة الجودة على حساب الحجم؛ أحياناً قيمة 2 لـ qpmin تعطي حجماً أكبر من اللوسلس نفسه o_O. الرفع من قيمة qpmin يسبب انخفاض في جودة "أجزاء الصورة الأقل أهمية" مثل الخلفيات الساكنة.
تغيير قيمة الـ qpmin غير منصوح به عموماً. القيم الممكنة تمتد من 0 إلى 51.
القيمة الافتراضية : 10
i--qpmax
يحدد أقصى قيمة يمك أن يأخذها الـ QP. تخفيض الـ qpmax يؤدي إلى زيادة الجودة الفيديو، هذه الزيادة تستفيد منها "أجزاء الصورة الأقل أهمية" أكثر من غيرها. القيم تمتد بين 51 إلى 0. عموماً، لا يجب أن تنزل تحت الـ 40. والخبراء ينصحون بعدم تغيير القيمة الافتراضية.
القيمة الافتراضية: 51.
i--qpstep
يحدد أقصى حد يمكن تبلغه درجة تغيير الـ QP بين فريمين. قيمة كبيرة للـ qpstep تسبب اختلافاً كبيراً في الجودة بين فريمين متتاليين، قيمة صغيرة للـ qpstep. تتسبب في تبذير بترايت بلا فائدة.
القيمة الافتراضية: 4، غيرها إن كنت تعتقد أنك تجيد التحكم في الجودة أكثر من الانكودر.
i--crf-max
مثل الـ qpmax غير أنه يحدد أقصى crf يمكن أن تبلغه. لا فائدة من هذا الأمر إلا إن كنت تنتج بالـ crf ولديك ضوابط متعلقة بالـ VBV، في هذه الحالة فإن الانكودر لن ينتج الفيديو بجودة أقل من crf-max حتى إن أدى هذا إلى تجاوز ضوابط الـ VBV.
القيمة الافتراضية هي "غير مفعّل"
i--ratetol
معناه rate tolerance أو مستوى التسامح في تجاوز البترايت المحدد. يُستعمل هذا الأمر في حالتين :
- عند الإنتاج بـ pass واحد مع بترايت ثابت (i--pass 2 --bitrate x)، قيمة 10 تعني أن الانكودر يستطيع ضخ بترايت أكثر بـ 10% من القيمة المحددة بواسطة bitrate.
- عند استعمال الـ VBV، يسمح هذا الأمر للبترايت بتجاوز القيود التي يفرضها الـ VBV عند الحاجة مما يسمح بجودة. لكن في هذه الحالة من الممكن ألا تتمكن من مشاهدة الفيديو على الجهاز.
القيمة الافتراضية: 1
i--qcomp
يحدد مستوى تغير تركيز البترايت بين المَشاهد حسب تعقيدها. القيم الممكنة تمتد من 0 إلى 1.
القيمة 0 تعني أن جميع المَشاهد ستأخذ نفس البترايت مما يعطي المَشاهد البطيئة حجماً أكثر مما تستحقه ويحرم مشاهد الحركة من حجم كان من الممكن أن يزيد جودتها.
القيمة 1 تعني أن جميع المَشاهد سيكون لها نفس الجودة أي كأنك تستخدم i--qp
تخفيض الـ qcomp يؤدي إلى أن يكون البترايت متقارباً بين المشاهد والجودة متفاوتة. زيادة الـ qcomp تؤدي إلى أن تكون الجودة مستقرة على طول الفيديو في حين يكون البترايت متفاوتاً.
القيمة الافتراضية : 0.6. من المحبذ ألا تخرج من [0.55 , 0.75] إلا إذا كانت لديك أسباب وجيهة. فيما خلاف هذا فلا تعبث بالقيمة الافتراضية.
i--no-mbtree
الـ MacroBlock Tree Rate Control المعروف بـ MB-Tree هو تعميم للـ qcomp على مستوى الماكروبلوك (بدل المَشاهِد) وفائدته هي زيادة فعالية الضغط الجملي للفيديو وزيادة الجودة.
بشكل أكثر تفصيلا، فإن الـ MB-Tree Rate Control يخفض جودة (يعني يرفع الـ qp الخاص بـ) المقاطع (ماكروبلوكات) الأكثر تعقيداً فقط من مشاهد الحركة بدل تخفيضها في المشهد كله.
تحديد إن كان المقطع معقداً أم لا، وقدر تخفيض الجودة الذي يلزمه يقع عبر "اقتفاء أثر المقطع" في الفريمات المستقبلية.
أيضاً، MB-Tree تخفض جودة المقاطع التي لا تقع "استعارة" البيانات منها بشكل مكثف. MB-Tree لا تعمل جيداً مع الاختفاء التدريجي للصورة (fades) إلا مع بعض b-adapt 2 وبعض الأوامر الأخرى والتي سنتعرض لها.
هذا الأمر يعطل استعمال الـ MB-Tree.يُنصح بعد استعمال هذا الأمر لأن MB-Tree تزيد فاعلية الضغط.
زيادة qcomp تضعف من تأثير MB-Tree
القيمة الافتراضية هي "غير مفعّل"
i--rc-lookahead
له وظيفتان:
- يحدد عدد الفريمات التي "سيقتفي الانكودر أثرها" عند استعمال الـ MB-Tree. قلتُ الانكودر، لا الديكودر. القيمة التي ستأخذها MB-Tree هي العدد الأصغر بين rc-lookahead وkeyint.
- يسمح للـ VBV بالعمل مع الـ crf بشكل أفضل.
زيادة قيمة rc-lookahead تؤدي إلى زيادة فعالية الضغط -في أغلب الأحيان- لكن على حساب سرعة الانتاج والحاجة إلى ذاكرة عشوائية كبيرة.
ارفع الـ rc-lookahead فوق المئة إن بلغت درجة لا بأس بها من عدم الاكتراث للسرعة/إعطاء الأولوية القصوى والمطلقة لفعالية الضغط.
القيمة الافتراضية: 40
i--ipratio
يحدد مدى زيادة معدل جودة الـ I-frame مقارنة بالـ P-frame. زيادة هذه القيمة تؤدي إلى زيادة جودة الـ I-frame دون التأثير - بشكل مباشر- على جودة بقية أنواع الفريمات. زيادة جودة الـ I-frames تؤدي إلى زيادة جودة الفريمات التي "تستعير" منها بياناتها. زيادة جودة الـ I-frames تؤدي إلى زيادة في الحجم. تخفيض الـ ipratio يؤدي إلى تخفيض جودة الـ I-frames دون التأثير -بشكل مباشر- على جودة بقية أنواع الفريمات.
القيمة الافتراضية : 1.4 وهي مناسبة لأغلب المصادر ويُنصح بتخفيضها حتى 1.1 للمصادر التي تحتوي على grain أو الفيديو الذي يحتوي على حركة سريعة فتكون أغلب الـ GOPs قصيرة مما يخفف من أهمية الـ I-frames.
i--pbratio
يحدد مدى انخفاض معدل جودة الـ B-frames مقارنة بالـ P-frames. زيادة هذه القيمة تؤدي إلى المزيد من انخفاض جودة الـ B-frames زيادتها تؤدي إلى العكس. طبعاً معدل جودة الـ P-frames يبقى ثابتاً ولا يتأثر بشكل مباشر.
القيمة الافتراضية : 1.3 لا يُنصح بتغييرها إلا عند التعامل مع مصادر تحتوي على grain فلا بأس من تخفيضها إلى 1.1
عند استعمال الـ MB-Tree لا تقلق نفسك باللعب بهذه القيمة لأن الـ MB-Tree سيتكفل باختيار القيمة المناسبة وحده.
i--chroma-qp-offset
يحدد مستوى زيادة أو نقصان جودة مكونات الكروما (أو الألوان) مقارنة باللوما (أو السطوع). قيم إيجابية تزيد من جودة الكروما في حين أن القيم السلبية تخفض منها. يذكر أن العين البشرية تتأثر باللوما أكثر من الكروما، لذا ستصعب رؤية هذا النقصان في الجودة.
القيمة الافتراضية : 0 يمكنك التخفيض منها بواحد أو اثنين إن كنت تدرك ما تفعله جيداً، وإلا فاتركها كما هي.
i--aq-mode
يحدد خوارزمية التحكم التناسبي في توزيع الجودة (adaptative quantization). فائدته هي التوزيع الأفضل (و"العادل") للبترايت على جميع الماكروبلوك لأن الانكودر يميل إلى تجويع الماكروبلوكات التي لا تحتوي على تفاصيل مما يؤدي إلى ظهور مربعات (blocks) أو تدرج غير متناسق للألوان (banding).
لدينا 3 قيم ممكنة:
0 : يعطل التوزيع التناسبي للجودة.
1: يسمح بالتوزيع التناسبي للجودة بأسلوب ثابت.
2: يسمح بالتوزيع التناسبي للجودة بأسلوب متغير؛ أي أن الانكودر يلائم من أسلوبه في التوزيع التناسبي بطريقة تناسبية. هذا هو الأسلوب الأفضل، كان لا يعمل جيداً مع Mb-Tree أما الآن فقد حُلّت جميع مشاكله.
القيمة الافتراضية: 1
i--aq-strength
يحدد مدى ميلان التوزيع التناسبي للجودة نحو "إشباع" الماكروبلوكات الفقيرة من التفاصيل. يجب أن تكون القيمة إيجابية. زيادة الـ aq-strength تساعد على التخلص من الـ banding والمربعات على حساب زيادة في الحجم في حالة الانتاج بالـ crf أو على حساب المقاطع التي لا تحتوي على هذه العيوب في حالة الانتاج بالـ bitrate.
القيمة الافتراضية :1
لا يجب زيادة أو تخفيض aq-strength بأكثر من 100%، يعني خليك في [0,2]. وعموماً لا يجب أن تخرج من [0.5, 1.5].
i--cplxblur
يطبق نوع (guassian) من البلور على الفريمات من أجل الحد من تفاوت الجودة. اعبث به إن كنت لا زلت لا تنتج بالـ crf وتعتقد أن البلور جميل.
القيمة الافتراضية: 20
i--qblur
يطبق بلور بطريقة أخرى، مثل سابقه. ليس إعداداً مهماً
القيمة الافتراضية: 0.5
i--zone
يطبق بعض الإعدادات المعينة على مقاطع محددة من الفيديو. باستعمال هذا الأمر يمكنك تحديد إعدادات مختلفة عن الإعدادات العامة لبعض مقاطع الفيديو.
يكتب هذا الأمر كما يلي:
كل منطقة تبدأ بالفريم الأول منها ثم الفريم الأخير ثم الإعدادات وفاصلات بين جميع القيم.
المناطق المتعددة يُفصل بينها بـ ‘/’
لتحديد البترايت تكتب b=value، حيث value هي قيمة ضرب البترايت الأصلي للحصول على البترايت في المنطقة.
لتحديد الـ QP تكتب q=value حيث value هي قيمة الـ QP المراد.
الإعدادات التي يمكن تغييرها هي:
ref: لا تستطيع تجاوز العدد المحدد في الإعدادات العامة.
b-bias=value
scenecut=value: إذا كانت مفعلة في الإعدادات العامة.
no-deblock
deblock=alpha:beta
deadzone-intra=value
deadzone-inter=value
direct=value
merange=value: لا يمكنك تجاوز القيمة الأصلية إن كنت تستعمل esa أو tesa.
nr=value
subme=integer: لا يمكنك تغييرها إن كانت 0 في الأصل.
trellis=value
psy-rd=rdo:trellis
no-chroma-me
no-dct-decimate
no-fast-pskip
no-mixed-refs
b-pyramid=value
no-8x8dct
me=value: لا يمكنك رفعها إلى esa أوtesa إن كانت dia,hex أو umh في الأصل.
مثال:
i--zone 0,1000,b=2/1001,2000,q=20,deblock=-1:-1,ref=6
القيمة الافتراضية هي "غير مفعّل"
i--qpfile
يسمح لك بالتحكم يدوياً في أنواع الفريمات والـ QP الخاص بهم عن طريق تحديد ملف يكون على هذا الشكل:
ترتيب_الفريم_في_الفيدوي نوع_الفريم الـQP_الخاص_به
أنواع الفريمات تأخذ الأحرف التالية:
IDR-Frame = I
I-frame = i
P-Frame = P
B-frame = B
b-Frame = b
Keyframe = K
B ترمز إلى B-frame يقع استعمال على شكل فريم مرجعي
b ترمز إلى B-frame لا يقع استعمال على شكل فريم مرجعي
K ترمز إلى IDR-frame إن كنت لا تستعمل الـ open-gop وإلا فإنها ترمز إلى I-frame يمكن بداية GOP به.
إعطاء -1 لقيمة الـ QP تعني السماح للانكودر باختيار ما يراه أفضل.
لست بحاجة لتحديد جميع الفريمات.
لا تعبث بهذا الأمر إلا إذا كنت تدرك ما تفعله جيداً.
القيمة الافتراضية هي "غير مفعّل" -----------
المسلي في الأمر أن كل الحديث السابق ليس، في حقيقة الأمر، حول التحكم في توزيع الجودة بل حول التحكم في توزيع ضياع الجودة لأن الـ QP يعني مستوى خسارة الجودة مقارنة مع الإشارة الأصلية. Happy Xmas
5 - إعدادات تحليل معطيات الفيديو
That's why people should at least mess with the CLI and not depend on any silly GUIs to find out what the heck is actually going on
i--partition
كما قلنا في الموضوع السابق، الكوديك H.264 يسمح بتقسم الماكروبلوكات إلى بلوكات ذات أبعاد أقل أثناء عملية الضغط. الانكودر x264 يسمح بتقسيم الماكروبلوكات إلى هذه الأبعاد: 4×4،8×4،4×8،8×8،8×16 و 16×8.
القيم الممكنة حسب نوع الفريم:
I-frame: i4x4,i8x8
P-frame: p8x8 (التي تفعل p8x16 وp16x8 أيضاً)p4x4, (التي تفعل p4x8 وp8x4 أيضاً)
B-frame: b8x8 (التي تفعل b8x16 وb16x8 أيضاً)
كلما قسمت الماكروبلوكات أكثر ازدادت قدرة الانكودر على تخمين الحركة (motion estimation) بشكل أفضل وازدادت فعالية الضغط وارتفعت الجودة. بالنسبة للـ I-frames فمن الأفضل أن تفعل جميع الخيارات لأنه كلما زادت جودة هذه الفريمات زادت الجودة الكلية للفيديو.بالنسبة للـ P-frames فتفعيل p4x4 لا يضر مع الأبعاد المتوسطة (480p) لكن فائدته ضئيلة، أما مع الأبعاد الكبيرة فإنه يأخذ وقتاً لا بأس به دون فائدة تُذكر.
ما يُنصح به هنا هو ترك الإعدادات الافتراضية كما هي.
القيمة الافتراضية هي : p8x8,b8x8,i8x8,i4x4
لا يمكنك الاستفادة من i8x8 إلا عند استعمال i--profile high أو i--profile high10
--no-8x8dct
التطبيق التناسبي للـ DCT على البلوكات 8×8 (adaptative 8x8 DCT Transform) المنتمية للـ I-frames يرفع من فعالية الضغط ويزيد الجودة لكنه غير متاح إل في البروفايل high وhigh10. هذا الأمر يعطله.
تفعيل هذا الخيار يحرمك من أحد أهم مميزات الكوديك H.264.
القيمة الافتراضية هي "غير مفعل"
i--me
يحدد أسلوب تخمين الحركة على مستوى الخانات. القيم المتاحة: dia: أسرع أسلوب ويعطي نتائج سيئة فيما يخص الجودة. لا تستعمله إلا إذا كانت السرعة والسرعة وحدها هي أولويتك. hex: أقل سرعة من dia. يعطي نتائج لا بأس بها مقارنة بـ dia وبسرعة مرضية. umh: أبطئ من hex ويعطي نتائج أفضل. إن كنت تهتم للجودة ولديك معالج أفضل من pentium IV فسترغب في استعمال هذا بدل hex وdia. esa: أبطئ من umh بكثير (مرتين تقريباً). لا تستعمله إلا إذا بلغت درجة عالية جداً من عدم الاكتراث بالسرعة. يعطي، أحياناً، نتائج أفضل بقليل من umh. tesa: أبطئ حتى من esa (20-30%)i. استعمله إذا كان لديك حاسب بـ 48 نواة (لول) أو الكثير جداً من الوقت كي تضيعه.
عموماً، إن كنت ستستعمل esa فاستعمل هذا مرة واحدة وكمّل المعروف. يعطي، أحياناً، نتائج أقل بقليل من umh وأقل بقليل جداً من esa.
الخبراء ينصحون بالابتعاد عن dia قدر الإمكان، واستعمال umh إن لم تكن السرعة هي الأولوية القصوى.
esa وtesa أشبه بالانتحار أو الجنون.
القيمة الافتراضية:hex
--subme
يحدد مدى تعقيد الـ subpixel motion estimation التي تحدثنا عنها في الموضوع السابق. هناك إحدى عشر قيمة ممكنة من 0 إلى 10. استعمال قيمة أقل من 2 يضر بعمل الـ lookahead والـ scenecut. كلما زادت القيمة انخفضت السرعة، لكن على عكس me، تزيد الجودة هنا بشكل مرضي.
القيمة الافتراضية :7 وهي جيدة لأغلب المصادر والانتقال من 7 إلى 8 فما أكثر يعطي نتائج أفضل خاصة إن كانت هناك مشاهد حركة كثيرة.
i--subq
مثل subme تماماً. ما الفائدة منها ؟ لا أعلم، اسأل مطوري الانكودر.
i--merange
يحدد المدى الأقصى "لمجال عمل تخمين الحركة" بالبكسل. لا يمكنك تجاوز 16 مع me بقيمة dia أو hex. لكن، يمكنك تجاوز 16 مع umh,esa وtesa. زيادة merange تؤدي إلى زيادة وقت الإنتاج. زيادة merange تكون مفيدة مع الأبعاد الكبيرة لأن الأجسام تكون أكبر مما يعني مجالاً أكبر -بالبكسل- لحركتها.
القيمة الافتراضية:16 وهي مناسبة جداً بالنظر إلى عامل السرعة/فعالية الضغط. وعموماً لن ترغب في تجاوز 32.
i--mvrange
يحدد الطول الأقصى لاتجاه الحركة (motion vector) عمودياً بالبكسل.
القيمة الافتراضية: 1- أي أن الانكودر يقدر القيمة وحده. لا داعي للعبث بهذه القيمة.
i--mvrange-thread
لست بحاجة لمعرفة وظيفته.
القيمة الافتراضية: 1- إياك أن تعبث بها.
i--direct
سنحتاج إلى بعض التعريفات؛
skip: هو الماكروبلوك الذي لا يحتوي على أي بيانات باستثناء إشارة (flag) تدل على أنه skip. هذه الإشارة يمكن أن تكون مشتركة لعدة ماكروبلوكات. مثلاً، مقاطع الفريم الثابتة والمكررة في فريمات أخرى تكون skip. في الكوديكات التي سبقت H.264 لا يمكن أن يكون ماكروبلوك skip إذا كان متحركاً بين الفريمات. لكن، H.264 أتاح للماكروبلوكات المتحركة أن تكون skip من خلال اتجاه الحركة (motion vector)مما يساعد على تخفيض الحجم.الـ skip يمكن أن يكون في B-frame أو P-frame.
direct: هذا بلوك لا يمكن أن يوجد سوى في B-frame وهو بلوك متحرك لكن دون إسناد اتجاه حركة له على مستوى الـ bitstream. كيف يمكن تحديد مكانه إذاً ؟ من خلال تخمين اتجاه حركته إما بالاعتماد على اتجاهات حركة البلوكات المجاورة له في نفس الفريم أو بالاعتماد على اتجاهات حركة نظرائه من البلوكات في الفريمات المرجعية (سواء كانت مستقبلية أو ماضية؛ تذكر، direct لا يكون سوى في B-frame)
forward: هو الماكروبلوك الذي ينتمي إلى B-frame وله اتجاه حركة مأخوذ من فريمات ماضية فقط.
backward: هو الماكروبلوك الذي ينتمي إلى B-frame وله اتجاه حركة مأخوذ من فريمات مستقبلية فقط.
bidirectionnal: هو الماكروبلوك الذي ينتمي إلى B-frame وله اتجاه حركة مأخوذ من الفريمات السابقة والماضية معاً.
هذا الأمر يحدد أسلوب تخمين اتجاه الحركة في البلوكات المنتمية إلى B-frame. يعني بدل أن يكتب الانكودر بيانات اتجاه الحركة في الـ bitstream يضع إشارة تدل الديكودر على طريقة تخمين اتجاه الحركة. لدينا 4 قيم ممكنة:
none: يعطل تخمين اتجاه الحركة. هذا يضر بالجودة في حالة الإنتاج بحجم ثابت ويزيد في الحجم في حالة الإنتاج بالـ crf أو الـ qp.
spatial: يفعّل تخمين اتجاه حركة البلوك بواسطة الاعتماد على اتجاهات حركة البلوكات المجاورة له في نفس الفريم.
temporal: يفعّل تخمين اتجاه حركة البلوك بواسطة الاعتماد على اتجاهات حركة نظرائه من البلوكات في الفريمات المرجعية.
auto: يفعّل تخمين اتجاه حركة البلوك ويسمح للانكودر باختيار ما يراه أفضل بين saptial وtemporal.
temporal يكون أفضل عندما تكون لديك حركة انسيابية. spatial أفضل عندما تكون لديك حركة غير انسيابية مثل الأنيمي.autoيأخذ وقتاً أكثر بقليل (قليل جداً) من بقية الخيارات لكنه أسلم لك.
القيمة الافتراضية: auto
i--no-chroma-me
تخمين الحركة يعمل مع اللوما والكروما. هذا الأمر يعطل تخمين حركة مكونات الكروما في مقابل زيادة طفيفة للسرعة وضرر بالجودة.
القيمة الافتراضية هي "غير مفعّل"
i--weightp
يسمح للانكودر بإعطاء ثقل لدرجة تأثير كل واحدة من الفريمات المرجعية على الـ P-frame الذي سينتج عن تعويض الحركة. هذا الأمر يساعد على التخلص من العيوب (banding, blocks) التي تظهر بسبب الاختفاء التدريجي للصورة أو تداخل مشهدين (fade). القيم المتاحة هي:
0: يعطل هذا الأمر
1: يفعّل الأمر باستخدام أسلوب غير دقيق وتنقصه الفعالية.
2: يفعّل هذا الأمر بأسلوب جيد ويعطي نتائج جيدة خاصة مع MB-Tree.
كلما زادت القيمة انخفضت السرعة نسبياً.
القيمة الافتراضية:2. لا تغيرها إلا إذا كنت تحتاج حقاً إلى تغييرها.
i--no-weightb
الكوديك H.264 يسمح للانكودر بإعطاء ثقل للفريمات المرجعية التي تؤثر على الـ B-frames أيضاً. هذا الأمر يعطل تلك الخاصية.
القيمة الافتراضية هي "غير مفعل"
لا تـُفعّل هذا الأمر إلا إذا كانت السرعة أهم من الجودة بالنسبة لك.
i--deadzone-intra
i--deadzone-inter
خوارزمية الـ deadzone تـُستعمل عند الـ quantization وتأثيرها هو تحويل قيم عناصر الـ DCT "القريبة" من الصفر إلى صفر. يعني، بالعربي، خوارزمية الـ deadzone تتخلص من التفاصيل الدقيقة (التي قد لا تلاحظها العين). هذان الأمران يُفعلان اعتماد هذه الخوارزمية ويحددان إلى أي مدى يُسمح لهذه الخوارزمية بالتخلص من التفاصيل الدقيقة.كلما انخفت القيم حافظ الانكودر على تفاصيل دقيقة أكثر وكلما ازدادت القيم تخلص الانكودر من تفاصيل دقيقة أكثر. عند التعامل مع مصدر يحتوي على grain يُنصح بتخفيض القيم من أجل الحفاظ على الـ grain. التفاصيل الدقيقة يمكن أن تكون وشوشة أيضاً (noise). القيم التي يمكن أن يأخذها كلا الأمران تتراوح بين 0 إلى 32.
القيمة الافتراضية هي "غير مفعّل"
i--trellis
خوارزمية quantization أخرى. لم أفهمها جيداً لأنها معقدة كثيراً. لكن أستطيع القول إنها تعمل على ملائمة عملية الـ quantization كي تسمح بعمل entropy encode أكثر فعالية. القيم المتاحة:
0: يعطل استعمال trellis، في هذه الحالة سيستعمل الانكودر الـ deadzone دائماً.
1: يفعّل استعمال trellis في المرحلة الأخيرة والأهم من الـ quantization. أي أن dead zone يبقى لها تأثير هنا، لكنه ضعيف.
2: يفعل الـ trellis وحدها في كل مراحل الـ quantization. يضر بسرعة الإنتاج بشكل لا بأس به لكنه يزيد من فعالية الضغط.
جدير بالذكر أن trellis سواء 1 أو2 أفضل من deadzone فيما يخص فعالية الضغط. deadzone أسرع من trellis لكنها أقل فعالية. deadzone تساعد على المحافظة على الـ grain أكثر من trellis.
القيمة الافتراضية:مفعّل بقيمة 1
i--psy-rd
العين البشرية لا تريد أن تكون الصورة المضغوطة مثل الصورة الأصلية فقط. بل تريدها أن تكون مثلها في درجة التعقيد. لهذا فإننا نفضل رؤية بلوك مشوش لكن يحتوي على تفاصيل على رؤية بلوك غير مشوش لكن ممسوح التفاصيل (بلور). هذا الأمر يسمح بفعل هذا الشيء من أجل المحافظة على التفاصيل الدقيقة (خاصة الـ grain). هذا الأمر يأخذ قيمتين ليكون على هذا الشكل :
i--psy-rd strength:trellis
strength: مدى استعداد الانكودر لتشويش الصورة من أجل الحفاظ على التفاصيل. لا يعمل إلا إذا كانت subme>5. القيمة الافتراضية: 1 لكنها لا تبقى ثابتة طول الفيديو بل تنخفض وترتفع مع الـ QP
trellis: لا أعلم بالضبط ما وظيفتها. لا تعمل إلا مع trellis>0. القيمة الافتراضية: 0
يُذكر أن psy-rd تخفض من الكروما لفائدة اللوما. كما يُذكر أنه في i--tune animation تكون قيم psy-rd منخفضة جداً لأن المبرمجين وضعوها على أساس العمل مع الكرتون (الأمريكي تحديداً) الذي لا يحتوي على أي تفاصيل تقريباً، لذا من المستحسن أن ترفعها دائما على الأقل إلى i--psy-rd 0.6:0
i --no-psy
يعطل عمل psy-rd.
القيمة الافتراضية هي "غير مفعّل"
i--no-mixed-refs
يمكن استعمال أكثر من فريم مرجعي لاستعارة البيانات منه داخل بلوك واحد وهذا عبر تقسيم الماكروبلوك إلى بلوكات بأبعاد 8×8 بدل أن تستعمل كل البلوكات داخل ماكروبلوك واحد نفس الفريمات المرجعية. هذا الأمر يلغي هذه الإمكانية ويضر بالجودة ويزيد من سرعة الإنتاج.
القيمة الإفتراضية هي "غير مفعّل". لا تفعّل هذا الأمر إلا إذا كنت تهتم للسرعة أكثر من الجودة.
i--no-fast-pskip
يعطل الاكتشاف المبكر للبلوكات التي لن يكتب الإنكودر لها أي بيانات في الـ bitstream. هذا الأمر يزيد الجودة قليلاً ويخفض من سرعة الإنتاج كثيراً.
القيمة الافتراضية هي "غير مفعّل"
i--no-dct-decimate
يعطل تجاهل عناصر الـ DCT التي يراها الانكودر غير ضرورية. تجاهل هذه العناصر يزيد من فعالية الضغط في مقابل ضياع القليل من الجودة "عادة".
القيمة الافتراضية هي "غير مفعّل". إن كنت تود المحافظة على الـ grain في المصدر فسيكون من المفيد أن تفعّل هذا الأمر.
i--nr
يقلل من الوشوشة (noise) الموجودة في المصدر. كلما زادت القيمة أكثر زاد تخلص الانكودر من التفاصيل الدقيقة (يمكن أن تكون وشوشة ويمكن ألا ىتكون كذلك). تقليل الوشوشة بواسطة هذا الأمر أقل فعالية من الفلاتر الخارجية بكثير لكنه أسرع بكثير.
القيمة الافتراضية:0. إن كنت تريد استعماله فجرب قيم بين 100 و1000.
i--cqm
يحدد الـ quantization matrice. لا داعي لأن تعرف ما هي خاصة أن فعاليتها تنخفض مع استعمال الـ AQ وMB-Tree.
القيمة الافتراضية: flat. لا تغيرها إلا إذا كنت تعلم ما تفعله.
i--cqmfile
يستعمل quantization matrice خارجية على شكل ملف cfg. القيمة التي يأخذها هي مسار هذا الملف. لا تستعمله إلا إذا كنت تدرك ما تفعله جيداً.
القيمة الافتراضية هي "غير مفعّل"
, i--cqm4i, --cqm4p, --cqm8i, --cqm8p,--cqm4
, i--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc, --cqm8
مجموعة أوامر على علاقة بالـ quantization matrice. لا تعبث بها.
6 -إعدادات أخرى
لن أتحدث عن جيمع الإعدادات المتبقية، بل سأذكر أهمها فقط (أو بالأحرى، أقلها قلة أهمية).
i--fullrange
يحدد ما إن كانت قيم الخانات ستأخذ قيم بين [0،255] أو بين [16، 235] أثناء عرض الفيديو. لا فائدة من هذا الأمر إلا إذا كنت تخطط لمشاهدة الفيديو على تلفاز. القيم المتاحة:
off: يُفعل استعمال [16، 235]
on: يُفعل استعمال [0،255]
لا تستعمله إلا إذا كنت تعلم طبيعة مصدرك. في هذه الحالة اختر نفس قيمته.
عموماً، لا تأثير مهم له عند التشغيل على الحاسب لأن الديكودر سيتجاهله في أغلب الأحيان.
القيمة الافتراضية: off
i--colormatrix
يحدد الجدول الذي يستعمله الديكودر كي يحول الألوان إلى RGB. هذا التحويل لا يقع عادة إلا إذا أراد المستخدم ذلك عبر تغيير إعدادت الديكودر. القيم المتاحة هي :
القيمة الافتراضية هي undef. إن كنت تعلم الجدول الخاص بالفيديو الذي تعمل عليه فاختر القيمة المناسبة أو اترك القيمة الافتراضية كما هي.
i--chromaloc
إن كنت تنتج من MPEG1 دون أي تغيير في الألوان فضع القيمة 1 أو تجاهل هذا الأمر إن لم فيما الحالات أخرى.
بالنسبة للأوامر السابقة في هذه الفقرة فلا يوجد أي ضمان أن الديكودر سيحترم ما وضعته.
i--nal-hrd
إن كنت تنتج للبلوراي باستعمال البترايت فضع القيمة cbr وإن كنت تنتج للبلوراي باستعمال الـ crf أو الـ qp فضع القيمة vbr. تجاهل هذا الأمر إن لم تكن تنتج للبلوراي.
i--pic-struct
يجب أن تضعها إن كنت تستعمل i--bff أو i--tff أو i--pulldown
لا تضعها إن لم تكن تستعمل تلك الإعدادات.
i--muxer
يحدد الحاوي الذي سيضع فيه الانكودر الفيديو المضغوط. الخيارات المتاحة:
auto, raw, mkv, flv, mp4
عند اختيار auto سيكتب الانكودر الفيديو في الحاوي المحدد بواسطة --output
القيمة الافتراضية:auto
جدير بالذكر أن الإنكودر يضغط الفيديو فقط مما يعني أنه سيكتب (muxing) الفيديو فقط ضمن الحاوي. الـ muxer يضيف معلومات إضافية (headers) لملف الفيديو كي يتعرف الـ demuxer على الطريقة المناسبة لقراءته.
i--demuxer
يحدد الأداة (ديكودر) التي سيستعملها الانكودر لقراءة المصدر. القيم المتاحة:
auto: يختار الانكودر الأداة المناسبة للمصدر وحده.
raw: تـُستعمل إذا كان المصدر خاماً بالفعل. يعني فيديو غير مدموج داخل حاوي.
y4m: تستعمل إذا كان المصدر بنظام ألوان yuv وبحاوي mpeg1,2,4.
avs: يأخذ الانكودر الفيديو من سكربت avs
lavf: يستعمل الانكودر مكتبة lavf الخاصة بحاوي avi.
ffms: يستعمل الإنكودر فلتر ffms2.
القيمة الافتراضية: auto. لا تغيرها إلا إذا كانت لك أسباب وجيهة
i--fps
يحدد سرعة فريمات الفيديو حين الانتاج بسرعة فريمات ثابتة. القيم يمكن أن تكون عشرية (23.076) أو كسرية (1001/24000). إن لم تحدده يدوياً فسيحاول الانكودر اكتشاف القيمة المناسبة وحده بالاعتماد على demuxer وإلا فسيضعها 25.
i--sar
يحدد الـ sample aspect ratio الخاص بالفيديو. شرحه مزعج، المزيد من المعلومات هنا أو هنا أو هنا.
i--seek
يحدد الفريم الذي سيبدأ الإنكودر بإنتاجه. هذا الخيار يسمح ببداية إنتاج الفيديو من أي فريم في الفيديو.
i--frames
يحدد عدد الفريمات الأقصى التي يُسمح للانكودر بإنتاجها. في هذه الحالة سيتوقف الإنتاج عند بلوغ هذه القيمة حتى إن لم ينته الفيديو. هذا الأمر والذي قبله مفيدان حين اختيار الإعدادات الأفضل، فيضغط المنتج عدداً معيناً من الفريمات أولها محدد بواسطة seek وينظر إلى مفعول إعداداته ويغير منها إن تتطلب الأمر.
i--psnr
يسمح للإنكودر بحساب الـ PSNR ووضع النتائج في تقرير نهاية الإنتاج.
i--ssim
يسمح للإنكودر بحساب الـ SSIM ووضع النتائج في تقرير نهاية الإنتاج.
i--threads
يتحكم في استعمال الأنوية من أجل زيادة أوتخفيض سرعة الإنتاج. القيمة التي يأخذها هي:
1.5×عدد الأنوية. فإن كان عدد الأنوية فردي فسيأخذ أصغر وأقرب عدد طبيعي إلى القيمة السابقة.
مثال: عندك أربعة أنوية وتريد استخدام 3 فقط. إذن يجب أن يأخذ هذا الأمر القيمة 4 وهي الأقرب إلى 1.5×3 = 4.5. وإن كنت تريد استعمال الأنوية الأربع معاً فيجب أن يأخذ الأمر القيمة 6=1.5×4
القيمة الافتراضية: auto أي أن يتكفل الانكودر بتحديد هذه القيمة.
لا تغيرها إلا إذا كنت تريد تخفيض استعمال الأنوية.
i--thread-input
يسمح بقراءة المصدر في نفس الوقت الذي يجري فيه الإنتاج من أجل زيادة السرعة.
القيمة الافتراضية هي "مفعّل إذا كان threads>1"
i--aud
فعّل هذا الأمر إن كنت تنتج للبلوراي.
القيمة الافتراضية هي "غير مفعّل"
i--force-cfr
يفرض سرعة فريمات ثابتة. في هذه الحالة فسترغب في استعمال --fps لتحديد هذه السرعة.
القيمة الافتراضية هي "غير مفعّل"
i--tcfile-in
عند استعمال سرعة فريمات متغيرة للمصدر يكون الزمن الفاصل بين ظهور الفريمات (Presentation TimeStamp PTS )متغيراً. يمكن حفظ توقيت عرض جميع الفريمات في فيديو معين ضمن ملف نصي يسمى timecode file. هذا الأمر يحدد الـ timecode file الخاص بالمصدر.
i--tcfile-out
يكتب الـ timecode file الخاص بالفيديو المضغوط. لا فائدة منه إلا عند الإنتاج بسرعة فريمات متغيرة.
i--timebase
هذا الأمر يتيح لك التحكم بطريقة ظهور الفريمات في الفيديو المضغوط بواسطة الزمن بدل سرعة الفريمات.
i--video-filter
يطبق فلاتر محددة على المصدر قبل بدء الضغط. يمكنك تطبيق أكثر من فلتر واحد بالفصل بين الفلاتر بواسطة /
الفلاتر المتاحة هي:
crop:left,top,right,bottom
لا أعتقد أنها تحتاج إلى شرح.
resize:[width,height,sar,fittobox,csp,method]i
فلتر تغيير الأبعاد:
width: عرض فريمات الفيديو بعد الضغط
height: ارتفاع فريمات الفيديو بعد الضغط
sar: هو الـ sar
fittobox: يغير الأبعاد من الأجل الوفاء بأحد الشروط: width، height أو both أي كلاهما معاً.
csp:يغير الألوان
أسلوب تغيير الأبعاد، القيم المتاحة هي: fastbilinear, bilinear, bicubic, experimental, point, area, bicublin, gauss, sinc, lanczos, spline
هذا الفلتر لا يتطلب سوى width وheight، أي أن بقية الخيارات ليست ضرورية.
select_every :step,offset1,offset2...i
يحدد فريمات معينة كي ينتجها الانكودر ويتجاهل ما سواها.
كي تنتج الفريم الأول من كل فريمين متتاليين وتتجاهل الثاني:
select_every:2,0
كي تنتج الفريم الثاني من كل فريمين متتاليين:
select_every:2,1
كي تنتج أول فريمين من كل ثلاث فريمات متتالية وتتجاهل الثالث:
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64profile
x264 [info]: profile High, level 4.1
هذه المعلومات تظهر بعد بداية الانكودر في ضغط الفيديو وهي معلومات عامة؛
- السطر الأول يحدد الـ demuxer الدي يستخدمه الانكودر (avs في حالتنا)، أبعاد المصدر، الـ sar الخاص بالمصدر، سرعة الفريمات في المصدر (24000/1001) ونمطها (cfr).
- السطر الثاني يحدد الـ sar الذي يستخدمه الانكودر أثناء ضغط الفيديو.
السطر الثالث يحدد خصائص المعالج التي يستعملها الانكودر
السطر الرابع يحدد البروفايل والـ level المستعمل لضغط الفيديو.
السطر الأول يدلنا على معدلات تقسيم الماكروبلوكات في الـ I-frames إلى بلوكات 16×16، 8×8، 4×4 بالترتيب
السطر الثاني يتحدث عن الـ P-frames والثالث يتحدث عن الـ B-frames.
L1 تشير للفريمات المستقبلية و L0 تشير للفريمات الماضية.
x264 [info]: final ratefactor: 27.45
يظهر هذا السطر حين الانتاج بالبترايت ويعطي معدل الـ QP.
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
معدل الفريمات التي تستعمل drect أوskip لتخمين اتجاه الحركة. تظهر هذه الإحصائية في حالة أنك اخترت direct auto.
x264 [info]: SSIM Mean Y:0.9851369 (17.254db)
إن طلبت حساب الـ SSIM فتـُظهر لك هذه الإحصائية معدله في الفيديو.
x264 [info]: PSNR Mean Y:42.506 U:46.641 V:46.212 Avg:43.374 Global:42.523 kb/s:475.50
في حالة طلبت حساب الـ PSNR تظهر لك إحصائية الـ PSNR العام للوما والكروما إضافة للـ PSNR الجملي (Avg). Global يعطيك معدل البترايت في الفيديو الراو (دون حساب headers الخاص بالحاوي)
encoded 300 frames, 119.24 fps, 722.37 kb/s
عدد الفريمات في الفيديو، سرعة ضغط الفيديو بالفريم في الثانية ومعدل البترايت بما في ذلك الـ headers الخاص بالحاوي.
هناك إحصائيات أخرى لكنني لم أضعها لقلة أهميتها.
9- Speech
هذا الكلام خاص بالفانسب وإنتاج الأنيمي فقط:
كيف أختار الإعدادات المناسبة ؟
حدد مدى بطئ الإنتاج الذي يمكنك أن تستحمله، واختر الـ preset المناسب لهذه السرعة. لا تستعمل preset أسرع من fast للإنتاج النهائي، تستطيع فعل ذلك للوورك راو واللوسلس. لكن الإنتاج النهائي...
اختر الـ crf الذي ستنتج به أو البترايت في حالة أنك لا زلت تعيش في زمن البترايت والأحجام المحددة مسبقاً.
تأكد من أنك تستخدم aq-mode واحد أو اثنين واختر قيمة aq-strength بما يتوافق مع الخام.
تأكد من أنك لا تستعمل أياً من خيارات الـ vbv.
إن كان المصدر مليئاً بالتفاصيل فارفع من قيم الـ psy-rd
تأكد من أنك لا تستخدم i--no-mbtree, --no-cabac, --no-deblock, no-8x8dct, --no-scenecut
لا تعبث بأي شيء لا تعرفه. لا تلعب فيها Mr.CustomizeR.jpg وتحشر الكثير من الإعدادات في الـ CLI.
تأكد من أن الديكودر منصب بطريقة صحيحة لديك.
امسح رغبة الحصول على نفس الجودة (أو جودة أفضل LOL) من فؤادك. ضغط الفيديو يتسبب في خسارة البيانات (lossy compression).
اختر مقاطعاً (200 إلى ألف فريم أو شيء كهذا) من المصدر وأنتجها عدة مرات بإعدادات مختلفة وباستعمال i--seek وi--frames لكن لا تغير البترايت أثناء المقارنة. تستطيع استعمال الـ PSNR والـ SSIM ليساعدوك على إعطاء بعض الأرقام (لكن يجب أن تستعمل معهم no-psy) لكن ما تراه العين يبقى دائماً أهم من هذه الأرقام. تستطيع مقارنة نفس الفريمات من نتائج التجارب لكن لا تعتمد على المقارنة بالفريم كثيراً لأن استعمال MB-Tree يحسن من جودة بعض الفريمات ويضر بجودة أخرى (لكن النتيجة الجملية تبقى أفضل دائماً)
توكل على الله وأنتج فور أن تصل إلى الإعدادات التي حازت على رضاك أنت.
المصدر فيه بلوكس، كيف أعالجه ؟
إذن فهو موجود في المصدر بالفعل، لست بحاجة لمعالجته... أو:
ضاعف حجم الفيديو 4 أو 5 مرات، ارفع من قيمة aq-strength إلى 2 واستعمل i--deblock 3:3 ثم استمتع بالبلور والتفاصيل الممسوحة.
المصدر فيه dither ما العمل ؟؟ (الديثر هو مثل ذاك الموجود في التطبيق الثاني) لا أريد banding ولا أريد بلوكس !!
لا يوجد أي مفر من الـ banding هنا سوى زيادة البترايت ورفع قيم aq-strength وpsy-rd. تستطيع إضافة القليل من الـ grain بالـ avisynth من أجل التغطية على هذا العيب.
المصدر فيه grain، كيف أحافظ عليها ؟
ارفع البترايت، ارفع قيمتا psy-rd (لا تزيد من psy-trellis أكثر من 0.2)، جرب aq-strength في جوار 1.2، خفض من ipratio، خفض من قيم الـ deblock (ربما تود تجربة 2-:2-)، جرب زيادة qcomp قليلاً فقط وإن كنت لا تهتم للحجم النهائي كثيراً، جرب تخفيض qpmax (لكن لا تنزل تحت 45) وربما تفكر في استعمال deadzone بقيم منخفظة بدل trellis.
الإنتاج بطيء. كيف أسرِّعه ؟
هناك عدة حلول:
- استعمل لوسلس إن كنت تنتج من مصدر متداخل يحتاج إلى فلترة... ولا تحشر 87 فلتر في سكربت الـ avs.
- خفض الـ preset.
- إن كانت فعالية الضغط ليس بتلك الدرجة القصوى من الأهمية، فلا تعبث بـ rc-lookahead ولا ترفع bframes فوق 8 (هذا في حالة سلمنا أنك تحتاج أكثر من 8 bframes)
- شوفلك على جهاز حقيقي بدل قطعة الخردة اللي عندك ولا تعبث بـ i--threads
أستعمل crf، الحجم كبير. كيف أخفض منه ؟
لا، ليس كبيراً. اقرأ الموضوع مرة أخرى.
حاولت وحاولت دون أن أستطيع التفاهم مع الـ CLI. ألا توجد طريقة أستعمل بها MeGui؟
حمل النسخة الأخيرة من الانكودر من موقع x264.nl وضعها في هذا المسار:
C:\Program Files\megui\tools\x264
ثم افتح الميغوي، اضغط على config، اعمل شيك على Show Advanced Settings واختر Misc من الأعلى. ستجد مجال نصي مكتوب فوقه Custom Command Line؛ اكتب الإعدادات هناك.
كل ما هو مكتوب في السبويلر آرائي الشخصية وبث سموم. أغلبه متعلق بالذوق لا البرهان.
DirectShowSource
سحقاً !! كفوا عن استعمال أمر استدعاء التخلفي هذا. أمر أحمق وغبي لا يفرق بين cfr وvfr. يعطي عدد فريمات مختلف عن المصدر في الكثير من الأحيان خاصة إن استعملت trim. ليس من قبيل الصدفة أن مبرمجي الانكودر أدرجوا فلتر ffms ولم يدرجوا هذا الفلتر التخلفي. شكراً.
لا تستعملوه
RE-Re-re-reencoding
إن لم تجد خام حقيقي (ts, DVD, Bluray) واضطررت إلى استعمال شيء آخر فلا تضغطه، ادمج الترجمة سوفت سب فقط. Zero-raws, Leopard, Yousei.... كلهم لا يهتمون سوى بمن يضع الراو قبل الآخر. يستعملون --preset ultrafast بالمناسبة. دون أن أنسى أنهم جهلة لا يجيدون سوى:
OVERSHARPENING TO DEATH TO BRING HALO TO LIFE
Placebo
لا يستعمله إلا جاهل.
i--me esa/tesa
لا
i--bframes 16 --b-adapt 2
لا
i--deblock 1:1
سؤال: هل أن الثوب الجديد يبقى نفسه بعد الغسيل ؟ لا.
كذلك الأنيمي لا يحافظ على طابعه الأصلي بعد strong deblocking.
تعساً، الأنيمي (الياباني) في 2010-2011 لم يعد مجرد كرتون. ربما كونان وون بيس، لكن البقية ؟
Noise or grain ?
لا، هي grain وعليك أن تحافظ عليها. الخيار لا يعود لك أنت. يجب أن تحافظ على الـ grain وإلا أفسدت الفيديو كله.
SHARPENING
تخيل شخصاً يقفز كيلومتراً إلى الأعلى خلال ثانية. هذا يساوي 3600 كيلومتر في الساعة.
نفس الشيء مع عناصر الـ DCT. كنت في جسم معين له لونه الثابت وإضاءته الثابتة ثم... فجأة تجد حداً أسود اللون (أو أياً كان) وذو إضاءة مختلفة تماماً. هذا الأمر يجعل من عناصر الـ DCT الخاصة بالحدود كبيرة جداً مقارنة بغيرها. عناصر DCT ذات قيم عالية تعني بترايت أعلى للحدود. بترايت أعلى للحدود (التي لا تحتل أكثر من 10% من الفيديو) يعني بترايت أقل وبلور للخلفيات.
باختصار، كن حذراً مع الحدود. الحدود مهمة، لكن لا تبالغ في إسناد الأهمية لها ولا يجب أن تكون حادة أكثر من المصدر !!!!!!!!!!!!!!!!!!!!!!!!!!!
BLU-RAY
هذا هو المصدر الذي ستود العمل عليه (لا أتحدث عن الـ i**itty rips). سهل ونظيف عادة، خاصة إن لم يكن من FuNiMaTiOn’s Cr*p.
ts
التعامل معهم ليس صعباً إلى تلك الدرجة التي تتوهمونها. لا تفلتروه كثيراً فقط.
Hardsubs
أفضل أسلوب للإساءة إلى جودة الفيديو وأكبر عائق أمام تقدم الإنتاج العربي. لا يستعمله أي منتج يحترم الجودة.
KaRaOkE
Pointless stuff that nobody give a dam* about
بالفعل، يصعب أن أفهم مغزى روماجي تخرج منه صراصير.
AE=yet another pointless stuff
أعتقد أن سبب تركيز العرب على شيء عديم النفع كلياً ويستهلك مثل هذا الكم من الجهد والوقت هو التغطية (التلبيس) على العيوب الحقيقية. لا تستعمله إلا في الحجب، إن اضطررت.
QC
هذه صورة (اضغط هنا) يحدد لنا فيها فريق إنجليزي ذو صيت واسع خريطة جديدة لأوروبا.. كما ترون؛ باريس ليست في فرنسا.
الفريق هو Frostii ويُقال أن مراقبة الجودة عنده ما تخرش المية.
Entrprise-style
هذا أكثر ما يعيق تطور الفانسب العربي، أقتبس من كلام أحدهم:
They aren't actually spending that much more time on improving their release; they're mostly using it sitting around doing nothing because everything that needs to be done needs to go five layers of bureaucracy first. That, and they spend a lot of time doing the same thing over and over and over (like letting three people QC the same version of the script once each and having each of them point out the same errors and then doing it all over again on the next version of the script).
The keys to efficient, quick, relatively painless and good quality subbing are relying on the individual and using a small team.
You shouldn't ever have more than 5 people in a team (TL, editor, typesetter, timer, encoder); you can and should usually get away with less (having a dedicated typesetter is usually unnecessary, since someone can double as it; same thing withencoder and timer). The more people you involve the more make-work you create, the more you have to wait for people to stop being afk and the more inefficient the entire thing becomes. ..... This way you rely on every person's individual effort rather than falling prey to the Somebody Else's Problem mentality that most enterprise-style "quality" groups seem to have.
TL;DR: a good fansub doesn't need to take a long time to produce; the reason it frequently does is that fansubbers are terrible at managing human resources.
لا حظوا البلوك خلف التلفاز في نهاية المقطع. الآن غيروا tune إلى film وجربوا.
مقطع لوسلس FFV1 من قناة BBC HD patr1 - part2
جرب الإنتاج بالـ crf وtune film ثم بترايت واستمتع بالتجارب.
حطوا الـ demuxer على lavf لأن ffms لن ينفع، على الأقل أنا لم ينفع معي.
----- If you give someone a button, they will press it. And even after it shoots them in the leg, they'll go limping around for more buttons to press
شخصياً، أعتقد أن سبب نفور البشر من الـ CLI هو أنه لا يُتاح لك استعمال COPY-PAST فيها....
في الختام أود أن أهدي الموضوع لكل من يعتقد أن الثلاجة ليست المكان الصحيح للعقل البشري.
ربنا لا تؤاخذنا بما فعل السفهاء منا ولا تسلط علينا بذنوبنا من لا يخافك ولا يرحمنا.
والسلام عليكم ورحمة الله وبركاته
التعديل الأخير تم بواسطة ElPsy ; 25-12-2010 الساعة 11:19 PMسبب آخر: تنسيق ( ¯3¯)y-~
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
ماشا الله وأخيرا انتهيت من الكتيب << ليس موضوع ... المووضوع مفيد جدا في كل كلمة قلتها .. وموسع ماشاء الله خاصتا انه يحتويي على مفاهيم لم نعتد عليها .. كأنه يحتوي على شفرات نحتاج فكهاا ببرنامج << غسـان =D لا انكر ان قراءت المووضوع بشكل واضح يحتاج على الأقل اسبوعان و 3 اسابيع لفهمه بشكل أكبر لذلك الأفضل .. ان تقوم بعمل كتيب بسيط توضح وتكتب هذه الأمور .. خلال وقت فراغك حتى يكون شامل أكبر ^^ وحتى يكون مرجع للجميع .. فمن الصعب قراءة مووضوع بهذا الكم الهائل .. خلال ايام وفهمه =] جزاك الله خيرا ووفقك .. دمت برعاية الله ~
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
المشاركة الأصلية كتبت بواسطة ALKOON
لا انكر ان قراءت المووضوع بشكل واضح يحتاج على الأقل اسبوعان و 3 اسابيع لفهمه بشكل أكبر لذلك الأفضل .. ان تقوم بعمل كتيب بسيط توضح وتكتب هذه الأمور .. خلال وقت فراغك حتى يكون شامل أكبر ^^ وحتى يكون مرجع للجميع .. فمن الصعب قراءة مووضوع بهذا الكم الهائل .. خلال ايام وفهمه =]
همم، لعلك تعلم أنني لم_أكن_أعلم_شيئاً_عن_الإنتاج منذ شهرين. لا يوجد أي سبب مقنع يحول دون الفهم، حسب رأيي. خاصة مع تشريع باب الاستفسارات.
كل ما في الأمر أن من لا يهتم بالتعلم لن يبذل جهداً ولن يتعلم.. وصحيح التنسيق ليس جيداً كعادتي i ┐( ̄ー ̄)┌ i
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
السلام عليكم،
لا أظن أن تساؤلي يصح أن يوضع في الدرس الأول لأنه متعلق بالـ x264 على ما أظن. المهم، بعض ما فهمت من الشرح أنه يتوجب علينا أن ننتج دون أن نضع معدل بت ثابت، وكما فهمت من الشرح أنه يفضل أن نستخدم بدلاً عنه الـ crf، صحيح؟ حسنًا، عندما أتصفح بعض خصائص الإنتاجات الأجنبية أجد بعضها بمعدل بت عالي؛ على سبيل المثال فاينال فانتاسي (لا أذكر أي فيلم تحديدًا) أصدرته ثورا بجودة بلوراي بمعدل بت يبلغ 5758 (تقريبًا) فهل هذا اعتمادًا على الـ crf بقيمة معينة؟ آخرًا، في بعض خصائص الفيديوهات أجد معدل بت متغير بشكل جنوني (من وجهة نظري)؛ من 2800 إلى 10000 بت! كيف أفعل هذا مع أنني لم ألحظ وجود خيار خاص بمعدل البت المتغير.
ملاحظة أخير، ما الفرق بين Average Bitrate and Variable Bit rate؟
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
بعض ما فهمت من الشرح أنه يتوجب علينا أن ننتج دون أن نضع معدل بت ثابت
في الفانسب، نعم. لكن حين تنتج للمشاهدة المباشرة، للـ iPhone، أو عندك vbv constraints في هذه الحالة يكون البترايت أفضل ومع هذا تستطيع الانتاج بالـ crf إن كان لديك بعض الخبرة
وكما فهمت من الشرح أنه يفضل أن نستخدم بدلاً عنه الـ crf، صحيح؟
نعم
هذا اعتمادًا على الـ crf بقيمة معينة؟
نعم + ثورا تشفر إعدادات إنتاجها، يعني لا تستطيع قراءتها مباشرة من الميدياإنفو encoding settings
كيف أفعل هذا مع أنني لم ألحظ وجود خيار خاص بمعدل البت المتغير
لا، أنت لم تقرأ الموضوع جيداً. هناك qcomp يمكنك من فعل هذا حين الانتاج بالـ crf أو يمكنك الإنتاج بالـ qp لكن الخيار الأخير (qp) يجب الابتعاد عنه قدر الإمكان : http://forum.doom9.org/showpost.php?...69&postcount=3
ما الفرق بين Average Bitrate and Variable Bit rate؟
ليس بالضرورة أن يكون هناك فرق.
Average Bitrate: أسلوب الإنتاج بمعدل بترايت ثابت
Constant Bitrate: أسلوب الإنتاج ببترايت ثابت يمكن فعل بواسطة qcomp=0
Variable Bit rate: نمط البترايت المتغير في الفيديو. يمكن أن تحصل عليه باستعمال الـ crf أوbitrate أو qp حين تختار qcomp مختلف عن صفر.
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
أحببت أن أنبه لحيلة تعلمتها قبل مدة وجيزة، وهي أنه بإمكاننا فتح الـ CMD في أي مجلد أحببنا بالضغط على مفتاح shift، والنقر بالزر الأيمن للفأرة، فيظهر لنا خيار كما هو موضخ في الأسفل.
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
المشاركة الأصلية كتبت بواسطة كمال سليم
ماشاء الله أخوي موضوع قمة في الروعة وفيه من الفوائد الكثير ، ولكن لماذا أتعب نفسي واتعلم كل هذا عندما يمكنني فعل كل هذا بمجرد ضغظة زر في ميوجي
الميغوي مجرد واجهة رسومية سخيفة برمجها شخص له ذوقه الخاص به ووضع بروفايلات يرى هو أنها مناسبة لكن هذا لا يعني أنها كذلك بالفعل. وأضيف أن مبرمجي الميغوي لا ينتجون أنيمي بل ينتجون أفلام واقعية ولا خبرة لهم بإنتاج الأنيمي
+ الميغوي لا يحتوي على جميع إعدادات الانكودر
+ بعض الإعدادات تأخذ أسماء مختلفة عن الأسماء الرسمية فإن أردت معرفة وظيفة أحد الإعدادات فسيتشوش ذهنك بين أسماء الميغوي غير الرسمية والأسماء الرسمية التي يشرح بها المبرمجون الحقيقيون للانكودر.
+ ما تسميه ضغطة زر هو خبط لصق لا إنتاج
+ الميغوي فيه الكثير من المشاكل المستقلة عن الانكودر يعني ستقل رسائل الخطأ التي تعذب منتجين
+ استعمال الميغوي يضيف طبقة غير ضرورية بين "المنتج" والإنتاج
+ الإعدادات المناسبة تختلف من أنمي إلى آخر ومن حلقة إلى أخرى
+ في الميغوي لا يمكنك معرفة what the heck is actually going on
+ الموضوع يتحدث عن التحكم في ضغط الفيديو بالانكودر x264 وهذا الأمر لا يتيحه لك الميغوي بالقدر اللازم
+ ....
+ هذا المرجع ينفع حتى مستخدمي الميغوي وقد ذكرتُ الطريقة
المشاركة الأصلية كتبت بواسطة كمال سليم
هل الجودة هنا أفضل ؟
إن كان المنتج منتبهاً ويفقه ما يفعله.
المشاركة الأصلية كتبت بواسطة كمال سليم
هل الأنكود بيكون أسرع ؟ .
نعم، لأنك ستعمل على النسخة الأخيرة من الانكودر التي تنتظر أسابيع وأشهر كي تدرج ضمن الميغوي. تحديثات الانكودر يومية.
المشاركة الأصلية كتبت بواسطة كمال سليم
هل يمكن معرفة ماذا أستخدم بدل هذا الأمر ، بحث في النت عن طريقة لأستخدام ffms لأستدعاء الملف بدلاً عن DirectShowSource و لكن لم يحالفني الحظ لأسف .
أقتبس كلام ذكرته سابقاً
المشاركة الأصلية كتبت بواسطة Akkipuden-senpai
DirectShowSource's Bullxyzt
أمر استدعاء الملفات المعروف DirectShowSouce هو من أغبى وأسوء فلاتر الـ avisynth لا تستعملوه أبداً. هذا ليس كلامي أنا وحسب، ادخل إلى منتديات doom9 وابحث عن كلمة DirectShowSouce وستجد الجميع يسب ويشتم في هذا الفلتر الأحمق. عيوبه: يغير الألوان رغماً عن أنفك. لا يميز بين cfr وvfr لا يعطيك نفس عدد الفريمات خاصة إن استعملت أمر القص، يعني ليس frame accurate لا يدعم الـmulti-threading فلتر رسمي، وكما تعلمون، أي شيء رسمي يكون سيئاً. مثل الحكومات ومايكروسوفت هلم جراً... يلعب بتزامن الصوت والصورة
ما البديل إذن ؟ FFMS2 (The Fabulous FM Source 2)i وظيفته كما شرحها مبرمجه هي : Loads video files without sucking ميزاته: يستدعي الفيديو بشكل صحيح ويفرق بين cfr وvfr يدعم الـ multi-threading إن استعملت ffms2-mt لا يغير الألوان إلا إذا طلبت منه ذلك بواسطو colorspace="blah"i يساعد أوتوماتيكياً على مزامنة الصوت والصورة؛ تستطيع إلغاء هذه المزامنة إن أردت لكنك ستكون الخاسر في أغلب الأحيان
ضعه (الملفين ffms وffmsindexer) في مجلد مختلف عن plugins الـ avisynth لتفادي مشاكل تأثر الـ dlls ببعضها. استدع الفلتر بواسطة : loadplugin("x:\yzt\ffms2.dll")i استدع الصوت أولا بواسطة:
audio=FFAudioSource("x:\blah\lol.mp4")i ثم استدع الفيديو بواسطة: video=FFVideoSource("x:\blah\lol.mp4")i ثم AudioDub(video,audio)i
تريد أن تفرض سرعة فريمات -ثابتة- معينة ؟ video=FFVideoSource("x:\blah\lol.mp4",fpsnum=24000, fpsden=1001)i هذا يفرض سرعة فريمات 24000/1001
تستطيع أيضاً أن تفرض سرعة الفريمات من خلال الانكودر بإضافة i--fps 24000/1001 للإعدادات....
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
┐( ̄ー ̄)┌
المشاركة الأصلية كتبت بواسطة Akkipuden
الميغوي مجرد واجهة رسومية سخيفة برمجها شخص له ذوقه الخاص به ووضع بروفايلات يرى هو أنها مناسبة لكن هذا لا يعني أنها كذلك بالفعل. وأضيف أن مبرمجي الميغوي لا ينتجون أنيمي بل ينتجون أفلام واقعية ولا خبرة لهم بإنتاج الأنيمي
+ الميغوي لا يحتوي على جميع إعدادات الانكودر
+ بعض الإعدادات تأخذ أسماء مختلفة عن الأسماء الرسمية فإن أردت معرفة وظيفة أحد الإعدادات فسيتشوش ذهنك بين أسماء الميغوي غير الرسمية والأسماء الرسمية التي يشرح بها المبرمجون الحقيقيون للانكودر.
+ ما تسميه ضغطة زر هو خبط لصق لا إنتاج
+ الميغوي فيه الكثير من المشاكل المستقلة عن الانكودر يعني ستقل رسائل الخطأ التي تعذب منتجين
+ استعمال الميغوي يضيف طبقة غير ضرورية بين "المنتج" والإنتاج
+ الإعدادات المناسبة تختلف من أنمي إلى آخر ومن حلقة إلى أخرى
+ في الميغوي لا يمكنك معرفة what the heck is actually going on
+ الموضوع يتحدث عن التحكم في ضغط الفيديو بالانكودر x264 وهذا الأمر لا يتيحه لك الميغوي بالقدر اللازم
+ ....
+ هذا المرجع ينفع حتى مستخدمي الميغوي وقد ذكرتُ الطريقة
إن كان المنتج منتبهاً ويفقه ما يفعله.
نعم، لأنك ستعمل على النسخة الأخيرة من الانكودر التي تنتظر أسابيع وأشهر كي تدرج ضمن الميغوي. تحديثات الانكودر يومية.
أقتبس كلام ذكرته سابقاً
تحية لك يا معلم حقاً هذا الأمر أفضل بدرجات و ارتحت له الصراحة شكراً لك حقاً ، شئ آخر عند أستخدام هذا ألامر واستخدام ملف ترجمة فلأسف الترجمة تكون مو مضبوطه
أقصد التوقيت ، كما لو أنه الترجمة تستخدم أمر استدعاء DirectShowSource ، هل يمكن أنه عند إستدعاء ملف الفيديو لكي أضبط التوقيت عليه الايجي ساب يستدعيه بأمر DirectShowSource
، وهل الحل هو بأستدعاء ملف avs بدلا من استدعاء الفيديو الأصلي في ميوجي ؟
وآسف أني نسيت أستخدام الأبتسامة في المشاركة السابقة . ┐( ̄ー ̄)┌
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
المشاركة الأصلية كتبت بواسطة كمال سليم
تحية لك يا معلم حقاً هذا الأمر أفضل بدرجات و ارتحت له الصراحة شكراً لك حقاً ، شئ آخر عند أستخدام هذا ألامر واستخدام ملف ترجمة فلأسف الترجمة تكون مو مضبوطه
أقصد التوقيت ، كما لو أنه الترجمة تستخدم أمر استدعاء DirectShowSource
تأكد جيداً من أنك تستخدم النسخة الأخيرة من الإيجي سب لأن النسخ القديمة كانت تستعمل أمر DirectShowSource لاستدعاء الفيديو ولهذا السبب شُهرت بعدم دقة التوقيت عليها. أما النسخ الأخيرة فتستعمل ffms2
المشاركة الأصلية كتبت بواسطة كمال سليم
وهل الحل هو بأستدعاء ملف avs بدلا من استدعاء الفيديو الأصلي في ميوجي ؟
لم أفهم إن كنت تتحدث عن حل "مشكلة" توقيت الترجمة فلا علاقة بالميغوي بها. بل الإيجي هو المسؤول على هذا الأمر، لماذا؟ لأنك تستخدم في الـ avs أمر استدعاء لا يخطئ في توقيت الفريمات وعددها.
تأكد من أن هناك ملف اسمه ffms2.dll في C:\Program Files\Aegisub
إن لم ينفع معك هذا أيضاً فاستدع ffms2 من المسار الذي ذكرته سابقاً. هناك إمكانية أن الإيجي -لأسباب غير مبررة- يستعمل directshowsource بدل ffms2
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
المشاركة الأصلية كتبت بواسطة Akkipuden
تأكد جيداً من أنك تستخدم النسخة الأخيرة من الإيجي سب لأن النسخ القديمة كانت تستعمل أمر DirectShowSource لاستدعاء الفيديو ولهذا السبب شُهرت بعدم دقة التوقيت عليها. أما النسخ الأخيرة فتستعمل ffms2
لم أفهم إن كنت تتحدث عن حل "مشكلة" توقيت الترجمة فلا علاقة بالميغوي بها. بل الإيجي هو المسؤول على هذا الأمر، لماذا؟ لأنك تستخدم في الـ avs أمر استدعاء لا يخطئ في توقيت الفريمات وعددها.
تأكد من أن هناك ملف اسمه ffms2.dll في C:\Program Files\Aegisub
إن لم ينفع معك هذا أيضاً فاستدع ffms2 من المسار الذي ذكرته سابقاً. هناك إمكانية أن الإيجي -لأسباب غير مبررة- يستعمل directshowsource بدل ffms2
الأنيمي يستفيد من الفريمات المرجعية والـ B-frames بشكل كبير. ربما تفكر في زيادة تلك القيم من أجل رفع فعالية الضغط والحصول على حجم أقل لنفس الجودة.
هل هذه هي إعدادات الميغوي الافتراضية لبروفايل معين ؟
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
نعم أخوي هي إعدادات نسختها من الميوجي ولكنها ليست من بروفايل جاهز بل قمت بتعديلها على كلامك بأعلى ، بالنسبة للفيرمات المرجعيه أنا قرأت في السابق أنه
عند زيادة الفيرمات المرجعية كثير يصبح فيديو ثقيل في بلي باك وخصوصاً إذا كنت تريد الأنتقال من نقطه لأخرى في ملف الفيديو ، فما رأيك أخليها 8 أم ازيدها أكثر ؟ ،
بالنسبة B-frames فما الرقم الذي تنصح به أنت ؟
مما قرأت في موضوعك إنه يمكن يكون لها تأتير ويمكن لا يكون لها تأتير أبداً و خصوصاً انها تـأخد وقت أكبر في الأنتاج ، بالنسبة لأشياء الزرقام سيتم حذفها و لكن umh مما قرأت في الموضوع أنه
رد: [i ┐( ̄ー ̄)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264
بالنسبة للفريمات المرجعية فالمهم هو حجمها لا عددها، لكن، بديهياً، حجمها يزداد مع عددها. لكن حين تستعمل بترايت متوسط/منخفض كحالتك crf 20 فإن حجم الفريمات سيتقلص يعني يمكنك زيادته دون التأثير على الـ playback
الـ level 4.1 ييسمح لك باستعمال 9 فريمات مرجعية للـ 720p. شخصياً أستعملهم كلهم (أو 8 على الأقل) حتى مع بترايت أعلى بكثير مما لديك.
الـ bframes تعتمد على المصدر لا يوجد رقم ثابت. لكن دائماً لها تأثير وتأثير مهم(ربما أخطأتَ في فهم الموضوع).
اقرأ فقرة الـ bframes مرة أخرى و x264 output expanation | شرح تقرير نهاية الإنتاج وإن شاء الله ستفهم. أما umh فهي مفعلة افتراضياً في perset slower لا معنى من إعادة تفعيها. شيء مهم هنا: let the preset help you
المفضلات