[i ┐(￣ー￣)┌ i] المرجع الشامل للتحكم في ضغط الفيديو بالانكودر x264

[إكسير الحياة]

هل بتكون شغالة على نظام الماك ؟

[تيرزم]

أهلاً أخي وشكراً على الموضوع

عندي بضعة استفسارات

bitrate

ينتج لك فيديو بحجم محدد مسبقاً. أسلوب الـ quantization هنا تناسبي، لكن ليس من أجل الوصول إلى جودة أعلى، بل من أجل الالتزام بحجم معلوم مسبقاً.

عند استخدام هذا الأسلوب تكون الجودة النهائية للفيديو غير معلومة. القيمة التي يأخذها هذا الأمر هي البترايت المرغوب فيه بالكيلوبت في الثانية (1 بايت = 8 بت، 1 كيلوبايت = 8×1024 بت).
لم يعد أحد يستعمل هذا الأسلوب في 2010، لا داعي لأن تستخدمه في الفانسب.
القيمة الافتراضية "غير مفعّل"

i--crfi
أسلوب التحكم في الجودة الأكثر تقدما. قلنا أن qp يطبق أسلوب quantization متماثل (uniform)، الـ crf يطبق أسلوب quantization تناسبي (adaptative) فيخفض من قيمة الـ QP بالنسبة للفريمات التي تحتوي تفاصيل معقدة ويزيد منها في الفريمات التي تنتمي إلى مشاهد الحركة والفريمات الفقيرة من التفاصيل. الـ crf يعطي نفس جودة الـ qp عند استعمال نفس القيمة لكليهما، لكن بحجم أقل.
القيم التي يمكن أن يأخذها هذا الأمر تمتد من 0 (لوسلس~) إلى 51.
قيم بين 23 و18 تعطي عادة جودة لا بأس بها مع حجم مناسب لجميع المصادر.
القيمة الافتراضية هي "مفعّل بقيمة 23"

الـ 2pass أو تحديد البيت ريت كما هي معروفة

مكتوب هنا أنها توقف استعمالها عام 2010

لكن بعض الفرق كـ UTW و Thora و Doki لها أعمال محددة البيت ريت ولم تستعمل الـ CRF

فهل فعلاً انتهت أم هذا مكتوب بمرجع ما أخذت كلامك منه ؟؟

لأن أنا قمت ببعض البحث عن الـ 2pass والفرق بينه بين الـ CRF أو ما أساسه هو "Fixed Quality"

وهذا ما ظهر لدي

[edit] Methods of VBR encoding

Note that the choice of a variable bitrate (VBR) method only affects the encoding process. Decoding a VBR stream is performed identically in all cases, regardless of how the encoder chooses to allocate bits.

[edit] Multi-pass encoding and single-pass encoding


VBR is created using the so-called single-pass encoding or multi-pass encoding. Single-pass encoding analyzes and encodes the data "on the fly" and it is also used in the constant bitrate encoding. Single-pass encoding is used when the encoding speed is most important - e.g. for real-time encoding. Single-pass VBR encoding is usually controlled by the fixed quality setting or by the bitrate range (minimum and maximum allowed bitrate) or by the average bitrate setting. Multi-pass encoding is used when the encoding quality is most important. Multi-pass encoding cannot be used in real-time encoding, live broadcast or live streaming. Multi-pass encoding takes much longer than single-pass encoding, because every pass means one pass through the input data (usually through the whole input file). Multi-pass encoding is used only for VBR encoding, because CBR encoding doesn't offer any flexibility to change the bitrate. The most common multi-pass encoding is two-pass encoding. In the first pass of two-pass encoding, the input data are being analyzed and the result is stored in a log file. In the second pass, the collected data from the first pass are used to achieve the best encoding quality. In a video encoding, two-pass encoding is usually controlled by the average bitrate setting or by the bitrate range setting (minimal and maximal allowed bitrate) or by the target video file size setting.[SUP][6][/SUP][SUP][7][/SUP][SUP][8][/SUP][SUP][9][/SUP][SUP][10][/SUP][SUP][11][/SUP][SUP][12][/SUP][SUP][13][/SUP][SUP][14][/SUP]
[edit] Fixed quality

One means of VBR encoding is fixed quantizer or fixed quality encoding. It is usually single-pass encoding. The user specifies a given subjective quality value, and the encoder allocates bits as needed to achieve the given level of quality. This ensures the output stream will have consistent quality throughout. A quality level usually has an associated bitrate range. The disadvantage of this encoding method is that the average bitrate (and hence file size) will not be known ahead of time, and achieving a certain average bitrate requires trial and error. This is typically more of a concern for video than for audio, since file sizes are much larger and encoding can take much longer.

يعني تقريباً تقنية الـ 2pass تحتوي ميزة الـ CRF وهي إعطاء كل فريم حقه بالبتس

وقمت بتجربة بإنتاج مقطعين مماثلين بنفس الحجم بـ CRF و 2pass

وجربتهم بالـ MPC وكانت نتيجة البتس شبه متماثل وينخفض ويرتفع بنفس الشكل (عرفت ذلك بـ "ضغطة يميني" على الصورة ثم "View" ومن ثم "Statistics") وكان في تفاوت كبير

+

مرجع آخر

(CRF will take less time than a 2pass bitrate encode, because the 'first pass' from a 2pass encode was skipped. On the other hand, it's impossible to predict the bitrate a CRF encode will come out to. It's up to you to decide which rate-control mode is better for your circumstances. )

يعني هو جزء من الـ 2pass وصحيح أنه أسرع لكن أنا أُرجح استخدام الـ 2pass وتحديد بيت ريت مناسب للحلقة "أو الأنمي" بالاعتماد على خبرة المنتج ليحصل على أكبر قدر ممكن من تصغير للحلقة دون خسارة كبيرة بالجودة أو ظهور مشاكل

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

+

هل للطريقتين أي تأثير على الإنتاج من ناحية ظهور بلوكس أو بندنج ؟؟ من مرجع قرأته قال أنه لا يؤثر وكما نجد الفرق الانكليزية تستخدم الطريقتين

وشكراً لك

[~ VEGETA ~]

سلام

أكيبودن...

بالنسبة لموضوع اللوسليس هو كالتالي:

فيديو لوسليس avi بكوديك Huffman حجمه 18 غيغا أنتج فيديو H264 بحجم 201 ميغا 10 بت طبعاً
فيديو لوسليس mkv بإنكودر x264 حجمه 8 غيغا أنتج فيديو H264 بحجم حوالي 170 ميغا 10 بت

و إعدادات الفلاتر نفسها و الإنكودر x264 نفسها مع العلم أن اللوسليس أبو 8 غيغا كان 8 بت (للأسف بالميجوي) و بإعدادات fast أو faster

ممكن أن إعدادات الـ fastest أو أسرع الإعدادات تكون أقل فاعلية في الضغط و لهذا كان يجدر بي الإنتاج بأسرع بريسيت موجود كي أنتج النهائي بججم أقل! ممكن هذا الصح فإنت شو رأيك

+

سؤال فني: بخصوص الفلترة في ياتا... عندما تضع لأحد المقاطع فلاتر معينة مثلاً و الباقي بدون فلترة كيف تكون سرعة الإنتاج؟ هل تكون سريعة و عندما تصل للمنطقة اللي فيها فلاتر تبطئ؟؟؟؟؟؟

[ElPsy]

أ

الـ 2pass أو تحديد البيت ريت كما هي معروفة

مكتوب هنا أنها توقف استعمالها عام 2010

لكن بعض الفرق كـ UTW و Thora و Doki لها أعمال محددة البيت ريت ولم تستعمل الـ CRF

فهل فعلاً انتهت أم هذا مكتوب بمرجع ما أخذت كلامك منه ؟؟

mata desu ka

UTW يستعملون crf وجميع الفرق الانجليزية الجيدة في الإنتاج (Eclipse, Static-Subs, gg) وشبه الجيدة (Commie, Nutbladder, Coalguys, UnderWater, Thora, mazui) كذلك تستعمل crf وحتى الفرق السيئة أغلبها تستعمل crf. هل شاهدت crappy re-encode لإصداراتهم ثم قلت ما قلته؟ حتى Doki الأغبياء يستعملون crf، حملت إصدار لهم خصيصا كي أضحك قليلا (لأني وثقت بكلامك نوعاً ما، شيء لا أستغربه منهم) لكن خاب ظني، إنهم يستعملون الـ crf
أصلاً، كيف حكمت أنهم يستخدمون bitrate بدل crf في إعداداتهم؟؟

أ

لأن أنا قمت ببعض البحث عن الـ 2pass والفرق بينه بين الـ CRF أو ما أساسه هو "Fixed Quality"

وهذا ما ظهر لدي

http://en.wikipedia.org/wiki/Variable_bitrate

يعني تقريباً تقنية الـ 2pass تحتوي ميزة الـ CRF وهي إعطاء كل فريم حقه بالبتس

وقمت بتجربة بإنتاج مقطعين مماثلين بنفس الحجم بـ CRF و 2pass

وجربتهم بالـ MPC وكانت نتيجة البتس شبه متماثل وينخفض ويرتفع بنفس الشكل (عرفت ذلك بـ "ضغطة يميني" على الصورة ثم "View" ومن ثم "Statistics") وكان في تفاوت كبير

كلام الويكيبيديا الذي طرحته هنا لا علاقة له بموضوع crf vs bitrate. الموضوع يتحدث بشكل عام جداً عن أساليب التحكم في توزيع البترايت/الجودة ولا يأخذ خصوصية x264 بالحسبان ويقارن بين 2pass bitrate mode و fixed quality mode. لو أنك قرأت الموضوع جيداً لعلمت مباشرة أن المقصود هو QP وليس CRF.
اقرأ جيداً ما كتب هناك:
One means of VBR encoding is fixed quantizer or fixed quality encoding
واضح يا أخي أنه يتحدث عن qp هداك الله لا تتهم crf بعيوب غيره. ودونك كلام مطور الانكودر الذي له 75 بالمئة من commits في الكود:
http://forum.doom9.org/showthread.ph...69#post1415969
ركز على هذا تحديداً:
CRF is the default for a reason; don't go out of your way to add stupidity where there isn't any to start with.

لو كنت أعلم أن ملء الموضوع بكلام أنشط مطوري الانكودر Akupenguin (المخ) و Dark_Shikari (الجهاز العصبي) سيكفي لإقناع المعاندين بأن الـ crf أفضل من bitrate لفعلت

وكلا، أسلوب معدل البترايت لا يحتوي خاصية إعطاء كل بت حقه من البترايت، الأمر نفسه ينطبق على الـ crf لكن بدرجة أقل. الـ crf يعطي كل ماكروبلوك الجودة التي قدر المنتج أنها حقه.
لم أقل في حياتي كلها إن استعمال معدل بترايت يعطي بترايت ثابت على طول الفيديو. لن تحصل على ذلك إلا إذا جعلت qcomp بقيمة 0 ولا أظن عاقلاً يريد فعل ذلك اللهم في حالات خاصة جداً لا علاقة لها بالفانسب والريب.

+

مرجع آخر

(CRF will take less time than a 2pass bitrate encode, because the 'first pass' from a 2pass encode was skipped. On the other hand, it's impossible to predict the bitrate a CRF encode will come out to. It's up to you to decide which rate-control mode is better for your circumstances. )

يعني هو جزء من الـ 2pass وصحيح أنه أسرع لكن أنا أُرجح استخدام الـ 2pass وتحديد بيت ريت مناسب للحلقة "أو الأنمي" بالاعتماد على خبرة المنتج ليحصل على أكبر قدر ممكن من تصغير للحلقة دون خسارة كبيرة بالجودة أو ظهور مشاكل

لا، اقرأ هذا الكلام ما دام كلامي أنا غير موثوق:
http://doom10.org/index.php?topic=267.msg2071#msg2071
http://doom10.org/index.php?topic=1393.msg6900#msg6900
الخوارزمية مستعملة في كليهما، لكنه ليس جزءً من 2pass. يعني 2pass تستعمل خوارزمية الـ crf لتقحم الجودة المناسبة حسب البترايت المحدد (رجاءً، محدد لا تعني ثابت).
أما أسلوب الـ crf فيستعمل الخوارزمية ذاتها لكن ليقحم البترايت المناسب للجودة المحددة.

خبرة المنتج؟ عم تتحدث؟ هل تتوهم أن خبرة المنتج أفضل من كفاءة الانكودر x264 وخوارزمياته؟
أنا، رغم كل ما في جعبتي من معرفة عن تقنيات الانكودر وأساليبه ورغم التجارب التي لا تحصى التي أجريتها، أجدني عاجزا في أغلب الأحيان عن توقع البترايت الذي يعطيني الجودة التي ترضيني. فما بالك بمن لا يعرف شيئاً عن frame type decision وrate control technics و motion estimation وهلم جراً... هؤلاء هم المنتجون العرب، عن أي خبرة تتحدث؟

لكن يجب أن أقول هنا، الجودة تكون ذاتها إذا استعملت 2pass أو crf في وخرجت بنفس الحجم في الحالتين، باستثناء أن 2pass أطول. ولا أظن بشرياً سوياً يهوى الانتظار بلا فائدة.

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

كما قلت، كلامك غير واقعي هنا. لا يوجد منتج يعرف ما ينتج وحتى إن وجد فلن تكون معرفته أفضل من x264، لا تقلل من شأن الانكودر؛ هذا برنامج ناضج (mature) منذ 3 سنوات على الأقل، هو المستعمل في facebook وyoutube وكثير غيرهما هناك قنوات بث تلفزي تستخدمه وحتى شركات إنتاج بلوراي، دائماً يكون من أول الحاضرين في اختبارات Intel وAMD لتحديد قوة معالجاتهم، كل من له علاقة بالفيديو في العالم يعلم أنه أفضل انكودر لأفضل كوديك موجود حالياً (في انتظار HEVC)

ثم يأتي الفانز العرب، وتقريبا العرب فقط، ليقولوا : نجيد اختيار البترايت المناسب أكثر منه، lol

هل للطريقتين أي تأثير على الإنتاج من ناحية ظهور بلوكس أو بندنج ؟؟ من مرجع قرأته قال أنه لا يؤثر وكما نجد الفرق الانكليزية تستخدم الطريقتين

كما قلت، جميع الفرق الانجليزية المحترمة وشبه المحترمة (إضافة إلى أغلبية البقية) تستعمل الـ crf فقط.
بالطبع، أي أسلوب ضغط يؤثر على العيوب وضياع التفاصيل (أغلب الناس يركزون على العيوب ويلقون بالتفاصيل في الجحيم) لكن بالنسبة لسؤالك، ففي حالة كان الناتج النهائي بنفس الحجم فلا فرق فيما يخص العيوب أو أي شيء آخر. أما إذا كانت الحال غير ذلك فأيهما يعطيك حجما أكبر هو الأفضل، كل ما في الأمر أنك لا تعرف من سيعطيك الحجم الأكبر مسبقاً ~

[ElPsy]

بالنسبة لموضوع اللوسليس هو كالتالي:

فيديو لوسليس avi بكوديك Huffman حجمه 18 غيغا أنتج فيديو H264 بحجم 201 ميغا 10 بت طبعاً
فيديو لوسليس mkv بإنكودر x264 حجمه 8 غيغا أنتج فيديو H264 بحجم حوالي 170 ميغا 10 بت

و إعدادات الفلاتر نفسها و الإنكودر x264 نفسها مع العلم أن اللوسليس أبو 8 غيغا كان 8 بت (للأسف بالميجوي) و بإعدادات fast أو faster

ممكن أن إعدادات الـ fastest أو أسرع الإعدادات تكون أقل فاعلية في الضغط و لهذا كان يجدر بي الإنتاج بأسرع بريسيت موجود كي أنتج النهائي بججم أقل! ممكن هذا الصح فإنت شو رأيك

لا أعلم سبب هذا، لكن ربما يكون bug في أحد الانكودرز أو شيء من هذا القبيل وربما لا، سأحاول تقصي الأمر على العموم، لكن لا أعدك بشيء

مع العلم أن اللوسليس أبو 8 غيغا كان 8 بت (للأسف بالميجوي) و بإعدادات fast أو faster

أعتقد أنك ستفضل إنتاج اللوسلس بـ 8 بت ثم النهائي بعشرة بت

سؤال فني: بخصوص الفلترة في ياتا... عندما تضع لأحد المقاطع فلاتر معينة مثلاً و الباقي بدون فلترة كيف تكون سرعة الإنتاج؟ هل تكون سريعة و عندما تصل للمنطقة اللي فيها فلاتر تبطئ؟؟؟؟؟؟

المسألة لا علاقة لها بسرعة الإنتاج بمعنى الضغط، بل بسرعة الـ frameserving يعني avisynth.
ما يفعله ياتا هو التالي

Mpeg2Source("FunnyIndexes.d2v")
FunnyIVTC
FunnyDecimation
FunnyCropping
FunnyResizing
trim(0,x)+trim(x+1,y).FunnyFilter1(FunnySettings1)+trim(y+1,z)+trim(z+1,t).FunnyFilter2(FunnySettings2)+...

أفيسينث لا ينتظر انتهاء عملية "إرسال" الفريم x ليبدأ "بتحضير" الفريم x+1، بل لديه خوارزمياته ولديه ما يسمى buffer (مساحة في الذاكرة العشوائية)
إذا كان هناك مجال يتسع لفريم إضافي وكانت الخوارزميات "موافقة" على ملئه فستملؤه. المشكلة هنا أن هذه الخوارزميات متخلفة نوعاً ما (أفيسينث يعود إلى التسعينات والجميع يعلم أن أخطر نقاط ضعفه هي سوء التحكم في الذاكرة)
إضافة إلى أن أفيسنث ليس لديه مفهوم lookahead غير سيء، لذا ففي أغلب الأحيان سيبدأ في تحضير الفريمات القادمة من أجل الإرسال في وقت متأخر، لكن قبل انتهاء إرسال x. هنا إذا استغرق x+1 وقتاً طويلاً فسيكون انخفاض السرعة حاداً. ثم ستتراكم فريمات أخرى بعد x+1 تتنظر انتهاء تحضيره كي يجيء دورها.
وعلى العموم، انخفاض السرعة هذا لا يمكنك ملاحظته من خلال مؤشر السرعة الخاص بالانكودر لأنه يعطيك معدل سرعة إنتاج الفريمات السابقة كلها لا معدل سرعة إنتاج الفريمات الأخيرة فقط

[تيرزم]

رجعت

وكلا، أسلوب معدل البترايت لا يحتوي خاصية إعطاء كل بت حقه من البترايت، الأمر نفسه ينطبق على الـ crf لكن بدرجة أقل. الـ crf يعطي كل ماكروبلوك الجودة التي قدر المنتج أنها حقه.
لم أقل في حياتي كلها إن استعمال معدل بترايت يعطي بترايت ثابت على طول الفيديو. لن تحصل على ذلك إلا إذا جعلت qcomp بقيمة 0 ولا أظن عاقلاً يريد فعل ذلك اللهم في حالات خاصة جداً لا علاقة لها بالفانسب والريب.

قبل أن أبدأ هنا لك مني اعتذار

بنقاش آخر هُناك من جزم أن تحديد البت ريت سيُحدد بيت ريت ثابت على كل الحلقة
ومن جزم أن الـ 2pass يُظهر عيوب بالإنتاج "بلوكس وبندنج" بعكس الـ CRF
ومن جزم أن الـ CRF أفضل من الـ 2pass وأظن أنت تجزم بهذا لكن أنا مازلت أرى أن الاثنين لهم نفس الفعالية لكن هذا له مساوئ وميزات والثاني له مساوئ وميزات "ردي سيشرح ذلك"
لكن بما أن النتيجة مماثلة والـ CRF أسرع سأعتمده

والمشكلة أنهم ينشرونه وبعد أن تسألهم يقولوا "اذهب إلى مسومس"
وجئنا إلى مسومس وكان الكلام مختلف

UTW يستعملون crf وجميع الفرق الانجليزية الجيدة في الإنتاج (Eclipse, Static-Subs, gg) وشبه الجيدة (Commie, Nutbladder, Coalguys, UnderWater, Thora, mazui) كذلك تستعمل crf وحتى الفرق السيئة أغلبها تستعمل crf. هل شاهدت crappy re-encode لإصداراتهم ثم قلت ما قلته؟ حتى Doki الأغبياء يستعملون crf،
أصلاً، كيف حكمت أنهم يستخدمون bitrate بدل crf في إعداداتهم؟؟

لا أعلم إن كانت طريقة صحيحة لكن عند رؤية الـ Media Info بالـ MPC بالـ CRF لا يظهر خانة الـ بيت ريت لكن إذا تُم تحديد الـ بيت ريت فتظهر الخانة وهذا لمحته بإنتاج خاص بي

ممكن إذا كانت بطريقة إنتاج مختلفة قد تظهر لذا لن أجزم لكن الخانة ظهرت بـ UTW, Thora, Doki
ولم تظهر عند gg,Commie,Mazui,Coalgirls

حتى Doki الأغبياء يستعملون crf، حملت إصدار لهم خصيصا كي أضحك قليلا (لأني وثقت بكلامك نوعاً ما، شيء لا أستغربه منهم) لكن خاب ظني، إنهم يستعملون الـ crf

توقع كل شيء منهم

كلام الويكيبيديا الذي طرحته هنا لا علاقة له بموضوع crf vs bitrate. الموضوع يتحدث بشكل عام جداً عن أساليب التحكم في توزيع البترايت/الجودة ولا يأخذ خصوصية x264 بالحسبان ويقارن بين 2pass bitrate mode و fixed quality mode. لو أنك قرأت الموضوع جيداً لعلمت مباشرة أن المقصود هو QP وليس CRF.
اقرأ جيداً ما كتب هناك:
One means of VBR encoding is fixed quantizer or fixed quality encoding

One means of VBR encoding is fixed quantizer or fixed quality encoding

ذكر الـ fixed quality والتي لها نفس مفهوم الـ CRF

Single-pass VBR encoding is usually controlled by the fixed quality setting or by the bitrate range (minimum and maximum allowed bitrate) or by the average bitrate setting

هذه يقصد بها الـ Fixed quality الأساسية

[h=3][edit] Fixed quality[/h]One means of VBR encoding is fixed quantizer or fixed quality encoding
[/QUOTE]


وبما أن أحد المواضيع التي وضعتها يدل أن لهم نفس الخوارزمية فلا أجد فرق كبير وهذا ينطبق على ما قاله الويكي
الـ CRF هو نفسه بمثابة pass واحد من الـ 2pass
أما الـ pass الثاني الموجود بالـ 2pass هو لمعرفة الجودة اللازمة لتحصل على البت ريت المُحدد

"(the input data are being analyzed and the result is stored in a log file. In the second pass, the collected data from the first pass are used to achieve the best encoding quality

[QUOTE]

Moreso, qp is FOR DEBUGGING ONLY and anyone who uses it for real encoding (besides for setting lossless mode and a few other special cases) is a fool. CRF is the default for a reason; don't go out of your way to add stupidity where there isn't any to start with.

الموضوع أساسه عن الإنتاج بأسرع شكل ممكن بدون خسارة جودة "دون الاكتراث بالحجم النهائي"

والـ CRF سيتم وضعه Default لأنه الأفضل من هذه الناحية "ناحية الإنتاج بأقصى سرعة والحصول على جودة مماثلة" لكن المنتج يهتم بمعرفة الحجم النهائي

وأكيد المبرمج يعرف أكثر مني ومنك

لا، اقرأ هذا الكلام ما دام كلامي أنا غير موثوق:
http://doom10.org/index.php?topic=267.msg2071#msg2071
http://doom10.org/index.php?topic=1393.msg6900#msg6900
الخوارزمية مستعملة في كليهما، لكنه ليس جزءً من 2pass. يعني 2pass تستعمل خوارزمية الـ crf لتقحم الجودة المناسبة حسب البترايت المحدد (رجاءً، محدد لا تعني ثابت).
أما أسلوب الـ crf فيستعمل الخوارزمية ذاتها لكن ليقحم البترايت المناسب للجودة المحددة.

خبرة المنتج؟ عم تتحدث؟ هل تتوهم أن خبرة المنتج أفضل من كفاءة الانكودر x264 وخوارزمياته؟
أنا، رغم كل ما في جعبتي من معرفة عن تقنيات الانكودر وأساليبه ورغم التجارب التي لا تحصى التي أجريتها، أجدني عاجزا في أغلب الأحيان عن توقع البترايت الذي يعطيني الجودة التي ترضيني. فما بالك بمن لا يعرف شيئاً عن frame type decision وrate control technics و motion estimation وهلم جراً... هؤلاء هم المنتجون العرب، عن أي خبرة تتحدث؟

لكن يجب أن أقول هنا، الجودة تكون ذاتها إذا استعملت 2pass أو crf في وخرجت بنفس الحجم في الحالتين، باستثناء أن 2pass أطول. ولا أظن بشرياً سوياً يهوى الانتظار بلا فائدة.

CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.

No, it is not ABR. It is VBR, just like crf except that it takes a second pass to know what quality is needed to get the requested bitrate.

ثم يأتي الفانز العرب، وتقريبا العرب فقط، ليقولوا : نجيد اختيار البترايت المناسب أكثر منه، lol

الآن توضحت الأمور أكثر

سأذهب للنهاية فوراً

مقصدي هنا ليس "معرفة المنتج" أفضل من "البرنامج" نفسه

الطريقتين كما ذكر المبرمجين تعتمد على نفس الخوارزمية وستنتهي بنفس الجودة إن كان الحجم نفسه

لكن الـ CRF أسرع لكن لا يُمكنك معرفة الحجم الذي قد ينتج والـ 2pass يستغرق وقت أطول في سبيل تحديد الحجم وبكلا الحالتين على عاتق المنتج تحديد CRF أو بيت ريت ملائم لكن معرفة الـ بيت ريت أسهل لأنك ستقارن بماهيّة الحجم النهائي وهذه الفائدة على حساب الوقت

يعني على مقولة "جميع الطرق تؤدي إلى روما"

يمكنك أن تختار الطريق الطويل ووصولك مؤكد لـ روما أو تختار مُختصر طُرق سيوصلك أسرع لكن قد يصادفك عائق وتتأخر لكن بالنهاية نفس النتيجة

طلب: إذا أمكن موقع يتكلم بالتفصيل الممل عن الـ CRF

على كل حال أرسلت استفسار لتوضيح ما إن كان هناك فارق جوهري غير "سرعة دون معرفة الحجم الناتج بالـ CRFّ " "بطء مع معرفة الحجم الناتج"

سأستخدم الـ CRF حالياً لميرة الوقت

+

طريقتك بالكلام مثل المواقع الانكليزية فوراً رد "BULLSHIT"

[~ VEGETA ~]

لساتك مصر على رأيك رغم أن الكل قال لك أنك مخطئ

ترجمتك لما قاله الويكي أصلاً خطأ الـ crf ليس pass من الـ 2pass أبداً و شغلة ان لهما نفس الخوارزمية لا يعني أنهما متشابهان او جزء من بعض أبداً

و أنا ما قلت أن البت ريت ببقى ثابت!! البت ريت هو معدل فقط يعني بتغير بس تغيره مش بكفاءة الـ crf و الكل اصطلح عليه اسم بت ريت ثابت لا أكثر

المسألة مش توفير وقت و بس!! خلي الكل يشارك بالموضوع اذا أنا و أكيبودن مش مقنعينك.... و انا قلت ان المشاكل مثل بلوكس و باندينغ ليس سببها الأصلي و المباشر هو الانتاج 2pass!!! قلت أنه سبب غير مباشر يعني استخدامه يؤدي إلى إظهار عيوب ما كان المفروض تظهر!

و انت ما جاوبتني على سؤالي في مكسات ألا و هو كيف تنتج فيديو لوسليس باستخدام x264؟؟؟ ههممم هل راح تستخدم الـ 2pass تبعك؟؟؟؟

لا تحرف كلامي و تتهمني خطأ.... مصطلح البت ريت الثابت هو تسهيل لفظي فقط و الكل مدرك هذا الشيء!!! (حسستني اني داخل على الفانسب من يومين!!!!!!!!!!!!!!!!!!!!)

بانتظار أكيبودن و الخبراء

مشكورين

[ElPsy]

قبل أن أبدأ هنا لك مني اعتذار

بنقاش آخر هُناك من جزم أن تحديد البت ريت سيُحدد بيت ريت ثابت على كل الحلقة
ومن جزم أن الـ 2pass يُظهر عيوب بالإنتاج "بلوكس وبندنج" بعكس الـ CRF
ومن جزم أن الـ CRF أفضل من الـ 2pass وأظن أنت تجزم بهذا لكن أنا مازلت أرى أن الاثنين لهم نفس الفعالية لكن هذا له مساوئ وميزات والثاني له مساوئ وميزات "ردي سيشرح ذلك"
لكن بما أن النتيجة مماثلة والـ CRF أسرع سأعتمده

والمشكلة أنهم ينشرونه وبعد أن تسألهم يقولوا "اذهب إلى مسومس"
وجئنا إلى مسومس وكان الكلام مختلف

لا أعلم إن كانت طريقة صحيحة لكن عند رؤية الـ Media Info بالـ MPC بالـ CRF لا يظهر خانة الـ بيت ريت لكن إذا تُم تحديد الـ بيت ريت فتظهر الخانة وهذا لمحته بإنتاج خاص بي

ممكن إذا كانت بطريقة إنتاج مختلفة قد تظهر لذا لن أجزم لكن الخانة ظهرت بـ UTW, Thora, Doki
ولم تظهر عند gg,Commie,Mazui,Coalgirls

هذا يحدث كثيراً، يأتي شخص إلى الرايزون يقول لي انت قلت كذا وكذا وأنا لا علم لي بأي شيء ثم يظهر أنه يسمع كلام منقول بشكل غير دقيق. أو يأتي شخص يحاول لعب دور الشاطر ليوضح "أخطائي" في حين انه لم يقرأ الدرس جيداً... i ┐(￣ー￣)┌ i

ما قلته عن Mediainfo غير صحيح. إن كنت تريد معرفة أسلوب الإنتاج المعتمد فعليك بـ Hex Editor وستجد الإعدادات في البداية أو تكتفي بالميديا انفو لكن تنظر إلى

Encoding settings                : cabac=1 / ref=9 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.95 / psy_rd=0.60:0.10 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=9 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=120 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.80 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.32 / aq=1:0.93

Mediainfo ليست أداة موثوقاً بها

One means of VBR encoding is fixed quantizer or fixed quality encoding

ذكر الـ fixed quality والتي لها نفس مفهوم الـ CRF

Single-pass VBR encoding is usually controlled by the fixed quality setting or by the bitrate range (minimum and maximum allowed bitrate) or by the average bitrate setting

هذه يقصد بها الـ Fixed quality الأساسية

[edit] Fixed quality

One means of VBR encoding is fixed quantizer or fixed quality encoding

غير صحيح بالمرة. كما قلت، لو أنت قرأت هذا الموضوع الذي ترد عليه لما ارتكبت هذا الخطأ. CRF لا يعني جودة ثابتة-- ذلك يسمى qp
اقرأ:
"
CRF: أسلوب التحكم في الجودة الأكثر تقدما. قلنا أن qp يطبق أسلوب quantization متماثل (uniform)، الـ crf يطبق أسلوب quantization تناسبي (adaptative) فيخفض من قيمة الـ QP بالنسبة للفريمات التي تحتوي تفاصيل معقدة ويزيد منها في الفريمات التي تنتمي إلى مشاهد الحركة والفريمات الفقيرة من التفاصيل
"
حرفياً: qp= ضياع الجودة. كلما كان أصغر حافظت على الجودة أكثر. إذا كان ثابتاً، وفقط إذا كان ثابتاً، تكون الجودة ثابتة fixed
مضيعة للوقت أن أواصل دحض مثل هذه الحجة التي تعتمد على كلام لا يأخذ خصوصية الانكودر بالحسبان كما أنه مقتبس من wikipedia ولا يبدو أن أحداً اهتم بتحديثه فضلاً عن أن كاتبه المجهول كلياً يقر بنفسه أن كلامه غير شامل: usually، one means

وبما أن أحد المواضيع التي وضعتها يدل أن لهم نفس الخوارزمية فلا أجد فرق كبير وهذا ينطبق على ما قاله الويكي
الـ CRF هو نفسه بمثابة pass واحد من الـ 2pass

غير صحيح إن كنت تقصد ويكيبيديا. ويكيبيديا لم تتحدث في ذلك الرابط عن الـ CRF أصلاً. أما ميدياويكي (mewiki) فهذا أمر متوقع بالنظر إلى أن كاتب الصفحة هو أحد مطوري الانكودر kemuri-_9

أسلوب الـ crf ليس نفسه الباس الثانية، لأن الباس الثانية محدودة بالبترايت الذي حددته الباس الأولى وهذا الأمر لا ينطبق على crf. هذا الكلام لا يعارض mewiki بأي حال.

الموضوع أساسه عن الإنتاج بأسرع شكل ممكن بدون خسارة جودة "دون الاكتراث بالحجم النهائي"

والـ CRF سيتم وضعه Default لأنه الأفضل من هذه الناحية "ناحية الإنتاج بأقصى سرعة والحصول على جودة مماثلة" لكن المنتج يهتم بمعرفة الحجم النهائي

وأكيد المبرمج يعرف أكثر مني ومنك
الآن توضحت الأمور أكثر

كلام المطور لم يكن رداً على كاتب الموضوع بل تعليقاً وتأكيداً على أن crf هو الأفضل لكل ذي عينين.
الناس تستعمل الأحجام المحددة مسبقاً لأنهم يخافون أن يخرج الحجم عن سيطرتهم كونهم جهلة بالإعدادات. هذا غالباً يؤدي إلى bitrate starvation أو pointless filesize bloating

مقصدي هنا ليس "معرفة المنتج" أفضل من "البرنامج" نفسه

الطريقتين كما ذكر المبرمجين تعتمد على نفس الخوارزمية وستنتهي بنفس الجودة إن كان الحجم نفسه

لكن الـ CRF أسرع لكن لا يُمكنك معرفة الحجم الذي قد ينتج والـ 2pass يستغرق وقت أطول في سبيل تحديد الحجم وبكلا الحالتين على عاتق المنتج تحديد CRF أو بيت ريت ملائم لكن معرفة الـ بيت ريت أسهل لأنك ستقارن بماهيّة الحجم النهائي وهذه الفائدة على حساب الوقت

يعني على مقولة "جميع الطرق تؤدي إلى روما"

يمكنك أن تختار الطريق الطويل ووصولك مؤكد لـ روما أو تختار مُختصر طُرق سيوصلك أسرع لكن قد يصادفك عائق وتتأخر لكن بالنهاية نفس النتيجة

طلب: إذا أمكن موقع يتكلم بالتفصيل الممل عن الـ CRF

على كل حال أرسلت استفسار لتوضيح ما إن كان هناك فارق جوهري غير "سرعة دون معرفة الحجم الناتج بالـ CRFّ " "بطء مع معرفة الحجم الناتج"

سأستخدم الـ CRF حالياً لميرة الوقت

+

طريقتك بالكلام مثل المواقع الانكليزية فوراً رد "BULLSHIT"

لا تنس أنه لا يمكنك معرفة الجودة النهائية عند استعمال حجم محدد + تحتاج وقت أطول Vs تحصل على الجودة التي طلبتها في وقت أقل

المسألة كلها: هل الجودة (لا سيما أنها توفر الوقت) هي أولويتك أم حجم محدد كي ترضي الليشر الذين من الواضح أنهم من يسيرون الفانسب العربي

بالنسبة للشرح فكل ما تحتاجه هو معرفة أن : CRF = QP + AQ + QCOMP + Optional MBTree
ولو أنه لم يظهر لي أنك تبذل جهدا للفهم لوجدت رداً من ذلك القبيل. لأن أولئك الخلق لا فائدة من تعليمهم وتضييع الجهد عليهم

[~ VEGETA ~]

معك حق أكيبودن في كل ما قلته...

كلمة على السريع: ما قال أنه قرأه عن شخص آخر كان ذلك الشخص هو أنا و لكن ما قلت أي شيء خطأ اللهم هو فقط فهم كل شيء بالعكس الله يصلحه!

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

عموماً أنا ما أردت له إلا الخير و ممكن بعد كل هذه الحرب الكلامية تنعكس عليه بشكل إيجابي و أنا واثق من قدرته على ذلك (على الأقل بغلب حاله و بسأل و بدور صح؟!!!!) يا ريت الكل يصير مثله!!


ما يعجبني في موضوعك أنك تضع مراجع و مصادر للتعليم مش مجرد شرح للطريقة. هذا ما أريد رؤيته صراحة لأن المواضيع البسيطة لا تغني القارئ و سرعان ما يقع بمشكلة لا يعرف حلها بينما لو كان الموضوع شامل (بطريقة لا يقع فيها تلقين!!) لقدر على حلها بنفسه.... هذه هي قناعتي!!

بالتوفيق للجميع

[~ VEGETA ~]

لدي سؤال جديد... انت قلت أن مشاهدة إعدادات الإنتاج بالطريقة الصحيحة ليس عن طريق الميدياإنفو بل عن طريق Hex Editor... يا ريت تشرحلي شوي عنه لأني أول مرة بسمع فيه...

ثم.... أنا أنتجت إحدى الحلقات بـ ipratio=1.1 و الحجم كان أقل شوي من السابق... هل أستمر بهذا أم أعود إلى 1.4 أو قيمة أخرى؟ سؤالي الأصح هو ما فائدة اختيار قيمة كبيرة (1.4 مثلاً) بدل القيمة 1.1 اللي انت حكيت عنها انها مناسبة لحفظ التفاصيل؟

كمان qcomp لو زدته كثير مثلاً لحد 0.75 أو ما شابه... كيف سينعكس هذا على الحلقة؟ زيادة حجم؟ جودة؟ سرعة؟ طيب لو قللت القيمة أكثر؟

هذه استفساراتي... بانتظار الرد

[ElPsy]

لدي سؤال جديد... انت قلت أن مشاهدة إعدادات الإنتاج بالطريقة الصحيحة ليس عن طريق الميدياإنفو بل عن طريق Hex Editor... يا ريت تشرحلي شوي عنه لأني أول مرة بسمع فيه...

لم أقل ذلك. "إن كنت تريد معرفة أسلوب الإنتاج المعتمد فعليك بـ Hex Editor وستجد الإعدادات في البداية أو تكتفي بالميديا انفو لكن تنظر إلى Encoding Settings "
طريقة مضمونة مثلاً هي أن تثبت MinGW على ويندوز ثم تضيف إليه MYSYS وتفتح MYSYS.bat ثم تكتب strings filename.mkv | less
ثم تكتب

/x264

وتضغط Enter للبحث عن كلمة x264
سيأخذك مباشرة إلى شيء كهذا

تحت لينوكس لا تحتاج لهذه البرامج.
لن أجيب عن أي سؤال إضافي بهذا الشأن لأنه يمكنك معرفة ذلك بميديا إنفو أو افتح الفيديو في محرر وابحث عن x264

سؤالي الأصح هو ما فائدة اختيار قيمة كبيرة (1.4 مثلاً) بدل القيمة 1.1 اللي انت حكيت عنها انها مناسبة لحفظ التفاصيل؟

الجواب في الموضوع، لكن سأتعمق قليلاً

QP(P)=ipratio x QP(I)

عندما يكون لدينا فيديو مليئ بالنويز والغرين (التي إن تخلصنا منها صار الفيديو قبيحاً وغبياً) فسيذهب مفهوما التكرار والاستعارة في البتستريم إلى الجحيم بدرجة لا بأس بها... لأن هاتين الخاصيتين لا يمكن أن تكونا ثابتتين من جهة ولأنهما تضيفان حدوداً في كل مكان من الفيديو. لهذا قد تصبح أغلب الفريمات كأنها I-frame من ناحية عدم/قلة استعارة البيانات من جيرانها (وليس من ناحية القدرة على التشغيل بدءً منها)، في هذه الحالة لن يكون هناك معنى كبيراً لتدليل الفريمات التي تمثل تغير المشاهد بقيم QP صغيرة لا تستحقها، لأنه على مستوى البتستريم كأنك تغير المشهد كل فريم +-

الحدود تمثل تغير مفاجئ وكبير في الألوان بين جسمين لذا هي تكون في البتستريم على شكل قيم DCT كبيرة جداً يعني تحتاج إلى عدد كبير من البتس لتخزينها (يمكنك تخزين قيمة 5 في 3 بت أما قيمة 2514 فتحتاج إلى 12 بت، مثال مبسط جداً للتوضيح)

عموماً قيمة 1.1 لا أعتقد أنها قد تناسب الأنيمي، أنا لا أنزل تحت 1.25 ( وهذه في حالات نادرة)

كمان qcomp لو زدته كثير مثلاً لحد 0.75 أو ما شابه... كيف سينعكس هذا على الحلقة؟ زيادة حجم؟ جودة؟ سرعة؟ طيب لو قللت القيمة أكثر؟

الموضوع

[~ VEGETA ~]

طيب يعني الـ ipratio ليس من المفضل تقليلها أكثر من 1.25...

سؤال آخر: الـ rclookahead... في بعض الفرق مثل صحراء الأنمي يختاروا قيمة كبيرة جداً تصل إلى 170 و البعض الآخر قيمة قليلة مثل 40... أنا شاهدت إعلان أحد الأفلام (السداسية) منكم و لقيت أن الـ rc lookahead تساوي 35 مع إنك ذاكر في الدرس أنها مفيدة...

هذا شيء حابب أفهمه...

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

ما وجهة نظرك في ما سبق؟

[ElPsy]

سؤال آخر: الـ rclookahead... في بعض الفرق مثل صحراء الأنمي يختاروا قيمة كبيرة جداً تصل إلى 170 و البعض الآخر قيمة قليلة مثل 40... أنا شاهدت إعلان أحد الأفلام (السداسية) منكم و لقيت أن الـ rc lookahead تساوي 35 مع إنك ذاكر في الدرس أنها مفيدة...

هذا شيء حابب أفهمه...

Sins of the past and all
لو كان هناك شيء يمكن أن يشجعني على تحديث الموضوع فهو معلومة rc-lookahead. في preset placebo قيمتها هي 60. حرفياً، مطورو الانكودر يقولون لك ارفعها إلى 60 إن كنت مازوخياً: http://ar.wikipedia.org/wiki/فتيشية

rc-lookahead هي عدد الفريمات المستقبلية التي سيقتفي الانكودر أثر الماكروبلوكات المكررة فيها. فلنقل إن لدينا فيديو بسرعة 24، يعني كل ثانية لديك 24 فريم. إذا رفعت rc-lookahead من 24 إلى 48 فهذا يعني أنك تريد الاستفادة من التكرار الذي سيطرأ بعد مرور ثانية عن عرض الفريم الحالي وقبل مرور ثانيتين. هذا يعني أن التكرار المذكور (الذي طرأ) لم يكن موجوداً خلال الثانية الأولى التي تلي عرض الفريم الذي يضغطه الانكودر الآن. المعلوم بالضرورة من طبيعة أي فيديو هو أن أغلب التكرار يكون موجوداً في الفريمات المتقاربة زمنيا من جهة عرض الفيديو. قيمة ثانية (24 فريم) واحدة ستمكنك من الحصول على أغلب (أحيانا كل) التكرار المستقبلي الممكن. كلما زدت قيمة rc-lookahead، قلّت فائدة هذه الزيادة. في المقابل ستزيد من وقت الإنتاج بلا فائدة حقيقية في أغلب الأحيان.
شيء إضافي، rc-lookahead محدودة بـ keyint. يعني إذا اخترت قيمة 120 ولا يزال هناك 60 فريم فقط في الـ GOP الحالي، فكل ما ستستفيده من هذه القيمة العالية جداً هو 60 فريم فقط وملء الذاكرة بـ 120 فريم لا فائدة من نصفهم.
ولأنني سئلت أكثر من مرة عن هذا الإعداد فسأدعم كلامي ببعض من كلام الشخص الذي كتب خوارزمية MB-Tree التي أوجدت rc-lookahead
http://forum.doom9.org/showthread.php?t=160527
اقرأ المشاركات الثلاث الأولى، خاصة التأكيد على أن فائدة زيادة قيمتها هي: provide basically zero benefit besides making you feel better


Oh Boya, you saved an incredibly hilarious 0.5 kb/s of bitrate

هذا أيضاً: http://forum.doom9.org/showthread.ph...42#post1419442

هذا الموضوع أيضاً:
http://forum.doom9.org/showthread.php?t=162888

هذا النقاش أيضاً:

[22:26] <Daemon404> Lord, high motion scenes sitll get mangled with teh default qcomp of 0.6
[22:26] <Daemon404> with mbtree
[22:26] <Dark_Shikari> that's intentional
[22:26] <Dark_Shikari> the hope is you won't notice.
[22:27] <Dark_Shikari> which in most cases, you don't.
[22:27] <Daemon404> yeah i know it is
[22:27] <Dark_Shikari> unless you start screenshotting.
[22:27] <Lord> or maybe seeking I guess
[22:27] <Daemon404> well it's easier to notice with anime
[22:27] <Dark_Shikari> There is a problem with mbtree, and that is that its lookahead isn't capped
[22:27] <Dark_Shikari> that's what hits anime hard
03[22:27] * EienShouko|Sleep is now known as EienShouko
[22:27] <Lord> could you elaborate?
[22:27] <Daemon404> Dark_Shikari, i thought i was capped
[22:27] <Dark_Shikari> ok, so basically
[22:27] <Daemon404> at 250
[22:27] <Dark_Shikari> not quite what I mean, Daemon404 
[22:27] <Dark_Shikari> so, if something lasts 100ms
[22:27] <Dark_Shikari> you see less of it than if it lasts 200ms
[22:27] <Dark_Shikari> right?
03[22:27] * Kristen is now known as Kristen|Out
[22:27] <Dark_Shikari> so you can make it lower quality.
[22:28] <Dark_Shikari> But this effect caps out!
[22:28] <Dark_Shikari> at, maybe, 500ms -- you can see the whole thing.
[22:28] <Dark_Shikari> Or maybe it's 1 second.
[22:28] <Dark_Shikari> I don't know.
[22:28] <Dark_Shikari> But clearly, you can see something just as well after 1 second as after 10 seconds.
[22:28] <Daemon404> it gets the idea across tho
[22:28] <Dark_Shikari> So the effect of MB-tree has to be capped
[22:28] <Dark_Shikari> to not allow propagation longer than some number of milliseconds
[22:28] <Dark_Shikari> I suspect the value is between ~300ms and ~800ms
[22:28] <Dark_Shikari> anime is hit, because anime has many still objects much longer than that
[22:29] <Dark_Shikari> Those still objects get quality-boosted an extra amount
[22:29] <Dark_Shikari> this takes bits away from the objects that move
[22:29] <Dark_Shikari> rc-lookahead isn't enough for this, particularly because of VFR.
[22:29] <Dark_Shikari> I have some WIP patches for this.
[22:30] <Daemon404> cool
[22:30] <Lord> er... if we ignore vfr and counting in frames, do you mean it really shouldn't look ahead that much at all?
[22:30] <Lord> as in you should specify a very low rc-lookahead
[22:31] <Dark_Shikari> The default is probably fine for now, but yes people who set rc-lookahead 250 are stupid
[22:31] <Lord> that's very good to know
[22:31] <Dark_Shikari> note this would be with psy optimizations only
[22:31] <Dark_Shikari> i.e. this won't help psnr or some shit
[22:32] <MirkoAssPee> I thought a good lookahead was between 60 and 120? Or is that too much already?
06[22:32] * Lord couldn't care less about what the metrics say
[22:32] <Dark_Shikari> I set the default to 40 for a reason
[22:32] <Lord> MirkoAssPee: very much
[22:32] <Dark_Shikari> well, back then it was for speed
[22:32] <Lord> MirkoAssPee: with a 30 fps video that will be 2-4 seconds
[22:32] <Dark_Shikari> The main issue is the following
[22:32] <Lord> [21:26:00] <Dark_Shikari> I suspect the value is between ~300ms and ~800ms
[22:32] <Dark_Shikari> for film content
[22:32] <Dark_Shikari> NOTHING is static.
[22:32] <Dark_Shikari> So even if rc-lookahead is 250, you won't get propagation values like "10 seconds"
[22:33] <Dark_Shikari> because there's noise.
[22:33] <Dark_Shikari> But anime can have literally perfectly still objects for 10 seconds
[22:33] <Dark_Shikari> with no grain or noise
03[22:33] * Heaud (~Heaud@tayg.id.eajy) has joined #darkhold
[22:33] <Lord> anyway that is a very interesting fact to add to my testing when I get around to it
[22:33] <Dark_Shikari> The real question is
[22:33] <Dark_Shikari> how do we figure out what this number is?
[22:33] <Dark_Shikari> i.e. how long you have to see something before the effect caps out
[22:34] <MirkoAssPee> it depends on the object itself, really
[22:34] <Dark_Shikari> effectively we want a curve of "how long something is visible" vs "how much you notice loss of quality".
[22:34] <Lord> let the user specify I would say, and pick some "seems to be fine in most cases" default
[22:34] <Lord> i.e. rc-lookahead but in ms and not frames
[22:34] <Dark_Shikari> the current assumption is that the curve is logarithmic
[22:34] <Lord> oh you mean something else I guess
[22:35] <Eilafan> Lord: more like --rc-lookahead-cap
[22:35] <Haali> 10s is close to the usual keyframe interval
[22:35] <Lord> probably that's why they chose it I'd guess
[22:35] <Dark_Shikari> 250?  pulled out of hat.
[22:35] <Lord> oic
[22:36] <Lord> btw did you have any tests to see how much increasing rc-lookahead seems to benefit compression?
[22:37] <Lord> as in a curve or the like
[22:37] <Dark_Shikari> no, not really
[22:37] <Dark_Shikari> the problem is it is heavily content-dependent
06[22:37] * Lord is wondering if just lowering it a lot would make it much less useful or not
[22:37] <Dark_Shikari> and it's also used for VBV, so that can be misleading
[22:37] <Dark_Shikari> and there's also the fact that we can't trust psnr/ssim here too much
[22:37] <Lord> I mean values like 10
[22:38] <Lord> or up to 20
[22:38] <Dark_Shikari> 20 is probably sane
[22:38] <Dark_Shikari> I need to get around to doing this at some point, finishing these patches
[22:38] <Dark_Shikari> I did commit vfr-aware psnr/ssim
[22:38] <Dark_Shikari> so it's easier to test that kind of fuckery
[22:38] <Haali> Dark_Shikari: but simply reducing keyframe interval to 100 or less should impose a cap on these effects?
[22:39] <Dark_Shikari> Haali: no, reduce rc-lookahead
[22:39] <Lord> [21:35:48] <Dark_Shikari> 20 is probably sane <- you mean 10 seems to be way too low?
[22:39] <Dark_Shikari> cutting keyframe interval on anime is compressionretarded
[22:39] <Dark_Shikari> Lord: yes imo
[22:39] <Dark_Shikari> that's just gut feeling
[22:39] <Dark_Shikari> never tested it.
[22:39] <Lord> ok, will test anyway
[22:39] <Dark_Shikari> I could be wrong.

أخيراً، في شارة بداية أنيمي فراكتال، أنتجتها ذات مرة بقيمة rc-lookahead 40 ثم 120. بقية الإعدادات هي نفسها والسكربت كذلك. النتيجة: قيمة 120 أخذت 4 كيلوبايت في الثانية زيادة عن قيمة 40 (أتحدث عن البترايت).

هناك من قال لي إنه أنتج فيديو ثم أعاد إنتاجه بـ ref و bframesو rc-lookahead أكبر بكثير وحصل على انخفاض لا بأس به في الحجم. استنتاجه كان أن رفع rc-lookahead شيء جيد.
هذه طريقة خاطئة لإجراء التجارب. الطريقة الصحيحة يطول شرحها، لن أفعل ذلك، ابحثوا عنها بأنفسكم.

TL;DR
رفع rc-lookahead أكثر من 60 ليس اختيارا ذكياً بالمرة. 60 بحد ذاتها من الممكن جداً أن تكون فائدتها مقاربة للصفر في مقابل عذاب إنتاج أطول واستخدام ذاكرة أكثر، إن كنت لا تفهم الكلام السابق جيداً فستكون بخير إن التزمت بما حدده مطورو الانكودر في الـ preset

Raising rc-lookahead is waaaaay too much useless, INEFFICIENT and masochistic

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

الفلترة أذواق، المهم ألا تفعل أشياء غبية مثل استعمال gradfun2dbmod بقيم عالية مثل 2.7 كما سمعت من أحدهم
الفلترة ليست حرام وليست حماقة بحد ذاتها
هناك دائماً أقراص البلوراي التي تكون ألذ من البث الفضائي في كثير من الأحيان

[~ VEGETA ~]

معك حق... الـ GradFun2DBMOD بقيمة 2.7 كبير جداً! هل تنصح باستخدامه أو باستخدام العادي؟ شو القيمة المناسبة؟

في فلاتر دي باند أخرى مثل flash (لا أتذكر اسمه الكامل) و أيضاً gradfun3 اللي بيجي مع الـ dither... يعني خيارات كثيرة بس شو الأفضل بينها عشان أضمن نتيجة الإنتاج بالإنكودر تكون فعالة؟

أيضاً: الـ ipratio لو خليتها 1.4 أو زدتها كيف بنعكس هذا الشيء على الحجم و أيضاً الجودة؟

في pysrd له قيمتين الأولى أضعها دائماً 1 لأنها تفيد في الحفاظ على التفاصيل مع إني بشوف البعض بضعها 0.9 فحبيت أعرف السبب؟ و قيمة ثانية مثلاً 0.9:0.2 الـ 0.2 هي تريليز طيب شو بالضبط عملها؟

[KILLUA]

السلام عليكم

الفلترة أذواق، المهم ألا تفعل أشياء غبية مثل استعمال gradfun2dbmod بقيم عالية مثل 2.7 كما سمعت من أحدهم
الفلترة ليست حرام وليست حماقة بحد ذاتها
هناك دائماً أقراص البلوراي التي تكون ألذ من البث الفضائي في كثير من الأحيان

الفلترة أذواق حتى لو وصل ال gradfun2dbmod الى 3 او 3.5 اذا فعلا الراو يستحق هذه القيم اذا نعم
~ VEGETA ~
الاشياء الغبيه انه ان تضع الفلاتر عبط او تضع فيها ارقام عشوائية
لديك برامج مثل ال avsp جرب عليه الفلتر باعدادات لا تسمع لهذا الكلام
القيم تختلف من راو الى اخر
سلام

[امجد صلاح]

[i ┐(￣ー￣)┌ i]

اولا: اشكرك لجهودك في طرح الموضوع بتلك الطريقة الشاملة

ثانيا: صورة الحمار في البداية , لا تعليق

شخصياً، أعتقد أن سبب نفور البشر من الـ CLI هو أنه لا يُتاح لك استعمال COPY-PAST فيها....

اضن انك مخطئ , هنالك edit وبها الكوبي و البيست
انظر


ترى الاكس الاحمر الذي يغلق النافذة و جنبه مربع التكبير و جنبه زر التصغير , اضغط رايت كلك على الشريط الذي بجنبهم وستظهر لك قائمة منها الـ EDIT و بها يوجد الـ COPY-PAST

على العموم ان كان موضوعك من ورائه نوايا حسنة فانا اشكرك و احييك

و عليكم السلام و رحمة الله

[ElPsy]

في فلاتر دي باند أخرى مثل flash (لا أتذكر اسمه الكامل) و أيضاً gradfun3 اللي بيجي مع الـ dither... يعني خيارات كثيرة بس شو الأفضل بينها عشان أضمن نتيجة الإنتاج بالإنكودر تكون فعالة؟

الأفضل هو أفضل ما يناسبك أنت. جرب.
اقرأ الموضوع من أجل الإعدادات.

الفلترة أذواق حتى لو وصل ال gradfun2dbmod الى 3 او 3.5 اذا فعلا الراو يستحق هذه القيم اذا نعم

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

[i ┐(￣ー￣)┌ i]

اولا: اشكرك لجهودك في طرح الموضوع بتلك الطريقة الشاملة

ثانيا: صورة الحمار في البداية , لا تعليق



اضن انك مخطئ , هنالك edit وبها الكوبي و البيست
انظر
http://img600.imageshack.us/img600/1393/cmdt.png

ترى الاكس الاحمر الذي يغلق النافذة و جنبه مربع التكبير و جنبه زر التصغير , اضغط رايت كلك على الشريط الذي بجنبهم وستظهر لك قائمة منها الـ EDIT و بها يوجد الـ COPY-PAST

على العموم ان كان موضوعك من ورائه نوايا حسنة فانا اشكرك و احييك

و عليكم السلام و رحمة الله

لا يبدو أنك تعرف معنى COPY-PAST
كلك يمين في السواد يكفي لفعل ما تتحدث عنه، وهو، مرة أخرى، ليس COPY-PAST

[امجد صلاح]

الأفضل هو أفضل ما يناسبك أنت. جرب.
اقرأ الموضوع من أجل الإعدادات.


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




لا يبدو أنك تعرف معنى COPY-PAST
كلك يمين في السواد يكفي لفعل ما تتحدث عنه، وهو، مرة أخرى، ليس COPY-PAST

عذرا مرة اخرى لكن بالطريقة التي ذكرتها انا

بامكاني ان انسخ بها و الصق بها لكن بقليل من تشغيل للعقل


اولا تختر select all بطريقة الـEDIT او بطريقة الرايت كلك

ثم نعمل كوبي للكتابة كلها

او اذا اريد اختيار بعض من الكلمات بالماوس يمكن ذلك بعد select all و من ثم نعمل لها كوبي

لكن الكوبي لا يمكن عمله الا بالـEDIT او كوترول سي , اي لا يعمل بالرايت كلك , لذا الـEDIT تعتبر اشمل طريقة


+ لا تتهم الناس بانها لا تعرف بدون دليل منطقي فهمت

لان الكوبي و البيست من اسهل الامور بالكمبيوتر

و اي شخص يمسك فارة و كيبورد على حسب علمي يعرف ما هي الكوبي و البيست

وعليكم السلام و رحمة الله

[ElPsy]

http://i.imgur.com/mitLF.gif
مع ذلك، هذه ليست COPY-PAST ولول ليست حتى COPY-PASTE
لا بد أنك جديد على الـ cmd. هناك أنواع من cli المتطورة أيضاً تسمح بعدة أشياء
العبث بـ properties ربما ليس فكرة سيئة.


"Sorry for the obvious troll, coudn't imagine someone falling for it"

[امجد صلاح]

http://i.imgur.com/mitLF.gif
مع ذلك، هذه ليست COPY-PAST ولول ليست حتى COPY-PASTE
لا بد أنك جديد على الـ cmd. هناك أنواع من cli المتطورة أيضاً تسمح بعدة أشياء
العبث بـ properties ربما ليس فكرة سيئة.


"Sorry for the obvious troll, coudn't imagine someone falling for it"

انا جديد , اضحكتني , انا واعوذ بالله من كلمة انا , كنت افرمت الحاسب بالام اس دوس

يعني قبل ان يكون هنالك بوت من السيدي للوندوزات القديمة 98 و الme و غيرها , هذا ان كنت تعرف كيف تكون الفرمتة اصلا

والcmd ليس بجديد علي فانا اخفي منه جهازي عن الشبكة

صورتك اهديها لك
http://i.imgur.com/mitLF.gif

COPY-PASTE , تعرف نفسك ان أملائك خطأ

+ لم أرى انك قد كتبت لي جملة مفيدة بجوابك

كان من الافضل ان لا تجب

Sorry for the obvious troll, coudn't imagine someone falling for it

اكتب عربي يا مناصر لغة الضاد المزعوم.