하드웨어 -H264 인코딩에서 어떤 속도를 기대할 수 있습니까?


29

나는 브로드 GPU가 하드웨어 지원을 가지고있는 위키 백과 - 기사를 통해 발견 인코딩 뿐만 아니라, H.264 / AVC를 코딩 (joint-coding)을.

또한 누군가가 ffmpegh264 / mp4 비디오 파일을 생성하는 데 사용하는 기사를 찾았습니다 . Ok, 특수 GPU를 갖춘 범용 CPU이므로 실제로 놀라운 것은 아닙니다.

그러나 평균 그래픽 카드를 사용하는 표준 데스크탑 PC와 비교할 때 Raspberry Pi는 H.264 / AVC를 더 빠르게 인코딩 할 수 있습니까? 데스크탑 사용자가 $ 150 Ati / Nvidia 그래픽 카드 ffmpeg를 사용하여 Core-i5xxx 에 맞게 최적화했다면, 그 조합이 "하드웨어 H.264 인코딩 지원"과 같은 방식으로 제공됩니까? 그렇지 않다면 특별히 채택 된 Raspberry-Pi-ffmpeg가 더 빠를까요? 그렇다면 속도 비교가 이미 있습니까?


라즈베리 파이가 데스크탑 PC보다 빠를 것이라고 생각해서는 안됩니다.
Jivings

5
누군가는 벤치 마크를 분명히하고 결과를 보여 주어야합니다.
XTL

@XTL 캔은 당신이 그렇게? ;-)
towi

이것은 매우 좋은 결과입니다. 예제 명령에 오디오 트랜스 코딩을 추가 할 수 있습니까?

답변:


5

현재 Raspberry Pi가 h264 하드웨어 인코딩을 지원 한다고 공식 발표 된 경우에도 하드웨어를 사용하여 h264 비디오를 인코딩하는 안정적인 소프트웨어는 아직없는 것 같습니다 . 따라서 성능을 일반 PC와 비교하기위한 벤치 마크를 수행 할 수 없습니다 .

누군가 주제에 대해 작업하고 있는지 모르겠지만 개발자 는 기존 프로젝트 에 그러한 모듈을 통합하는 것에 대해 비관적 인libav 것처럼 보입니다 (12 월 2 일, 09:23의 답변 참조).libav

라이브러리 나 소프트웨어에서 허용 할 때 벤치 마크를 수행하게되어 기쁩니다.


어디서부터 시작해야할지 모르겠지만 시도해 볼 수 있습니다. 나는 항상 libavcodec src를 파헤 치거나 정확한 x264를 찾는 이유를 찾았습니다.
towi

2
GStreamer 라이브러리는 Broadcom 칩 OpenMax API에 연결할 수 있으며 하드웨어 인코딩을 수행 할 수있는 것 같습니다 : gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html
speedplane

25

2015 년 4 월 현재 Raspbian에 포함 된 GStreamer 1.2는 omxh264enc를 통해 OpenMAX 하드웨어 가속 H.264 인코딩을 지원합니다.

벤치마킹 비교를 수행했습니다.

  1. MacBook Pro (2011 년 초) 듀얼 코어 i7-2620M 2.7GHz (Sandy Bridge)-4GB RAM
  2. RaspBerry Pi 2 모델 B 900MHz 쿼드 코어 ARM Cortex-A7 CPU-1GB RAM

샘플 파일 : 영화 Alatriste (2006)의 60 초 샘플. 원본 파일은 1080p이며 30MB가 걸립니다. 파일을 720p로 트랜스 코딩했습니다. 비디오 트랜스 코딩에 대한 연구에 집중하기 위해 모든 오디오 트랙은 무시되었습니다.

결과 :

(1)에서 핸드 브레이크 (x264 코덱)를 사용하여 x264 설정을 매우 느리고 평균 비트 전송률 1145kbps (1 패스)로 트랜스 코딩하여 7.7MB 파일을 생성했습니다. 프로필 높음, 레벨 4.0. 4 개의 스레드를 사용하여 인코딩하는 데 3 분 36 초가 걸렸습니다. 수동 브레이크의 총 누적 CPU 충전 ~ 380 %. 비디오 품질이 매우 좋았습니다. 작은 인공물이 관찰 될 수 있었으며 세부 사항의 손실이 쉽게 관찰되지 않았습니다. 아래 내용을 참조하십시오.

(2)에서 GStreamer 및 omxh264enc (하드웨어 가속)를 사용하여 target-bitrate = 1145000 (1145kbps), control-rate = 1 (variable bitrate control method)로 트랜스 코딩하여 6.9MB 파일을 생성했습니다. 1 개의 스레드를 사용하여 인코딩에 7 분 4 초가 걸렸습니다. gst-launch-1.0 ~ 100 %의 총 누적 CPU 요금. 선명하고 잘 보이는 디테일 손실을 쉽게 볼 수있는 인공물로 인해 비디오 품질이 눈에 띄게 저하되었습니다. 아래 내용을 참조하십시오.

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

x264enc와 함께 GStreamer를 인코더로 사용하는 경우 gst-launch-1.0의 총 누적 CPU 요금은 약 380 %가되며 이는 omxh264enc가 실제로 GPU를 사용한다는 사실을 지원합니다. 또한 (2)의 x264enc를 사용하면 시간이 15 분을 초과합니다.

결론:

상당히 유사한 파일 크기의 경우 하드웨어 가속 RaspBerry Pi 2 GPU 인코더가 소비하는 시간은 듀얼 코어 i7-2620M의 소프트웨어 x264 인코더보다 거의 두 배였습니다. 오디오 트랜스 코딩 및 멀티플렉싱을 추가하면이 테스트 동안 RaspBerry Pi에서 CPU를 많이 사용하지 않기 때문에이 차이를 약간 줄일 수 있습니다. 소프트웨어 인코딩 파일에서 비디오 품질이 분명히 우수했습니다. 아래 스틸을 참조하십시오.

omxh264enc (gst-inspect-1.0에 의해 노출됨)에 사용 가능한 구성 옵션은 x264 인코더에 비해 제한되어 있지만 추가 실험을 통해 더 나은 품질을 제공 할 수 있습니다.

신관:

Raspbian 리포지토리에서 GStreamer 및 OpenMax 설치 :

$ 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

MacBook Pro에서 HandBrake (x264)를 사용하여 여전히 720p 비디오의 QuickTime X 코드 변환 (자세한 내용은 이미지 열기 또는 다운로드) :

MacBook Pro에서 HandBrake (x264)를 사용하여 720p 비디오의 QuickTime X 스틸 코드 변환

Raspberry Pi 2에서 GStreamer (OpenMAX를 통한 하드웨어 인코딩)를 사용하여 여전히 720p 비디오로 코딩 된 QuickTime X (자세한 내용은 이미지 열기 또는 다운로드) :

Raspberry Pi 2에서 GStreamer (OpenMAX를 통한 하드웨어 인코딩)를 사용하여 720p 비디오로 코딩 된 QuickTime X

최신 정보:

다음 ecc29의 제안 방법을 확장에는 Lanczos를 사용하는 나는 추가 시험 수행 method=lanczos에를 videoscale. 인코딩 프로세스는 시간이 두 배로 증가하여 약 7 분에서 14 분 37 초로 증가했습니다. 결과는 방법이없는 품질과 거의 동일합니다 (기본 이중선). 실제로 결함은 주로 하드웨어의 인코딩 프로세스에서 발생합니다. 그들은 분명히 압축 아티팩트입니다.


GStreamer 트랜스 코딩 후의 이미지 품질을 위해서는 다른 요소를 고려해야합니다. gstreamer가 omxh264enc에 이미지를 보내기 전에 비디오 스케일에 대한 다른 매개 변수가 이미지에 영향을 미칩니다. 비디오 스케일은 이중 선형을 기본 옵션으로 사용합니다. Lanczos가 더 좋지만 너무 느립니다. gstreamer 개발자는 비디오 스케일에 대한 더 많은 옵션을 연구하고 있지만 아직 안정 버전이 아닙니다. 생성 된 일부 패턴은 다른 옵션을 비교하는 데 도움이 될 수 있습니다.
ecc29

gst-launch-1.0 -e videotestsrc pattern=zone-plate kx2=80 ky2=45 num-buffers=1 ! video/x-raw, width=1920, height=1080 ! videoconvert ! videoscale method=lanczos ! video/x-raw, width=1280, height=720 ! avimux ! filesink location=lanczos_1280.avi
ecc29 April

lanczos스케일링 방법 의 결과로 게시물을 업데이트했습니다 .
M. Rubio-Roy

3 b + 구매에 대한 생각. 3 년 반 후에 업데이트가 있습니까? 지금 실시간 인코딩이 가능합니까?
akostadinov

1

RPi의 GPU는 매우 비쌉니다. 인코딩 측면에서 1080p @ 30fps를 인코딩 할 수 있다는 것을 읽었습니다. 또한 여러 스트림을 인코딩하는 것도 가능합니다. 또한 RPi를 사용하여 즉시 비도를 인코딩 할 수 있다고 믿어집니다.

그러나. 오늘날의 그래픽 카드는 GPU에서 전체 인코딩을 실행할 수있는 기능을 제공하므로 GPU가 정말 좋습니다.

개인적 견해를 측정해야한다면 RPi는 중간 사양 그래픽 카드보다 빠르지 않을 것입니다. 그러나 나는 그것이 생각보다 훨씬 빠를 것이라고 생각합니다. 어쩌면 속도의 75 %에 가깝습니다.

어디서나 사용할 수있는 비교를 찾을 수 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.