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

ملاحظة : الاعضاء الكرام أغلب هذا الرد ليس له علاقة مباشرة بالانكودر x264
وارجو المعذرة من الاخ akkipuden لأنني خرجت عن الموضوع
هذا الرد هو رد على رد الاخت fearry
__________________________________________________ ______________

لو عمل الباك سبيس معي هالعملة كان زمان طيرته من الشباك icon944

الاخت fearry ، لك كل الاحترام على اكتشافك بنفسك لهذه الطريقة ، وكذلك على التجارب التي قمتي بها.


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

2- اذا تعددت المشاهد المراد حذفها سينتج كما ذكرتي:

اقتباس:

---

طيبعا هناك مشكله الان ما هي انه منحط فريمات قبل و بعد المكان الي بدنا ياه

---

لذلك انا لا استعمل هذه الطريقة انما استعمل طريقة مشابهة لطريقتك keyint 1 --min-keyint 1--

الطريقة التي استعملها او بالأحرى هن طريقتين لكن يعتمدن على نفس المبدأ:

الطريقة الاولى :
اقوم بإدخال الفيديو للفيرتشوال دب ثم اعمل save باستعمال
full processing mode وال compession بكون (Uncompressed RGB/YCbCr)
بهذه الطريقة سينتج فيديو فيه كل الفريمات تكون key-frames
نقوم بالحذف في اي مكان نريده ثم نعمل حفظ باسخدام direct stream copy
(اذا كان يوجد صوت يكون الصوت جاهز .. اي تم قطع المقطع الموازي لمشهد الفيديو المحذوف )
بعد ذلك اقوم بضغط الفيديو باستعمال x264 (شكراً akkipuden لهذه النقلة من megui الى x264)
طبعاً يمكن الضغط مباشرة من الفيرتشوال دب لمن اراد ذلك

الطريقة الثانية:
في بعض الحالات اضطر الى تحويل الفيديو الى صور (اي image sequence) لعمل تعديلات معينة
بعد ذلك احول الصور الى Uncompressed video باستعمال الفيرتشوال دب ، مع دمج الصوت معاه
اي نتج لدي فيديو فيه كل الفريمات تكون key-frames
ثم يتم عمل باقي الخطوات مثل الطريقة السابق

ما يمييز هاتا الطريقتان عن طريقتك ( keyint 1 --min-keyint 1-- ) هو انني اقوم بعمل encoding فقط مرة واحدة في المرحلة النهائية ويكون الناتج فيديو عادي وليس كوكتيل من ال key-frames

بينما في طريقتك اذا اردنا ضغط الفيديو النهائي بذلك نكون ضغطنا الفيديو مرتين => خسارة المزيد من الجودة
واذا ارت تركه كما هو ، اي ان كل فريم يكون key-frames يكون الفيديو الناتج كبير الحجم وثقيل جداً وقت التشغيل

بالمناسبة هنالك بعض التفصيلات لم اتطرق لها بخصوص الطريقتين التي استعملهن.
من واجه مشكلة باستعمال هاتين الطريقتين (ما هو اعراب هاتين ؟ ) أو اي مشكلة بخصوص الحجب يمكنه مراسلتي على الخاص مؤقتاً ، الى ان انهي موضوعي الخاص بالحجب ان شاء الله(بعد 100 سنة Icon498)

------

لكن بعد ان تعرفنا على الاخ akkipuden اصبحت هذه الطريقة بدائية (في اغلب الحالات)

ابتدائاً من اليوم سأبدأ ان شاء الله باستعمال ال qpfile ، وهو كالتالي:

اذا كان لدينا فيديو مكون من 10510 فريم مثلاً، وأردنا تحويل الفريمات 105،210،250 الى key-frames
كل ما علينا فعله هو انشاء ملف text نكتب بداخله الاعدادات التالية:

كود:

---

105 I
210 I
250 I

---

ثم اضافة الأمر التالي في اعدادات الانكود:

كود:

---

--qpfile "file.txt"

---

المزيد من التفاصيل حول ال qpfile تجدونها في الصفحة الاولى من هذا الموضوع

اقتباس:

---

عن ال quantization parameter اتوقع انه قال " إن كنت ستستعمل هذا الأمر فالخبراء ينصحون باستعمال i "--crf ليس له علاقة في موضوع اتوقع ههههه

---

انا كنت اتكلم عن quantization parameter الخاص بال qpfile iconQ

السلام عليكم
ارجو المعذرة من الاخ akkipuden لأنني خرجت عن الموضوع كثير بدون هدف
__________________________________________________ ___________
هممم اول شيء مبروك انه كل مشاكلك انحلت
ثاني شيء طريقتي هي انه تكون سلاسة السيغنج للفيديو كما في يوتيوب و افضل فقط ههه
اما عن ال كل فريم كي فريم بعرف الطرقتين لكن قالت طريقتي متخلفه مش من العصور الحجرية
هههههه عيوب طريقتك اولا بدك مساحة في الهارد ديسك و ثانيا بدك كمان مساحة في الهارد دسك
على اي حال شاي و قهوه كلهم بدون سكر المهم اعطيتك معلوما حتى لما تروح على منتدى ثاني و تسأل في شيء مماثل
وواحد يقول عن طريقة لانتاج كل فريم كي فريم بكون عندك 3 طرق بتقول هع انا من مدرسة مسومس للبصل و الثوم تعال بعلمك
شايف يعني كل واحد بصله معاه و الثوم للفول ما تنسى هههههه
يلا في التوفيق و ما تحرمنا من اسألتك بما انه مو انا الي برد اسأل كما تريد ههههه
و تعلمت شيء مفيد عن ال qpfile سو ما طلعت بدون السمنه و العسل هه طلعت في بصل
و تقبل الله
في امان الله
و مع السلامة

الله يبارك فيك

اقتباس:

---

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

---

صحيح ... مساحة مش بعقل ... خصوصاً اني بستعمل bmp image sequence لأن png يغيير اللون

السلام عليكم
حسنا الكبيودن بقتلنا اذا حطينا رد ماله علاقة في الموضوع زودناها
الان شيء واحد فقط اذكر انه في برامج كانت فيها خاصية رائعة جدا فعلا
انه اول شيء بتقطع الحلقة او الملف الفيديو دايرت مع mp4 و اذا بدك تعدل على فريم او تقطع فريم
كان اذا اخترت استخراج دايركت كانت تاخذ الالمقاطع الي تم تعديلها بين كي فريمين و تعيد انتاجه بالعالة جوده ممكنه و بنفس الكود
و بنفس الاعدادات يعين برامج حقا ذكية يعين ضع الفيديو و عدل عليه و يمكن كان في اسؤ الاحوال يزيد معاي 3 ميغا
و لا يتم اعادة انتاج غير المقاطع الي تم التعديل عليها في الحقيقة من زماان ما استخدمته لانه عندي معرفه صغيرة في ال avs لكن كان مفيد
في الحجب و السريع و التعديل السريع و الميوزك فيديوز ههههههه فعلا كان رائع ///
بالاختصار بنتج المقاطعه الي تم تعديل عليها فقط و برجع بدمجها في الفيديو فقط يعين حقا طريقة بتوفر عليك كثيير مشقة
نسيت شو اسمه المهم كانه في واحد نفس خاصيه مع العلم هذاك سهل التلاعب معاه و كل شيء روووعة اخ بس منه نسيت شو اسمه
نزلته حتى اتأكد طلع شوي معقد و بما انه ما بهمني الامر لم احاول معاه المهم انت اذا بدك انت شوف اسمه VideoChargeStudio
رابط التحميل على الميديا فير رفعته الان يعين لس جديد خخخخخ فرش http://www.mediafire.com/?ybk4s17yagkgy86
المهم اذا انه بنتج بستخدم الانكودر x264 هههههههههههههه
سلام

للأسف lavf يغير الالوان مثل directshow .....

وهكذا عدت الى نقطة الصفر ...

المشكله : لدي bmp image sequence اريد تحويلهن الى فيديو h264 طبعاً باستعمال x264 مع المحافظة على الالوان ... ارجو المساعدة

--------------------------------------
تعديل:

قمت بتحويل ال bmp image sequence الى فيديو غير مضغوط باستعمال الفيرتشوال دب .. ثم ضغطه ب x264 مع استعمال lavf
لكن نتج تغيير الوان

المحاولة الثانية كانت عن طريق انشاء ملف avs .. حيث تم "استدعاء" الصور باستعمال الدالة ImageSource
واستعملت الأمر demuxer avs-- في إعدادت الانكودر ، لكن .............. ايضاً تغيرت الالوان

*المقصود بتغيير الالوان هو اضافة تعتيم خفيف اي تقليل الاضاءة.......

--------------------------------------
تعديل2:

غرييييييييب .. انا استعمل media player classic مع حزمة k-lite
دخلت الى خيارات ال player وجربت اغيير ال renderer .. وجدت انه Haali renderer يشغل الفيديو عادي بالوانه الطبيعية.

انا الآن "بطلت اجمّع" هو المشكلة فييين ؟
يبدو انها ليست مشكلة ال demuxer وال x264

لكن ماذا اذا اردت وضع الفيديو على الانترنت واردت ان يشاهده الناس بالوانه الاصلية
اقعد اقلهم غيروا الrenderer !!!!!!!!!!!!

ارجو المساعده
وشكراً

حدث هذا مع CCCP ؟ واحذف k-lite
احذف CoreAVC إن كان منصباً عندك. الخطأ ليس من الديمكسر ولا الانكودر!

حذفت k-lite وركبت cccp
لكن للأسف cccp ايضاً نفس المشكلة

حذفت cccp وركبت k-lite مرة اخرى (كل شيء على الافتراضي) بقيت نفس المشكلة
لكن حتى Haali renderer لم يعد يظهر الالوان الاصلية

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

للتذكير: ما زالت المشكلة قائمة
ارجو المساعدة

-----------------------------------------
اضافة خارجة عن الموضوع :

وجدت ان الفيرتشوال دب يقوم بالمزايا التي ذكرتها الاخت fearry
حيث يمكنك تفعيل خيار smart rendering من قائمة video
وبذلك يمكنك الحذف بأي مكان ترغبه دون التقييد بقضية ال key-frames
تفعيل هذا الخيار يعني انه سيقوم بعمل direct stream copy لكل الفيديو ماعدا المنطقة التي تم التعديل عليها فيقوم بعمل encoding لها فقط.
يمكن الاستفادة من هذه الميزة ايضاً اذا اردت اضافة شعار يظهر لوقت معين من الفيديو.
وبذلك يتم المحافظة على الجودة الاصلية للفيديو ، وتقليل وقت الsave بشكل ملحوظ.

ملاحظة : يجب ان يتوفر لديك نفس الكوديك المضغوط به الفيديو ... اذا كان الفيديو h264 يمكنك تثبيت x264vfw لإستعماله بالفيرتشوال دب
مع انه لا ينصح بهذا الانكودر .. لماذا؟ .. تجد الجوابهنا .. المشاركة الرابعة (FAQ ) كتبها Sharktooth

السلام عليكم
هممممممم تدخلت في الموضوع كثيير غومين
____________________________________

حسنا جربت ان تنتج فيديو غير مضغوط (No recompression: YV12)
يعني اقرأ الملفات بستخدام ImageSource داخل ملف avs
و ادخل الملف داخل الفيرتشوال دب مود و فقط اعمل سيف از
و اختر من video اختر direct stream copy و انتجه
طبعا حيكون الحجم خرافي شو اذا تغيرت الالوان
اذا لا حاول ان تنتج الملف المنتج مرة اخرى لكن بستخدام ffm2 كما سمعت انه ما بغير الالوان
__________________________________--
تعديل 1
سؤال غبي حسنا ماذا لو وضعنا في الAvs دايركت شو و اجبرنا الديكودر ان يقرأ الملف عن طريق ffms
هل يعامل الفيديو كانه فيديوه انتج دايركت ستريم و قرأئه من الرام و يعيد انتاجه بستخدام ffms
يعين هل الالوان ستتغير في باس ال دايركت شو و تثبت في ال ffms ام لن تتغير الالوان ؟؟؟؟
سلام

وعليكم السلام

الاخت fearry

اقتباس:

---

حسنا جربت ان تنتج فيديو غير مضغوط (No recompression: YV12)
يعني اقرأ الملفات بستخدام ImageSource داخل ملف avs
و ادخل الملف داخل الفيرتشوال دب مود و فقط اعمل سيف از
و اختر من video اختر direct stream copy و انتجه
طبعا حيكون الحجم خرافي شو اذا تغيرت الالوان

---

لم تتغير الالوان iconQ

اقتباس:

---

اذا لا حاول ان تنتج الملف المنتج مرة اخرى لكن بستخدام ffm2 كما سمعت انه ما بغير الالوان

---

عند انتاج فيديو غير مضغوط ب ffms تحدث هذه المشكلة:

http://images.msoms-anime.net/images...8889833316.jpg



شكراً على المحاولة

السلام عليكم
حسنا الان استطعت ان تحول ال bmp image sequence الفيديو و لم تتغير الالوان تقدم ههههه
الفيديو ادخله الى ال Avs مرة اخرى لكن ما تجبر الانكودر ان يستخدم اي شيء خليه اوتو و استدعي الملف عن طريق ال ffms2
هل جربت هذه الطريقة /// ما عندي علم في هذه الاشياء لكن هذه اشياء بديهيه جرب
و لوووووول smart rendering رائع شكرا على البحث في الموضوع كما قلت اعمل سلطة احسن
كان الموضوع مساعده لك ههههههه حسنا شيء اخر مهم
الان depth 10 لما لا تستخدمه عملت عليه تجارب قبل مده طويله و كان يعطيك صورة نقية جدا
سلام

عندما تستدعي فيديو في avsp بواسطة ffms2، هل تجد تغيراً في الألوان؟؟!
بعد الضغط لا بد أن تقل الإضاءة قليلاً جداً، لأنه ضغط! إن كنت لا تريد أي نوع من تغير الألوان فعليك بإنتاج لوسلس بحجم خيالي.
ffms2 ليس جيداً جداً في استدعاء كوديكات غير ليست من عائلة mpeg لأنه ffmpegsource
من الواضح أن نظام ألوان الخام ليس yuv4:2:0 في مصدرك، بل rgb24
ألا تستطيع أن تنتجه المصدر بنظام الألوان الأول؟

السلام عليكم
حسنا تريد الحل الوافي و الكافي و انتي ماكافي
استخدم كود ال quicktime مضمون انه لا يغير الالوان و بعطيك h264
سو ابعد عن الخبيث x264 مغير الالوان و حتى ترتاح نفسيا و عاطفيا ههههه
لا لا حقا ال quicktime رائح جربه و ترى انه الالوان لن تتغير بعطيك بمتداد mov و تستطيع ان تعيد المكس الى mp4 او mkv
لكن بده البتريت يكون اكثر شوي يعين بدل 700 بده 900 طبعا نفس الالوان جرب ههههههه

++++++++++++++++
تعديل 1
صورة جميله للانتر فيس للديكودر
http://images.msoms-anime.net/images...1923406847.png
_______________________
تعديل اخر الكود الي بشغل الyv12 على ال quicktime
http://www.unthinkable.com/downloads...eCodec.win.zip
//////////////////////////////////
تعديل اخر 1
http://athos.leffe.dnsalias.com/ffvfw-20031028.exeاذا بتتذكر انه كان موجود برنامج ال avs to avi او makeavsi البرنامج يضع الAvs داخل كونتينر Avi

و تجعل جميع الديكودرات اليتي لا تقبل غير Avi تعمل برنامج رائع جدا لووووووووول

سلام

الاخت fearry
وعليكم السلام

اقتباس:

---

حسنا الان استطعت ان تحول ال bmp image sequence الفيديو و لم تتغير الالوان تقدم ههههه
الفيديو ادخله الى ال Avs مرة اخرى لكن ما تجبر الانكودر ان يستخدم اي شيء خليه اوتو و استدعي الملف عن طريق ال ffms2
هل جربت هذه الطريقة /// ما عندي علم في هذه الاشياء لكن هذه اشياء بديهيه جرب

---

للأسف نفس رسالة الخطأ السابقة

اقتباس:

---

الان depth 10 لما لا تستخدمه عملت عليه تجارب قبل مده طويله و كان يعطيك صورة نقية جدا

---

شو يعني depth 10 ؟

اقتباس:

---

حسنا تريد الحل الوافي و الكافي و انتي ماكافي
استخدم كود ال quicktime مضمون انه لا يغير الالوان و بعطيك h264
سو ابعد عن الخبيث x264 مغير الالوان و حتى ترتاح نفسيا و عاطفيا ههههه
لا لا حقا ال quicktime رائح جربه و ترى انه الالوان لن تتغير بعطيك بمتداد mov و تستطيع ان تعيد المكس الى mp4 او mkv
لكن بده البتريت يكون اكثر شوي يعين بدل 700 بده 900 طبعا نفس الالوان جرب ههههههه

---

انا بكره ال quicktime .. + استعمال x264 احترافي اكثر Icon030
لكن ربما استعمله اذا نجح ..

اقتباس:

---

اذا بتتذكر انه كان موجود برنامج ال avs to avi او makeavsi البرنامج يضع الAvs داخل كونتينر Avi

و تجعل جميع الديكودرات اليتي لا تقبل غير Avi تعمل برنامج رائع جدا لووووووووول

---

اول مرة اسمع عنه Icon108

انا بعرف avc2avi
على كل حال سأجربه لاحقاً ان شاء الله

وشكراً على المساعدة

آسف اخي Akkipuden على التأخر في الرد
لكن احببت اجراء بعض التجارب قبل الرد عليك

اقتباس:

---

عندما تستدعي فيديو في avsp بواسطة ffms2، هل تجد تغيراً في الألوان؟؟!

---

احصل على رسالة الخطأ التالية:

كود:

---

Traceback (most recent call last):
File "AvsP.pyo", line 7123, in OnPaintVideoWindow
File "AvsP.pyo", line 9474, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x0517A300

---

اقتباس:

---

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

---

فعلاً التغيير الحاصل ليس كبير جداً .. يبدو انني سأرضى به وأكمل عملي
وهذه صورة تبين التغيير:
http://images.msoms-anime.net/images...4460081491.jpg

مع العلم ان التغيير يبدو واضحاً أكثر من خلال مشغل الفيديو
لمن لم يلاحظ التغيير يمكنه حفظ الصورة لدية وفحصها بالفوتوشوب
او اي محرر صور
واكرر ان التغيير يكون ملحوظ بشكل اكبر من خلال مشغل الفيديو

اقتباس:

---

من الواضح أن نظام ألوان الخام ليس yuv4:2:0 في مصدرك، بل rgb24
ألا تستطيع أن تنتجه المصدر بنظام الألوان الأول؟

---

سأحاول ذلك

وجدت هذه الداله الخاصة بال ffms2 :

كود:

---

FFImageSource()

---

حاولت استعمالها على مجموعة صور .. وقمت باستدعاء ملف ال avs في ال x264 دون تحديد demuxer لكن النتيجة انه ضغط فقط frame واحد

السلام عليكم
حسنا لووووول في الحقيقة لم ارد الرد لكن في الصباح يتغير الامر هههههه
المهم كما قال الكبيبودن انه مصدرك rgb حسنا
و لما تعمله لوسيس بدوه يخرج اللوسيس نفس صيغة الايميج سو حتبقى rgb
اوك هذه معلومه جديده الان اكتشفتها بعد ما وضعت صورة داخل كونتينر لووول
المهم افضل شيء ان تنتج بستخدم الالوان الاولية وتستدعيهم من اللوسيس الي عملته
بكون الامر هيك AviSource("file.avi", pixel_type="RGB24")i
طبعا سرقت الامر من هنا http://avisynth.org/mediawiki/AviSource
المهم انتهينا من هذا الامر
عن depth 10 راجع الموضوع مرة اخرى اتوقع تم ذكر الامر و ابحث عنه /// تجرب ولا تقرأ هههههه كسل
المهم كما تعلم انه التحويل يعني فقدان في الجوده مهما كان التحويل لهذا اذا بدك تحول من rgb to yv12
حتخسر الكولتي 100 في ال 100 لهذا مافي غير انه تنتج بنفس نظام الالوان
و خلص يكفي لن تجد له اي حل اخر /// اسأل عن شيء اخر هههه
===============================================
تعديل 1
حسنا لا ادري هل عندما تستدعي الفيديو بستحدام ffms2 يستدعيها نفس الالوان لكن اعلم انه الديكودر
مهما كان يختار افضل شيء و بالعادة يختار ال yv12 شاهدت اعدادات الديكودر واعتقد انه تستطيع تحديد الناتج
لهذا همم جد طريقة لتجعل الانكودر يقرأ الالوان كما هي هل استدعاء يكفي ؟؟ الله اعلم انت جرب و اخبر
الن انت ابعد عن الffms2 و لا تحدد الطريقة اجعلها اتومتيك اتوقع انه بستخدم افضل طريقة لا تلعب بها ههه
سلام

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

بداية اقدم اعتذاري على هذا الغياب الطويل .. لكني كنت مشغول جداً جداً .. ارجوا معتذرتكم وانا آسف .

الف شكر لك اخي akkipuden وكذلك الف شكر لك اخت fearry على المساعدة التي قدمتموها لي .

ها انا قد عدت لكن لست خاوي اليدين .. فبعد عدة تجارب تبين ما يلي :
----------------------------------------------------------------------------
1- الضغط بواسطة x264 لا يسبب تغير في الالوان
2- استعمال lavf كـ - demuxer في الانكودر لا يسبب تغير في الالوان
3- التحويل من rgb24 الى yuv4:2:0 هو الذي يسبب التغير في الالوان (اي كما توقعتم )

وهذه صورة لتجربة تبين ذلك :


http://images.msoms-anime.net/images...3978499605.jpg


كما ترون انه عندما ضغطت المصدر الاصلي باستعمال x264 فانه يحدث تغير بالالوان ، هذا التغير ناتج عن التحويل من rgb24 الى yuv4:2:0 ( الذي يقوم بهذا التحويل هو الانكودر ... لكن هذا ليس مهماً فانا اريد ان يكون الفيديو الناتج yuv4:2:0 )
واثبات ذلك انه كما ترون في الصورة ، عندما ضغطت الفيديو ال yuv4:2:0 باستعمال x264 لم ينتج اي تغير في الالوان بتاتاً .

والاثبات الاخر انه عندما حولت مجموعة الصور مبااشرة الى yuv4:2:0 حدث تغير الالوان .

الحمد لله تم تشخيص المشكلة بفضلكم .. بارك الله فيكم وجزاكم الله خيراً

اما الحل فهو ان تكون الصور بنظام yuv وليس rbg ...اي اريد تحويل فيديو الى صور yuv4:2:0 ... كيف .. لا اعرف! icon114 اذا كان هذا ممكناً اصلاً !!!! جاري البحث

شكراً على الدرس المفيد

درس طويــــــل لكن الأفضل

سأحضر وقتاً خاصاً لقراءته Icon-flowers0

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

أهلا عزيزي أكيبودن

كيف أستطيع الإنتاج بجودة الـ HD والـ SD من خلال الـ x264 ؟

والأنمي اللي عندي بيختلف حجم الراو من حلقة لـ أخرى . .

http://im9.gulfup.com/2011-09-01/1314893452751.png

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ポートガス・D・エース

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

أهلا عزيزي أكيبودن

كيف أستطيع الإنتاج بجودة الـ HD والـ SD من خلال الـ x264 ؟

والأنمي اللي عندي بيختلف حجم الراو من حلقة لـ أخرى . .

---

هل قرأت الموضوع؟

كود:

---

x264 --preset slower --crf 19 --aq-strength 0.8 --psy-rd 0.7:0 --output output.mkv input.mkv

---

^ هذا مجرد مثال على السريع. اختر إعداداتك كما تشاء

بالنسبة للـ SD فيمكنك تغيير الأبعاد في سكربت avs كما يمكنك استعمال إعداد video-filter (شرحه موجود في الموضوع)

نعم ..
قرأت الموضوع "عدة مرات" لكنني لم أفهم icon114

شكرا لك . .
سأجربها وأحاول تعديلها لـ أجد المناسب ..
أسعدك ربي أينما كنت iconQ

إذا أشكلت عليك جزئية أو اثنتان في الموضوع فيمكنني الشرح أكثر لكن لم تفهم الموضوع كله...

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

شكرا على أية حال ^^"

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

^

وعليكِ السلام ورحمة الله وبركاته . .
لا أحب الإنتاج باستخدام الميغوي .. كما أنني لا أجيده أيضا . .
يأخذ الكثير من الوقت . . + . . في كل مرة أبدأ فيها الإنتاج تظهر لي كلمة "Error"
وجع رأس لا أكثر هههه
وأنا أنتج الآن باستخدام x264 . .
ودائما ما تذهلني النتائج . .
طُلب مني أن أنتج بالجودتين HD و SD ..
وأتيت هنا لطلب المساعدة :’D

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

^
وعليكم السلام ورحمة الله وبركاته . .

ههههه أعلم هذا . .
نعم لدي ويندوز 7 . . سأبدأ بالبحث عنها . . لكن هل هناك موضوع تنصحينني به ؟
لن أقول إنني فهم المقصد من هذا المثل هههه
شكرا لك ^^"
لسنا فريقًا قويا ولا متوسط القوة .. ولسنا فريقا صعيفا حتى . .
فريق في أول خطواته .. لذا لا داعي لأن أحرق المسكين Icon108

يبدو أنني أحاول تخمين معنى كلامك فقط . . icon994

ان شاء الله . .
فعلا . . كلامك غير مترابط ههه icon95
شكرا .. وأنت بألف خير . . ^^"
وعليكم السلام ورحمة الله وبركاته . .

السلام عليكم
هممممممممم
ما عبفر شيء في وندز سبعة لكن سمعت عنه هو و مشاكله
لكن مواضيع تبدأ فيها
[h=3]:: فــلـنـتـعلـم Avisynth سـويـةً ~[/h]
اذا بتعرف كيف تكتب سكربتات اذا انت قطعت 70 في المية من المشوار لول
اه وشيء اخر اي موضوع عليه العلامة التجاريه هذه i ┐(￣ー￣)┌ i اذا لم تريد ان تتعب على نفسك ما بتفيدك الموضيع هذه
مش مشكله انا ما بفهم امثلتي ايضا لول وعن الفريق اذا بدك يا مساعده بس على شرط انه ما يكون لمسومس صار في فرق اكثر من الاعضاء
ههههههههههههههههه خلص سامحه مش مشكله اي تخمين انا لا اعلم معنى ما اقول لول طنش طنش بتعيش احلى معانا العيد احلى
اه عندك العضو Pirate king عنده مواضيع اكثريتها حول الوندوز 7 لول طول حياته بقاتل في هذا الفايرس كل مرة بطلعله في شيء لووووول
يمكن يستسلم ويشتري ماك ما بتعرف او احتمال يروح يبيع فول و حمص و قرقيش في السوق مع باقي الاعضاء لول في خصم لاعضاء مسومس
اه ولا تنسى هذا الموضوع شرح لـ MiniCoder.. برنامج الإنتاج الواعد.
من اهم المواضيع الي في القسم لوووووول لم استخدم البرنامج لكن بسيط و افضل بكثير من ميغوي و الي عمل الشرح عبقري في الاجتهاد
وعندك العضو Next - Gen عضو سطع نجمه بعد ما جلس ياكل الفول في الساحة المسموسية لول عنده موضوع حول وندز سبعة لووووول
في التوفيق و ما تنسى المثل الي بقول ليست جميع البقوليان فلقة واحده يوجد منها ذو فلقتين اه
مع السلامة

^
وعليكم السلام ورحمة الله وبركاته
أعرف كيف أكتبها لكنني لا أحفظها كلها . .
هو فـعلا ليس من مسومس . . ^^"
خخخخخ محشششة انتِ . . مين نقل لك العدوى . . رونقة ولا ماجد أبو البصل ؟
حتى أمثالك مخرفة خخخ
شكرا . .
سأبحث عن هذه المواضيع . .
في أمان الله ،

أهلًا أخي أكيبودن هل لك بأن تشرح --tcfile-out بشكل توسعي أكبر ؟

اقتباس:

---

المشاركة الأصلية كتبت بواسطة THE-KING

أهلًا أخي أكيبودن هل لك بأن تشرح --tcfile-out بشكل توسعي أكبر ؟

---

tc= timecode
file= ملف
out= استخراج

=> أمر استخراج ملف الـ timecodes
أمر غير مهم لأنه بإمكانك استخراج هذا الملف بعدة طرق، ادخل هنا كي تعرف المزيد أو هنا
وباختصار، الأمر يستخرج ملف يحتوي على توقيت ظهور الفريمات. هذا الملف مهم جداً في حالة كنتَ تتعامل مع شيء VFR لأنك ستستخدمه أثناء الدمج في mkv أو حتى mp4

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

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

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

اقتباس:

---

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 وتحديد بيت ريت مناسب للحلقة "أو الأنمي" بالاعتماد على خبرة المنتج ليحصل على أكبر قدر ممكن من تصغير للحلقة دون خسارة كبيرة بالجودة أو ظهور مشاكل

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

+

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

وشكراً لك :)

سلام

أكيبودن...

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

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

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

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

+

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة تيرزم

أ

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

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

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

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

---

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

المسألة لا علاقة لها بسرعة الإنتاج بمعنى الضغط، بل بسرعة الـ 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

---

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

اقتباس:

---

كلام الويكيبيديا الذي طرحته هنا لا علاقة له بموضوع 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"

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

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

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

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

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

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

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

مشكورين

اقتباس:

---

المشاركة الأصلية كتبت بواسطة تيرزم

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

بنقاش آخر هُناك من جزم أن تحديد البت ريت سيُحدد بيت ريت ثابت على كل الحلقة
ومن جزم أن الـ 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 :Smile:

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

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

+

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

---

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

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

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

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

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

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

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


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

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

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

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

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

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

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

كود:

---

/x264

---

وتضغط Enter للبحث عن كلمة x264
سيأخذك مباشرة إلى شيء كهذا
http://dl.dropbox.com/u/20364183/x264UserData.jpg
تحت لينوكس لا تحتاج لهذه البرامج.
لن أجيب عن أي سؤال إضافي بهذا الشأن لأنه يمكنك معرفة ذلك بميديا إنفو أو افتح الفيديو في محرر وابحث عن x264

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

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

كود:

---

QP(P)=ipratio x QP(I)

---

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

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

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

الموضوع

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

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

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

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

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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

سؤال آخر: الـ 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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ~ VEGETA ~

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

---

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

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

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

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

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

السلام عليكم

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ElPsy

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

---

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

[i ┐(￣ー￣)┌ i]

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

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

اقتباس:

---

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

---

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

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

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

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

اقتباس:

---

في فلاتر دي باند أخرى مثل 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

اقتباس:

---

المشاركة الأصلية كتبت بواسطة ElPsy

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


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




لا يبدو أنك تعرف معنى 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"

اقتباس:

---

المشاركة الأصلية كتبت بواسطة 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"

---

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

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

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

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

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

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

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

اقتباس:

---

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

---

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