هل بتكون شغالة على نظام الماك ؟
|
هل بتكون شغالة على نظام الماك ؟
أهلاً أخي وشكراً على الموضوع
عندي بضعة استفسارات
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"
وهذا ما ظهر لدي
يعني تقريباً تقنية الـ 2pass تحتوي ميزة الـ CRF وهي إعطاء كل فريم حقه بالبتس[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.
وقمت بتجربة بإنتاج مقطعين مماثلين بنفس الحجم بـ 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 وتحديد بيت ريت مناسب للحلقة "أو الأنمي" بالاعتماد على خبرة المنتج ليحصل على أكبر قدر ممكن من تصغير للحلقة دون خسارة كبيرة بالجودة أو ظهور مشاكل
وبالتأكيد اختيار الـ بيت ريت يعتمد على مهارة المنتج ومعرفته بما ينتجه
+
هل للطريقتين أي تأثير على الإنتاج من ناحية ظهور بلوكس أو بندنج ؟؟ من مرجع قرأته قال أنه لا يؤثر وكما نجد الفرق الانكليزية تستخدم الطريقتين
وشكراً لك
|
سلام
أكيبودن...
بالنسبة لموضوع اللوسليس هو كالتالي:
فيديو لوسليس avi بكوديك Huffman حجمه 18 غيغا أنتج فيديو H264 بحجم 201 ميغا 10 بت طبعاً
فيديو لوسليس mkv بإنكودر x264 حجمه 8 غيغا أنتج فيديو H264 بحجم حوالي 170 ميغا 10 بت
و إعدادات الفلاتر نفسها و الإنكودر x264 نفسها مع العلم أن اللوسليس أبو 8 غيغا كان 8 بت (للأسف بالميجوي) و بإعدادات fast أو faster
ممكن أن إعدادات الـ fastest أو أسرع الإعدادات تكون أقل فاعلية في الضغط و لهذا كان يجدر بي الإنتاج بأسرع بريسيت موجود كي أنتج النهائي بججم أقل! ممكن هذا الصح فإنت شو رأيك
+
سؤال فني: بخصوص الفلترة في ياتا... عندما تضع لأحد المقاطع فلاتر معينة مثلاً و الباقي بدون فلترة كيف تكون سرعة الإنتاج؟ هل تكون سريعة و عندما تصل للمنطقة اللي فيها فلاتر تبطئ؟؟؟؟؟؟
|
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 في إعداداتهم؟؟
كلام الويكيبيديا الذي طرحته هنا لا علاقة له بموضوع 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 ولا أظن عاقلاً يريد فعل ذلك اللهم في حالات خاصة جداً لا علاقة لها بالفانسب والريب.
لا، اقرأ هذا الكلام ما دام كلامي أنا غير موثوق:
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 فقط.
بالطبع، أي أسلوب ضغط يؤثر على العيوب وضياع التفاصيل (أغلب الناس يركزون على العيوب ويلقون بالتفاصيل في الجحيم) لكن بالنسبة لسؤالك، ففي حالة كان الناتج النهائي بنفس الحجم فلا فرق فيما يخص العيوب أو أي شيء آخر. أما إذا كانت الحال غير ذلك فأيهما يعطيك حجما أكبر هو الأفضل، كل ما في الأمر أنك لا تعرف من سيعطيك الحجم الأكبر مسبقاً ~
|
لا أعلم سبب هذا، لكن ربما يكون bug في أحد الانكودرز أو شيء من هذا القبيل وربما لا، سأحاول تقصي الأمر على العموم، لكن لا أعدك بشيء
أعتقد أنك ستفضل إنتاج اللوسلس بـ 8 بت ثم النهائي بعشرة بت
المسألة لا علاقة لها بسرعة الإنتاج بمعنى الضغط، بل بسرعة الـ frameserving يعني avisynth.
ما يفعله ياتا هو التالي
أفيسينث لا ينتظر انتهاء عملية "إرسال" الفريم x ليبدأ "بتحضير" الفريم x+1، بل لديه خوارزمياته ولديه ما يسمى buffer (مساحة في الذاكرة العشوائية)كود: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)+...
إذا كان هناك مجال يتسع لفريم إضافي وكانت الخوارزميات "موافقة" على ملئه فستملؤه. المشكلة هنا أن هذه الخوارزميات متخلفة نوعاً ما (أفيسينث يعود إلى التسعينات والجميع يعلم أن أخطر نقاط ضعفه هي سوء التحكم في الذاكرة)
إضافة إلى أن أفيسنث ليس لديه مفهوم lookahead غير سيء، لذا ففي أغلب الأحيان سيبدأ في تحضير الفريمات القادمة من أجل الإرسال في وقت متأخر، لكن قبل انتهاء إرسال x. هنا إذا استغرق x+1 وقتاً طويلاً فسيكون انخفاض السرعة حاداً. ثم ستتراكم فريمات أخرى بعد x+1 تتنظر انتهاء تحضيره كي يجيء دورها.
وعلى العموم، انخفاض السرعة هذا لا يمكنك ملاحظته من خلال مؤشر السرعة الخاص بالانكودر لأنه يعطيك معدل سرعة إنتاج الفريمات السابقة كلها لا معدل سرعة إنتاج الفريمات الأخيرة فقط
رجعت
قبل أن أبدأ هنا لك مني اعتذاروكلا، أسلوب معدل البترايت لا يحتوي خاصية إعطاء كل بت حقه من البترايت، الأمر نفسه ينطبق على الـ crf لكن بدرجة أقل. الـ crf يعطي كل ماكروبلوك الجودة التي قدر المنتج أنها حقه.
لم أقل في حياتي كلها إن استعمال معدل بترايت يعطي بترايت ثابت على طول الفيديو. لن تحصل على ذلك إلا إذا جعلت qcomp بقيمة 0 ولا أظن عاقلاً يريد فعل ذلك اللهم في حالات خاصة جداً لا علاقة لها بالفانسب والريب.
بنقاش آخر هُناك من جزم أن تحديد البت ريت سيُحدد بيت ريت ثابت على كل الحلقة
ومن جزم أن الـ 2pass يُظهر عيوب بالإنتاج "بلوكس وبندنج" بعكس الـ CRF
ومن جزم أن الـ CRF أفضل من الـ 2pass وأظن أنت تجزم بهذا لكن أنا مازلت أرى أن الاثنين لهم نفس الفعالية لكن هذا له مساوئ وميزات والثاني له مساوئ وميزات "ردي سيشرح ذلك"
لكن بما أن النتيجة مماثلة والـ CRF أسرع سأعتمده
والمشكلة أنهم ينشرونه وبعد أن تسألهم يقولوا "اذهب إلى مسومس"
وجئنا إلى مسومس وكان الكلام مختلف
لا أعلم إن كانت طريقة صحيحة لكن عند رؤية الـ Media Info بالـ MPC بالـ CRF لا يظهر خانة الـ بيت ريت لكن إذا تُم تحديد الـ بيت ريت فتظهر الخانة وهذا لمحته بإنتاج خاص بيUTW يستعملون crf وجميع الفرق الانجليزية الجيدة في الإنتاج (Eclipse, Static-Subs, gg) وشبه الجيدة (Commie, Nutbladder, Coalguys, UnderWater, Thora, mazui) كذلك تستعمل crf وحتى الفرق السيئة أغلبها تستعمل crf. هل شاهدت crappy re-encode لإصداراتهم ثم قلت ما قلته؟ حتى Doki الأغبياء يستعملون crf،
أصلاً، كيف حكمت أنهم يستخدمون bitrate بدل crf في إعداداتهم؟؟
ممكن إذا كانت بطريقة إنتاج مختلفة قد تظهر لذا لن أجزم لكن الخانة ظهرت بـ UTW, Thora, Doki
ولم تظهر عند gg,Commie,Mazui,Coalgirls
توقع كل شيء منهمحتى Doki الأغبياء يستعملون crf، حملت إصدار لهم خصيصا كي أضحك قليلا (لأني وثقت بكلامك نوعاً ما، شيء لا أستغربه منهم) لكن خاب ظني، إنهم يستعملون الـ crf
One means of VBR encoding is fixed quantizer or fixed quality encodingكلام الويكيبيديا الذي طرحته هنا لا علاقة له بموضوع crf vs bitrate. الموضوع يتحدث بشكل عام جداً عن أساليب التحكم في توزيع البترايت/الجودة ولا يأخذ خصوصية x264 بالحسبان ويقارن بين 2pass bitrate mode و fixed quality mode. لو أنك قرأت الموضوع جيداً لعلمت مباشرة أن المقصود هو QP وليس CRF.
اقرأ جيداً ما كتب هناك:
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"
|
لساتك مصر على رأيك رغم أن الكل قال لك أنك مخطئ
ترجمتك لما قاله الويكي أصلاً خطأ الـ crf ليس pass من الـ 2pass أبداً و شغلة ان لهما نفس الخوارزمية لا يعني أنهما متشابهان او جزء من بعض أبداً
و أنا ما قلت أن البت ريت ببقى ثابت!! البت ريت هو معدل فقط يعني بتغير بس تغيره مش بكفاءة الـ crf و الكل اصطلح عليه اسم بت ريت ثابت لا أكثر
المسألة مش توفير وقت و بس!! خلي الكل يشارك بالموضوع اذا أنا و أكيبودن مش مقنعينك.... و انا قلت ان المشاكل مثل بلوكس و باندينغ ليس سببها الأصلي و المباشر هو الانتاج 2pass!!! قلت أنه سبب غير مباشر يعني استخدامه يؤدي إلى إظهار عيوب ما كان المفروض تظهر!
و انت ما جاوبتني على سؤالي في مكسات ألا و هو كيف تنتج فيديو لوسليس باستخدام x264؟؟؟ ههممم هل راح تستخدم الـ 2pass تبعك؟؟؟؟
لا تحرف كلامي و تتهمني خطأ.... مصطلح البت ريت الثابت هو تسهيل لفظي فقط و الكل مدرك هذا الشيء!!! (حسستني اني داخل على الفانسب من يومين!!!!!!!!!!!!!!!!!!!!)
بانتظار أكيبودن و الخبراء
مشكورين
|
هذا يحدث كثيراً، يأتي شخص إلى الرايزون يقول لي انت قلت كذا وكذا وأنا لا علم لي بأي شيء ثم يظهر أنه يسمع كلام منقول بشكل غير دقيق. أو يأتي شخص يحاول لعب دور الشاطر ليوضح "أخطائي" في حين انه لم يقرأ الدرس جيداً... i ┐( ̄ー ̄)┌ i
ما قلته عن Mediainfo غير صحيح. إن كنت تريد معرفة أسلوب الإنتاج المعتمد فعليك بـ Hex Editor وستجد الإعدادات في البداية أو تكتفي بالميديا انفو لكن تنظر إلى
Mediainfo ليست أداة موثوقاً بهاكود: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
غير صحيح بالمرة. كما قلت، لو أنت قرأت هذا الموضوع الذي ترد عليه لما ارتكبت هذا الخطأ. CRF لا يعني جودة ثابتة-- ذلك يسمى qp
اقرأ:
"
CRF: أسلوب التحكم في الجودة الأكثر تقدما. قلنا أن qp يطبق أسلوب quantization متماثل (uniform)، الـ crf يطبق أسلوب quantization تناسبي (adaptative) فيخفض من قيمة الـ QP بالنسبة للفريمات التي تحتوي تفاصيل معقدة ويزيد منها في الفريمات التي تنتمي إلى مشاهد الحركة والفريمات الفقيرة من التفاصيل
"
حرفياً: qp= ضياع الجودة. كلما كان أصغر حافظت على الجودة أكثر. إذا كان ثابتاً، وفقط إذا كان ثابتاً، تكون الجودة ثابتة fixed
مضيعة للوقت أن أواصل دحض مثل هذه الحجة التي تعتمد على كلام لا يأخذ خصوصية الانكودر بالحسبان كما أنه مقتبس من wikipedia ولا يبدو أن أحداً اهتم بتحديثه فضلاً عن أن كاتبه المجهول كلياً يقر بنفسه أن كلامه غير شامل: usually، one means
غير صحيح إن كنت تقصد ويكيبيديا. ويكيبيديا لم تتحدث في ذلك الرابط عن الـ CRF أصلاً. أما ميدياويكي (mewiki) فهذا أمر متوقع بالنظر إلى أن كاتب الصفحة هو أحد مطوري الانكودر kemuri-_9
أسلوب الـ crf ليس نفسه الباس الثانية، لأن الباس الثانية محدودة بالبترايت الذي حددته الباس الأولى وهذا الأمر لا ينطبق على crf. هذا الكلام لا يعارض mewiki بأي حال.
كلام المطور لم يكن رداً على كاتب الموضوع بل تعليقاً وتأكيداً على أن crf هو الأفضل لكل ذي عينين.
الناس تستعمل الأحجام المحددة مسبقاً لأنهم يخافون أن يخرج الحجم عن سيطرتهم كونهم جهلة بالإعدادات. هذا غالباً يؤدي إلى bitrate starvation أو pointless filesize bloating
لا تنس أنه لا يمكنك معرفة الجودة النهائية عند استعمال حجم محدد + تحتاج وقت أطول Vs تحصل على الجودة التي طلبتها في وقت أقل
المسألة كلها: هل الجودة (لا سيما أنها توفر الوقت) هي أولويتك أم حجم محدد كي ترضي الليشر الذين من الواضح أنهم من يسيرون الفانسب العربي
بالنسبة للشرح فكل ما تحتاجه هو معرفة أن : CRF = QP + AQ + QCOMP + Optional MBTree
ولو أنه لم يظهر لي أنك تبذل جهدا للفهم لوجدت رداً من ذلك القبيل. لأن أولئك الخلق لا فائدة من تعليمهم وتضييع الجهد عليهم
|
معك حق أكيبودن في كل ما قلته...
كلمة على السريع: ما قال أنه قرأه عن شخص آخر كان ذلك الشخص هو أنا و لكن ما قلت أي شيء خطأ اللهم هو فقط فهم كل شيء بالعكس الله يصلحه!
حاولت أفهمه و أعطيه شرح الميدياويكي بس ترجمه غلط مثل ما انت شفت!!! و حاولت أقنعه بأن ترجمته للنص الإنجليزي أصلاً خطأ و لا زال غير مقتنع فشو أعمل... دليته على موضوعك مع إنه قلل من شأن المواضيع العربية بس شكله ما عرف وين يدور...
عموماً أنا ما أردت له إلا الخير و ممكن بعد كل هذه الحرب الكلامية تنعكس عليه بشكل إيجابي و أنا واثق من قدرته على ذلك (على الأقل بغلب حاله و بسأل و بدور صح؟!!!!) يا ريت الكل يصير مثله!!
ما يعجبني في موضوعك أنك تضع مراجع و مصادر للتعليم مش مجرد شرح للطريقة. هذا ما أريد رؤيته صراحة لأن المواضيع البسيطة لا تغني القارئ و سرعان ما يقع بمشكلة لا يعرف حلها بينما لو كان الموضوع شامل (بطريقة لا يقع فيها تلقين!!) لقدر على حلها بنفسه.... هذه هي قناعتي!!
بالتوفيق للجميع
|
لدي سؤال جديد... انت قلت أن مشاهدة إعدادات الإنتاج بالطريقة الصحيحة ليس عن طريق الميدياإنفو بل عن طريق Hex Editor... يا ريت تشرحلي شوي عنه لأني أول مرة بسمع فيه...
ثم.... أنا أنتجت إحدى الحلقات بـ ipratio=1.1 و الحجم كان أقل شوي من السابق... هل أستمر بهذا أم أعود إلى 1.4 أو قيمة أخرى؟ سؤالي الأصح هو ما فائدة اختيار قيمة كبيرة (1.4 مثلاً) بدل القيمة 1.1 اللي انت حكيت عنها انها مناسبة لحفظ التفاصيل؟
كمان qcomp لو زدته كثير مثلاً لحد 0.75 أو ما شابه... كيف سينعكس هذا على الحلقة؟ زيادة حجم؟ جودة؟ سرعة؟ طيب لو قللت القيمة أكثر؟
هذه استفساراتي... بانتظار الرد
|
لم أقل ذلك. "إن كنت تريد معرفة أسلوب الإنتاج المعتمد فعليك بـ Hex Editor وستجد الإعدادات في البداية أو تكتفي بالميديا انفو لكن تنظر إلى Encoding Settings "
طريقة مضمونة مثلاً هي أن تثبت MinGW على ويندوز ثم تضيف إليه MYSYS وتفتح MYSYS.bat ثم تكتب strings filename.mkv | less
ثم تكتب
وتضغط Enter للبحث عن كلمة x264كود:/x264
سيأخذك مباشرة إلى شيء كهذا
تحت لينوكس لا تحتاج لهذه البرامج.
لن أجيب عن أي سؤال إضافي بهذا الشأن لأنه يمكنك معرفة ذلك بميديا إنفو أو افتح الفيديو في محرر وابحث عن x264
الجواب في الموضوع، لكن سأتعمق قليلاً
عندما يكون لدينا فيديو مليئ بالنويز والغرين (التي إن تخلصنا منها صار الفيديو قبيحاً وغبياً) فسيذهب مفهوما التكرار والاستعارة في البتستريم إلى الجحيم بدرجة لا بأس بها... لأن هاتين الخاصيتين لا يمكن أن تكونا ثابتتين من جهة ولأنهما تضيفان حدوداً في كل مكان من الفيديو. لهذا قد تصبح أغلب الفريمات كأنها I-frame من ناحية عدم/قلة استعارة البيانات من جيرانها (وليس من ناحية القدرة على التشغيل بدءً منها)، في هذه الحالة لن يكون هناك معنى كبيراً لتدليل الفريمات التي تمثل تغير المشاهد بقيم QP صغيرة لا تستحقها، لأنه على مستوى البتستريم كأنك تغير المشهد كل فريم +-كود:QP(P)=ipratio x QP(I)
الحدود تمثل تغير مفاجئ وكبير في الألوان بين جسمين لذا هي تكون في البتستريم على شكل قيم DCT كبيرة جداً يعني تحتاج إلى عدد كبير من البتس لتخزينها (يمكنك تخزين قيمة 5 في 3 بت أما قيمة 2514 فتحتاج إلى 12 بت، مثال مبسط جداً للتوضيح)
عموماً قيمة 1.1 لا أعتقد أنها قد تناسب الأنيمي، أنا لا أنزل تحت 1.25 ( وهذه في حالات نادرة)
الموضوع
|
طيب يعني الـ ipratio ليس من المفضل تقليلها أكثر من 1.25...
سؤال آخر: الـ 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
هذا النقاش أيضاً:
أخيراً، في شارة بداية أنيمي فراكتال، أنتجتها ذات مرة بقيمة 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 كما سمعت من أحدهم
الفلترة ليست حرام وليست حماقة بحد ذاتها
هناك دائماً أقراص البلوراي التي تكون ألذ من البث الفضائي في كثير من الأحيان
|
معك حق... الـ GradFun2DBMOD بقيمة 2.7 كبير جداً! هل تنصح باستخدامه أو باستخدام العادي؟ شو القيمة المناسبة؟
في فلاتر دي باند أخرى مثل flash (لا أتذكر اسمه الكامل) و أيضاً gradfun3 اللي بيجي مع الـ dither... يعني خيارات كثيرة بس شو الأفضل بينها عشان أضمن نتيجة الإنتاج بالإنكودر تكون فعالة؟
أيضاً: الـ ipratio لو خليتها 1.4 أو زدتها كيف بنعكس هذا الشيء على الحجم و أيضاً الجودة؟
في pysrd له قيمتين الأولى أضعها دائماً 1 لأنها تفيد في الحفاظ على التفاصيل مع إني بشوف البعض بضعها 0.9 فحبيت أعرف السبب؟ و قيمة ثانية مثلاً 0.9:0.2 الـ 0.2 هي تريليز طيب شو بالضبط عملها؟
|
السلام عليكم
الفلترة أذواق حتى لو وصل ال gradfun2dbmod الى 3 او 3.5 اذا فعلا الراو يستحق هذه القيم اذا نعم
~ VEGETA ~
الاشياء الغبيه انه ان تضع الفلاتر عبط او تضع فيها ارقام عشوائية
لديك برامج مثل ال avsp جرب عليه الفلتر باعدادات لا تسمع لهذا الكلام
القيم تختلف من راو الى اخر
سلام
[i ┐( ̄ー ̄)┌ i]
اولا: اشكرك لجهودك في طرح الموضوع بتلك الطريقة الشاملة
ثانيا: صورة الحمار في البداية , لا تعليق
اضن انك مخطئ , هنالك edit وبها الكوبي و البيستشخصياً، أعتقد أن سبب نفور البشر من الـ CLI هو أنه لا يُتاح لك استعمال COPY-PAST فيها....
انظر
ترى الاكس الاحمر الذي يغلق النافذة و جنبه مربع التكبير و جنبه زر التصغير , اضغط رايت كلك على الشريط الذي بجنبهم وستظهر لك قائمة منها الـ EDIT و بها يوجد الـ COPY-PAST
على العموم ان كان موضوعك من ورائه نوايا حسنة فانا اشكرك و احييك
و عليكم السلام و رحمة الله
|
الأفضل هو أفضل ما يناسبك أنت. جرب.في فلاتر دي باند أخرى مثل flash (لا أتذكر اسمه الكامل) و أيضاً gradfun3 اللي بيجي مع الـ dither... يعني خيارات كثيرة بس شو الأفضل بينها عشان أضمن نتيجة الإنتاج بالإنكودر تكون فعالة؟
اقرأ الموضوع من أجل الإعدادات.
نعم، لكن الذوق لا يغير من حقيقة الحماقة. قد يُقدم لشخص كوب ماء نظيف فيسكبه في البالوعة وينزل إلى دورة المياه كي يشربه هناك، ثم يدعي أن هذا ذوقه.الفلترة أذواق حتى لو وصل ال gradfun2dbmod الى 3 او 3.5 اذا فعلا الراو يستحق هذه القيم اذا نعم
لا يبدو أنك تعرف معنى COPY-PAST
كلك يمين في السواد يكفي لفعل ما تتحدث عنه، وهو، مرة أخرى، ليس COPY-PAST
عذرا مرة اخرى لكن بالطريقة التي ذكرتها انا
بامكاني ان انسخ بها و الصق بها لكن بقليل من تشغيل للعقل
اولا تختر select all بطريقة الـEDIT او بطريقة الرايت كلك
ثم نعمل كوبي للكتابة كلها
او اذا اريد اختيار بعض من الكلمات بالماوس يمكن ذلك بعد select all و من ثم نعمل لها كوبي
لكن الكوبي لا يمكن عمله الا بالـEDIT او كوترول سي , اي لا يعمل بالرايت كلك , لذا الـEDIT تعتبر اشمل طريقة
+ لا تتهم الناس بانها لا تعرف بدون دليل منطقي فهمت
لان الكوبي و البيست من اسهل الامور بالكمبيوتر
و اي شخص يمسك فارة و كيبورد على حسب علمي يعرف ما هي الكوبي و البيست
وعليكم السلام و رحمة الله
|
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
المفضلات