Que velocidade posso esperar da codificação de hardware H264?

Eu tropeçou na Wikipedia-artigo que o Broadcom GPU tem suporte de hardware para codificação H.264 / AVC, não só de -coding.

Eu também encontrei um artigo em que alguém deu um exemplo usando ffmpegpara gerar arquivos de vídeo h264 / mp4. Ok, é uma CPU de uso geral com uma GPU especializada, então essa não é realmente a surpresa.

Mas comparado a um PC de mesa padrão com uma placa gráfica média, o Raspberry Pi potencialmente codifica H.264 / AVC talvez ainda mais rápido ? Se um usuário de desktop otimizasse o seu ffmpegpara o Core-i5xxx com uma placa gráfica Ati / Nvidia de US $ 150 ... essa combinação oferece algo como "suporte à codificação de hardware H.264"? Caso contrário, um Raspberry-Pi-ffmpeg especialmente adotado será ainda mais rápido? Se sim, já existe uma comparação de velocidade?

No momento, parece que ainda não há software estável para codificar o vídeo h264 usando o hardware, mesmo que tenha sido oficialmente anunciado que o Raspberry Pi suporta a codificação de hardware h264. Portanto, não podemos fazer um benchmark para comparar desempenhos com um PC comum .

Não sei se alguém está trabalhando no assunto, mas um desenvolvedor libavparece pessimista em integrar esse módulo no libavprojeto existente (veja sua resposta em 2 de dezembro, 09:23).

Ficarei feliz em fazer uma referência quando uma biblioteca ou software permitir.

Em abril de 2015, o GStreamer 1.2 incluído no Raspbian suporta a codificação H.264 acelerada por hardware OpenMAX através do omxh264enc.

Fiz alguns testes comparativos comparando:

1. MacBook Pro (início de 2011) dual core i7-2620M 2,7 GHz (Sandy Bridge) - 4 GB de RAM
2. RaspBerry Pi 2 Modelo B CPU ARM Cortex-A7 de 900MHz e quatro núcleos - 1GB de RAM

Arquivo de exemplo: amostra dos anos 60 do filme Alatriste (2006). O arquivo original é 1080p e ocupa 30 MB. Eu transcodifiquei o arquivo para 720p. Todas as faixas de áudio foram ignoradas para concentrar o estudo na transcodificação de vídeo.

Resultados:

Em (1), usando o Handbrake (codec x264), eu transcodifiquei com o xys4-settings veryslow e a taxa de bits média de 1145kbps (1 passagem) que resultou em um arquivo de 7,7MB. Perfil Alto, nível 4.0. A codificação levou 3min 36s usando 4 threads. Carga total da CPU acumulada do freio de mão ~ 380%. A qualidade do vídeo foi muito boa. Pequenos artefatos podem ser observados e a perda de detalhes não é facilmente observável. Veja ainda abaixo.

Em (2), usando GStreamer e omxh264enc (acelerado por hardware), eu transcodifiquei com taxa de bits de destino = 1145000 (1145kbps), taxa de controle = 1 (método de controle de taxa de bits variável) que resultou em um arquivo de 6,9MB. A codificação levou 7min 4s usando 1 thread. Carga total da CPU acumulada de gst-launch-1.0 ~ 100%. A qualidade do vídeo foi visivelmente degradada com artefatos claramente visíveis e perda de detalhes facilmente observável. Veja ainda abaixo.

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

Ao usar o GStreamer com o x264enc como codificador, a carga total da CPU acumulada do gst-launch-1.0 chega a cerca de 380%, o que suporta o fato de o omxh264enc realmente usar a GPU. Além disso, com x264enc em (2), o tempo vai além de 15min.

Conclusão:

Para um tamanho de arquivo bastante semelhante, o tempo gasto pelo codificador RaspBerry Pi 2 GPU acelerado por hardware foi quase o dobro do do codificador software x264 em um i7-2620M de núcleo duplo. A adição de transcodificação e multiplexação de áudio pode diminuir um pouco essa lacuna devido à CPU amplamente usada no RaspBerry Pi durante este teste. A qualidade do vídeo foi claramente superior no arquivo codificado por software. Veja as fotos abaixo.

As opções de configuração disponíveis para o omxh264enc (expostas pelo gst-inspect-1.0) são limitadas em comparação com o codificador x264, mas experiências adicionais podem fornecer melhor qualidade.

Anexo:

Instalação do GStreamer e OpenMax a partir dos repositórios 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

Ainda QuickTime X de vídeo 720p transcodificado usando o HandBrake (x264) em um MacBook Pro (abra ou faça o download da imagem para obter detalhes completos):

O QuickTime X ainda de vídeo 720p transcodificado usando o GStreamer (codificação de hardware através do OpenMAX) em um Raspberry Pi 2 (abra ou faça o download da imagem para obter todos os detalhes):

Atualizar:

Seguindo a sugestão de ecc29 de usar o método de escala de lanczos, realizei um teste adicionando method=lanczosa videoscale. O processo de codificação dobrou no tempo, saltando de cerca de 7min para 14min 37s. O resultado é quase igual em qualidade àquele sem método (padrão bilinear). De fato, os defeitos vêm principalmente do processo de codificação no hardware. Eles são claramente artefatos de compactação.

A GPU no RPi é bastante robusta. Eu li que, em termos de codificação, você pode codificar 1080p a 30fps. Também é possível codificar vários fluxos. Também se acredita que você pode codificar vídeos em tempo real usando o RPi.

Mas. As placas gráficas modernas têm a capacidade de executar toda a codificação na GPU, que é realmente uma boa GPU.

Se eu tivesse que avaliar uma opinião pessoal. O RPi não seria mais rápido que uma placa gráfica de média especificação. Mas acho que seria muito mais rápido do que você pensa. Talvez até 75% da velocidade.

Não consegui encontrar uma comparação disponível em nenhum lugar.