ffmpeg: Decodificando vídeos via hardware

A decodificação padrão de vídeos do ffmpeg, bem como outros players no Linux, é via software. Isso não tem lá grandes impactos, pela minha experiência, com processadores rápidos como o i7-4770 (o meu, atual), mas, é claro, se a placa de vídeo pode fazer o trabalho de decodificação, liberamos o processador para tarefas mais nobres.

Tanto o VLC quanto o ffmpeg suportam a decodificação por hardware usando uma das duas bibliotecas desenvolvidas para isso: A VA-API (Video Acceleration Aplication Programming Interface) e a VDPAU (Video Decode and Presentation API for Unix). Das duas, prefira a VDPAU. Foi desenvolvida pela nVidia e é suportada por todos os melhores fabricantes de placas de vídeo… Exceto se você tem uma Intel on-board! A Intel só suporta a VA-API… Existe um driver surrogate chamado vdpau-va-driver que funciona como uma camada de abstração para a VA API usando o VDPAU, caso vocẽ queira abstrair as configurações e usar VA API em todas, mesmo em máquinas que tenham uma GForce ou uma placa de ATI… Mas, recomendo mesmo o uso de VDPAU.

No caso do VLC, não há muito o que fazer. A configuração default detecta se você tem um dos decoders de hardware funcionais e os usa, automaticamente. Mas, no caso do ffmpeg, você precisa usar a opção -hwaccel apenas como DECODER para os vídeos (não tem como usar para codificar os pacotes que serão salvos num arquivo!). Para saber quais decodecs estão disponíveis, é só usar:

$ ffmpeg -hide_banner -hwaccels
Hardware acceleration methods:
vdpau
vaapi

Se aparecer vdpau ou vaapi eles podem ser usados… Geralmente basta instalar o pacote libvdpau-va-gl1 e esses decoders são habilitados para você.

Instale também o pacote vdpauinfo para poder obter o que sua placa de vídeo pode ou não fazer. No caso da minha:

$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  367.57  Mon Oct  3 20:32:14 PDT 2016

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12 
422     4096  4096  UYVY YUYV 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                           0 65536  4032  4048
MPEG2_SIMPLE                    3 65536  4032  4048
MPEG2_MAIN                      3 65536  4032  4048
H264_BASELINE                  41 65536  4032  4080
H264_MAIN                      41 65536  4032  4080
H264_HIGH                      41 65536  4032  4080
VC1_SIMPLE                      1  8190  2048  2048
VC1_MAIN                        2  8190  2048  2048
VC1_ADVANCED                    4  8190  2048  2048
MPEG4_PART2_SP                  3  8192  2048  2048
MPEG4_PART2_ASP                 5  8192  2048  2048
DIVX4_QMOBILE                   0  8192  2048  2048
DIVX4_MOBILE                    0  8192  2048  2048
DIVX4_HOME_THEATER              0  8192  2048  2048
DIVX4_HD_1080P                  0  8192  2048  2048
DIVX5_QMOBILE                   0  8192  2048  2048
DIVX5_MOBILE                    0  8192  2048  2048
DIVX5_HOME_THEATER              0  8192  2048  2048
DIVX5_HD_1080P                  0  8192  2048  2048
H264_CONSTRAINED_BASELINE      41 65536  4032  4080
H264_EXTENDED                  41 65536  4032  4080
H264_PROGRESSIVE_HIGH          41 65536  4032  4080
H264_CONSTRAINED_HIGH          41 65536  4032  4080
H264_HIGH_444_PREDICTIVE       41 65536  4032  4080
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y

Minha placa é uma low end, OEM, GForce 635GT, e é bem limitada. No entanto, repare que ela aceita a decodificação de todos os profiles para os codecs MPEG1, MPEG2, h.264, VC1, DIVX4 e DIVX5, não suportando apenas o h.265 (ou HEVC)…

Para recodificar um vídeo, por exemplo, vocẽ poderia fazer:

$ ffmpeg -hwaccel vdpau \
   -i video.mp4 -c:v libx264 -crf 18 \
   -c:a libvo_aacenc -b:v 128k \
   video-out.mp4

Note que a opção, agora, é -hwaccel sem o ‘s’. Desse jeito, o ffmpeg vai decodificar o vídeo usando VDPAU e recodificá-lo usando a libx264. Mas, ATENÇÃO! Se o vídeo não estiver estritamente dentro do padrão h264 (ou de algum outro decoder suportado pelo VDPAU), vão aparecer um monte de erros e você acaba sem o stream de vídeo no arquivo final.

Use a decodificação por hardware com cuidado, se for fazer algum script de conversão de vídeos, por exemplo…

Anúncios

Dica interessante sobre expansão de pathnames

De tempos em tempos tenho que verificar se um determinado processo está em execução ou não. Uma maneira é usando o comando ‘ps’. Por exemplo:

$ ps -ef | grep java

Só que esse jeito, ai em cima, lista, inclusive, o processo do grep. Evitar isso é bem simples:

$ ps -ef | grep [j]ava

Como a expressão [j]ava será substituída pelo bash para “java”, o processo do grep (que recebeu “[j]ava”) não será listado. Interessante, não?

Happy new year and happy with old tools

É fim de ano e estive olhando os códigos que produzi durante 2011 e observei algumas melhorias obtidas na produção.

A principal, e que não posso mais perder de vista, sem dúvidas, é a documentação.

Documentação de projetos é sempre muito chato e aparentemente inútil, mas vejo, mais uma vez que os livros estavam certos: é a parte principal de qualquer projeto. Conclusão que cheguei, após reler o ROADMAP do meu projeto “cinco” e ver que, mesmo em passadas lentas e distantes, eu segui uma linha de ação que converge para um fechamento. Nos anos anteriores, sempre tinha a sensação, ao rever códigos, que deveria reescrevê-los pois não existia uma linha mestra determinada pela documentação que revi há pouco e que me deu inspiração para criar este post.

Entretanto, os livros não são muito “amigos” quando não determinam um modo “ótimo” de fazer as coisas e deixando isto a critério do programador.

Testei muitas ferramentas nestes últimos anos e estou certo que as melhores persistem. Aqui relaciono o estado atual do conjunto que elegi e pretendo me fidelizar.

Faço isto pois em vários e-mails para amigos, sinto que esta é uma necessidade comum e que no fim das contas todos estamos procurando uma zona de conforto e establidade que nos permitam concentrar esforços em produção de códigos ou textos, e não de familiarização com “novidades”.

Sistema operacional – GNU/Linux – Debian

Desnecessário dizer que o windows não presta para uso de desenvolvimentos “sérios”. Tenho dúvidas se a equipe de produção da M$ utiliza aquilo para desenvolver o windows. Suspeito que eles tenham um unix deles de uso interno ou mesmo utilizam o linux. A ferramenta Windows é totalmente voltada para usuários finais. Desktops principalmente. No que diz respeito aos servidores eles devem ter um segmento distinto de “transformação”, ou seja, pegam as idéias advindas da cultura unix e “empacotam” com aquelas “janelas” tradicionais.

Sempre senti necessidade, desde o início de minha carreira, de um sistema confiável, simples e que fosse de custo acessível, preferencialmente gratuito, para atividades de desenvolvimento. O objetivo é bem simples: não ser pego de surpresa por uma “virada” na forma de apresentação ou políticas de marketing.

A primeira “pedrada” que me atingiu, e que me fez pensar assim, veio na mudança de DOS para Windows. Na mesma época eu também lidava com outro sistema, VMS, que passado alguns anos foi sendo mumificado pelas sucessivas aquisições da Digital pela Compaq e desta pela HP e enfim o sistema caiu no esquecimento. Junto com ele toda uma gama de conhecimentos e horas de dedicação foram soterradas e daí nasceu a minha grande ” birra” com sistemas fechados. Enfim, nos idos de 1995, encontrei um sistema que antes eu resistia em aceitar por ser da linhagem “unix” mas, após entendê-lo,  com ele permaneço até hoje.

O que eu poderia esperar de um sistema em termos de estabilidade, confiabilidade, padronização e custos, foi plenamente atendido pela plataforma que, de quebra, me inseriu numa cultura que sobrevive desde os idos de 1968, ou seja, tem quase a minha idade.

O GNU/Linux é o patrocinador desta minha tranquilidade e por isto me dedico tanto a utilizá-lo. Fiz amigos e inimigos, tentando evangelizá-los, pois queria que tivessem o mesmo benefício que eu possuo.

Editor de texto – não sei quanto ao mundo “javanizado” ou “.netzado” mas com certeza quem desenvolve usando uma linguagem de verdade ou mesmo tem necessidade de economizar bandas ao manter um servidor de web é um adepto declarado da “tela preta”. Neste con”texto”, perdoem-me o trocadilho – optei por me desenvolver no vi. Certamente quando usava DOS passei um bom tempo usando o Boxer e gostava das facilidades de gerenciamento de textos e arquivos, bem como sua estabilidade. Mas era “pago” e cheguei a comprar uma versão. Logo vi que manter aquelas atualizações iria me custar caro ou me obrigar a “piratear”. Pensei: se usam vi, deve ter algo bom. E tem: é versátil, possui versões para todas as plataformas e consequentemente pode ser usado e abusado. Me empenhei em aprender os “cabalísticos” modos e comandos para depois notar que não eram tão complexos, e nem poderiam. Me firmei com o Vim, com o qual mantenho um relacionamento há uns 6 anos pelo menos.

Mas confesso que alguns problemas me deixam meio insatisfeito com o vim. Os modos diferenciados, as facilidades adicionadas que não existem no vi original e que o tornam meio dependente de plataformas, e a sua “desintegração” com o sistema – falta de shell (me faz dar Ctrl-Z), me fizeram tentar outra evolução: o Emacs.

No início, quando buscava um editor confiável, tentei usar o Emacs, mas esbarrei nas suas “teclas estranhas” e também no seu onipresente lisp (nunca entendi direito lisp), mas estudando-o um pouco desde outubro deste ano, estou cada vez mais convencido do poder de integração e gerenciamento que este “sistema operacional capaz de editar textos” está me propiciando.

Recentemente descobri o “org mode” e me surpreendi que todas as ferramentas de controle de projeto estão lá. Mapas mentais, todo list, planner, notes, agenda, calendário, time keeper, etc, etc, etc (sim três) pois o sistema é bem extenso.

Então a minha migração está iniciada, mas ainda dependo do vim e do recente gerenciador de dados (PIM) que estou usando, mas pretendo migrar de vez no ano que vem e sossegar até o fim com o emacs.

PIM – j-pilot

Este software é sem dúvida o que me fez rever toda a minha agenda, contatos, e todo list. Ainda é um processo de transição. Ele foi iniciado com o achado de um PDA o meu velho visor edge (um palm pilot) adquirido e abandonado em 2002. Usei-o por um mês, que foi suficiente para rever todos os meus conceitos de concentração de dados em um ambiente sob “o meu” controle, não em posse do “google”. O google está com umas “viadagens” de modificar o lay-out e que, na minha opinião ficaram uma “merda”. Lenta, bloated e “desnecessariamente” clean. Aquilo esteve bom desde 2005 quando comecei a usar, mas sinceramente, não estou gostando mais. Portanto a minha meta é continuar centralizando tudo neste velho j-pilot até que eu tenha domínio completo do orgmode do emacs. Mas para isto, passei por muitas ferramentas até achar o “ponto texto” do negócio de gerenciamento de informações pessoais.

Compilador/Debugger – não vou me estender muito: gcc/gdb. Quem quiser que os aprenda para saber do seu valor.

Web language – PHP – sim é lame, mas foi ela que através do maravilhoso framework Codeigniter, me fez tomar contato com o modelo M-V-C (model-view-control) que passei a adotar em meu projeto “cinco” em linguagem “c”.

Web design – blueprint. CSS dá trabalho e o blueprint tira. Resumindo, não sou designer.

Banco de dados – SQLite e Firebird. Conceito e aplicação. Gosto do mysql, mas apenas um sgdb que rode em windows me satisfaz. O outro, sqlite, pretendo usar, como foi falado no site oficial, com o objetivo de eliminar o fopen.

Relatórios – formato pdf.

Suítes office – deixo isto para os meus usuários. Quando preciso, uso o br-office, especificamente o oocalc.

Gerenciador de dinheiro – gnu cash simples, fácil e eficiente.

Edição de imagens – Gimp.

Navegação web – qq navegador padrão do sistema que estiver instalado. Não tenho mais o fetiche por estas “coisas”. Depois que transformaram a web em “televisão”, passei a não mais ligar para estes “aparelhos de tv” metidos a software. Lixo e propaganda? Basta pegar o carro e rodar pela cidade olhando para os outdoors.

Este conjunto de ferramentas é o que eu uso e pretendo usar daqui por diante e ir eliminando, cada vez mais as interfaces via mouse, pois estou com uma LER em função do uso excessivo de planilhas e Gnu/Cash desde setembro.

Enfim, Feliz ano novo a todos.

{}’s

MaRZ

UBUNTU, muito bom enquanto durou…

Recentemente fiz o upgrade dos SOs em minhas máquinas. Venho usando o UBUNTU desde a sua versão 7.04 e, infelizmente, a Canonical decidiu tirar a minha liberdade de escolher qual ambiente gráfico devo usar. Desde 2004 eu me acostumei com o GNOME 2. Acho esse ambiente muito fácil de usar. Bem mais fácil e configurável do que o Unity.

No último mês de outubro de 2011 decidiram (sem me consultar) que o GNOME 2 não funcionará mais no UBUNTU. Tenho, é claro, mais opções do que teria no famigerado Windows. Mesmo assim, o GNOME 2 não “funfa” mais… Reluto em usar o KDE (too bloated, como diria um amigão meu), e o XFCE me parece coisa de criança. Então, farei um esforço que já não faço há 7 anos: Backup de tudo o que é importante e a instalação de outra distribuição. Meu amigo, e co-autor neste blog, vai rolar no chão de rir, mas vou me render ao DEBIAN. Vai rir porque parece que sou meio devagar em me render aos conselhos desse meu amigo (e estou fazendo isso de novo, com relação ao KDE!). Há anos ele vêm me recomendando o Debian e me dizendo que o Ubuntu é uma droga… Com esse golpe dado pelo Sr. Mark Shuttleworth, não me restam mais dúvidas… Ficou mesmo uma bela porcaria…

O código e a história

Há um dilema que me atormenta: manter o histórico de um projeto para que, quando se está trabalhando sozinho? Vale a pena o esforço?

Eu tentei utilizar várias ferramentas: cvs, subversion, bazar e o git. Todas são bem interessantes no início, mas se tornam bem “chatinhas” depois de uma ou duas semanas. Parecem pedras no caminho. Temos que ficar parando e documentando, analisando código velho e ainda por cima borrando idéias novas.

Mas nunca perdi a vontade de manter o histórico evolutivo de um projeto e, mesmo sem muita habilidade, venho fazendo isto.

Recentemente recuperei e “reprisei” a evolução de um projeto do qual havia feito o “breadcrumb” por um mês. Note aqui que o meu “breadcrumb” é o de alterações no projeto, não a técnica utilizada para navegação em sites.

Foi uma experiência interessante pois retomei um projeto do zero, iniciado em nov/2008 e concluído em dez/2008. Foi como ver um filme antigo antes de tentar reescrever uma nova etapa. Mas o que me deixou chateado foi que eu já havia usado várias ferramentas antes do bazar, que estava no controle daquele final de projeto (eu ainda não havia usado o git).

Tentei por todo o jeito importar diretamente do bazar para o git mas sem sucesso. Daí parti para rever o código usando o bzr mesmo. Depois de umas três horas testando recolocando e analisando os resultados com o bzr diff, “reaprendi” como eu tinha feito o projeto que estava meio apagado da minha memória, após alguns anos. Em seguida percebi que o curto período avaliado registraram grandes modificações no meu modo de pensar – em questão de dois meses, muda-se muito de idéia. Mas restava a frustração de não ter o histórico completo.

Há pouco, baixei o repositório do kernel do linux e pensei: como era a versão 0.0.1 do sistema? Será que vou ver o “initial import” do linux? Legal!

Mandei um git log > /tmp/log e fui avaliar !

Eis a minha surpresa:

4002798 commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
4002799 Author: Linus Torvalds <torvalds@ppc970.osdl.org>
4002800 Date:   Sat Apr 16 15:20:36 2005 -0700
4002801
4002802     Linux-2.6.12-rc2
4002803
4002804     Initial git repository build. I'm not bothering with the full history,
4002805     even though we have it. We can create a separate "historical" git
4002806     archive of that later if we want to, and in the meantime it's about
4002807     3.2GB when imported into git - space that would just make the early
4002808     git days unnecessarily complicated, when we don't have a lot of good
4002809     infrastructure for it.
4002810
4002811     Let it rip!

Pelo jeito, o problema de se perder o histórico aconteceu inclusive com o autor do linux e do git.

Independente da minha frustração, fiquei satisfeito por ver que o “modo” de pensar, em termos de controle de versões, é problemático também por quem tem muita habilidade.

Repasso, então, a lição aprendida: priorize o resultado e faça a história depois. Mas faça, o código e a história!

Linux bloated?

Este assunto está me interessando depois que descobri o minix.

O próprio Linux já admitiu que o linux está “bloated”.

Tudo bem que o sistema é excelente e altamente utilizável, mas depois de 20 anos, acho que deve surgir algo novo ou melhor.

Hoje foi anunciado que o novo kernel 3.0rc1 não tem nada de novo… É somente uma “coisa de macho-alfa” que motivou a mudança da sequência de numeração, sem novidades alucinantes como no caso do gnome e do kde.

Sério?! Duvido…

Estou baixando o código fonte para ver se consigo entender alguma coisa e acompanhar. Se não ganhar nada, ganho com a experiência.

Enquanto isto vou lendo e recomendando o AST. O sistema minix é muito interessante mesmo.