Logo Hardware.com.br
Marcos FRM
Marcos FRM Highlander Registrado
10.3K Mensagens 712 Curtidas

Como gravar a tela com o FFmpeg

#1 Por Marcos FRM 10/01/2011 - 10:53
Primeiro, vamos ao comando:

ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 15 -s 1600x900 -i :0.0 -acodec libvorbis -aq 0 -vcodec libtheora -qscale 4 -f ogg captura.ogg


ONDE:
"-f alsa -ac 2 -i pulse" --> fonte do áudio, para distribuições que usem o PulseAudio (Ubuntu, Fedora, Mandriva, openSUSE, ...); "-ac 2" define o número de canais.
"-f x11grab -r 15 -s 1600x900 -i :0.0" --> fonte do vídeo; a resolução precisa ser especificada. Caso seja menor que a resolução da tela, o ffmpeg capturará a resolução especificada a partir do canto superior esquerdo. "-r 15" define o frame rate a ser usado. Quando maior, melhor a fluidez do vídeo maior o tamanho do arquvo.

Se quiser capturar o áudio do sistema, ao invés do microfone/entrada de linha, em "Preferências de som" -> "Hardware" -> "Perfil", troque "Analog Stereo Duplex" por "Analog Stereo Output". Assim, qualquer som sendo tocado pelo sistema será gravado.

configurar_pulseaudio.ogg (300KB)

Por fim, é possível definir o deslocamento para capturar resoluções menores dentro da tela.

":0.0" pode ser expandido para ":0.0+X,Y", substituindo X e Y pelos deslocamentos horizontal e vertical, respectivamente, a partir do canto superior esquerdo da tela. O comando xwininfo é útil para obter dados (tamanho/posição) de janelas.

As demais opções do ffmpeg, "-acodec", "-vcodec" e "-f", você pode customizar a gosto.

Exemplo: Monitor do Sistema

ex_monitor_do_sistema.ogg (1MB)

deu_sono.png
Marcos FRM
Marcos FRM Highlander Registrado
10.3K Mensagens 712 Curtidas
#3 Por Marcos FRM
10/01/2011 - 11:54
Não sei lhe dizer. Porém suspeito que o recordmydesktop use o mesmo processo, capturando a tela a via xlib.

A carga sobre o processador dependerá do codec de vídeo usado e das configurações do mesmo. A libtheora não pesa muito (o padrão é speed level 1 e não achei como mudar pelo ffmpeg), mas não é muito otimizada nem multithreaded. O codec "mpeg4" do ffmpeg (FMP4) é conhecidamente rápido e pode ser uma saída para ter um menor gasto de processamento. A libx264 no preset "fast" idem.

As compilações do ffmpeg usadas pels distros usam "--enable-runtime-cpudetect", que é falha ainda. Ou seja, não escolherá corretamente na swscale o melhor código otimizado para o processador em uso e cairá no código genérico em C, mais lento. Como workarround, é possível especificar o conjunto de instruções a ser usado com a opção -sws_flags , como em:

-sws_flags sse2


Fonte: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=1185

Isso só diz respeito a swscale, que é a parte de lida com o vídeo bruto, vindo dos decoders, troca de formato de pixel (bgra->yuv420p), redimensionamento, crop, etc. O resto do impacto sobre o desempenho é praticamente todo do encoder de vídeo. Estes (libxvidcore, libx264, libvpx, libtheora, etc) são compilados pelas distros com algum tipo de "runtime-cpudetect" habilitado quando disponível.
m45t3r
m45t3r Veterano Registrado
986 Mensagens 57 Curtidas
#4 Por m45t3r
10/01/2011 - 17:37
Marcos FRM disse:
Não sei lhe dizer. Porém suspeito que o recordmydesktop use o mesmo processo, capturando a tela a via xlib.

A carga sobre o processador dependerá do codec de vídeo usado e das configurações do mesmo. A libtheora não pesa muito (o padrão é speed level 1 e não achei como mudar pelo ffmpeg), mas não é muito otimizada nem multithreaded. O codec "mpeg4" do ffmpeg (FMP4) é conhecidamente rápido e pode ser uma saída para ter um menor gasto de processamento. A libx264 no preset "fast" idem.

As compilações do ffmpeg usadas pels distros usam "--enable-runtime-cpudetect", que é falha ainda. Ou seja, não escolherá corretamente na swscale o melhor código otimizado para o processador em uso e cairá no código genérico em C, mais lento. Como workarround, é possível especificar o conjunto de instruções a ser usado com a opção -sws_flags , como em:

-sws_flags sse2


Fonte: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=1185

Isso só diz respeito a swscale, que é a parte de lida com o vídeo bruto, vindo dos decoders, troca de formato de pixel (bgra->yuv420p), redimensionamento, crop, etc. O resto do impacto sobre o desempenho é praticamente todo do encoder de vídeo. Estes (libxvidcore, libx264, libvpx, libtheora, etc) são compilados pelas distros com algum tipo de "runtime-cpudetect" habilitado quando disponível.


Marcos, eu não sei se especificar uma otimização específica ajudaria muito. Muitos codecs são otimizados demais já, como o x264 que é completamente otimizado em ASM. MMX, SSE1/2/3/4, muitas vezes nem fazem muita diferença.

Mas a dica é interessante, qualquer dia desses vou testar.
Marcos FRM
Marcos FRM Highlander Registrado
10.3K Mensagens 712 Curtidas
#5 Por Marcos FRM
10/01/2011 - 17:49
m45t3r disse:
Marcos, eu não sei se especificar uma otimização específica ajudaria muito. Muitos codecs são otimizados demais já, como o x264 que é completamente otimizado em ASM. MMX, SSE1/2/3/4, muitas vezes nem fazem muita diferença.

Mas a dica é interessante, qualquer dia desses vou testar.

Essa opção não afeta os encoders. Afeta a libswscale. Os encoders têm suas próprias otimizações.
© 1999-2024 Hardware.com.br. Todos os direitos reservados.
Imagem do Modal