ทำไมโปรเซสเซอร์ถึงดีกว่าสำหรับการเข้ารหัสกว่า GPU

ฉันอ่านบทความนี้และฉันเห็นว่า CPU ดีกว่าสำหรับการบีบอัดวิดีโอมากกว่า GPU

บทความบอกเพียงว่าเกิดขึ้นเพราะโปรเซสเซอร์สามารถจัดการอัลกอริทึมที่ซับซ้อนกว่า GPU แต่ฉันต้องการคำอธิบายทางเทคนิคเพิ่มเติมฉันทำการค้นหาบนอินเทอร์เน็ต แต่ฉันไม่พบอะไรเลย

ดังนั้นใคร ๆ ก็รู้ที่จะอธิบายหรือเชื่อมโยงเว็บไซต์เข้ากับฉัน

บทความที่คุณเชื่อมโยงนั้นไม่ดีมาก

โดยปกติการเข้ารหัสบิตเรตผ่านครั้งเดียวจะแปลงบิตเรตของคุณเป็นค่า RF ด้วยขีด จำกัด บิตเรตสูงสุดและนำมาจากที่นั่น

ratecontrol ABR One-x264 ไม่ได้นำมาใช้เป็นขีด จำกัด CRF + เขาพูดถูกว่า 2pass นั้นเป็นวิธีที่ดีที่สุดในการเข้าถึงบิตเรตเป้าหมาย

เห็นได้ชัดว่าเขาไม่ทราบว่าเขาสามารถเริ่ม x264 ด้วย threads = 3 หรือบางสิ่งบางอย่างเพื่อปล่อยเวลา CPU ให้ว่างสำหรับงานอื่น ๆ หรือตั้งค่าลำดับความสำคัญของ x264 ให้ต่ำมากดังนั้นจึงได้รับเวลา CPU ที่ไม่มีงานอื่นเท่านั้น

เขายังผสมรวมเธรด = 1 กับการใช้ CUDA หรืออะไรบางอย่าง ไม่น่าแปลกใจที่คุณมีคำถามเพราะบทความนั้นมีคำอธิบายแบบ TERRIBLE บทความทั้งหมดโดยทั่วไปเดือดลงไปที่: ใช้x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvหรืออาจจะใช้ตัวกรองแสงบางส่วนกับสคริปต์ AviSynth อินพุต จริง ๆ แล้วเขาแนะนำ "ยาหลอก" นั่นคือเฮฮา ฉันไม่เคยเห็นไฟล์ละเมิดลิขสิทธิ์เข้ารหัสด้วยยาหลอก (คุณสามารถบอกได้จากme=esaหรือme=tesaแทนสำหรับทุกที่ตั้งไว้ล่วงหน้าที่มีคุณภาพดีขึ้นสิทธิที่จะme=umhveryslow

เขาไม่ได้พูดถึงการใช้ความลึกของสี 10 บิต ช้าลงในการเข้ารหัสและถอดรหัส แต่แม้หลังจาก downconverting กลับไปเป็น 8 บิตคุณจะได้รับ SSIM 8 บิตที่ดีกว่า มีความแม่นยำมากขึ้นสำหรับเวกเตอร์การเคลื่อนไหวที่เห็นได้ชัดช่วย นอกจากนี้ไม่ต้องปัดเศษเป็นค่า 8 บิตทั้งหมดช่วย คุณสามารถนึกได้ว่า 8-bit ต่อองค์ประกอบเป็นการแฮ็คความเร็ว การหาปริมาณในโดเมนความถี่แล้วบีบอัดด้วย CABAC หมายความว่าสัมประสิทธิ์ความลึกบิตที่สูงขึ้นไม่จำเป็นต้องใช้พื้นที่มากขึ้น

(BTW, h.265 ได้รับประโยชน์น้อยลงจากการเข้ารหัส 10 บิตสำหรับวิดีโอ 8 บิตเนื่องจากมีความแม่นยำมากกว่าสำหรับเวกเตอร์เคลื่อนไหวถ้ามีประโยชน์ในการใช้ 10 บิต x265 สำหรับอินพุตวิดีโอ 8 บิตมันมีขนาดเล็กกว่า ด้วย x264 ดังนั้นจึงมีความเป็นไปได้น้อยกว่าที่การลงโทษด้วยความเร็วจะคุ้มค่า)

ในการตอบคำถามจริงของคุณ:

แก้ไข: doom9 ขึ้นแล้วอีกครั้งดังนั้นฉันจะจัดระเบียบลิงก์ให้เรียบร้อย ไปที่มันเพื่อการอ้างอิงที่เหมาะสมของผู้ที่พูดอะไร

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google เก็บเฉพาะรุ่นที่พิมพ์โง่ซึ่งแสดงข้อความไม่ถูกต้อง ฉันไม่แน่ใจว่าส่วนใดของข้อความเหล่านี้คือเครื่องหมายคำพูดและส่วนใดของบุคคลนั้น

รูปแบบการแตกแขนงที่ผิดปกติอย่างมาก (โหมดข้าม) และการปรับบิต (การเข้ารหัส quantization / entropy) ไม่เหมาะกับ GPU ที่มีอยู่ในปัจจุบัน IMO แอปพลิเคชันที่ดีเพียงอย่างเดียวในขณะนี้คืออัลกอริทึมการค้นหา ME แบบสมบูรณ์ในที่สุดแม้ว่าการค้นหาแบบเร่งเต็มรูปแบบยังคงช้าแม้ว่ามันจะเร็วกว่าบน CPU
- MfA

จริงๆแล้วทุกอย่างสามารถทำได้อย่างสมเหตุสมผลบน GPU ยกเว้น CABAC (ซึ่งสามารถทำได้มันก็ไม่สามารถเทียบเคียงได้)

x264 CUDA จะใช้อัลกอริทึม fullpel และ subpel ME ในตอนแรก ต่อมาเราสามารถทำอะไรบางอย่างเช่น RDO ด้วยการประมาณค่าบิตแทนที่จะเป็น CABAC

เพราะมันต้องทำทุกอย่างด้วยความแม่นยำจุดลอยตัวเดียว
- MfA

ผิด CUDA รองรับคณิตศาสตร์จำนวนเต็ม

- Dark Shikari

Dark Shikari เป็นผู้ดูแล x264 และเป็นผู้พัฒนาฟีเจอร์ส่วนใหญ่ตั้งแต่ปี 2007 เป็นต้นไป

AFAIK, โครงการ CUDA นี้ไม่ได้เลื่อนออกไป มีการรองรับการใช้ OpenCL เพื่อลดภาระงานจากเธรด lookahead (การตัดสินใจ I / P / B อย่างรวดเร็วไม่ใช่การเข้ารหัสขั้นสุดท้ายที่มีคุณภาพสูงของเฟรม)

ความเข้าใจของฉันคือพื้นที่การค้นหาสำหรับการเข้ารหัสวิดีโอนั้นใหญ่มากซึ่งฮิวริสติกแบบชาญฉลาดสำหรับการยกเลิกเส้นทางการค้นหาก่อนหน้าบนซีพียูก่อนจะเอาชนะ GPU ที่ดุร้ายกำลังนำมาสู่ตารางอย่างน้อยก็สำหรับการเข้ารหัสคุณภาพสูง เปรียบเทียบกับ-preset ultrafastที่คุณอาจเลือกการเข้ารหัส HW มากกว่า x264 โดยเฉพาะ หากคุณมี CPU ช้า (เช่นแล็ปท็อปที่มี dual core และไม่มี hyperthreading) สำหรับซีพียูเร็ว (i7 ควอดคอร์ที่มีไฮเปอร์เธรด) x264 superfastอาจจะเร็วและดูดีกว่า (ที่บิตเรตเดียวกัน)

หากคุณกำลังเข้ารหัสที่ทำให้อัตราการบิดเบือน (คุณภาพต่อขนาดไฟล์) สำคัญคุณควรใช้ x264 -preset mediumหรือช้ากว่า หากคุณเก็บถาวรบางสิ่งบางอย่างการใช้เวลา CPU มากขึ้นตอนนี้จะช่วยประหยัดไบต์ได้ตราบใดที่คุณเก็บไฟล์นั้นไว้

บันทึกข้างเคียงหากคุณเคยเห็นข้อความจาก deadrats ในฟอรัมวิดีโอจะไม่เป็นประโยชน์ เขาผิดเกี่ยวกับสิ่งที่เขาพูดถึงในทุกหัวข้อที่ฉันเคยเห็น โพสต์ของเขาปรากฏขึ้นในสองสามกระทู้ที่ฉันไปเกี่ยวกับการเข้ารหัส GPU x264 เห็นได้ชัดว่าเขาไม่เข้าใจว่าทำไมมันไม่ง่ายและโพสต์หลายครั้งเพื่อบอกนักพัฒนา x264 ว่าทำไมพวกเขาถึงโง่ ...

การอัปเดต 2017:

ffmpeg สนับสนุน H264 และ h265 NVENC GPU-accelerated เข้ารหัสวิดีโอ คุณสามารถทำการเข้ารหัสแบบ 1-pass หรือ 2-pass ได้ตามคุณภาพที่คุณเลือกไม่ว่าจะเป็น hevc_nvenc หรือ h264_nvenc หรือแม้กระทั่งกับ GPU ระดับเริ่มต้นก็เร็วกว่าการเข้ารหัสแบบไม่เร่งความเร็วและการเข้ารหัสแบบเร่งด่วนของ Intel Quick Sync

การเข้ารหัสคุณภาพสูงแบบ 2 รอบ:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

การเข้ารหัสเริ่มต้น 1 รอบ:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

วิธีใช้และตัวเลือก NVENC ffmpeg:

ffmpeg -h encoder=nvenc

ใช้มันเร็วกว่าการเข้ารหัส CPU

หากคุณไม่มี GPU คุณสามารถใช้ตัวแปลงสัญญาณ Intel Quick Sync, h264_qsv, hevc_qsv หรือ mpeg2_qsv ซึ่งเร็วกว่าการเข้ารหัสแบบไม่เร่งความเร็วมากเช่นกัน

ในการอธิบายเพิ่มเติมเล็กน้อยเกี่ยวกับสิ่งที่ Peter พูดโดยทั่วไปการใช้โปรเซสเซอร์หลายตัวช่วยในกรณีที่คุณมีงานอิสระหลายอย่างที่ทุกคนต้องทำ แต่ไม่ต้องพึ่งพาซึ่งกันและกันหรืองานที่คุณทำงานเหมือนกัน คณิตศาสตร์กับข้อมูลจำนวนมหาศาล

อย่างไรก็ตามหากคุณต้องการเอาท์พุทของการคำนวณ A เป็นอินพุทของการคำนวณ B และเอาท์พุทของการคำนวณ B เป็นอินพุทไปยังการคำนวณ C ดังนั้นคุณไม่สามารถเร่งความเร็วได้โดยการทำงานหลักที่แตกต่างกันในแต่ละงาน A, B หรือ C) เพราะไม่สามารถเริ่มจนกว่าจะเสร็จสิ้นอีก

อย่างไรก็ตามแม้ในกรณีข้างต้นคุณอาจสามารถทำให้มันขนานกันได้อีกทางหนึ่ง หากคุณสามารถแบ่งข้อมูลนำเข้าของคุณเป็นชิ้น ๆ คุณอาจมีหนึ่งงานหลักในการทำ A จากนั้น B จากนั้น C กับหนึ่งชิ้นข้อมูลในขณะที่อีกแกนทำงานในการทำ A แล้ว B จากนั้น C ในกลุ่มข้อมูลที่แตกต่างกัน .

มีข้อควรพิจารณาอื่น ๆ เช่นกัน บางทีคุณอาจหาวิธีในการคำนวณแบบขนาน แต่เพียงแค่อ่านข้อมูลจากดิสก์หรือผ่านเครือข่ายหรือการส่งไปยัง GPU จะใช้เวลานานกว่าการคำนวณ ในกรณีนี้มันไม่สมเหตุสมผลเลยที่จะทำให้มันขนานกันเพราะการรับข้อมูลลงในหน่วยความจำนั้นใช้เวลานานกว่าเวลาที่คุณบันทึกโดยทำการคำนวณแบบขนาน

กล่าวอีกนัยหนึ่งมันเป็นศิลปะมากพอ ๆ กับวิทยาศาสตร์