ฉันสามารถคาดหวังความเร็วเท่าใดจากการเข้ารหัสของฮาร์ดแวร์ -H264

ผมสะดุดวิกิพีเดียบทความว่า Broadcom GPU มีการสนับสนุนฮาร์ดแวร์สำหรับการเข้ารหัส H.264 / AVC, ไม่เพียง แต่เด -coding

ฉันยังพบบทความที่มีคนให้ตัวอย่างใช้ffmpegในการสร้างไฟล์วิดีโอ h264 / mp4 ตกลงซีพียูวัตถุประสงค์ทั่วไปด้วย GPU เฉพาะเพื่อให้ไม่ได้จริงๆแปลกใจ

แต่เมื่อเทียบกับพีซีตั้งโต๊ะมาตรฐานที่มีกราฟิกการ์ดเฉลี่ย Raspberry Pi จะเข้ารหัส H.264 / AVC ได้เร็วขึ้นหรือไม่ หากผู้ใช้เดสก์ท็อปต้องปรับให้เหมาะสมffmpegกับCore-i5xxxด้วยกราฟิกการ์ดAti / Nvidia $ 150 ... การรวมกันนั้นมีอะไรในรูปแบบของ "การเข้ารหัสฮาร์ดแวร์ H.264 รองรับ" หรือไม่? ถ้าไม่ Raspberry-Pi-ffmpeg ที่ถูกนำมาใช้เป็นพิเศษจะเร็วขึ้นหรือไม่ ถ้าใช่มีการเปรียบเทียบความเร็วหรือไม่

ในขณะนี้ดูเหมือนว่ายังไม่มีซอฟต์แวร์ที่มีเสถียรภาพในการเข้ารหัสวิดีโอ h264 โดยใช้ฮาร์ดแวร์แม้ว่าจะมีการประกาศอย่างเป็นทางการแล้วว่า Raspberry Pi รองรับการเข้ารหัสฮาร์ดแวร์ h264 ดังนั้นเราจึงไม่สามารถทำเกณฑ์เปรียบเทียบเพื่อเปรียบเทียบสมรรถนะกับพีซีปกติได้

ฉันไม่รู้ว่ามีใครบางคนกำลังทำงานเรื่องนี้อยู่หรือไม่ แต่ผู้พัฒนาlibavดูเหมือนจะมองโลกในแง่ร้ายเกี่ยวกับการรวมโมดูลดังกล่าวในlibavโครงการที่มีอยู่(ดูคำตอบของเขาในวันที่ 2 ธันวาคม 09:23)

ฉันยินดีที่จะทำเกณฑ์มาตรฐานเมื่อห้องสมุดหรือซอฟต์แวร์อนุญาต

เมื่อวันที่เมษายน 2015 GStreamer 1.2 รวมอยู่ใน Raspbian รองรับฮาร์ดแวร์ OpenMAX เร่งการเข้ารหัส H.264 ผ่าน omxh264enc

ฉันได้ทำการเปรียบเทียบการเปรียบเทียบ:

1. MacBook Pro (ต้นปี 2554) ดูอัลคอร์ i7-2620M 2.7GHz (Sandy Bridge) - 4GB RAM
2. Raspberry Pi 2 รุ่น B 900MHz quad-core ARM Cortex-A7 CPU - RAM 1GB

ไฟล์ตัวอย่าง: ตัวอย่าง 60 วินาทีจากภาพยนตร์ Alatriste (2006) ไฟล์ต้นฉบับคือ 1080p และใช้เวลา 30MB ฉันแปลงไฟล์เป็น 720p แทร็กเสียงทั้งหมดไม่ได้รับความสนใจเพื่อมุ่งเน้นการศึกษาเกี่ยวกับการแปลงรหัสวิดีโอ

ผล:

ใน (1), ใช้ Handbrake (x264 codec) ฉันแปลงรหัสด้วย x264-settings veryslow และ bitrate เฉลี่ย 1145kbps (1-pass) ซึ่งส่งผลให้ไฟล์ 7.7MB โปรไฟล์สูงระดับ 4.0 การเข้ารหัสใช้เวลา 3 นาที 36 วินาทีโดยใช้ 4 เธรด ค่าใช้จ่าย CPU ที่สะสมทั้งหมดของเบรกมือ ~ 380% วิดีโอคุณภาพดีมาก สามารถสังเกตสิ่งประดิษฐ์เล็ก ๆ น้อย ๆ และการสูญเสียรายละเอียดไม่สามารถสังเกตได้ง่าย ดูด้านล่าง

บน (2) ใช้ GStreamer และ omxh264enc (เร่งความเร็วด้วยฮาร์ดแวร์) ฉันแปลงรหัสด้วยบิตเรตเป้าหมาย = 1145000 (1145kbps) อัตราการควบคุม = 1 (วิธีการควบคุมอัตราบิตผันแปร) ซึ่งส่งผลให้ไฟล์ 6.9MB การเข้ารหัสใช้เวลา 7 นาที 4s โดยใช้ 1 เธรด ค่าใช้จ่าย CPU สะสมทั้งหมดของ gst-launch-1.0 ~ 100% คุณภาพวิดีโอลดลงอย่างเห็นได้ชัดด้วยสิ่งประดิษฐ์ที่มองเห็นได้ชัดเจนและสูญเสียรายละเอียดที่สังเกตได้ง่าย ดูด้านล่าง

gst-launch-1.0 -v filesrc location=sample-1080p.mp4 ! decodebin ! videoconvert ! \
videoscale ! video/x-raw,width=1280,height=688 ! omxh264enc control-rate=1 \
target-bitrate=1145000 ! h264parse ! mp4mux ! \
filesink location=sample-720p-OMX-1145kbps.mp4

เมื่อใช้ GStreamer กับ x264enc เป็นตัวเข้ารหัสค่าใช้จ่าย CPU ที่สะสมทั้งหมดของ gst-launch-1.0 จะอยู่ที่ประมาณ 380% ซึ่งรองรับความจริงที่ว่า omxh264enc ใช้ GPU จริง นอกจากนี้ด้วย x264enc ใน (2) เวลาผ่านไปเกิน 15 นาที

สรุป:

สำหรับขนาดไฟล์ที่ค่อนข้างคล้ายกันเวลาที่ใช้โดยตัวเข้ารหัส GPU Raspberry Pi 2 ที่เร่งความเร็วด้วยฮาร์ดแวร์นั้นเกือบสองเท่าของตัวเข้ารหัส x264 ของซอฟต์แวร์บน dual core i7-2620M การเพิ่มการแปลงรหัสเสียงและมัลติเพล็กซ์สามารถปิดช่องว่างนี้เล็กน้อยเนื่องจาก CPU ส่วนใหญ่ที่ไม่ได้ใช้ใน RaspBerry Pi ระหว่างการทดสอบนี้ คุณภาพวิดีโอดีกว่าไฟล์ที่เข้ารหัสซอฟต์แวร์อย่างชัดเจน ดูภาพนิ่งด้านล่าง

ตัวเลือกการกำหนดค่าที่ใช้ได้สำหรับ omxh264enc (เปิดเผยโดย gst-inspect-1.0) มีข้อ จำกัด เมื่อเปรียบเทียบกับตัวเข้ารหัส x264 แต่การทดลองเพิ่มเติมอาจให้คุณภาพที่ดีขึ้น

ภาคผนวก:

การติดตั้ง GStreamer และ OpenMax จากที่เก็บ Raspbian:

$ apt-get install libgstreamer1.0-0 libgstreamer1.0-0-dbg libgstreamer1.0-dev liborc-0.4-0 liborc-0.4-0-dbg liborc-0.4-dev liborc-0.4-doc gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gstreamer1.0-alsa gstreamer1.0-doc gstreamer1.0-omx gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-dbg gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-base gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-base-doc gstreamer1.0-plugins-good gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-good-doc gstreamer1.0-plugins-ugly gstreamer1.0-plugins-ugly-dbg gstreamer1.0-plugins-ugly-doc gstreamer1.0-pulseaudio gstreamer1.0-tools gstreamer1.0-x libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-bad1.0-dev libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.2.0
GStreamer 1.2.0

QuickTime X ภาพนิ่งที่แปลงวิดีโอ 720p โดยใช้ HandBrake (x264) บน MacBook Pro (เปิดหรือดาวน์โหลดอิมเมจเพื่อดูรายละเอียดทั้งหมด):

QuickTime X ยังคงมีการแปลงวิดีโอ 720p โดยใช้ GStreamer (การเข้ารหัสฮาร์ดแวร์ผ่าน OpenMAX) บน Raspberry Pi 2 (เปิดหรือดาวน์โหลดอิมเมจสำหรับรายละเอียดทั้งหมด):

ปรับปรุง:

ต่อไปนี้ข้อเสนอแนะของ ecc29ของการใช้วิธีการปรับ Lanczos ผมดำเนินการทดสอบการเพิ่มการmethod=lanczos videoscaleกระบวนการเข้ารหัสสองเท่าในเวลากระโดดจากประมาณ 7 นาทีถึง 14 นาที 37 วินาที ผลลัพธ์มีคุณภาพใกล้เคียงกันโดยไม่ใช้วิธี (ค่าเริ่มต้น bilinear) แท้จริงแล้วข้อบกพร่องส่วนใหญ่มาจากกระบวนการเข้ารหัสในฮาร์ดแวร์ มีการบีบอัดสิ่งประดิษฐ์อย่างชัดเจน

GPU ใน RPi นั้นค่อนข้างอ้วน ฉันอ่านแล้วว่าในแง่ของการเข้ารหัสคุณสามารถเข้ารหัส 1080p @ 30fps การเข้ารหัสหลายสตรีมก็เป็นไปได้เช่นกัน นอกจากนี้ยังเชื่อว่าคุณสามารถเข้ารหัสวิดีโอได้ทันทีโดยใช้ RPi

แต่. กราฟิกการ์ดยุคใหม่มีความสามารถในการใช้งานการเข้ารหัสทั้งหมดบน GPU ซึ่งเป็นสิ่งที่ GPU ทำได้ดีจริงๆ

ถ้าฉันต้องวัดความเห็นส่วนตัว เป็นไปได้ว่า RPi จะไม่เร็วกว่าการ์ดกราฟิกขนาดกลางที่มีสเปค แต่ฉันคิดว่ามันจะเร็วกว่าที่คุณคิด อาจถึงความเร็ว 75%

ฉันไม่พบการเปรียบเทียบที่สามารถใช้ได้ทุกที่