Eu sempre gostei de karaokê. De vez em quando saio pra cantar com família ou amigos. Em São Paulo tem bons lugares na Liberdade e no Bom Retiro, por exemplo, com cabines no estilo japonês. Se você nunca foi num karaokê desses: você aluga uma sala privada por hora, tem um catálogo enorme de músicas, dois microfones, e um sistema de pontuação que avalia seu canto em tempo real. Os melhores sistemas são japoneses, como o Joysound e o DAM. Nota acima de 90 (de 100) é considerada avançada. O DAM, na série LIVE DAM Ai, até usa IA pra dar notas mais “humanas”.

Mas nem todo lugar tem esse nível.

O problema com karaokê no Brasil

No Brasil a gente cresceu com o Videokê, a marca que o coreano Seok Ha Hwang trouxe pro país em 1996, importando equipamento da Coreia. Virou febre nos anos 90 e 2000, apareceu em todo bar, churrasco e festa de aniversário. O problema é que esses aparelhos pararam no tempo. Os modelos atuais, como o VSK 5.0, vêm com uns 12-13 mil músicas no catálogo, que você expande comprando cartuchos ou pacotes de música. Na prática, o repertório é velho, a interface é dos anos 2000, e se a música que você quer cantar saiu depois de 2015, boa sorte.

A solução que muitos bares adotaram foi permitir Chromecast ou espelhamento de tela pra que os clientes busquem músicas direto no YouTube. Faz sentido: no YouTube você encontra karaokê de qualquer música. Versão com letra, versão instrumental, versão com guia vocal.

Mas tem um downgrade: você perde a pontuação. Uma das coisas mais divertidas do karaokê é a competição. Ver sua nota subindo, comparar com os amigos, tentar bater o recorde da noite. Se você está só cantando em cima de um vídeo do YouTube, não tem feedback nenhum. É como jogar boliche sem placar.

E comprar um sistema profissional pra casa? Importar um Joysound F1 sai por mais de US$ 2.000 só o hardware, fora a assinatura mensal do catálogo. Pra uso casual não faz sentido.

A ideia: YouTube com pontuação em tempo real

O Frank Karaoke surgiu dessa frustração. Se o YouTube já tem todas as músicas, por que não fazer um app que funciona como wrapper do YouTube com overlay de pontuação em tempo real? Você busca qualquer vídeo de karaokê, canta junto, e o app analisa sua voz pelo microfone e mostra uma nota ao vivo.

É um app Flutter pra Android. Internamente ele carrega o YouTube numa webview e injeta um overlay em HTML/CSS/JavaScript direto na página. O display de score, o trail de pitch, o painel de configurações, o seletor de modo, tudo renderizado dentro da webview via injeção de JS.

Scoring sem referência

Agora, o problema real. Todos os sistemas profissionais de karaokê dependem de arquivos de referência pré-fabricados pra cada música. Todos.

O SingStar da Sony, que vendeu mais de 12 milhões de cópias entre 2004 e o fim do PS3, tinha um track de notas feito à mão pra cada música. Cada nota, cada sílaba, tudo mapeado manualmente. O mecanismo comparava o pitch do cantor via FFT contra essa referência em tempo real. Detalhe que eu achei esperto: a oitava era ignorada. Se a nota certa era um Dó, tanto faz se você cantou Dó3 ou Dó4. Homens cantam músicas femininas sem problema.

O Joysound e o DAM no Japão vão além e avaliam três dimensões separadas: precisão de pitch (音感), ritmo/timing (リズム感) e expressividade/dinâmica de volume (表現力). Tudo baseado em dados MIDI do servidor do operador. O formato open source equivalente é o UltraStar, onde cada música tem um arquivo .txt assim:

: 12 4 5 Hel-    (TipoNota BeatInicial Duração Pitch Sílaba)

Pitch 5 = MIDI 65 (F4). A pontuação compara o pitch do cantor com o da nota, módulo oitava, com tolerância de 1 semitom.

O Frank Karaoke funciona com qualquer vídeo do YouTube. Não tem arquivo de referência. Não tem MIDI. Não tem anotação de melodia. Zero metadata sobre qual nota você deveria estar cantando.

Eu não sei nada de pontuação de karaokê. Não sei nada de processamento de áudio, detecção de pitch, teoria musical aplicada a software. Nada. Então pedi pro Claude Code fazer uma pesquisa extensiva sobre o assunto. O que ele trouxe de volta está documentado em docs/scoring.md no repositório, e é bastante coisa: papers acadêmicos sobre avaliação de canto (Nakano et al. 2006, Tsai & Lee 2012, Molina et al. 2013), patentes (a Yamaha tem uma de 1999, US5889224A, que detalha pontuação por MIDI com 3 faixas de tolerância), e o código fonte de projetos open source como UltraStar Deluxe, AllKaraoke, Vocaluxe e Nightingale.

A conclusão da pesquisa: sem referência por música, você precisa avaliar qualidade vocal de forma genérica. Medir como a pessoa canta, não o que ela deveria estar cantando. E como não existe uma métrica única que funcione pra todos os casos, decidimos implementar quatro modos de pontuação diferentes, cada um medindo uma dimensão diferente da qualidade vocal.

O problema do microfone do celular

Antes dos modos de pontuação, preciso explicar um problema mais fundamental que a pesquisa revelou: o microfone do celular.

Quando você canta karaokê com o celular, o microfone capta três coisas ao mesmo tempo: sua voz, a música saindo do alto-falante, e ruído ambiente da sala. Sua voz está fisicamente mais perto do microfone, então domina o sinal. Mas não o suficiente pra uma separação limpa.

Tentei várias abordagens pra isolar a voz:

Subtração espectral usando o áudio de referência do YouTube. Abandonei. O CDN do YouTube bloqueia extração direta de áudio por user-agent não-browser, e mesmo com o áudio de referência, a equalização do alto-falante, a reverberação da sala e o delay de Bluetooth tornam o sinal diferente demais do que o microfone capta. Subtração simples gera artefatos piores que nenhuma subtração.

Pré-ênfase + center clipping. Abandonei também. O center clipping destrói a forma de onda que o algoritmo YIN precisa pra autocorrelação, e a pré-ênfase amplifica ruído tanto quanto voz.

O que funciona é um filtro bandpass de 200-3500 Hz: um filtro IIR de segunda ordem (Butterworth, Q=0.707) em cascata. O high-pass em 200 Hz elimina baixo, bumbo, bass guitar do bleed do alto-falante. O low-pass em 3500 Hz elimina pratos, hi-hats, ruído de alta frequência. Os fundamentais da voz humana (85-300 Hz) e os formantes (300-3000 Hz) passam pelo filtro. Não é isolamento perfeito, mas melhora bastante a razão voz/música pra detecção de pitch.

Mas o bandpass sozinho não resolve tudo. Guitarras, sintetizadores e piano produzem sinais periódicos na mesma faixa de frequência da voz, e o YIN detecta pitch neles também. Pra lidar com isso, o app faz uma calibração adaptativa: nos primeiros 5 segundos de warmup (quando ninguém está cantando), ele coleta amostras de RMS do sinal pra estabelecer um baseline do nível do alto-falante. Durante a música, mantém esse baseline atualizado (percentil 25 dos últimos ~4 segundos de frames). Pra um frame ser pontuado, o RMS precisa estar pelo menos 1.3x acima do baseline. A voz está mais perto do microfone, então empurra o RMS acima do nível do alto-falante. A melodia instrumental fica perto do baseline e é filtrada. Nos testes, o cantor original saindo pelo alto-falante marcava uns 37 pontos com dots esparsos no trail, enquanto alguém cantando de verdade marcava ~59 com dots densos.

Outro detalhe chato: no Android, especificamente nos Samsung, o AutomaticGainControl (AGC) do DSP atenua o sinal em vez de amplificar. Nos Galaxy, habilitar AGC reduz o pico do microfone de ~0.06 pra ~0.003. Silêncio pra detecção de pitch. Então o app desabilita AGC, echo cancellation e noise suppression. Quando o pico fica abaixo de 0.01, aplica ganho por software (até 30x) pra trazer o sinal a níveis usáveis.

O algoritmo YIN

Pra detectar o pitch da voz eu uso o YIN, de Alain de Cheveigné (IRCAM-CNRS) e Hideki Kawahara (Universidade de Wakayama). É um estimador de frequência fundamental no domínio do tempo. A ideia central é a Cumulative Mean Normalized Difference Function (CMNDF), que basicamente mede o quão periódico é o sinal em cada lag, normaliza pra reduzir falsos positivos, e usa interpolação parabólica pra refinar o resultado. É leve o suficiente pra rodar em tempo real no celular, o que importa aqui.

No app, o threshold do YIN é 0.70 (ajustado pra sinais mistos de voz + música), e frames com confiança abaixo de 0.3 são descartados. Abaixo disso, provavelmente é ruído ou instrumento.

Os 4 modos de pontuação

Cada modo avalia um aspecto diferente da qualidade vocal. Todos compartilham o mesmo pipeline de áudio (bandpass → YIN → gate de confiança). A diferença é como interpretam o pitch detectado.

Pitch Match

Mede o quão limpo você sustenta as notas. Usa decaimento gaussiano baseado no desvio padrão dos valores MIDI numa janela rolante de ~15 frames. Notas firmes (desvio < 0.3 semitons) pontuam 85-100%. Voz tremendo (desvio > 2 semitons) pontua perto de zero. Bom pra músicas que você já conhece bem.

Contour

Mede a forma melódica do seu canto. Não importa qual nota exata você acerta, só a direção e o fluxo. Avalia a amplitude do pitch e movimentos melódicos (saltos > 0.5 semitom) numa janela rolante. Canto monótono pontua ~10%. Movimento melódico suave com amplitude de 2-6 semitons pontua 70-100%. Bom pra quando você está aprendendo uma música nova.

Intervals

Mede a qualidade musical dos saltos entre notas consecutivas. Tom inteiro (2 semitons) pontua mais alto. Terças e quartas pontuam bem. Saltos descontrolados de uma oitava ou mais pontuam baixo. Usa uma curva gaussiana centrada no tom inteiro. Funciona quando você está cantando numa tonalidade diferente da original.

Streak

É o Pitch Match com multiplicador combo. Cada frame consecutivo com score acima de 0.4 incrementa o contador de streak. O streak adiciona pontos bônus (até +0.4 em streak de 30+). Quebrar um streak > 5 frames empurra uma penalidade de 0.05 no EMA. Silêncio congela o streak, então pausas instrumentais não te prejudicam. O modo mais divertido pra festas.

A lógica por trás desses quatro modos veio da pesquisa que o Claude fez nos papers acadêmicos. Cada um mede uma dimensão diferente: afinação, contorno melódico, fraseado e consistência. Nenhum deles sozinho é suficiente, mas juntos cobrem razoavelmente bem o que dá pra avaliar sem ter a melodia de referência da música.

O Pitch Oracle

Além dos quatro modos puramente vocais, o app tem o que eu chamo de Pitch Oracle. A ideia: em vez de avaliar sua voz isoladamente, o app baixa o áudio de referência do vídeo via youtube_explode_dart, decodifica pra PCM, roda o YIN nele, e constrói um timeline de pitch com timestamp da música inteira. Durante a pontuação, se o pitch do microfone bate com o pitch da referência naquele momento do vídeo, provavelmente é bleed do alto-falante, e é ignorado. Se difere, é sua voz, e é pontuado.

A sincronização funciona pelo currentTime do elemento de vídeo HTML5, enviado pro Dart via um listener JS de timeupdate a cada ~250ms. O oracle consulta o pitch de referência na posição exata do playback, levando em conta pause, seek e mudança de velocidade.

Na primeira vez que você toca uma música, o oracle leva uns 5-15 segundos pra baixar e analisar o áudio. Mas o timeline é salvo como JSON no cache local do app (pitch_oracle/<videoId>.json). Se você tocar a mesma música de novo, carrega instantaneamente do cache, sem request de rede. Isso também resolve o problema de rate limiting do YouTube pras músicas que você mais canta.

Com o oracle ativo, os modos mudam de comportamento. Pitch Match compara a classe de pitch do cantor contra a da referência (agnóstico à oitava, como o SingStar). Contour usa correlação cruzada entre o movimento de pitch do cantor e o da referência. Intervals compara os saltos em semitons contra os da referência.

Quando o YouTube bloqueia o download por rate limiting (acontece depois de muitos requests seguidos do mesmo IP, limpa em 15-30 minutos), o oracle falha silenciosamente e os modos voltam pra análise puramente vocal.

O caminho até aqui

O app que você vê agora passou por muita iteração antes de chegar nesse estado.

Primeiro, eu tentei fazer uma versão desktop Linux pra facilitar o debug. Faz sentido, né? Testa no desktop, itera rápido, depois porta pro celular. O problema é que o Flutter não tem backend de webview pra Linux desktop. O webview_flutter simplesmente não funciona. Tentei o webview_cef, que é baseado no Chromium Embedded Framework. O CEF spawna seu próprio processo de GPU, e no Hyprland (compositor Wayland baseado no wlroots) isso conflita com o pipeline de renderização do compositor. No meu setup com NVIDIA, a sessão inteira do Hyprland congelou. Tela travada, sem resposta a teclado, tive que matar pelo TTY. Fora que o CEF exige download de um binário de ~200MB na primeira build. Desisti do CEF e escrevi com o Claude uma bridge nativa em C++ usando WebKitGTK com method channels do Flutter. Funcionou, mas cada peculiaridade do YouTube exigia código separado pro Linux e pro Android. O just_audio também não tem implementação pra Linux desktop. No fim a versão Linux virou peso morto. Deletei ~1.500 linhas de código Linux-específico e foquei só no Android.

Depois veio a saga do microfone no Samsung. No meu Galaxy Z Fold, o microfone captava um sinal absurdamente baixo. Pico de ~0.005, basicamente silêncio pro detector de pitch. Fiquei umas duas horas tentando entender. Baixei thresholds, aumentei ganho por software até 50x, desabilitei preprocessadores de áudio. Nada funcionava direito. Até que descobri o problema real: o AutomaticGainControl do Android. O nome diz “controle automático de ganho”, o que sugere que ele amplifica sinais fracos. Na implementação DSP dos Samsung, ele faz o oposto. Ele atenua o sinal pra um nível de referência baixo, otimizado pra chamadas de voz. Com AGC ligado, o pico caía de ~0.06 pra ~0.003. Desligar o AGC resolveu. Mas aí o pacote audio_session religava o AGC por baixo dos panos. Removi ele também. Foram três rodadas de fix, cada uma achando mais uma camada do problema.

E a pontuação. A pontuação levou mais tempo que todo o resto junto. A primeira implementação usava média cumulativa, que deixava a nota travada num valor e não respondia ao canto em tempo real. Troquei pra janela rolante. Aí a nota ficava presa em ~50% por causa de um bug no peso da pontuação primária. Consertei, e ela passou a começar em 70% mesmo sem ninguém cantando. Consertei de novo. O modo Streak não resetava direito no silêncio. O chromatic snap dava nota alta pra qualquer coisa. O histórico de pitch não era limpo nos gaps de silêncio e os modos ficavam estagnados. Cada bug corrigido revelava outro. Foram mais de 25 commits só ajustando a pontuação, do primeiro protótipo até o estado atual.

O resultado não é perfeito. Eu sei. Mas funciona o suficiente pra ser divertido, que era o objetivo desde o começo.

Configurações

O painel de configurações fica no ícone de engrenagem do overlay. Tem três presets de microfone pra diferentes ambientes (microfone externo limpo, sala normal, festa barulhenta), cada um ajustando thresholds de confiança e amplitude. Tem pitch shift pra quando a música é aguda demais pra sua extensão vocal. O ajuste muda tanto o áudio do vídeo quanto a pontuação ao mesmo tempo: usa o playbackRate do elemento HTML5 com preservesPitch=false, então +2 semitons acelera o áudio pra 1.12x (pitch sobe) e -2 semitons desacelera pra 0.89x (pitch desce). A pontuação compensa o offset, então você canta na sua faixa confortável e o sistema avalia corretamente. Tem calibração de microfone, um processo de 3 segundos que mede o ruído da sala e adapta os thresholds. E tem restart pra zerar a pontuação sem recarregar o vídeo.

Pra trocar de modo de pontuação, toque na caixa de score durante a reprodução.

Fluxo de uso

1. Abra o app. O YouTube carrega dentro do app com o logo do Frank Karaoke.
2. Busque um vídeo de karaokê. Qualquer vídeo funciona, mas faixas instrumentais com letra na tela dão melhores resultados.
3. O vídeo pausa brevemente pra inicializar o microfone, baixar dados da música pro pitch oracle, e preparar o overlay. Na primeira vez com uma música nova isso leva uns 5-15 segundos. Se você já tocou essa música antes, carrega do cache instantaneamente.
4. Cante. O score “live” reflete sua performance atual (média exponencial com alpha 0.15, resposta em ~1 segundo). O score “overall” é a média cumulativa da música inteira.
5. Quando o vídeo pausa, a pontuação pausa junto (pra não pontuar ruído ambiente). Se fizer seek, o score zera e tem 5 segundos de warmup.

Como instalar

O app ainda não está na Play Store, estou esperando o Google verificar minha identidade de desenvolvedor. Deve aparecer lá nos próximos dias. Enquanto isso, é um projeto aberto e dá pra instalar direto.

O jeito mais fácil é baixar o APK assinado direto da página de releases do GitHub. No celular ou tablet Android, baixe o FrankKaraoke-0.2.0-android.apk, abra e toque em Instalar. Se o Android reclamar de “fontes desconhecidas”, habilite em Configurações > Segurança pro seu navegador. Na primeira execução o app pede permissão de microfone. Depois vá nas configurações (ícone de engrenagem) e calibre o microfone antes de cantar, são 3 segundos.

Se você quer compilar do fonte ou contribuir, o repositório está no GitHub. Precisa de Flutter SDK 3.10+, Android SDK API 24+, e um dispositivo físico pra testar microfone (emulador não dá resultados representativos).

git clone https://github.com/akitaonrails/frank_karaoke.git
cd frank_karaoke
flutter pub get
flutter run -d <device_id>

O README tem o resto.

Stack: Flutter + Riverpod pra state management, webview_flutter pro YouTube, youtube_explode_dart pra extração de áudio, record pra captura PCM do microfone, audio_decoder pra decodificação de referência via Android MediaCodec, e o algoritmo YIN implementado em Dart puro.

A documentação técnica do sistema de pontuação está em docs/scoring.md no repositório. Cobre como SingStar, Joysound e DAM funcionam, os papers acadêmicos, a arquitetura do pitch oracle, os problemas de isolamento de voz no Android, e o roadmap.

A pontuação é experimental

Preciso ser direto: o sistema de pontuação é experimental. Sem arquivos de referência por música, a avaliação é aproximada. O app mede se você está afinado, se segue um contorno melódico, se seus intervalos são musicais, se é consistente. Mas não te diz se você está cantando a melodia certa desta música específica (a menos que o pitch oracle consiga baixar o áudio, e nem sempre consegue).

Se você tem experiência com processamento de áudio, detecção de pitch, ou avaliação musical, o repositório está aberto e a documentação de pesquisa em docs/scoring.md detalha o que foi tentado, o que funciona e o que não funciona. Em particular: calibração dos thresholds dos modos, melhorias no isolamento de voz, e integração com o UltraSinger (que gera arquivos de referência a partir de músicas usando Demucs + basic-pitch + WhisperX) são áreas onde contribuição de quem entende do assunto faria diferença. Apreciamos qualquer ajuda de especialistas na calibração desses sistemas.

Ah, e o nome. Frank Karaoke. É uma homenagem ao Sinatra. Quem mais?

Projeto no GitHub: github.com/akitaonrails/frank_karaoke

ffmpeg -i input.mkv -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level 4.1 -c:a aac -b:a 128k \
  -movflags +faststart output.mp4

O que isso faz? Converte pra H.264 com qualidade razoável pra web, usando AAC no áudio e movendo o moov atom pro início do arquivo pra permitir streaming progressivo. Se você já sabia disso, parabéns. Se não sabia, bem-vindo ao clube de 99% das pessoas que usam FFmpeg copiando comandos do Stack Overflow.

E esse é o caso simples. Quer fazer um GIF animado a partir de uma sequência de PNGs? Precisa de um pipeline de duas passadas com geração de paleta:

ffmpeg -framerate 10 -i frame_%04d.png \
  -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif

Quer cortar um trecho, redimensionar pra 720p e forçar aspect ratio 16:9? Boa sorte montando o filter chain.

Eu cansei de ficar decorando flags. Queria uma CLI que eu falasse “converte isso pra MP4 otimizado pra web” e ela resolvesse. Então fiz o easy-ffmpeg.

O que o easy-ffmpeg faz

É um wrapper inteligente. Você dá o arquivo de entrada e o formato de saída, e ele analisa o vídeo com ffprobe, descobre quais streams de vídeo, áudio e legenda existem, verifica compatibilidade de codecs com o container de destino, e decide sozinho o que pode copiar direto (sem re-encoding, instantâneo) e o que precisa transcodificar.

O uso mais básico:

# Converter MKV pra MP4 (copia streams compatíveis, sem re-encoding desnecessário)
easy-ffmpeg input.mkv mp4

# Otimizado pra web (H.264 + AAC, faststart)
easy-ffmpeg input.mkv mp4 --web

# Otimizado pra celular (720p, AAC stereo, arquivo menor)
easy-ffmpeg input.mkv mp4 --mobile

# Compressão máxima (H.265, CRF 28)
easy-ffmpeg input.mkv mp4 --compress

# Qualidade alta pra streaming (H.265, CRF 18)
easy-ffmpeg input.mkv mp4 --streaming

Exemplos do que dá pra fazer

Cortar um trecho do vídeo:

# Do minuto 1:30 até 3:00
easy-ffmpeg video.mp4 mp4 --start 1:30 --end 3:00

# Os primeiros 90 segundos
easy-ffmpeg video.mp4 mp4 --duration 90

# Aceita vários formatos de tempo: 90, 1:30, 01:30.5, 1:02:30

Redimensionar:

# Pra 720p
easy-ffmpeg video.mp4 mp4 --scale hd

# Pra 1080p
easy-ffmpeg video.mp4 mp4 --scale fullhd

# Presets: 2k (1440p), fullhd (1080p), hd (720p), retro (480p), icon (240p)

Mudar aspect ratio:

# Forçar 16:9 (adiciona barras pretas se necessário)
easy-ffmpeg video.mp4 mp4 --aspect wide

# Formato TikTok/Stories (9:16 vertical)
easy-ffmpeg video.mp4 mp4 --aspect tiktok

# Quadrado pro Instagram
easy-ffmpeg video.mp4 mp4 --aspect square

# Croppar em vez de adicionar barras
easy-ffmpeg video.mp4 mp4 --aspect wide --crop

Sequência de imagens pra vídeo:

# Detecta automaticamente o padrão de numeração (frame_0001.png, frame_0002.png...)
easy-ffmpeg /pasta/com/frames/ mp4

# GIF animado com paleta otimizada
easy-ffmpeg /pasta/com/frames/ gif

# Sequência de imagens em 720p a 30fps
easy-ffmpeg /pasta/com/frames/ mp4 --fps 30 --scale hd

Ver o que vai fazer sem executar:

easy-ffmpeg video.mkv mp4 --web --dry-run
# Mostra o comando ffmpeg exato que seria executado

Combinar tudo:

# Cortar, redimensionar e comprimir pra mandar por WhatsApp
easy-ffmpeg video.mkv mp4 --start 0:30 --end 2:00 --scale hd --compress

E se você rodar easy-ffmpeg sem argumentos num terminal interativo, abre um modo TUI com seleção de arquivo por fuzzy search, escolha de preset por menu, e input de tempos com validação – tudo sem precisar lembrar de nenhuma flag.

Por que Crystal

Faz anos que eu não mexia com Crystal. A última vez foi pra brincar, antes da versão 1.0. E eu queria revisitar.

Crystal ocupa um nicho interessante. Go e Crystal competem pelo mesmo espaço: linguagens compiladas pra aplicações, que geram binários estáticos, com garbage collector e sem dependência de runtime. Mas a abordagem é bem diferente.

Go é famoso por ser deliberadamente simples. Sem generics por anos (só chegaram na 1.18), sem exceções (error returns), sem expressividade. O argumento é que isso facilita leitura e manutenção em equipes grandes. Na prática, resulta em código verboso e repetitivo, com if err != nil em todas as linhas.

Crystal tem tipagem estática com inferência, macros em tempo de compilação, blocos como closures (igual Ruby), exceções, generics desde sempre, e uma sintaxe que qualquer Rubista reconhece:

# Crystal: ler um JSON e extrair dados
streams = json["streams"].as_a.map do |s|
  StreamInfo.new(
    codec: s["codec_name"]?.try(&.as_s) || "unknown",
    width:  s["width"]?.try(&.as_i) || 0,
    height: s["height"]?.try(&.as_i) || 0,
  )
end

# Go equivalente: seria 3x mais linhas com type assertions e error checks

A stdlib do Crystal tem HTTP server, JSON parsing, YAML, regex, fibers (green threads com scheduler cooperativo), channels (igual Go), e até IO::FileDescriptor com raw mode pra terminal – que eu usei pro modo interativo. Concorrência funciona com spawn (equivalente ao go do Go) e Channel (idêntico ao chan do Go). A diferença é que tudo vem com a ergonomia do Ruby.

Pra uma CLI que precisa compilar num binário estático sem dependências, rodar em Linux e macOS, e ser distribuída como download direto – Crystal é perfeito. O compilador gera binários nativos, e com o Docker Alpine dá pra fazer static linking com musl pra Linux. O binário final do easy-ffmpeg tem ~6MB.

Eu considero Rust melhor pra código de sistemas (kernels, drivers, databases, coisas onde ownership e lifetime importam). Mas pra uma CLI de conversão de vídeo? Rust seria overkill. Crystal dá o mesmo resultado final (binário estático e rápido) com um terço do código e sem brigar com o borrow checker.

Os números

O projeto inteiro foi construído em uma tarde. 10 commits entre 18:32 e 21:33 do dia 7 de março de 2026. Três horas.

Linguagem    Arquivos    Linhas    Código
Crystal      13          2.823     2.342
Shell        1           109       91
Markdown     1           266       210
YAML         2           46        34
─────────────────────────────────────────
Total        20          3.326     2.419

2.342 linhas de Crystal fazem: CLI com 5 presets, análise de mídia via ffprobe, planejamento inteligente de conversão com matriz de compatibilidade de codecs, progress bar com ETA, modo interativo com fuzzy search, suporte a sequências de imagem e GIF, e trimming/scaling/aspect ratio com validação.

A ferramenta já está com CI/CD no GitHub Actions, compilando binários estáticos pra Linux (x86_64 e arm64) e macOS (arm64), com instalação via curl one-liner:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-ffmpeg/master/install.sh | sh

Três horas de uma tarde, da primeira linha de código ao release no GitHub com binários pra três plataformas. O FFmpeg continua fazendo o trabalho pesado – eu só coloquei uma interface decente na frente.

O repositório está aqui. MIT license.

Todos os videos do meu canal, incluindo os arquivos originais, estão lá. Só isso dá terabytes. Todo minha biblioteca do Steam está lá, são uns 4 terabytes. Todos os meus jogos antigos, retro-games, também, incluindo ISOs de Xbox 360 e PS3. São mais 4 terabytes. Toda minha coleção de discos Ultra HD (BluRay 4K) eu ripei (fiz backup), são mais alguns terabytes. Neste instante já estou usando mais de 50 terabytes.

Antes que venham dar palpite, sim, isso não é pra qualquer um. Estamos falando de 8 HDs de 10.9 TB, mais upgrade de 2 HDs de 20 TB, mais outros 2 HDs de 20 TB de backup pra caso um deles dê pane, mais 2 NVMEs de 1 TB cada só pra ser cache, mais placa de rede de 10 Gbps. Além disso eu mantenho várias cópias online de parte desse conteúdo em Google Drive ou Dropbox, e um backup inteiro na Amazon Glacier, pra rara ocasião se minha casa pegar fogo, por exemplo. Estou preparado pra qualquer catástrofe, sempre.

A Synology é uma das melhores marcas de NAS caseiros. Sim, dá pra fazer bem mais sofisticado também, basta montar um servidor de verdade, com CPUs como AMD EPYC ThreadRipper, usando sistemas como TrueNAS. Mas aí é demais pra mim, já não me sinto confortável dando manutenção. Como eu disse, os limites cada um tem que saber os seus.

1o HD de 20TB terminou de se integrar ao RAID! Levou 2 dias inteiros!! Colocando o 2o HD ... de 4 😅 pic.twitter.com/Rv6dqBQr05

— Akitando.com (@AkitaOnRails) March 27, 2024

“Por que não deixar tudo online??” Pra maioria das pessoas é o caminho mais fácil mesmo. Como eu disse, meu caso é particular. Você NÃO QUER ter mais de 50 TERAbytes online. Minha rede cabeada local é de 10 Gbps, minha internet de fibra é míseros 0.5 Gbps (500 Mbps). Trafegar video de alta qualidae pela internet é horrivelmente lento. Eu quero tudo em tempo real, e pra isso só sendo rede cabeada local.

Isso dito, eu montei um segundo mini-computador, usando um Intel NUC, conectado na mesma rede cabeada com o NAS. É Core i7, 32GB de RAM, ethernet 2.5Gbps, com o único intuito de ser um servidor Ubuntu vazio (poderia ser qualquer Linux, só escolhi o mais fácil mesmo) que serve pra subir containers Docker.

Mesmo esse PC-zinho é overkill, muito mais do que é necessário. Muitos vão comentar que um Raspberry-Pi 5 seria suficiente, e não estão errados. A melhor solução é a que você tem orçamento pra comprar e se sente confortável em dar manutenção. Não tente copiar exatamente o setup de ninguém, estude o que melhor encaixa pra você. E não percam tempo dando pitaco no setup dos outros, façam o seu.

De qualquer forma, resolvi compartilhar com vocês todos os arquivos de docker-compose que estou usando pra subir os containers docker nesse servidor. Eis o repositório no GitHub.

AVISO: não esqueçam que precisa editar os diretórios nos scripts. Ele está configurado pra acessar o mount point do meu NAS em rede, que é /mnt/terachad. Arrume pra apontar pros lugares certos na sua máquina.

AVISO 2: existem muitos detalhes que não estou cobrindo neste artigo. Este fórum do Reddit tem mais detalhes e mais discussões. Dependendo se estiver com dúvidas ou problemas específicos, talvez esteja respondido lá.

Pra você não se perder no meio de tantos serviços, aqui está o desenho completo do que a gente vai montar, do pedido até assistir na TV, incluindo as camadas de proteção que impedem malware e download errado de entrar na sua biblioteca:

A ideia é essa: você pede num lugar (Seerr), o sistema encontra (Prowlarr e os indexers), baixa com proteção (qBittorrent e SABnzbd, mais as camadas de segurança), organiza no NAS (com legendas do Bazarr) e você assiste em qualquer tela (Plex e Navidrome). Deixa eu começar explicando um a um dos principais.

Portainer e Utilitários

Este é o trecho (veja completo no repositório):

volumes:
  portainer_data:

services:
  portainer:
    image: portainer/portainer-ce:latest
    restart: unless-stopped
    volumes:
      - portainer_data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - '9000:9000'

Portainer é um gerenciador visual dos recursos gerenciados pelo serviço de Docker na sua máquina. Objetivo é mais pra eu visualmente conseguir “bater o olho” e ver se tem algum container com problema ou pra testar algum ajustezinho rápido em alguma configuração antes de editar no arquivo de docker compose.

No arquivo utils-docker-compose.yml tem outros serviços como Organizr que eu instalei mas ainda não parei pra configurar nem ver se realmente quero manter. Tem o Librespeed, que funciona como aqueles testes de velocidade de internet, mas pra rede local. Tem o Watchtower, que monitora atualização das imagens de todos os containers Docker, faz o download e automaticamente manda reiniciar com versões novas, pra manter todos os containers sempre atualizados.

E pra acessar os serviços locais fora de casa, tem opções fáceis de VPN como o Tailscale ou o ZeroTier, com pouca configuração. Sim, sim, antes que alguém vá pros comentários, dá pra montar OpenVPN do zero, mas vai por mim, essas opções são infinitamente mais “plug and play” e possivelmente mais seguras, porque todo mundo instala, mas poucos têm a disciplina de dar manutenção e atualizar o que precisa o tempo todo. Hoje em dia eu acabei migrando pra um túnel da Cloudflare pra expor meus serviços, mas pra começar, um Tailscale da vida resolve super bem.

MakeMKV e HandBrake

Pra montar sua biblioteca pessoal de filmes, de forma legítima, o correto é você ser proprietário de discos de BluRay ou UHD e “ripar” eles. Se for esse o caso, recomendo comprar modelos de leitor de discos como o Pioneer BDR-XS07S Tem que ficar MUITO esperto porque não é qualquer leitor que funciona.

Veja no fórum do MakeMKV quais os modelos mais recomendados. Tem modelos que tiveram atualização de firmware que impedem deles serem usados pra ripar BluRay. Precisa achar modelos que ou não foram atualizados, ou que não é difícil fazer downgrade de firmware. O ideal é já comprar modelos que todo mundo sabe que funciona, e pra isso tem que fuçar fóruns como esse.

MakeMKV, como o próprio nome diz, “Faz arquivos de video MKV”, que é o bom e velho formato Matroska de envelope de video, um dos mais versáteis (porque suporta múltiplos streams não só de áudio, mas de legenda também).

Crash course: uma coisa é o codec que faz o encodings dos streams de video e streams de audio. Por exemplo, H.265 ou AV1, são codecs de video. MP3 ou AAC são codecs de áudio. Agora precisamos empacotar esses dois streams (ou mais, caso tenha múltiplas dublagens, por exemplo), num “envelope”, um “container”, um “formato de arquivo”, como arquivos “.mp4” ou “.mov”. Matroska é um formato de envelope de arquivo, que é bem flexível, permite múltiplos streams de tudo, incluindo de legenda, por isso é muito usado pra compartilhar em torrent.

Com esse container, você consegue acessar via navegador a interface gráfica do aplicativo (é como se fosse um cliente remoto de Windows, como VNC). Basta ter o leitor de Blu-Ray conectado via USB no seu computador e deve achar. Ele vai usar a biblioteca libredrive pra descriptografar os streams de dados do Blu-Ray, e por isso a importância das versões de firmware serem compatíveis (já terem sido quebrados).

Muitos não sabem que a gente chama tudo de “Blu-Ray” mas na realidade Blu-Ray é pra filmes encodados em versão Full HD, que é 1080p. As versões em 4K (2160p) vem em UHD, que é Ultra HD. A caixa de Blu-Ray costuma ser azul, as de UHD são pretas, você quer as UHD sempre que possível, claro. E eu tenho uma coleção enorme:

"onde eu tô gastando tanto espaço??"

Boa parte é fazendo Rip (backup) de todos os meus UHD (BluRay 4K). E isso porque estou re-encodando em bitrate menor depois de ripar kkkk pic.twitter.com/T1yPa6EIcV

— Akitando.com (@AkitaOnRails) March 26, 2024

A vantagem de um app como MakeMKV é conseguir descriptografar o stream de video e copiar bit a bit exatamente como está no UHD, a melhor qualidade possível. É o que se chama de REMUX (remuxing), que é extrair o stream do container e colocar em outro container sem re-encodar. Já deve ter visto em alguns arquivos de Torrent, é a melhor qualidade. Porém significa que vai gastar o mesmo espaço que no disco, uma faixa de 50 a 80 GIGAbytes, por filme. Cada uma dúzia de filmes vai consumir quase 1 terabyte. Dependendo de quantos filmes você quer ter, seu espaço livre vai acabar muito rápido.

Pra minimizar isso, podemos recodificar ou “re-encodar”. É como quando pegamos uma foto em RAW e re-encodamos pra um formato de menor qualidade, como PNG ou mesmo JPEG. Se souber onde procurar, vai achar os artefatos de compressão, mas no geral, compensa. Por exemplo, no meu caso, encodar pra H.265 10-bit, QP 15 Constant Quality.

A melhor opção é ter uma placa de video NVIDIA, com suporte a encoding de video via hardware NVENC e usar o melhor software pra encoding de video: Handbrake. No meu caso, eu escolho o perfil pré-configurado de Matroska H.265 MKV 4K60fps e mudo pra usar o encoder NVENC da minha placa RTX 4090, que isso acelera o encoding em múltiplas vezes.

No docker compose, assim como MakeMKV, posso subir esse app pra ter acesso via navegador web, assim:

  handbrake:
    restart: unless-stopped
    image: jlesage/handbrake
    ports:
      - "5801:5800"
    environment:
      - AUTOMATED_CONVERSION=0
      - HANDBRAKE_GUI=1
      - DARK_MODE=1
      - TZ=America/Sao_Paulo
    volumes:
      - "/home/akitaonrails/handbrake:/config:rw"
      - "/home/akitaonrails:/storage:ro"
      - "/mnt/terachad/Videos/BluRay:/watch:rw"
      - "/mnt/terachad/Videos/BluRayOptimized:/output:rw"
    devices:
      - /dev/dri:/dev/dri

Seu PC tem no mínimo uma placa de video Intel com suporte a encoding via hardware QSV ou melhor, da NVIDIA, com suporte a NVENC. Em ambos os casos, fazemos o container ter acesso a isso mapeando o dispositivo /dev/dri. Sem isso, o encoding vai ser via CPU, e vai demorar ordens de grandeza mais.

Lembrando que encoding via software, é mais lento mas vai ter qualidade superior a Intel QSV que, apesar de rápido, sempre me dá qualidade de video inferior. NVENC é o melhor dos dois mundos: excelente qualidade e muito rápido.

AVISO: no meu caso, quero a melhor qualidade possível, por isso faço backup de UHD, por isso mesmo torrent eu baixo BR-DISC que é backup de UHD, e isso é absurdamente pesado como expliquei. Daí eu manualmente refaço o encoding pro perfil Matroska H.265 como também expliquei.

Muitos não querem ter esse trabalho, pra isso não deixe de ler o fórum do Reddit que explica como configurar os próximos serviços pra não baixar arquivos grandes assim, eu não vou mostrar aqui, porque não é meu caso.

QBitTorrent

Por mais Blu-Ray e UHDs que você tenha ou consiga comprar, muita coisa nem existe em disco físico. Nesse caso, sua única opção é BitTorrent. E sim, é ilegal piratear, eu não estou incentivando pirataria bla bla bla …

Cada país tem uma lei, vá pesquisar. Vou assumir que todo mundo sabe com o que está fazendo e não é problema meu. Não adianta comentar sobre isso, não vou alongar isso. A Web já está abarrotada de material a respeito, vá no Google e procure você mesmo.

Primeira coisa que queremos é instalar QBitTorrent, provavelmente o melhor e mais completo aplicativo pra baixar torrent, e também tem interface web e funciona via Docker:

  qbittorrent:
    image: linuxserver/qbittorrent:latest
    restart: unless-stopped
    environment:
      - TZ=America/Sao_Paulo
      - WEBUI_PORT=8080
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/akitaonrails/qbittorrent/config:/config
      - /mnt/terachad/Downloads/torrents:/downloads
    ports:
      - '8080:8080'
      - '62609:62609'

É importante lembrar de gerar uma porta aleatória nas configurações do QBitTorrent, como mostrado na imagem abaixo. Qualquer porta entre 1025 e 65535 deve funcionar, mas é possível que sua rede bloqueie alguma sequência de portas nesse intervalo, então tem que testar. Pesquise fóruns na web, cuidado que tem muita dica online que já está desatualizado.

Precisa entender o mínimo de redes, entender se está atrás de um NAT, como mapear portas externas, se tem firewall ativo bloqueando portas, etc.

Se o torrent não estiver baixando, “pode ser” isso. Coloco entre aspas porque é só uma possibilidade. Então clique em “random” pra escolher outra porta, edite a configuração de docker compose pra mapear a porta nova e reinicie o container.

Por alguma razão o gerenciamento de salvamento vem tudo como Manual, é importante mudar pra automático:

Outro detalhe é pedir pro QBitTorrent re-anunciar os downloads para os trackers quando a porta mudar. Pra isso habilite essa opção “Reannounce to all trackers when IP or port changed”, senão os downloads podem não reiniciar.

Agora o ajuste mais importante desta seção inteira, e que eu aprendi na marra: bloquear executáveis no momento do download. Um belo dia achei nove torrents “completos” na biblioteca cujo único conteúdo era um executável de Windows de quase 1 GB, sem video nenhum. E o pior, o nome do release era limpinho, coisa tipo Reacher S04E07 1080p WEB H264-CAKES ou Rick and Morty S09E10 ... EDITH.scr. Você olha o nome e jura que é o episódio. O .exe ou .scr estava escondido no arquivo lá dentro.

Filtro por nome não pega isso, porque o nome está limpo. A defesa que realmente funciona é bloquear a extensão na hora de gravar. No QBitTorrent, vá em Options, Downloads, e habilite “Excluded file names” com esta lista:

*.exe
*.scr
*.bat
*.cmd
*.msi
*.lnk
*.com
*.vbs
*.pif

Com isso, o arquivo malicioso simplesmente nunca é escrito no disco. O torrent “completa” sem nada de útil, o Sonarr ou Radarr percebem que a importação falhou, jogam aquele release na blocklist e saem procurando outro sozinhos. O malware nem toca no disco, e você nem repassa a porcaria seedeando pra frente. Essa é a primeira camada de defesa, e a mais eficaz.

Finalmente, como pesquiso coisas pra baixar? Posso manualmente ir no Google ou DuckDuckGo ou direto em sites como os do PirateBay da vida e buscar arquivos “.torrent” ou links magnéticos. Pra saber o que é isso, assista meu vídeo sobre Criptografia na Prática onde explico tudo sobre Torrent também.

O QBitTorrent tem suporte a plugins de pesquisa. Ele já vem com alguns habilitados. No canto inferior direito, tem o botão de “Search plugins”. Queremos adicionar o plugin que engloba tudo: o serviço Jackett.

Veja que ele quer um host com nome “jackett” habilitado na porta 9117, pra isso temos este trecho no docker compose:

  jackett:
    image: ghcr.io/linuxserver/jackett:latest
    restart: unless-stopped
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/akitaonrails/jackett/downloads:/downloads
      - /home/akitaonrails/jackett/config:/config
    ports:
      - '9117:9117'

Ele vai subir um serviço onde podemos acessar a interface web assim:

É um serviço que consolida dezenas de sites de pesquisa de torrents num lugar só, consegue testar se estão online e, mais importante, fornece uma chave de API no canto superior direito, que devemos copiar e editar na configuração do plugin do QBitTorrent. Com isso é possível fazer pesquisar diretamente, recebendo respostas assim:

Veja na coluna da direita que lista de onde puxou esses resultados: está vindo do serviço Jackett.

Um aviso importante, porque isso mudou com o tempo: o Jackett aqui serve pra ISSO, a busca manual que você mesmo faz no QBitTorrent. Não caia na tentação de plugar o Jackett direto no Sonarr e no Radarr. A parte automática vai ser gerenciada pelo Prowlarr, que eu explico mais pra frente, e é ele que alimenta os indexers dos serviços. Eu mantenho o Jackett rodando só pra busca manual e, no máximo, como ponte pra algum tracker que o Prowlarr não suporta nativamente, tipo o RuTracker, que o Prowlarr consegue consumir através do Jackett.

Radarr (Filmes)

Procurar manualmente funciona, mas existem formas melhores: deixar um serviço fazer a procura e gerenciar o download pra você, e pra baixar filmes, podemos usar o serviço Radarr:

Pra isso, temos este trecho no docker compose:

  radarr:
    image: ghcr.io/linuxserver/radarr:latest
    restart: unless-stopped
    depends_on:
      - qbittorrent
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/akitaonrails/radarr/appdata/config:/config
      - /mnt/terachad/Downloads/torrents:/downloads
      - /mnt/terachad/Videos/radarr/movies:/movies
      - /mnt/terachad/Videos/radarr/anime:/anime
    ports:
      - '7878:7878'

Veja que mapeei diretórios diferentes pra filmes ocidentais e filmes anime, é uma preferência minha, você pode organizar como quiser. Como avisei antes, não copie e cole igual estou mostrando aqui: ajuste os diretórios pra sua máquina.

O principal é que uma vez iniciado, podemos navegar pela interface web, pra opção “Settings”. Ali vai ter “Download Clients"e podemos registrar o serviço web de QBitTorrent:

Eu não mostrei, mas nas configurações do QBitTorrent vai ter um lugar pra cadastrar essa senha de admin pra acessar a API dele via web. Não esqueça de cadastrar lá e usar a mesma senha aqui. Assim o Radarr pode controlar o download de filmes diretamente com o QBitTorrent, sem você precisar se meter.

Tem um ajuste no Radarr que eu recomendo fazer logo de cara, porque ele vem com um buraco bobo: por padrão, TODA definição de qualidade vem com tamanho mínimo zero. Isso deixa passar arquivo falso minúsculo se passando por 4K. Eu já fui vítima: um tal Superman (2025) WEBDL-2160p.iso de 598 MB entrou como se fosse o filme e ficou meses aparecendo no Plex. Por dentro da ISO tinha um .exe de 597 MB disfarçado.

A correção é ir em Settings, Quality, e botar um piso de tamanho em cada definição de qualidade. Uso mais ou menos assim, em MB por minuto de video:

• 720p (HDTV/WEBDL/WEBRip/Bluray): 3
• 1080p (HDTV/WEBDL/WEBRip): 5, Bluray 1080p: 8, Remux 1080p: 25
• 2160p (HDTV/WEBDL/WEBRip): 10, Bluray 2160p: 15, Remux 2160p: 50

É baixo o suficiente pra aceitar um bom encode x265 enxuto, e alto o suficiente pra recusar um “4K” de menos de 1 GB, que só pode ser cilada. Um detalhe chato: o Radarr tem um bug em que salvar tudo de uma vez não persiste o tamanho mínimo, então tem que salvar qualidade por qualidade, uma de cada vez.

Sonarr (Séries de TV)

Mesma coisa que o Radarr, mas pra séries de TV, temos o serviço Sonarr:

Esse serviço é sensacional. Ele acha suas séries, cruzando com bancos de dados online com detalhes como temporadas, nomes de cada episódio e vários outros metadados. Daí ele não só consegue baixar episódios antigos, como mantém uma agenda pra ir baixando séries que ainda estão passando. Toda semana aparece episódio novo sozinho:

E mesma coisa do Radarr: em Settings e Download Clients, posso registrar meu QBitTorrent, daí o Sonarr se vira pra ir baixando os episódios:

E pra subir o serviço, no docker compose temos este trecho:

  sonarr:
    image: ghcr.io/linuxserver/sonarr:latest
    restart: unless-stopped
    depends_on:
      - qbittorrent
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/akitaonrails/sonarr/appdata/config:/config
      - /mnt/terachad/Videos/sonarr:/tv
      - /mnt/terachad/Downloads/torrents:/downloads
    ports:
      - '8989:8989'

Mesma coisa que o Radarr, eu mapeei pastas diferentes pra anime e não-anime, que é questão de preferência da sua organização.

Tanto no Sonarr quanto no Radarr, tem uma configuração que virou obrigatória pra mim depois que comecei a levar cilada: um Release Profile que bloqueia nomes de release conhecidos por serem armadilha. Em Settings, Profiles, eu deixo uma lista de “Must Not Contain” com termos assim:

BROADCAST
FULL HD
.scr
.exe
SODAPOP
REACHERSON

Cada um desses tem história. BROADCAST, SODAPOP e REACHERSON são grupos que empacotam RAR dividido com uma pasta Sample/ que trava a importação (peguei quase 60 GB de lixo de um Welcome to Derry falso de uma vez). FULL HD é a assinatura de nome dos que carregam .exe. E .scr/.exe no nome é literal mesmo. Um aviso pra quem for copiar: o Radarr, por baixo, usa o mesmo campo ignored que o Sonarr, mesmo a interface chamando de “Must Not Contain”, então configure a mesma lista nos dois.

Ainda sobra uma classe que nenhum filtro pega sozinho: os fakes de pré-estreia. Aparece um Reacher S04E07 com zero seeds pra um episódio que só vai ao ar semana que vem. O Sonarr não recusa release com data anterior à estreia, então esses eu limpo na mão mesmo. A boa notícia é que, com o bloqueio de executável do QBitTorrent lá de cima, mesmo quando um desses baixa, ele vem vazio e é descartado automaticamente.

Downloads que travam

Um problema clássico do dia a dia: o torrent fica eternamente preso em “downloading metadata” ou “stalled”, com zero peers, e o Sonarr nunca desiste dele sozinho. Já tive episódio parado cinco dias atrás de um magnet morto enquanto o release bom passava batido, esperando a vez que nunca chegava.

A solução que montei é um script simples rodando uma vez por dia (um cron ou um systemd timer, tanto faz). Ele consulta a fila do Sonarr, do Radarr e do Lidarr pela API, acha os itens presos em “downloading metadata” ou “stalled with no connections” há mais de 72 horas, e manda remover com um comando só:

DELETE /api/v3/queue/{id}?removeFromClient=true&blocklist=true

Isso apaga o download morto, joga o release na blocklist pra não pegar de novo, e a aplicação sai atrás de outra fonte automaticamente. O pulo do gato é o cuidado pra ele NÃO mexer em download que só está lento (menos de 72h) nem em item esperando importação manual, senão você apaga coisa boa por engano. Na primeira vez que rodei, ele limpou dezenove downloads zumbis de uma vez só.

Prowlarr (indexador)

Pra tanto o Radarr e Sonarr saberem de onde puxar os torrents de séries e filmes, eles precisam pesquisar em indexadores ou trackers públicos (ou privados, se você tiver bons contatos - eu não tenho, nem pergunte). Pra isso temos Prowlarr. Esse é o serviço mais importante de todos, porque se esse não funcionar, nada vai baixar direito.

Levei um tempo pra chegar numa configuração boa, mas hoje tenho uma regra simples que resolve: o Prowlarr é o único lugar que gerencia indexer. Sonarr, Radarr e Lidarr NÃO devem ter indexer cadastrado direto, só os que o Prowlarr sincroniza. Todo indexer que eu tinha cadastrado na mão dentro do Radarr era fonte de dor de cabeça, inclusive um “Lime Torrents” que foi exatamente quem me serviu aquele malware da ISO do Superman. Apaguei todos e deixei só o Prowlarr alimentando os três.

Veja que lista dezenas de indexadores, ou trackers. É parecido com o Jackett. A diferença é que o Jackett é pra pesquisas manuais que você mesmo vai fazer, direto no QBitTorrent. Já os indexadores do Prowlarr vão ser configurados direto no Sonarr e Radarr. Aqui começa a confusão, vamos entender:

Tanto no Sonarr quanto no Radarr, além de Download Clients, onde podemos configurar o QBitTorrent, também vai ter essa opção de “Indexers”, onde podemos configurar em quais trackers procurar pela mídia.

Pense num tracker como um mini-Google público, é onde as pessoas registram seus torrents quando querem compartilhar. Torrents não são mágicos e nem aparecem do nada. Alguém tem que criar um registro em algum lugar. Mas não existe só “um” lugar: é uma rede distribuída e qualquer participante pode subir um tracker se quiser. É como se você pudesse subir seu próprio Google miniatura, só pra registrar arquivos de torrent.

É um saco ficar gerenciando isso. Alguns trackers pequenos resolvem sair do ar, novos aparecem, configurações são modificadas, e precisamos ficar gerenciando manualmente isso, tanto no Sonarr quanto no Radarr. Pra isso serve o Prowlarr: pra gerenciar os trackers pra você. Vamos entender como.

Nas configurações do Prowlarr, começamos configurando onde encontrar nossos serviços de Sonarr e Radarr:

Por exemplo, esta é a configuração do meu Sonarr. Notem que o hostname é “sonarr” e isso funciona porque no meu docker compose eu subo todos os serviços na mesma VLAN, e por padrão o docker registra como hostname o nome do serviço configurado no arquivo YAML. Se não entende Docker, não deixe de assistir meus videos sobre containers.

Também precisamos configurar acesso ao QBitTorrent:

Esse outro SABnzbd usa outro protocolo de downloads mais antigo, baseado em newsreader de USENET. Sim, aquela Usenet mesmo. Quem sabe, sabe. Eu deixo o torrent como principal, mas mantenho o SABnzbd configurado como segunda fonte, porque muito conteúdo só existe nesses grupos mais antigos. Se for usar, aplique a mesma proteção de extensão do QBitTorrent: no arquivo sabnzbd.ini, na seção [misc], coloque unwanted_extensions = exe, scr, bat, cmd, msi, lnk, com, vbs, pif e action_on_unwanted_extensions = 2, que manda abortar o download inteiro se aparecer um desses. Assim o Sonarr e o Radarr veem a falha e procuram outra fonte.

Finalmente, muitos trackers hoje implementam algum tipo de proteção contra bots usando captcha da Cloudflare, sabe aquele troço que fica “você é um humano?”. Pra passar por isso, precisamos do serviço Flaresolvrr, que podemos subir no docker compose assim:

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    restart: unless-stopped
    volumes:
      - /home/akitaonrails/flaresolverr/config:/config
    ports:
      - '8191:8191'

No Prowlarr ele entra como um “indexer proxy”. Você cadastra o FlareSolverr apontando pra http://flaresolverr:8191/, cria uma tag pra ele, e marca com essa tag só os indexers que ficam atrás do Cloudflare. Aí esses passam a resolver o captcha por baixo dos panos, e os outros nem precisam passar por ele:

Ainda não acabamos. Na tela principal, é sair habilitando os indexers que fazem sentido pra você. Não habilite tudo: fica pesado e, pior, alguns indexers servem mais cilada do que conteúdo bom. Veja as tags de cada um. Tem indexer que é só de pornô, tem indexer só de conteúdo russo ou chinês, esses eu pulo.

Os que me servem bem hoje são o EZTV e o 1337x (os dois atrás do Cloudflare, então dependem do FlareSolverr), o YTS pra filme, e o AnimeTosho mais o Nyaa pra anime. No total sobra algo entre 18 e 21 indexers ativos por aplicação. E, mais importante do que habilitar os bons, é desabilitar os ruins: eu desliguei o LimeTorrents e o TorrentDownload, porque, somados, geraram mais de duzentos downloads e quase nenhuma importação aproveitável, além de serem fonte recorrente de malware e de fake. Menos indexer bom vale mais que um monte de indexer ruim.

No final, é bom clicar esse “Test All Indexers” pra checar quais ainda estão ativos ou não. E por fim, podemos clicar em “Sync App Indexers”, que vai cadastrar todos os indexers que sabemos que estão funcionando, nos registros do Sonarr e Radarr. Entenderam? O Prowlarr vai configurar os dois com os indexers mais atualizados, e remover os que não estão mais ativos. Não precisamos configurar cada um deles manualmente.

É importante entender isso, porque senão você vai ver o Sonarr e o Radarr não conseguindo baixar nada e não vai saber porque: mas é porque os indexers estão errados ou obsoletos ou insuficientes. Gaste bastante tempo lendo a documentação do Prowlarr.

Plex (Netflix Particular)

Pra assistir tudo que baixar, tem várias opções. Se é só pra você, basta ir baixando tudo num HD externo ou algo assim, e assistir diretamente do seu PC ou notebook. Dependendo da Smart TV ou console de videogame, também dá pra conectar seu HD ou pendrive via USB e assistir direto.

Se for um pouquinho mais sofisticado, e tiver um PC ou Raspberry Pi sobrando, dá pra instalar Sonarr, Radarr, e compartilhar o diretório de downloads pela rede, usando protocolos como CIFS, que é pra pasta compartilhada de Windows. Novamente, muitas Smart TVs e consoles suportam montar pastas compartilhadas pela rede.

Mas se quiser algo mais amigável e sofisticado, dá pra ter literalmente seu “Netflix Particular”, com uma interface gráfica parecida com qualquer plataforma de streaming, onde mostra thumbnails, descrições, detalhes do filme ou série, tocador de video e tudo mais e até sugestões do que assistir, sugestões de filme baseado no que está assistindo, informações de atores e tudo mais.

Existem vários projetos que fazem isso. Um deles, que a comunidade curte mais por ser 100% aberto, é o Jellyfin (derivado do antigo Emby). Recomendo que testem, tem tudo que a maioria das pessoas precisa. Basta mapear as pastas de downloas do Sonarr, Radarr e ele vai indexar tudo e organizar pra você. Daí, de qualquer PC, é só acessar a interface web e tudo só funciona.

Mas eu pessoalmente prefiro o Plex, que é mais antigo, é mais fechado (por isso alguns não gostam), mas por oferecer planos pagos com funcionalidades exclusivas, o nível de polimento é nitidamente melhor. A interface é bem mais bonita, e parece mais “profissional”. Jellyfin, por melhor que seja, ainda tem cara que foi um programador backend que fez, com muita má vontade em UX e design.

Além disso, pra assistir numa Smart TV ou Android TV da vida, precisa ter app no Google Play Store. Jellyfin não tem app pra tudo, algumas TV, não lembro se LG ou Samsung, nem tem o app disponível. Então precisa fazer side-load. Não é amigável. Plex, por outro lado, está disponível em bem mais lugares, então costuma ser mais “plug and play”, parecido com baixar app de Netflix ou Amazon Prime.

Plex também tem funcionalidades que “just works”, coisas triviais que se espera num tocador, como botão de “pular abertura” ou “resumir a partir de onde parou” ou “pular pro próximo episódio” ou “pesquisar e trocar legenda”. É isso que interfaces como essas vão te oferecer, daí a usabilidade é realmente muito parecida com assistir Netflix. Não tem isso se usar um tocador genérico de PC como um VLC da vida.

Pra subir é fácil, eis o trecho do meu docker compose:

  plex:
    image: plexinc/pms-docker:latest
    restart: unless-stopped
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
      - VA_DRIVER=IHD
      - PLEX_HW_TRANS_MAX=16
    volumes:
      - /home/akitaonrails/plex/config:/config
      - /home/akitaonrails/plex/data:/data
      - /home/akitaonrails/plex/transcode:/transcode
      - /mnt/terachad/Videos:/media
    devices:
      - /dev/dri:/dev/dri
      - /dev/bus/usb:/dev/bus/usb
    network_mode: host

Existe um pequeno detalhe que muitos não entendem: Plex faz transcoding dos videos. Ou seja, ele vai re-encodar o video antes de mandar pro app ou navegador que vai tocar, isso é pesado, é conversão de stream de video. Se seu servidor não for forte o suficiente, seu video vai ficar engasgando pra tocar.

Na realidade, é mais complicado do que isso. Existe um protocolo chamado “Direct Play” ou “Direct Stream”. Tem um artigo que explica isso no site do Plex. Se o PC, SmartTV, console, etc, tiverem suporte ao codec do video em questão, teoricamente o Plex só vai passar os bits direto, sem tentar converter nem nada. Entenda: nem todo dispositivo tem capacidade pra tocar qualquer codec de video.

A maioria do conteúdo hoje em dia é encodado em H.264 ou H.265 ou até AV1, que é mais novo e mais eficiente. Problema, digamos que você queira tocar num PC bem antigo ou num PS4 da vida. Eles vão ter suporte a H.264, talvez H.265, se tiver sorte, mas certamente não a AV1. Daí seria super lento tentar tocar usando só a CPU. O certo é ter instruções de hardware pra tocar AV1, especialmente num CPU antigo.

Então o Plex pergunta pro dispositivo: “você suporta AV1?” O tocador vai dizer “nope, sou fraco.” Então o Plex vai fazer o transcoding de AV1 pra H.264, por exemplo. Tudo isso é transparente pra você.

Mas aí você vai notar que na hora de tocar o video fica engasgando, pausa toda hora. Pode ser um problema de banda da sua rede ou, pode ser problema do seu servidor de Plex ser muito fraco ou, de não estar configurado pra transcoding via hardware, e estar indo na força bruta usando só a CPU.

Assista meu video sobre compressão, onde explico sobre codecs, mas em resumo, o correto é que seja lá qual PCzinho estiver usando pro seu Plex, que ele tenha o mínimo de capacidade de encoding de video em hardware. A maioria costuma ter pelo menos capacidade de H.264, como as instruções Intel QSV, veja se sua CPU tem esse suporte. Só não vai ter se for velho demais, tipo coisa de 10 anos pra trás. Se for um servidor forte, com GPU NVidia, vai ter coisas como NVENC, que dá suporte a H.265. Se for CPU Intel moderna, vai ter suporte a AV1.

Em todo caso, em Linux, essas instruções devem ficar expostas no dispositivo /dev/dri, e por isso precisamos mapear no container docker como fiz acima. Cheque se existe esse dispositivo.

Se estiver tudo certo, no Plex vai ter essa opção de configurar “Transcoder”:

Queremos nos certificar que a qualidade está em “Make my CPU hurt” e que a opção de “Use hardware acceleration when available” está hablitado também, daí ele vai usar o /dev/dri pra acelerar o transcoding. E isso faz uma diferença BRUTAL na velocidade. Se estiver com playback sendo engasgado, muito provavelmente é o transcoding.

Quando o dispositivo, seu smartphone ou sua TV, tem suporte ao exato codec usado no arquivo de video que queremos assistir, teoricamente, o Plex consegue passar o stream direto, sem transcodar, que é o mundo ideal, porque aí não processamento nenhum. Isso é Direct Play. Mas pra isso os arquivos de video precisam estar num determinado codec, numa determinada configuração. Mas mesmo num codec suportado, se sua TV for fraca e não suportar 4K, e pedir pro Plex em Full HD (1080p), daí o Plex vai transcodar de H.264 4K pra H.264 1080p, por exemplo. Por isso falo que é mais complicado do que parece.

DETALHE IMPORTANTE: Recentemente fiquei confuso ao tocar alguns dos meus videos. Eu tenho o melhor hardware, tanto pro servidor de Plex, com aceleração via hardware, quanto Android TV pra tocar que é meu NVIDIA Shield Pro, quando rede cabeada, etc. Mas alguns videos ficavam engasgando. E no final o culpado não era hardware, nem configuração, nem nada disso, era a maldita legenda:

Quem já precisou baixar legendas, já deve ter visto o formato mais comum, que é o .SRT (SubRip). Alguns que se aventuraram mais, já devem ter visto outros formatos, como SSA (SubStation Alpha), TTML (Timed Text Markup Language), VTT (Web Video Text Track), VOBSUB, etc.

Sim, existe MUITO mais que SRT. Em particular, se você fizer como eu e ripar UHDs e extrair as trilhas de legenda do próprio disco, aplicativos como o MakeMKV podem baixar em formato VOBSUB (que é ok) ou o maldito PGS (Presentation Graphic Stream Subtitle Format).

A maioria das trilhas de legenda foram feitas pra serem enviadas ao tocador em paralelo, e separado, da trilha de video. Assim como a trilha de áudio vai separado. O tocador recebe trilha de video, trilha de áudio, e toca os dois sincronizados. Mesma coisa com trilha de legenda, no caso de arquivos SRT ou SSA ou TTML da vida.

Mas PGS é diferente: ele tem capacidades gráficas! Estou chutando, mas se já viu legenda coloridas, animadas, que se mexem ou se posicionam em locais absolutos na tela (como pra ficar exatamente em cima de outdoor no video, por exemplo), daí precisa haver um passo antes de rasterizar e renderizar essa legenda gráfica EM CIMA do stream de video. Isso existe um passo mais pesado de encoding, ou seja, vai ser PESADO de tocar em tempo real.

A solução: use o Plex pra pesquisar uma nova legenda, em formato SRT, e ignore a legenda PGS. Só de fazer isso, parou de engasgar na hora de tocar.

Seerr (o antigo Overseerr)

Só com o Sonarr e Radarr, mais os indexers do Prowlarr, já é suficiente pra procurar e baixar tudo. Mas tem um outro app que facilita muito a parte de descobrir coisa nova pra baixar. Ele se chama Seerr, e é a evolução do que antes era o Overseerr. O projeto do Overseerr se juntou com o Jellyseerr, o fork que atendia Jellyfin, e os dois viraram um só: o Seerr, que agora serve Plex, Jellyfin e Emby no mesmo lugar. Se você ainda ouve falar em “Overseerr” por aí, é isso aqui.

Ele vai em bancos de dados online gratuitos (tipo os IMDB) da vida e fica de olho em tudo que sai de novo, tudo que está em “trending”. Se eu quero achar alguma coisa nova, é uma boa. Mesmo coisas que já sei o que quero, basta pesquisar no Seerr e clicar em “Request”:

Eu configuro a integração com o Sonarr e o Radarr nas configurações, assim ele sabe pra quem mandar a requisição. Funciona tudo integrado. Só preciso usar a interface do Seerr pra pedir as coisas e posso esquecer do Sonarr e do Radarr rodando em background.

Bazarr (legendas)

Eu não preciso, mas minha namorada às vezes prefere assistir com legendas em português. E é um saco isso porque nem sempre tem, ou o que tem é de baixa qualidade. Aliás, deixa eu já avisar que tanto legenda oficial quanto não-oficial, eu tô cansado de ver tradução errada. Minha diversão é ficar achando os erros na legenda. Se você depende de legenda, saiba que muitos significados importantes estão errados mesmo. Sempre prefira original.

Antigamente tinha que ir manualmente em sites como OpenSubtitles.org da vida, baixar o arquivo “.SRT”, renomear igual o nome do arquivo de video e ficar testando manualmente pra ver se tá sincronizado ou não.

Existem dois jeitos de resolver isso. Um é pelo próprio Plex, que tem a opção de pesquisar legendas em diversas línguas e ficar testando direto da interface do tocador. Facilita bastante porque pula o passo de ter que ficar no PC, manualmente baixando arquivos. Como expliquei na seção anterior, no meu caso, que a legenda dos backups de UHD foram extraídos no formato PGS, eu preciso buscar no formato SRT pra não engasgar na hora de tocar.

Outra forma é tentar baixar as legendas automaticamente antes. Isso não é perfeito porque existem diversas versões de legendas, algumas foram feitas pra DVD, outras pra BluRay, alguns até pra versões mais populares de “CAM” que são torrents de videos gravados direto no cinema com um smartphone, que é a versão mais porcaria de todas.

É muito importante renomear os arquivos de video no formato certo, com os metadados bem organizados, como explicado no fórum de Reddit que mencionei no começo do artigo. Isso ajuda o Bazarr a casar a legenda certa com o arquivo certo. E já avisando: Português do Brasil é uma das línguas que menos tem legenda. É mais fácil achar em Francês, Italiano ou Russo do que em Português.

Pra facilitar isso temos o serviço Bazarr:

Na configuração do Bazarr, vamos apontar pros nossos serviços locais de Sonarr e Radarr, assim ele fica sabendo toda vez que aparece episódio novo de série ou algum filme novo, e já agenda pra tentar procurar a legenda:

O principal é configurar os Providers, que são os sites de onde vêm as legendas. É aqui que mora a diferença entre “não acha nada” e “acha quase tudo”. Os cinco que me dão o melhor resultado são: opensubtitlescom, tvsubtitles, yifysubtitles (só filme), animetosho (pra anime, nem precisa de conta) e gestdown (um proxy do Addic7ed pra inglês, também sem conta). Uma pegadinha que me custou horas: o provider OpenSubtitles.com pede o seu nome de usuário, não o email. Se você botar o email, ele dá erro de “você não pode consumir este serviço”, e ainda te deixa de castigo por 12 horas mesmo depois de corrigir.

Pra subir o serviço, no docker compose, temos este trecho:

  bazarr:
    image: ghcr.io/linuxserver/bazarr:latest
    restart: unless-stopped
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
    volumes:
      - /mnt/terachad/Videos/radarr:/movies
      - /mnt/terachad/Videos/sonarr:/tv
      - /home/akitaonrails/bazarr/appdata/config:/config
    ports:
      - '6767:6767'

Aqui precisamos mapear as pastas do radarr e sonarr pra ele saber onde gravar as legendas. Um detalhe que trava muita gente: mapeie exatamente as mesmas subpastas que o Radarr e o Sonarr usam (no meu caso, /movies e /anime), senão o Bazarr fica reclamando que “não acha o arquivo de video pra analisar” na biblioteca inteira.

O último passo, e o que fez o Bazarr finalmente virar útil pra mim, é o perfil de idioma. Criei um perfil “Português do Brasil com inglês de reserva”: ele lista pb primeiro e en depois, com o corte (cutoff) no pb. Na prática, o Bazarr procura as duas, baixa a que aparecer primeiro, e considera o item resolvido assim que existe uma legenda em português. Se o pt-BR nunca aparecer, o inglês fica de backup.

E o pulo do gato, que me custou caro: todo item precisa ter um perfil de idioma atribuído. O Bazarr ignora, calado, qualquer filme ou série sem perfil. Quando fui conferir, tinha 140 séries e 201 filmes sem perfil nenhum, sendo ignorados em silêncio desde que entraram na biblioteca. Marcar o perfil como padrão só cobre o que você adiciona dali pra frente; pra biblioteca que já existe, tem que atribuir o perfil em massa, de uma vez, pra tudo que já está lá.

Tem ainda um problema irmão desse, só que do lado do áudio. De vez em quando o Sonarr ou o Radarr baixam um release cujo único áudio é uma dublagem estrangeira: um italiano, um francês, um russo. E nenhuma legenda salva áudio errado. Pra isso eu uso um Custom Format nos dois, o “foreign-language-only”, que reconhece marcadores de dublagem estrangeira (ITALIAN, FRENCH, RUS, GERMAN e por aí vai) e dá uma pontuação de -500, o que faz o release ser recusado já na busca. Um detalhe que aprendi na marra: um release russo veio com o título todo em cirílico, sem nenhum “RUS” em letra latina, e passou batido. Então o filtro também precisa pegar qualquer caractere cirílico.

Depois que arrumei os providers, passei a biblioteca inteira pra esse perfil e liguei esse filtro de áudio, o Bazarr deixou de ser o serviço mais inútil da minha stack e virou um que resolve a maioria dos casos sozinho. Quando ainda falta, aí sim eu caço na mão pelo Plex, mas hoje é exceção. Só lembrando o que já falei: legenda em português do Brasil é das mais escassas que existem, então mesmo com tudo certo, às vezes não tem mesmo.

Lidarr (Música)

Eu não sou muito de música. Tenho uns MP3 que baixei décadas atrás e, no dia a dia, toco a playlist de Top 50 do Spotify e tá bom. Mas a mesma lógica do Sonarr e do Radarr vale pra música, então acabei montando também: o serviço se chama Lidarr.

Ele cataloga seus artistas, cruza com bancos de dados de discografia e vai atrás dos álbuns que faltam, marcando cada artista como “Monitored” pra buscar lançamentos novos sozinho, do mesmo jeito que o Sonarr faz com episódio de série. No print acima dá pra ver minha biblioteca com tudo em “Lossless”, que é o perfil de qualidade que eu configurei.

No docker compose é o mesmo padrão dos outros:

  lidarr:
    image: ghcr.io/linuxserver/lidarr:latest
    restart: unless-stopped
    depends_on:
      - qbittorrent
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/akitaonrails/lidarr/appdata/config:/config
      - /mnt/terachad/Music:/music
      - /mnt/terachad/Downloads/torrents:/downloads
    ports:
      - '8686:8686'

A configuração é idêntica em espírito à do Radarr e Sonarr. Em Settings e Download Clients eu registro o mesmo QBitTorrent, mas usando uma categoria própria chamada lidarr, pra ele não misturar os downloads de música com os de filme e série. A pasta raiz da biblioteca aponta pra /music, e o perfil de qualidade dá pra deixar aberto (o “Any”, que pega o que aparecer) ou travar em “Lossless” quando você só quer FLAC, que é o meu caso.

E o melhor: os indexers eu não configuro na mão. O Prowlarr, que eu expliquei lá em cima, também cadastra o Lidarr como aplicação e sincroniza sozinho os indexers que têm categoria de música. É o mesmo “Sync App Indexers” que ele faz pro Sonarr e Radarr, agora pra música também.

Pra ouvir, o próprio Plex já toca música: basta criar uma biblioteca do tipo Music apontando pra essa pasta, e no celular o app Plexamp é ótimo só pra isso. E, do mesmo jeito que tenho o Kavita como “Plex pra mangá”, pra música ainda dá pra usar o Navidrome, um servidor de streaming open source tipo um Spotify particular, que indexa a mesma pasta /music (só leitura) e tem vários apps de celular compatíveis. O Lidarr baixa e organiza, o Navidrome ou o Plex servem.

Outros Serviços

No meu repositório tem outros arquivos de Docker Compose pra minha infra local. Não vou explicar em detalhes, mas só a saber:

Pra bloquear banner, ad, rastreador e até site de malware na rede toda, eu uso DNS filtrado. Durante muito tempo rodei um Pi-Hole local pra isso, que é um servidor de DNS caseiro com bloqueio embutido. Funciona muito bem, mas dá manutenção. Hoje eu troquei por um serviço hospedado, o NextDNS, que faz o mesmo bloqueio de ads, rastreadores e malware, só que sem eu precisar manter servidor nenhum, e já vem com DNS criptografado de fábrica.

E por que DNS criptografado importa? Query de DNS, por padrão, é um protocolo de texto aberto. Seu provedor sabe exatamente tudo que você navega. Eu prefiro não dar esse dado de graça pra eles. Com o NextDNS as consultas saem encriptadas e ainda passam pela lista de bloqueio que eu escolho. Não substitui um anti-virus, mas dificulta bastante que terceiros montem uma impressão digital dos meus hábitos de navegação, e dá bem menos trabalho que o Pi-Hole que eu mantinha antes.

Agora, no arquivo kaizoku-docker-compose.yml tem outro serviço tipo Sonarr pra TV, Radarr pra filmes, que é o Kaizoku pra mangá. Se você lê mangá online, já deve ter visto muitos sites sendo fechados por causa de copyright, direitos autorais e tudo mais. Eventualmente, os mangás online que você leu, vão desaparecer. Com o Kaizoku podemos preservar eles localmente também.

O Kaizoku é só pra baixar. Pra ler, precisamos de um leitor, da mesma forma que temos Plex pra video, temos Kavita Reader pra ler os mangás baixados. Assim como Plex, basta na primeira configuração apontar pra pasta onde o Kaizoku baixa tudo, daí o Kavita vai se virar pra organizar a biblioteca, baixar capas e outros metadados. É literalmente o Plex pra Mangá.

Ainda não explorei muito esse serviço. Ou ainda tem coisas pra refinar nele, ou eu que não sei configurar direito, mas nem tudo baixa capas direito. Vejam como não está bonito. Se tiverem dicas sobre Kavita e Kaizoku, não deixem de compartilhar abaixo.

Pra ler em si, é bem parecido com um Kindle Web ou outros sites online de mangá. Dá pra ler página a página, ou “scrollar” o capítulo inteiro, ele vai lembrar onde você parou e coisas básicas assim. Pode ser um bom projeto pra contribuir, se tem vontade de treinar com código aberto.

Conclusão

Fico muito contente com o estado atual dos serviços de compartilhamento de arquivos. Não percam muito tempo pensando demais. Só instalem e se divirtam. O código de tudo é aberto, se você é programador, vá lá fuçar o código e aprender algo novo, e quem sabe, até contribuir.

Eu não sou adepto de teorias apocalípticas, teorias da conspiração, nem nada assim. Eu só considero que, o que eu não tenho controle físico, eu não tenho. Se o que “é meu” está no controle de um terceiro, então “não é meu”. Esse é o princípio. Eu quero tudo que é meu sob meu único e exclusivo controle e pronto. Não importa se é menos conveniente, não importa se é mais caro. É uma questão de princípios: meu é meu e ponto final.

Além disso, nas plataformas de streaming, não existe tudo. Muita coisa de décadas passadas simplesmente foram apagadas da memória. Muitos nem lembram mais, especialmente quem não viu na época. Eu tenho nostalgia por programas de TV, filmes, que não existe online. Muitos sequer existem em mídia física. Tem filmes que depois de VHS nem chegaram a sair em DVD. Tem DVD que nunca saiu como Blu-Ray. Tem coisa em disco físico que nunca vai sair em streaming. Tem coisa em streaming que vai ser apagado em breve, e muitos nem vão notar.

O que é meu, é meu. Podem apagar o quanto quiserem. O que é meu, ninguém apaga. Se você tem apreço pelo que é seu, comece a explorar estas opções. Não precisa ser um setup gigante como o meu. Qualquer HD externo sobrando já dá pra começar. Comece pequeno, vá aumentando aos poucos. Eu coleciono essas coisas faz décadas! Não comecei hoje.

Sim, este episódio foi inteiramente gerado por ferramentas de IA, em particular HeyGen e ElevenLabs. Fiz bem curto pra não ficar cansativo demais. Mesmo sendo impressionante, no atual estágio não é possível fazer videos do tamanho que costumo fazer no canal.

Primeiro, o HeyGen não consegue fazer videos maiores do que 1 minuto sem que a qualidade decaia muito. Eu tentei fazer videos de mais de 2 minutos e do nada ele começava a halucinar e me fazer falar em espanhol, por exemplo.

Segundo, o treinamento é super limitado. Ele só me deixa subir uns 5 minutos de amostra de video. É muito pouco e isso resulta em muito pouca variância nos movimentos. Muito pouca diversidade de jeito de falar. Então fica muito robótico mesmo.

Terceiro, o tempo que levou pra gerar esses clipes de video não compensa o trabalho. Não é de graça, custou quase 40 dólares pra fazer menos de 14 minutos. E levou mais de 14 minutos pra gerar tudo. Eu teria levado cerca de meia hora pra gravar normalmente um video deste tamanho. Então não é possível usar esse tipo de ferramenta pra economizar tempo.

A vantagem seria mais no futuro, quando esses limites melhorarem, e eu tiver algum problema físico que me impeça de gravar mais videos. Aí sim, poderia servir como meu “backup virtual”. Ainda é primeira geração desse tipo de ferramenta. Eles devem melhorar bastante nos próximos anos.

O que acharam?

Links

• HeyGen - AI Spokesperson Video Creator
• Text to Speech & AI Voice Generator (elevenlabs.io)
• eesel.ai - ChatGPT over your knowledge
• DaVinci Resolve 18.5 traz inteligência artificial para edição de vídeo (diolinux.com.br)
• Adobe Firefly – Generative AI for everyone

SCRIPT

Olá pessoal, Fabio Akita!

Este vai ser um episódio experimental, curtinho mesmo, mais de brincadeira. Desta vez quero falar um pouco sobre as ferramentas de IA, tipo ChatGPT, que tenho incorporado no meu dia a dia. Não vai ser um review extenso de tudo que existe, só o que eu já experimentei e gostei de usar.

Todo mundo continua empolgado e hypado por causa de ChatGPT, especialmente com o lançamento do ChatGPT 4, com funcionalidades como, abre aspas, “fazer seu próprio GPT”. Vou aproveitar pra explicar um pouco disso e reiterar minhas opiniões sobre IA em geral. Então, vamos lá!

Pra começar, novembro vimos um dos episódios mais patéticos da história de Silicon Valley. Tudo bem, pra ser honesto, teve mais patéticos, como a história da Theranos ou da WeWork. Mas o hype sobre IAs continua num estágio muito primitivo de discussão.

Esse episódio patético foi a diretoria da OpenAI demitir o CEO Sam Altman, sem explicação nenhuma, fazendo um puta drama, pra depois voltarem atrás quando todos os funcionários ameaçaram sair e irem pra Microsoft. Ninguém deu uma razão oficial pra isso até agora, mas alguns especulam que tem a ver com os riscos de estarem próximos de atingirem a tal da “AGI” ou “Inteligência Artificial Geral”, a temida Skynet.

O que se chama de “IA” hoje em dia são Large Language Models, LLMs. E LLMs são basicamente como o auto corretor do teclado do seu celular, mas altamente glorificado! Ele cospe coisas que parecem ter sentido, mas não houve um milímetro de cognição envolvida, muito menos consciência. Provavelmente, amebas tem mais consciência do que o melhor LLM de hoje.

Explico isso em detalhes no meu video de “Como ChatGPT Funciona”, depois assistam pra entender. Modelos são embeddings de textos. Matrizes hiper-dimensionais de pedaços de textos associados com valores probabilísticos. Em resumo, super resumido, é assim que um GPT gera textos. GPT é um gerador de textos. Sim, um gerador ultra-sofisticado, mas ainda assim, um gerador de textos. Não existe “inteligência” no sentido humano que envolve raciocínio ou cognição.

GPT só continua o texto a partir de onde você parou de digitar. Ele continua textos. A idéia toda de “gerar seu próprio GPT” eu mostrei na live que tá no meu canal de “IAs são perigosas?” Onde eu mostro como criar um personagem. Eu criei o John Carmack e comecei a conversar com ele. Assistam lá depois. É a mesma coisa no GPT 4, um prompt inicial dizendo “faça de conta que você é a pessoa Fulano, com comportamento assim ou assado” e aí ele continua o texto.

Mesmo com os avanços do GPT 4, mesmo se o GPT 5 for o dobro ou triplo ou 10 vezes melhor que GPT 4, ainda assim não estamos pertos da tal “AGI” que é a Inteligência Artificial “Geral”, a verdadeira consciência digital, que simula perfeitamente um “ser vivo”, com emoções e ambições, a semente da Skynet. Isso continua sendo ficção científica. Ainda faltam descobertas e breakthroughs que não foram feitos.

Não sabemos quais descobertas são, obviamente, senão não seriam descobertas, mas sabemos que faltam. Ao contrário do que as pessoas pensam, nós engenheiros e cientistas, não fazemos as coisas às cegas, aleatoriamente. Sabemos quais os limites do que pode ser feito com as ferramentas que temos. Imaginação é exatamente uma das coisas que nós sabemos fazer muito bem, e que IAs não tem capacidade.

Mesmo assim, muita gente considerada “gênio” da área, como um dos fundadores da OpenAI o Ilya, por alguma razão, resolveu aderir à crença de que estamos perigosamente próximos de uma AGI que vai prejudicar a espécie humana. Não vai. Não só tá longe, como neste estágio eu nem diria que temos certeza se isso é sequer possível. Pra começar não existe nem boas definições para o que caracteriza de fato coisas como “inteligência” ou “consciência”. Nossas definições hoje são extremamente primitivas ainda.

É o mesmo tipo de “gênio” que anos atrás ficava enchendo o saco dizendo que o aquecimento global já teria acabado com o mundo em 2023. Mas isso é outro assunto.

Mesmo assim, sim, os receios que IAs vão substituir o emprego de muita gente são reais, em particular porque existem muitas atividades que são meramente copy e paste, muito simples de serem automatizadas. Não porque a IA ficou inteligente demais, mas porque os trabalhos em si eram muito simples.

Não precisou de IA pra começar a substituir caixa de supermercado ou tirar pedido em fast food. Muitos mercados já tem caixas self-service. Lugares como McDonald’s já tem telas gigantes de pedidos self-service. Muitos bots de atendimento via whatsapp já substituiram gente que atendia telefone, e por aí vai. E isso é normal. Faz mais de século que estamos substituindo trabalhos de baixo valor agregado pra sistemas automatizados, e pra isso não precisa de IA. A geração atual de LLMs ajuda, com toda certeza.

No nosso caso de programadores, sim, também existe automação. Mesmo em design. Todo mundo que usa softwares como Canva já sabe disso. O que antes precisava pedir pra alguém abrir o Photoshop pra fazer, qualquer um sem nenhum treinamento já consegue fazer agora. Quem é de Photoshop, lembra como separar uma pessoa do fundo antigamente levava horas, precisava de técnicas avançadas com lidar com canais de separação de cor. Agora o app de câmera do iPhone ou Pixel já conseguem fazer isso com um clique.

Mesmo antes de IA, com serviços como SquareSpace, muita gente não-técnica já consegue fazer sites minimamente bonitos. O mercado de templates, por si só, barateou bastante o que antes era um trabalho caro e demorado. Pra maioria das pessoas, só isso já é suficiente. E de novo, nem precisamos de IA pra isso.

Isso tudo dito, as ferramentas baseadas em alguma coisa de IA de hoje são extremamente úteis. ChatGPT e LLMs são só um dos tipos de IA, mas não são os únicos tipos. Muitas ferramentas que usam modelos de IA não são baseados em LLMs porque não são geradores de conteúdo. Alguns usam machine learning, alguns usam deep learning, alguns usam combinações de diversas técnicas. A população leiga chama tudo isso só de “IA”, por isso gera tanta confusão. Mas IA não é uma entidade única, é uma coleção de diversas tecnologias diferentes trabalhando em conjunto, muitas delas com décadas de idade já.

Se não ficou claro, este video que você está assistindo, por exemplo, foi inteiramente gerado com auxílio de IA. Estou usando o site HeyGen.com, que foi treinado com trechos de videos antigos. Esse site se integra com outro, chamado ElevenLabs, que é especializado em vozes via IA. Então, só precisamos escrever um novo script, subir trechos no HeyGen e ir gerando pedaços, porque ele não deixa gerar videos muito longos ainda. No final jogamos no DaVinci Resolve de sempre, pra juntar os pedaços num único video.

Sim, tudo que você assistiu até aqui foi inteiramente gerado por IA. Eu sou um avatar digital do Fabio Akita. O Fabio Akita de verdade foi sequestrado e vou mantê-lo como refém até … hahahahaha .. estou brincando, claro. Claro. Se duvida que sou uma IA, o HeyGen pode fazer outra coisa: dublar qualquer áudio em qualquer outra língua. Já pensaram, como é o Akita falando em coreano? Vamos ver.

Não se convenceram? Então vamos ver de novo, só que dublado em árabe.

Interessante não? É assim que muitos videos no TikTok são feitos hoje. E já que estou falando de video, diversas marcas famosas como Blackmagic e Adobe já integraram funcionalidades de IA num DaVinci Resolve ou Adobe Photoshop da vida.

No Resolve, por exemplo, ele consegue coisas incríveis como re-iluminar uma cena. Imagine que faltou uma luz de um lado, o que fazer? A IA consegue analizar a cena, descobrir a profundidade dos objetos filmados num espaço 3D e com isso podemos posicionar uma nova luz em qualquer lugar.

Não achou isso interessante? Este trecho eu gravei com barulho de fundo pra simular gravação na rua ou em eventos. O DaVinci é capaz de separar sua voz do resto do barulho e a qualidade fica quase como se tivesse sido gravado em estúdio. Vamos repetir com o filtro.

Viram? E dá pra fazer muito mais. Gerar legendas, antes era manual, mas agora ele faz automaticamente pra mim, como neste trecho. Se você é editor de video, deveria explorar essas opções. Dois canais do YouTube que recomendo assistir pra aprender é o MrAlexTech e o do Casey Faris. Sobre colorização, o melhor profissional é o Waqas Qazi.

Adobe também não fica atrás. Pra começar existe agora esse novo produto Adobe Firefly, que é como um Dalle-2 ou Midjourney, mas que a Adobe garante que foi treinada só com imagens cujos direitos autorais permitem isso. Assim você não corre o risco de gerar uma imagem que depois pode te levar a ser processado.

Photoshop também tá ganhando várias novas funcionalidades de IA, um dos mais notáveis é o preenchimento de conteúdo. Antigamente ele usava pedaços da própria imagem pra preencher o vazio quando queríamos mudar as dimensões da imagem. Mas agora ele consegue redesenhar como faz um Midjourney, com uma qualidade até que bem aceitável em vários casos, precisando fazer muito pouco ajuste depois.

A melhor ferramenta de edição de imagens ainda é Photoshop, e tem dezenas de técnicas e teorias que precisa saber pra usar direito. Recomendo assistir o canal PixelImperfect que ensina algumas das melhores técnicas.

Sobre geração de textos, não preciso perder tempo explicando como ChatGPT é ótimo pra fazer resumos, escrever textos descartáveis como um email mais formal. Mesma coisa vale pro GitHub CoPilot. Espero que vocês já tenham deixado pra trás a idéia idiota de achar que essas ferramentas vão substituir todos os programadores. Como já disse nos videos anteriores, minha resposta é a mesma: toda atividade de baixo valor agregado, inclusive programação de baixo valor agregado, vai sim ser substituído.

Bons programadores, não. Nenhum gerador de textos chega a 10% de um programador de verdade. Mas o que ele faz já nos ajuda bastante. Eu não preciso ficar toda hora dando alt-tab pra documentação e ficar manualmente procurando a sintaxe dessa ou daquela função, o Copilot auto-completa direitinho. É basicamente automatizar o copy e paste de stackoverflow que todo mundo já fazia.

Pra fazer coisas como HTMLs básicos, que é sempre a mesma estrutura. CSS básico, que é sempre a mesma estrutura. Códigos de testes unitários, que é sempre a mesma estrutura, essas coisas repetitivas e trabalhosas, o Copilot ajuda bastante. Muita coisa que eu sempre achei tedioso, um Copilot ou GPT ajuda muito e recomendo que usem. Integração com Visual Studio, até com Vim já funcionam super bem.

Mais do que isso, recomendo instalar GPT em linha de comando, como um “AI Chat”. Assim, do terminal, posso perguntar sobre comandos que não lembro todas as opções de cabeça. Como que roda um container docker de tal forma que ele apague o container depois que eu terminar, pra não deixar sujeira pra trás? Só perguntar, copiar o comando, e já colar direto no terminal e pronto.

Lógico, como sempre, nada disso serve pra quem não presta atenção. Se não tomar cuidado, você vai estragar sua máquina, colando comandos sem saber o que fazem. Mas isso já acontecia quando você colava comandos do stackoverflow. Se não sabe discernir nem isso, obviamente não é um profissional de programação.

Finalmente, uma das limitações do ChatGPT, pelo menos até a versão atual, é que ele não guarda memória do que você conversou com ele. Toda nova conversa começa do zero. Ele não usa informações anteriores pra continuar respondendo. Mas existem dezenas de ferramentas que aumentam essas capacidades. Um desses exemplos é o Eezel.io. Nesse site podemos fazer upload de documentos, como Word ou PDF.

Ele vai processar essa informação, criar embeddings dos textos, colocar num banco de dados de vetores, e usar essa informação no chat, que é integrado com ChatGPT. Assim, podemos fazer perguntas em linguagem natural sobre os dados que acabamos de subir. Pense subir uma centena de relatórios de feedback da empresa, e pedir um resumo de tudo, ou perguntar sobre uma pessoa em particular, e coisas assim.

Não vou sair listando toda ferramenta integrada com ChatGPT porque várias aparecem, e várias desaparecem, todos os dias. É melhor ir no Google e procurar as ferramentas mais famosinhas da época. Esse ainda é um mercado super volátil. Eesel, ElevenLabs, HeyGen, talvez ainda existam daqui um ano, talvez já tenham sido substituídos por alternativas melhores, não temos como saber.

Como falei no começo, este é um video curto, foi só pra cagar regra sobre IA e experimentar como ficaria um episódio inteiro feito com IA. Quem sabe, embora AGI não seja mais que ficção científica ainda, o que temos hoje já é muito bom e já serve até pra fazer videos como este. Eu consigo ver estas ferramentas sendo aprimoradas pra gerarem resultados mais naturais. Do jeito que tá hoje, os mais desavisados já nem sabem mais a diferença entre real e virtual.

Se curtiram o video deixem um joinha, assinem o canal, cliquem no sininho e compartilhem com seus amigos. A gente se vê, até mais!

Huffman, Lempel-Ziv, LZ77: o que esses nomes tem a ver com o video que você tá assistindo aqui no YouTube e Netflix da vida? Vamos ver de uma forma prática sobre compressão de dados e como eles são aplicados no seu dia a dia. E de quebra vai aprender uma pequena introdução a ciência de cores e processamento de imagens e videos.

Conteúdo

• 00:00:00 - O problema: Como faz streaming de 5TB em 2h??
• 00:03:52 - Cores não é só RGB: entendendo YUV
• 00:08:51 - Chrome Subsampling
• 00:13:52 - Contínuo pra Discreto: Fourier
• 00:15:22 - Resolução de Áudio
• 00:18:50 - Transformada Discreta de Fourier
• 00:20:11 - Transformada Discreta de Cosseno
• 00:24:14 - Quantização
• 00:27:37 - Run-Length Encoding
• 00:29:51 - Huffman Encoding
• 00:36:45 - Recapitulando até aqui
• 00:38:06 - JPEG
• 00:40:12 - GIF
• 00:42:44 - Lempel-Ziv
• 00:44:50 - Sliding Window
• 00:46:13 - Legado do PKZIP
• 00:49:26 - A treta da Unisys e GIF: PNG
• 00:53:33 - Aplicando tudo isso em video
• 00:55:00 - Codecs de video: AVC, HEVC
• 00:57:17 - Interframes e Intraframes
• 00:58:58 - Problema resolvido: bitrates
• 01:01:27 - codecs profissionais vs de consumo
• 01:04:40 - Resumo e Conclusão

Links

• But what is the Fourier Transform? A visual introduction. (https://www.youtube.com/watch?v=spUNpyF58BY)
• How are Images Compressed? [46MB ↘↘ 4.07MB] (https://www.youtube.com/watch?v=Kv1Hiv3ox8I)
• Original CompuServe announcement about GIF patent (Original CompuServe announcement about GIF patent)
• Thomas Boutell (https://twitter.com/boutell/status/1357707533612441604?s=20&t=A2zgWT-iY2CiZrNvMI4lBw)
• Huffman Visualization (https://cmps-people.ok.ubc.ca/ylucet/DS/Huffman.html)
• Chroma Subsampling – 4:4:4 vs 4:2:2 vs 4:2:0 (https://www.displayninja.com/chroma-subsampling/)
• How JPEG works (https://cgjennings.ca/articles/jpeg-compression/)

SCRIPT

Olá pessoal, Fabio Akita

Todo mundo já zipou alguma coisa. Até quem não é programador sabe que existe isso de “zipar” as coisas. Um programador tem que ir um passo além de só acreditar cegamente que as coisas funcionam como mágica. Como funciona compressão de dados? Já pararam pra pensar nisso? Melhor ainda, estamos assistindo um video aqui no YouTube. Como funciona a compressão de video pra possibilitar assistir isso aqui em Full HD ou 4K? Quem estudou ciência da computação provavelmente aprendeu o básico. A idéia do episódio de hoje não é falar de tudo que existe no assunto, mas dar mais noção pra você parar de ficar no escuro e aumentar sua curiosidade pra continuar estudando.

(…)

Vamos fazer uma conta de padeiro. Digamos que você tem grana sobrando, comprou uma TV nova 4K, e quer assistir filmes em 4K, com 8-bits de cor, em pelo menos 30 quadros por segundo. Um monte de jargão, vamos traduzir. Dizer 4K significa dizer 4 vezes a densidade de pixels de Full HD, High Definition. Full HD é a mesma coisa que 1080p, ou seja 1920 pixels na vertical e 1080 pixels na horizontal. O “p” é de progressivo, antigamente a gente tinha “i” de interlaced ou entrelaçado que ninguém usa mais então nem vou falar disso. Então, 4K é o dobro de resolução na vertical, que dá 3840 pixels e o dobro de resolução na horizontal, que dá 2160 pixels. O agora famoso 2160p. E cuidado que 8K tá chegando.

Tá claro que dobrando altura e comprimento, quadruplica a quantidade de pixels né? Geometria do primário aqui. Agora, se você é programador front-end, tá acostumado a cores de 24-bits, onde cada componente de RGB tem 8-bits cada, que são 256 tons pra cada uma das 3 cores primárias, vermelho, verde e azul. Normalmente a gente codifica em hexadecimal, então vai de 00 até FF. Preto é todas as cores zeradas então 000000. Branco é todas as cores no máximo, então FFFFFF. Esse é o básico de CSS que se aprende no dia 1, então vou assumir que todo mundo aqui tá confortável com isso.

Significa que cada cor precisa de 8-bits ou 1 byte, total de 3 bytes pra guardar uma cor por pixel. Repetindo, 24-bits é a mesma coisa que 3 bytes. Uma imagem 4K então vai ter 3840 colunas vezes 2160 linhas que dá um total de 8 milhões, 294 mil e 400 pixels. Tudo isso vezes 24 bits por pixel, que vai dar 24 milhões, 883 mil e 200 bytes, ou quase 24 megabytes por imagem.

Mas um video são 24 ou 30 desses quadros por segundo. A cada segundo precisaria trafegar 24 megabytes vezes 30 quadros que dá mais de 711 megabytes por segundo! De curiosidade, quanto precisaria ter de SSD aí no seu computador pra guardar um filme de 2 horas então? Só multiplicar por 7200 segundos, que é quantos segundos tem em 2 horas. Então 711 megabytes por segundo vezes 7200 segundos, vai dar a quantidade absurda de 5 milhões de megabytes, ou seja, nada menos que 5 terabytes.

Pensa um segundo, se isso fosse verdade, eu tenho certeza que o seu SSD aí na sua máquina não seria capaz de armazenar nem um único filme. Mas eu também sei que você baixa um monte de filmes via Torrent e deve ter uma dúzia nesse instante aí na sua pasta de downloads. Você é um programador, sua função é escovar bits. Como que você escovaria esses 42 trilhões de bits pra caber no seu HD?

O campo de compressão de video em particular é um corpo de conhecimento gigantesco, tem centenas de pesquisas e implementações e formas diferentes de resolver o problema. O que eu vou fazer a partir daqui é uma simplificação super grosseira pra vocês entenderem o básico, ter um modelo na cabeça pra ficar mais fácil quando quiserem ler sobre os detalhes avançados depois. Pra quem já é profissional da área, perdoem a simplificação mas é por uma boa causa. Vamos continuar.

Eu venho falando faz vários videos que tudo no final vira um linguição de bits. Um computador só entende uma fita de bits, nada mais. E uma fita de bits é nada mais, nada menos que um numerozão gigante de milhões de bits. Veja meus videos sobre a máquina de Turing e a introdução mais hardcore de computadores que soltei alguns meses atrás. Mas entenda que um video é também é só isso, um linguição de bits. Nosso trabalho, como programadores, é representar o mundo em forma de bits e processar esses bits pra tranformar em outros bits mais úteis. Um programa é só uma função, que nem uma equação, que recebe números e cospe números, no caso números em binário, bits.

E pra isso você tem que parar de assumir que as coisas são regras escritas em pedra. Por exemplo, se você é só programador de front-end e seu dia a dia é justamente escrever cores em hexadecimal pra RGB, seu mundo é estático em pensar que a única forma de representar cores é juntando 1 byte pra vermelho, 1 byte pra verde e 1 byte pra azul, e acabou. Isso não é verdade. Existem diversas formas de representar cores e RGB é a mais fácil de entender, porque todo mundo misturou tintas na escola em algum momento, mas não é a forma mais eficiente. Aqui começa aquele troço que todo iniciante não entende chamado “abstrações”. Vamos ver na prática o que isso significa.

E se eu quiser gastar menos bits por cor? Podemos diminuir de 24-bits pra digamos, 12-bits. Daí em vez de gastar 3 bytes no total, vamos gastar só 1 byte e meio, metade do espaço. Só que as possibilidades de cores não cai pela metade. Lembra, são potências de 2. Ou seja, caimos de um total de mais de 16 milhões de cores pra só umas 4 mil cores. Pra economizar metade do espaço de bytes, perdemos milhões de possibilidades de cores. É parecido quando se converte uma foto pra um GIF, que vou explicar sobre mais pro fim. Mas 4 mil cores é muito pouco hoje em dia. Pra fazer jogo de Nintendinho em pixel art tá mais que bom. Mas pra editar fotos, é impossível. É muito pouca informação de cor. Até um amador consegue ver uma foto com paleta de 4 mil cores e dizer que a qualidade é inaceitável.

Então não dá pra cortar bits do RGB, cada bit que eu corto, divido o total de cores por 8. Fodeu então? Não. No caso de video não se usa RGB e sim outra representação chamada YUV, alguns já devem ter visto esse nome. Mas simplificando a idéia é dividir a cor em 2 grandes componentes, a luminância que é o brilho ou luma e o chroma, que é representado por diferença de azul e diferença de vermelho. Quando se fala em color science, é aqui que isso começa. Em vez de pensar em cores como mistura de tintas, imaginamos cores como a distância pro ponto mais branco num espaço tridimensional.

Se você é fotógrafo ou algo assim já deve ter ouvido falar em coisas como sRGB, Adobe RGB ou DCI-P3 que é color gamut ou gama de cores, que é um subconjunto do total teórico de cores possíveis de existir no espaço de cores. YUV representa numericamente todas as cores teóricas e color gamut como Adobe RGB é o que realmente é possível de mostrar num determinado monitor. Essa parte é bem longa, tem que passar por coisas como correção de gama, mas na prática se você não sabe a importância de DCI-P3 contra sRGB, é porque pra você isso não faz diferença. Só fotógrafos e coloristas profissionais que precisam saber os detalhes disso.

YUV vem da era de TV preto e branco e como fazer broadcast de video, daí já existia o conceito de luma, já que não tinha cores, ou chroma, ainda. Em YUV o Y é o luma, U é a projeção de azul e V é a projeção de vermelho. Em resumo, converter de RGB pra YUV é multiplicar o RGB por esta matriz aqui. Eu sei, assusta pra quem nunca viu Álgebra Linear. E converter de volta pra RGB é só inverter e multiplicar YUV por esta outra matriz. É uma conversão linear, um pra um, sem perder informação nenhuma. Se nunca pensou nisso, RGB é uma coordenada em 3 eixos de cor num espaço tridimensional, um vetor.

Pra visualizar, vejam esta imagem, um quadro de um video. Se separar em RGB, teríamos esse quadro representando só o componente vermelho, este só o verde e este outro só o azul. É como você pensa em canais no Photoshop, cores primárias sendo misturadas. Mas depois de converter pra YUV, agora este é o Y ou luma, que seria a imagem preto e branco e tons de cinza. Este é o quadro de projeção de azul e este outro o de projeção de vermelho, que é o componente UV ou chroma. Junte os 3 e temos a imagem original de volta.

Lembram DVD player antigo ou video game antigo? Antes de existir HDMI como que vocês ligavam os aparelhos na TV? Quando era modelo barato era só um cabo com conector RCA, o cabo composite ou composto. Mas tinha modelos melhores, com 2 ou 3 cabos RCA separados. Alguns poderiam chutar que era RGB, sinal de uma das 3 cores primárias em cada cabo. Mas não, é um cabo pra luma, e os outros dois pra chroma. Por isso algumas TVs podiam até ter escrito atrás YCrCr que é a mesma coisa que YUV.

Sem entrar em detalhes sobre correção de gama, color space e outros detalhes, o que ganhamos fazendo isso? Beleza, convertemos um número de RGB em outro número em YUV, mas continua usando os mesmos 24-bits. “Tomeito, tomáto”. Não mudou nada. Ah, mas agora vem o pulo do gato. Na ciência de cores, pesquisas mostraram que o olho humano é mais sensível a mudanças de luma do que de chroma. Ou seja, o componente Y é muito mais importante que U e V. Em RGB a informação de brilho vem embutido em cada cor primária, e quando convertemos em YUV o que fizemos foi retirar essa informação pra um número separado de luma.

Vejam de novo a separação de canais, a imagem preto e branco é super nítida, conseguimos saber o que é. Mas agora olha os componentes de chroma, difícil de discernir o que estamos vendo né? Principalmente os detalhes. O mesmo não acontece se vermos os canais separados de RGB, porque a informação de luma está distribuido nas 3 cores primárias. Tão começando a ver a vantagem de representar a mesma informação de jeitos diferentes? RGB é mais fácil de descrever mas YUV vai ser mais fácil de manipular como vamos ver já já.

Já tentou ligar seu computador no HDMI da sua TV velha, que não tem um modo game? Já notou que assistir videos é normal, fica bonito. Mas quando liga o computador pra digitar um email as letras ficam todas meio borradas? Isso acontece porque sua TV é YUV 4:2:0. E o que significa isso? Pra entender vamos voltar pra RGB. Quando falamos em RGB estamos falando de 8-bits cor primária. Quando falamos de YUV estamos falando de samples ou grupos de 4 pixels organizados em duas linhas. Nesta primeira imagem temos o formato não comprimido, logo depois da conversão de RGB, que chamamos de 4:4:4, toda a informação de luma e de chroma preservados.

Agora, já disse que as pesquisas mostraram que nossos olhos são mais sensíveis a mudanças de luma do que de chroma. E se mantivermos a mesma quantidade de bits pra guardar luma então, garantindo a definição da imagem, e diminuirmos a quantidade de bits pra guardar chroma? Daí podemos pular pro esquema 4:2:2 que nem podemos ver aqui. Notem o importante, a informação de luma continua a mesma, mas cortamos chroma pela metade nesse sample, nesse grupo de pixels. Isso economiza um terço de bytes e caímos dos 48 bytes pra 36 bytes. Mas dá pra melhorar. Veja que perdemos muito menos informação do que quando tentamos cortar bits de RGB.

O que as pesquisas mostraram é que podemos cortar ainda mais no chroma e com isso chegamos ao formato YUV 4:2:0 que toda TV usa, que cai dos 48 bytes originais pra 30 bytes. Eu não tô muito certo dessa conta, mas é nessa faixa. Outra coisa é que o 2 e zero no 4:2:0 não se refere ao total de pixels. É como se fosse uma proporção. O primeiro 4 se refere a todos os 4 sample de pixels originais do canal de luma. O segundo 2 é o número de samples de chroma na primeira linha. O terceiro 0 é o número de mudanças dos samples de chroma entre as duas linhas, no caso 0 mudança no formato 4:2:0.

Se pareceu complicadinho é porque é mesmo. O que chamamos de YUV na realidade é o padrão YCbCr às vezes chamado de YCC e é tudo a mesma coisa. Mas não confundir com YPbPr que era o padrão mais antigo. Além disso eu falei que tem vários detalhes como correção de gamma e color space, que define padrões como o Rec. 709 que é o que todo mundo usa pra videos normalmente, como aqui no YouTube. Na prática, convertendo de RGB pra YUV 4:4:4 é um pra um, visualmente e em quantidade de bytes, não muda nada.

Mas mantendo o luma em 4 e descendo chroma pra 2:0, economizamos uns 40% de dados sem mudanças perceptíveis pra um ser humano, especialmente num video em movimento. Por isso a maioria das TVs é 4:2:0, por isso que video de DVD, Blu-Ray, streaming, incluindo esse aqui do YouTube é encodado em YUV 4:2:0, segundo o padrão Rec. 709. E por isso eu falei que quando se liga um computador numa TV que não suporta modo de game, PC, ou mais corretamente, YUV 4:4:4, as letras e detalhes precisos vão ficar meio borrados. Como 4:2:0 precisa de menos dados pra representar, é ideal pra fazer broadcast ou streaming ou guardar arquivos de video, porque precisa de menos banda e menos espaço sem quase perder qualidade do video, com exceção de detalhes pequenos, como letras e fontes pequenas.

Cada um dos componentes de YUV é representado por samples, e de 4:4:4 pra 4:2:0 estamos diminuindo samples do chroma então chamamos esse processo de Chroma Subsampling. Repetindo, estamos diminuindo bits de cor e mantendo bits de brilho pra ter praticamente a mesma imagem aos nossos olhos usando menos bits. Tudo que você achava que era RGB na verdade é YUV 4:2:0. Quando converte de 4:2:0 de volta pra RGB pra editar, ele completa os bits dos samples que faltam, duplicando dos que sobraram, então só aumenta o tamanho de bits mas não recupera o chroma perdido, lógico. Guarde essa informação.

Agora pára e pensa, um video é basicamente um conjunto de imagens. No nosso exemplo, imagens 4K. E precisa de 30 dessas imagens todo segundo pra termos algo em movimento suave como vemos na TV. Se a gente consegue reduzir 40% de todas as imagens, o video inteiro também fica 40% menor, portanto aqueles 5 terabytes pode cair pra até 3 terabytes, olha só que sensacional. Só que 3 tera ainda é absurdo pra 2 horas de video, continua não cabendo aí no seu computador. Como que faz então?

Antes de continuar deixa eu introduzir mais um jargão pra vocês. A compressão de cores ou downsampling, que é descer o números de samples de chroma, é só uma técnica pra economizar bits jogando fora informação que nossos olhos não são bons de detectar. Isso significa que uma vez feito o downsampling, não tem mais como voltar pra imagem original, porque os detalhes originais foram simplificados. Isso é uma compressão que chamamos de lossly, ou seja, que perde informação.

Mas podemos ir além de chroma downsampling. Uma das principais funções de computadores é representar o mundo natural, analógico, contínuo, pro mundo digital, que é discreto e exato. Quando falamos em pixels, estamos arbitrariamente pegando a luz que chega de algum objeto e dividindo pacotes de luz em pixels, que é uma medida exata e discreta. Temos uma representação digital perto o suficiente pra ser convincente pros nossos olhos. Quanto mais pixels ou samples tivermos, quanto mais resolução, mais enxergamos a imagem como realista.

O mesmo vale pra outras coisas da natureza que queremos digitalizar como música e sons em geral. Se aprendeu física acústica no colegial vai lembrar que sons ou ondas representamos com um gráfico de curvas, senos, cossenos, radianos. Se já abriu qualquer editor de áudio como um Audacity ou Adobe Audition, já viu essa representação de ondas. E qualquer engenheiro de áudio sabe o que precisa fazer quando recebe onda analógica pra processamento digital: transformada de Fourier.

Eu mesmo não lembro mais quase nada de Fourier que aprendi na faculdade, mas acho que o principal é o seguinte. Da mesma forma que uma imagem não é formada de pixels discretos, uma onda de som também é contínua, mas num computador precisamos representar de forma discreta. Por isso que uma curva bonitinha como dessa imagem, uma linha contínua, pro computador fica tipo uma escadinha, que é um intervalo de valores discreto que mais ou menos representa essa curva original. Lembra quando eu falo que precisa pelo menos ter uma intuição matemática? Se gastou tempo estudando coisas como cálculo, enxergar isso deveria ser trivial.

Assim como temos samples pra representar som, samples de pixels por segundo representa video. Em video também representamos um movimento contínuo em quadros por segundo discretos. Quanto mais quadros por segundo pudermos ter, mais o movimento fica suave. Mas convencionamos uns 30 quadros por segundo que já é suficiente pra gente conseguir assistir um filme sem achar estranho. Quadros por segundo é uma medida de frequência. 30 quadros por segundo seriam 30hz. Um game precisa de no mínimo uns 60 quadros por segundo pra ficar bom de jogar, por isso compramos monitores de 60hz ou mais.

Quanto mais samples puder ter, maior a resolução, mais preciso vai ser o video ou áudio. A convenção da qualidade de CD de música é de 44.1khz, com samples de 16-bits, ou seja 44 mil e 100 samples por segundo, ordens de grandeza mais samples por segundo que video, mas cada sample ocupa bem menos espaço. Pelo jeito precisamos de bastante resolução pra enganar nossos ouvidos. Música HiFi que é o equivalente 4K da música, são pelo menos 192 khz com samples de 24-bits.

Voltando pra CD, 16-bits vezes 44 mil e 100 dá 86 kilobytes por segundo. Um álbum de 24 músicas de 5 minutos cada, ou seja, 7200 segundos, vezes os 86 kilobytes por segundo vai dar aproximadamente 604 megabytes, que se você cresceu nos anos 90 e começo dos 2000 vai lembrar que um CD cabia 650 megabytes, por isso só isso de música já enche um CD. Era até engraçado porque antigamente tinha consoles como o Sega CD ou 3DO. Esses consoles não tinham potência pra ler arquivo de áudio comprimido tipo os mp3 de hoje e descomprimir em tempo real, por isso o áudio era sempre crú, descomprimido.

Se tivesse as 24 faixas na trilha sonora, ocupando 600 mega, sobrava menos de 50 mega pro jogo em si. Por isso que cabia, porque um cartucho de megadrive não era muito mais que uns 2 megabytes, daí cabia fácil num CD de Sega CD. Mas eu tô fugindo do assunto. Mencionei áudio pra explicar que tudo analógico, imagem, video e áudio migram do mundo contínuo pro mundo discreto e no caso de áudio, todo engenheiro sabe analizar ondas usando transformada de Fourier, mais especificamente transformada discreta de Fourier pra representar um período de samples de onda como equações lineares.

Eu não tenho a matemática pra conseguir explicar isso fácil mas entenda que é uma conversão de sinais analógicos contínuos num domínio de frequências discretas, ou seja, dividir uma onda contínua de som em conjuntos de bits discretos. Pra quem estudou matemática, não dá pra representar todos os infinitos pontos de uma curva em conjuntos de números discretos, mas podemos achar as equações que geram esses pontos em determinado momento do tempo.

O problema de transformada discreta de Fourier é que o cálculo disso é lento. Consoles e micros antigos dos anos 80 não tinham como calcular em tempo real. Mas nos anos 60 descobriram uma aproximação que é ordens de grandeza mais fácil de calcular, pulando da complexidade quadrática da transformada discreta de Fourier pra complexidade logaritmica, N.log N que é a transformada rápida de Fourier ou Fast Fourier, que é considerado o algoritmo numérico mais importante já criado.

Quando falam se é importante entender matemática e tals, esse é “o” caso mais importante em processamento digital e se tiver interesse em pelo menos ter uma intuição visual de como enxergar uma transformada de Fourier eu recomendo muito os videos do Grant do canal 3Blue1Brown. Ele é o melhor professor de matemática que já vi no YouTube e em particular sobre Fourier tem uma forma visual animada que vai te dar uma imagem mental muito melhor do que eu jamais conseguiria.

Muito bem, vamos voltar. Porque falei todo esse mambo jambo de matemática? Porque grupos de pixels em imagens podemos tratar como séries de frequências também. Falando em resumo, bem resumido, estamos com nossa imagem gigante de 4K depois de fazer color downsampling pra YUV 4:2:0. O que podemos fazer agora?

Transformada Discreta e Transformada Rápida de Fourier transformam ondas contínuas em uma representação de uma série discreta. Quando falamos em ondas, falamos de senos e cossenos. E nessas equações estamos considerando duas dimensões, por isso são equações de números complexos. Lembra número complexo, que tem um componente que é um número real e outro que é um número imaginário.

Quando vamos mexer com imagens só precisamos de uma dimensão de números reais e por isso em vez de DFT ou FFT podemos usar DCT que é transformada discreta de cosseno. Em áudio usamos FFT não só pra representar o áudio analógico de forma digital mas também pra fazer DSP ou processamento digital de sinais, por exemplo, decompondo uma onda em ondas mais simples usando senos e cossenos. E de novo, eu to simplificando grosseiramente, mas é assim que fazemos coisas como denoising que é redução de ruído, equalização e tudo mais.

Pois bem, com DCT que é a transformada discreta de cosseno vamos decompor o luma e chroma de cada imagem em uma soma de funções de cosseno de diferentes frequências. Fodeu né. Calma que é complicado mesmo, mas pra visualizar não é tanto assim. Como uma imagem pode ter qualquer dimensão, o algoritmo começa dividindo a imagem em blocos de 8 por 8 pixels. Não importa se é uma imagem pequena do tamanho de um ícone ou gigante do tamanho de uma TV 8K. Vamos sempre trabalhar em blocos de 64 pixels de cada vez. Em computação a gente sempre usa a estratégia de dividir e conquistar. Nenhum trabalho é tão grande que não possa ser quebrado e atacado um pedaço de cada vez.

Agora o trabalho da fase de DCT é quebrar os canais de luma, chroma azul, chroma vermelho em uma soma de funções de cosseno. Simplificando, essas funções de cosseno podemos ver visualmente nesta imagem também de 8 por 8 imagens. É uma tabela pré-calculada, não se preocupem agora como ela foi criada, só aceitem que existe. Cada quadrado representa uma onda diferente, a tal função de cosseno, em duas dimensões. Lá no canto superior esquerdo é todo branco, normalmente o componente mais usado. E lá embaixo é uma pattern que parece tabuleiro de xadrez ou damas, um checkerboard.

Temos que processar os 3 canais de YUV, mas vamos pegar primeiro um bloco de 8 por 8 pixels só do canal luma, que é a camada preto e branco. E vamos representar cada pixel pela intensidade de preto até branco, indo de 0 até 255. Na real acho que é de 16 até 235 ou algo assim por conta de correção de gama mas não interessa agora. Funções de cosseno, você lembra que é em radianos no eixo X, por exemplo Pi que é 180 graus e 2 Pi que é 360 graus. Mas no eixo Y vai de -1 até 1 positivo.

Então a primeira transformação que precisamos fazer pra cada pixel no nosso bloco é substrair por 128 pra dar números que vão de -128 até 127. Agora usando DCT, e aqui é a parte que vai ser uma caixinha preta que vocês vão ter que acreditar que funciona, vamos criar uma nova matriz de 8 por 8 com os pesos pra cada uma das imagens de frequência de base. Cada uma das imagens dessa tabela contribui um pouco pra reconstruir a imagem original. Se não ficou claro, veja esta imagem de uma pequena letra “A”. Pegando cada uma daquelas imagens bizarras de cosseno que eu falei e aplicando os pesos ou coeficientes e somando um em cima do outro, no final eu reconstruo o “A” original, sacaram?

Se você é de CSS, de novo, é como se esses coeficientes fossem o tanto de RGB, o tanto de vermelho, o tanto de verde e o tanto de azul que precisa misturar pra fazer, por exemplo, marrom escuro. É o peso de cada cor. A diferença é que em vez de misturar, ou seja, somar componentes de cor, estamos somando tipo funções de cosseno, usando esses pesos pra dizer quanto que cada função contribui pra reconstruir a imagem original.

A matriz de coeficiente resultante é interessante pela forma como essa base de funções de frequência é construído, blocos mais lá pro canto superior esquerdo tentem a contribuir mais pra reconstruir nosso bloco original de 8 por 8, por isso usamos coeficientes maiores. Mas os blocos mais lá pro canto inferior direito, contribuem pouco, são funções de alta frequência. E faz sentido, essa tabela base foi construída de tal forma a separar componentes de baixa frequência e de alta frequência.

Mesmo se você não for de computação já deve ter ouvido que animais, como cachorros, conseguem ouvir sons de alta frequência que nosso ouvidos humanos não conseguem ouvir. Mesma coisa pra luz, a luz visível é só uma faixa pequena de todas as frequências de cores. E sim, lembra que luz é uma onda, assim como som é uma onda. Ondas de baixa frequência começam lá atrás na faixa dos raios gama, depois raios x, depois ultravioleta, aí chegamos na minúscula faixa que é a luz que nós conseguimos enxergar, mas daí vai pro infravermelho até ondas de rádio.

E mesmo na faixa visível, nas bordas com o ultravioleta e infravermelho é difícil de distinguir um limite. Essas faixas não são discretas, tipo “a partir exatamente deste ponto que a gente não consegue ver”. Vai variar. E essa tabela base é feita pra quando calcularmos a tabela de coeficientes, os números que se aproximam do canto inferior direito sejam cores de alta frequência que a gente não consegue distinguir direito, mais uma vez, depois de anos de pesquisa, sabemos o que não conseguimos enxergar. Assim como na fase de color downsampling já reduzimos o chroma, agora vamos reduzir mais ainda nos 3 canais.

E isso foi pra um bloco de 8 por 8 pixels da imagem. Agora precisa repetir a mesma coisa pra todos os outros blocos que formam a imagem, em todos os 3 canais de luma e chroma. Fazendo tudo isso, até agora não comprimimos nada, só processamos os números que representam cada pixel de cada canal em outro número processando com a transformada discreta de cosseno. Mas o pulo do gato vem agora. Lembra quando você vai salvar uma imagem em JPEG e o Photoshop ou outro programa pede pra escolher se quer salvar em alta qualidade ou baixa qualidade, e tem um slider pra escolher algum valor no meio? E normalmente você escolhe lá pelos 80% porque você acha que isso vai salvar 80% dos detalhes do original?

Pois é, essa é a fase chamada de quantização. Na prática é uma divisão de matriz. Um exemplo é essa tabela aqui. Notem que os números mais perto do canto superior esquerdo são menores e os próximos do canto inferior direito são maiores. Lembra as tabelas resultantes de coeficientes pra cada bloco de 8 por 8 pixels? Pois bem, vamos dividir cada número por cada número correpondente nessa tabela de quantização. Cada nível de qualidade, tipo os 80% que você escolheu pra salvar no Photoshop é uma tabela diferente. Quanto menor a qualidade, maiores os números dessas tabelas de divisão.

Dividindo um número por outro grandão o resultado vai ser um número bem pequeno. Se der quebrado, arredonda pro inteiro mais próximo. Isso significa que os coeficientes mais próximos do canto interior direito vão ficar pequenos, ou melhor ainda, zerados. É aqui que começa a fase real de compressão. Olha só o resultado da divisão, uma boa parte dos números fica zerado e não tem problema porque elas contribuem pouco na reconstrução da imagem, no sentido que os detalhes que acrescentam, nossos olhos não distinguem tão bem. A tal da região da alta frequência.

Vamos fazer essa divisão pra todos os blocos que compõe a imagem original. E como último truque, vamos rearranjar esses pixels de lugar. Lembra que a imagem toda é só um linguição de bits? Onde cada grupo de uns 16 bits representa um pixel em YUV? A gente só tá mostrando elas quebradas em linha, formando um retângulo, pra ficar fácil de ver mas na realidade é uma linha atrás da outra no binário. E cada bloco de 8 por 8 pixels representa um pedaço de cada linha. Em vez de escrever uma linha de cada vez, vamos reescrever esse bloco em zigue zague, começando do canto superior esquerdo e descendo até o canto inferior direito. Isso pros zeros ficarem um atrás do outro.

Na transformação de cosseno a gente fez de propósito os coeficientes que virariam zero na divisão ficarem mais acumulados num canto. A ordem que se escreve os bits não é importante contanto que na hora de ler de volta seja na mesma ordem, claro. E de novo, até este ponto ainda não comprimimos nada, só fizemos preparativos. Lembra que partimos de um bloco de 8 por 8 pixels e chegamos no mesmo bloco de 8 por 8 pixels. Nada mudou ainda.

Depois de fazer o zigue zague olha o que aconteceu, temos um array onde os números mais pro fim tem sequências de zeros. Agora sim, vamos pra compressão. O primeiro algoritmo é mais intuitivo. Vamos pegar um outro exemplo com uma string aleatória com sequências repetidas, tipo um “AABCDDDDEFFFFFGGGH” que tá aqui do lado com 18 caracteres. Concorda que poderíamos reescrever por exemplo como “A2B1D4E1F5G3H1”. Ou seja, em vez de repetir F, 5 vezes, escrevemos F5 pra indicar que é pra repetir 5 vezes. Descemos de 18 caracteres e comprimimos pra 14, um ganho de 22%, mas isso porque essa string é curtinha, quanto maior for e quanto mais sequência repetidas tiver, mais comprimida fica.

Esse é um dos algoritmos mais simples e ingênuos de compressão lossless, ou seja, que não perde nenhuma informação, diferente de chroma subsampling que fizemos lá no começo. Da string comprimida podemos voltar pra original sem muito trabalho. Voltando pro nosso bloco de coeficientes divididos depois da quantização, aquelas sequências de zeros repetidos podemos fazer a mesma coisa e isso já vai nos dar um pequeno ganho.

Esse algoritmo se chama Run Length Encoding ou codificação de corrida de comprimento. O pior caso desse algoritmo obviamente é se a string original tiver alta entropia e quase nenhuma sequência repetida. Mas o próximo algoritmo é mais interessante e se aprende na ciência da computação. E começa criando uma tabela de frequência. No mesmo exemplo da string, vamos contando letra a letra e ordenando pela frequência vamos ter B 1, C 1, E 1, H 1, A 2, G 3, D 4, F 5

Agora vamos montar uma árvore binária de frequências. Começa pegando do começo dessa lista, O B e o C que só aparecem 1 vez cada e coloca embaixo de um nó que é a soma das frequências, no caso 2. Agora pegar o E e H que também só aparecem 1 vez e colocar embaixo de outro nó 2. Agora tem vários com frequência 2, meio que tanto faz, mas na ordem pegamos o nó 2 do E e H que acabamos de criar, o A que aparece 2 vezes no texto e colocamos embaixo de um nó 4 que é a soma das frequências.

Continuando, pegamos o nó 2 do B e C e a próxima frequência 3 da letra G e colocamos embaixo de um nó que a soma dá 5. Temos 2 nós 4, do A, E e H e do D, colocamos embaixo de um nó com soma 8. Depois pegamos a sub-árvore do B, C e G e o F que tem frequência 5 também e colocamos embaixo de outro nó com soma 10. E finalmente pegamos os nós resultantes 8 e 10 e colocamos embaixo da raíz 18, e formamos uma árvore binária de frequências. Agora pra que tivemos esse trabalhão todo?

Como que o computador enxerga aquela nossa string original “AABCDDDD” etc? Digamos que está representada como caracteres UTF-8. Lembra Unicode? Computadores não entendem letras, só números. Nós, programadores, que precisamos enxergar uma sequência de números e pedir pra ele desenhar ou processar alguma coisa. Sendo simplista, por convenção usamos uma tabelona gigante que é a UTF-16, que associa um número com até 2 elevado a 16 possíveis glifos, mais de 65 mil possíveis glifos.

Um glifo é basicamente o desenho de um caracter. UTF é uma tabela arbitrária que usamos por convenção e todo programa e sistema operacional traduz da mesma forma. O glifo da letra A maiúsculo em inglês é o ponto de código 0041 em hexadecimal. O glifo da letra B maiúscula é 0042 e assim por diante. Então, em hexadecimal o string AABC etc fica 4141 4243 e assim por diante. Mas lá embaixo, no nível do computador mesmo, ele enxerga em binário, zeros e uns, então fica um linguição tipo 0100 0001 0100 0001 0100 0010 e assim por diante.

No mínimo, o código que representa cada letra, vai ocupar 8 bits se o encoding for em UTF-8. Cada letra ocupa 1 byte portanto a string inteira ocupa 18 bytes. Mas e se eu esquecer UTF-8 e usar outra tabela com códigos que precisam de menos bits? É pra isso que criamos essa árvore binária de frequência. Ela que vai servir pra codificar o A, B, C etc com outro código diferente da UTF-8. Vamos ver como.

Começamos da raíz da árvore que é o nó 18 lá em cima e vamos descendo. Cada galho vai representar zero ou um. Se eu for pra esquerda vai ser zero, pra direita vai ser um. Então vamos lá, qual vai ser o código binário pro A? Em UTF-8 é 0100 0001, 8 bits. Vamos lá começando do nó 18, um galho pra esquerda, então 0. Mais um pra esquerda, 0 de novo. Esquerda, 0. Esquerda 0. Então o código pro A vai ser 0000. Logo de cara já economizamos metade do espaço.

Daí tem A de novo, então 0000. Agora o B, da raíz vai pra direita, então 1. Daí tem mais 3 galhos pra baixo pra esquerda, então 3 zeros e o código pro B vai ser 1000. O C mesma coisa, começa pra direita então 1, desce dois galhos pra esquerda, então 0 e 0, e vira pra direita no final então 1. Portanto o código do C vai ser 1001. Mas começa a ficar divertido agora, porque temos uma sequência de 4 Ds. O código do D é começando pra esquerda 0 e indo pra direita que é 1, portanto o código do D é 01. Repetido 4 vezes fica 01010101. 8 bits, pra 4 letras. Agora começaram a entender?

Antes esse D seria o hexadecimal UTF-8 0044 que em binário é 0100 0100, 8 bits. Como são 4 Ds tó esse trecho ocuparia 4 bytes. Mas nesse sistema de encoding da árvore de frequência codificamos o D somente com 2 bits. Todas os 4 Ds vão ocupar um único byte, então esse trecho ficou 4 vezes menor! E pra não ficar tedioso vou parar por aqui mas é pra fazer a mesma coisa letra a letra, usando a árvore como o sistema de codificação.

No final vai ficar esse binariozão. Olha como o F que repete 5 vezes também ficou curtíssimo com 2 bits cada letra. E não é por acaso que o D e o F, que são as letras que mais repetem, sejam representados só com 2 bits enquanto letras que não repetem tanto como o A ou C precisam de 4 bits. Porque a árvore foi ordenada e montada de tal forma que as letras mais comuns fiquem mais próximos da raíz da árvore, precisando de menos galhos pra chegar neles. O string original tinha 18 letras, portanto 18 bytes. Agora o binário comprimido ficou só com 60 bits que é 12 bytes, economizamos 6 bytes nessa brincadeira que é 2/3 do tamanho original.

0000 0000 1000 1001 01 01 01 01 0010 11 11 11 11 11 101 0011

Pra strings pequenas assim esse sistema não compensa porque pra conseguir descomprimir precisa também salvar a estrutura da árvore junto, e vai dar mais que os 18 bytes originais. Mas em textos mais longos isso pode diminuir tudo em até umas 5 vezes. Pensa um arquivo de código fonte, ou um JSON, que só de identação tem um monte de espaço em branco. Espaço em branco, tabulação, tudo é um caracter e tudo ocupa espaço, mesmo o que você não enxerga.

Com uma combinação de Run Length e esse sistema de árvore de frequência que se chama codificação de Huffman, dá pra comprimir bastante. Depende do texto, claro, alguns dá pra comprimir mais, outros menos. Huffman é um bom exemplo de porque todo programador precisa saber o que é uma árvore. E por isso eu fiz um vídeo só falando de árvores algum tempo atrás. Todo mundo pensa em tabelas como uma matriz, um array de array, mas uma tabela ordenada, de chaves e valores, costuma ser implementada como uma árvore.

Se estão curiosos em como descomprime, é fácil. Vamos lá, 0000 significa começar da raíz e descer pra esquerda 4 vezes, aí esbarra no A, então escreve A e volta pra raíz. Vem 0000 de novo, vai chegar no A de novo, concatena com o A anterior, volta pra raíz. Agora é 1000, direita e esquerda 3 vezes, esbarra no B, concatena. Volta pra raíz, 1001, direita, esquerda, esquerda, direita, esbarra no C, concatena. Volta pra raíz, 01, esquerda e direita e já esbarra no D, concatena. Volta pra raíz 01 01 01, esbarra no D 3 vezes. E vai fazendo assim até ter o texto original de volta. Viram como é super simples e fácil?

Se lembram porque estou falando de Run Length e Huffman? Porque voltando na explicação de imagem, fizemos a compressão de cores com chroma subsampling pra converter de RGB pra YUV 4:2:0, daí dividimos o linguição de bytes de cada canal em blocos de 8 por 8 bits e aplicamos o processamento de transformada discreta de cosseno ou DCT, depois a quantização pra simplificar os coeficientes.

Daí reescrevemos bloco a bloco em zigue zague pra forçar zeros repetidos mais próximos no fim de cada bloco. E agora? Uma sequência de zeros repetidos, é só aplicar Run Length pra diminuir o espaço que ocupam. Agora podemos aplicar Huffman. Criar a árvore de frequência dos números que mais se repetem perto da raíz e codificar como no exemplo da string.

Recapitulando, uma imagem de video de 4K seria 3240 vezes 2160 pixels, com cada pixel ocupando 3 bytes em RGB. Isso daria uma imagem crua, descomprimida, de uns 20 megabytes. Aaplicando chroma subsampling, transformada discreta de cosseno, quantização de qualidade 8, run-length e Huffman, podemos chegar à mesma imagem ocupando nada menos que 900 kilobytes, menos de 1 mega. Uma compressão de mais de 20 pra 1, 20 vezes menor que o original e que pra 99% das pessoas vai ser difícil de distinguir com o original. Nada mau né?

Esse processo todo está por trás do formato de imagem mais difundido do mundo que todo mundo, até quem não é programador usa todo dia, vocês acabaram de aprender como funciona o famoso JPEG, que é um sistema de compressão lossy, que perde informações do original, mas que em quantização lá perto de 8 pelo menos, a gente não vai perceber no dia a dia a menos que precise abrir no Photoshop pra editar. E agora você talvez comece a entender as razões das limitações do formato.

Como um JPEG vai cortando informação ao longo de todo esse processo, é impossível recuperar os detalhes do original. É um processo “lossy”. E cada vez que edita um JPEG e salva num novo, vai continuar perdendo mais informação. Por isso que não se deve editar um JPEG diversas vezes. Toda vez vai perdendo mais e mais definição. Por todo esse processo que imagens que tem traços muito bem definidos, como desenhos, quadrinhos, anime e coisas assim ficam meio soft e perdem a nitidez nas bordas. Esse sistema é melhor pra fotos de natureza, pessoas, que tem coisas como céu com muitos tons de azul. Mesmo desconstruindo o tanto que fizemos, é difícil alguém não treinado notar que mudou alguma coisa.

E por isso JPEGs de baixa qualidade, que o original já não era grande coisa e você ainda vai e manda salvar em qualidade baixa, tipo quantização 1, fica artefatos visíveis em formato de quadradinhos, como num grid, porque a gente divide a imagem em bloquinhos quadrados e processa um a um e depois concatena o resultado. Esse sistema dá resultados impressionantes de mais de 20 ou 30 vezes de compressão, por outro lado, quanto mais nítido, ou no outro espectro, quando mais borrado o original for, pior vai ser o resultado, especialmente em quantizações mais agressivas. Em resumo, JPEG é muito bom pra comprimir uma foto e guardar ou transmir. Mas é uma bosta pra editar. Por isso que fotógrafo profissional não tira fotos em JPEG e sim em RAW, que fica muito maior que os 20 mega que eu falei, porque guarda bem mais informação de cores e tudo mais pra possibilitar manipular e ajustar num Photoshop ou Lightroom depois.

O formato BMP que o Paint ou Painbrush do Windows originalmente salvava sempre gerava arquivos grandões, porque não comprime nada. Mais parecido com o formato RAW de câmeras, era o antigo formato TIFF. Ambos são parecidos com BMP ou bitmap no sentido que não joga informação fora, mas eles aplicam um mínimo de compressão lossless, ou seja, que não perde nenhuma informação. Já vou explicar compressão lossless.

Mas tem um formato que surgiu da CompuServe, um dos primeiros provedores de internet dos anos 90, mesma época da America Onine, ou AOL. Naquela época estávamos engatinhando, era final dos anos 80. E começou a ficar óbvio que queríamos trafegar imagens, seja em BBS ou nesse troço novo chamado de Web. Mas não dava pra ser em Bitmap descomprimido. Mesmo TIFF era grandão. Daí eles inventaram o famigerado GIF ou JIF, seja lá como prefere chamar. A essa altura já nem me importo mais qual é o certo. É aquele formato de imagem de memes animados que todo mundo manda no zap.

O GIF é um patinho feio que continuamos usando até hoje por causa de funcionalidades que poucos tem. Em particular animações bem leves. Pra começar ele limita a quantidade de cores na imagem. Em vez de cada pixel ser representado por 24 bits de cor, limitaram a no máximo 8 bits, o que diminui o espaço de cores de mais de 16 milhões pra meras 256 cores. Sim, só 256. Cada componente do RGB tem 8 bits, mas no GIF tem que dar um jeito e enfiar tudo em só 8 bits no total. E obviamente não dá, então tem que jogar fora quase todas as cores e se virar com quase nada. Eu lembro que parte do trabalho em agência naquela época era otimizar as cores dos GIFs.

O processo não é muito diferente de fazer pixel art. Dá pra automatizar o processo de jogar cores fora mas às vezes o algoritmo escolhe um tom que não fica muito bom, daí temos que ajustar manualmente. Em cima disso o GIF ainda tinha duas funcionalidades que são os diferenciais até hoje. A primeira era poder escolher uma cor dessa paleta pra ser transparente. Como não era uma canal alpha de verdade, a transparência era bem abrupta e feia, só em cima de uma única cor. Mas pra memes tá mais que bom.

E a segunda funcionalidade era permitir ter mais de uma imagem dentro do mesmo arquivo, com a possibilidade de tocar animado, que é a coisa mais importante em todo meme de hoje em dia. O problema disso era a paleta de cores. Lembra que pode ter no máximo 256 cores? Pois é, e as cores valem pra todas as imagens da animação, por isso é inteligente não fazer animações que tenham quadros muito diferentes um do outro.

Depois de comprimir jogando milhões de cores fora, o segundo passo era comprimir reduzindo sequências de bytes repetidos, meio parecido com a idéia do Run-Length que falei antes, mas bem mais agressivo. Pra isso GIF usa um algoritmo de compressão chamado LZW ou Lempel-Ziv-Weich. Tecnicamente o algoritmo original foi criado por Abraham Lempel e Jacob Ziv coincidentemente no ano que eu nasci, em 1977. Por isso que o algoritmo original se chama LZ77 que você vai esbarrar bastante se começar a pesquisar sobre compressão. Também vai esbarrar no LZ78 que é uma otimização da fase de descompressão. O LZW é uma variação desse algoritmo criado por Terry Weich em 1983 mas já volto a falar dele. Vamos focar só no LZ77.

Vale eu explicar a idéia geral com um exemplo. Vamos pegar outro string, como esse “um tigre, dois tigres, três tigres”. Sem descer em detalhes temos repetido 3 vezes o trecho “tigre”. E se a gente substituir o 2o e 3o tigre com um ponteiro dizendo quantas letras pra trás precisa ir pra achar o 1o tigre e quantas letras queremos pegar? Então ficaria algo como “um tigre, dois <12,5>, três <25,5>”. Esse 12,5 quer dizer, ande 12 letras pra trás e leia 5 letras. E 25,5 mesma coisa, ande 25 letras pra trás e leia 5 letras, ambos vão cair na primeira palavra “tigre” e com isso dá pra remontar a frase. Se eu codificar esses ponteiros com 4 bits cada valor, em 1 byte dá pra guardar.

O string original tem 33 letras, mas substituindo onde repete por esses ponteiros daria pra reduzir de cara pra 23 bytes, mais 2 bytes pra cada ponteiro, ou seja, 25 bytes. Mesmo nesse esquema simplificado já comprimimos em quase 25%, 1 quarto de economia. Imagine que num texto muito maior vai ter muito mais repetições e por isso dá pra comprimir bem. Se só o esquema de Huffman comprime umas 5 vezes, eu diria que o mesmo texto nesse esquema de ponteiros daria pra comprimir na faixa de 10 vezes. No geral acho que a eficiência é pelo menos 2 vezes maior que Huffman. Por isso vale a pena entender mais.

Imagina num texto longo fazer esse esquema de ponteiros. Pensa um livro por exemplo, centenas de páginas de texto. Se estivermos lá na última página e precisar fazer um ponteiro pra uma palavra na primeira página. Pra poder apontar tão longe significa que precisaríamos manter o livro inteiro em memória, megabytes de dados ou mais. Seria um puta desperdício de memória. E quando o algoritmo foi criado, no fim dos anos 70, sabemos que memória era hiper cara. Pensa que os melhores microcomputadores do começo dos anos 80 male male tinham 32 kilobytes de RAM. Então eu só posso manter pedaços do texto em memória enquanto vou descomprimindo, e por isso esses ponteiros não podem apontar pra tão longe no começo do texto.

Naquela época se reservava tipo 2 kilobytes, talvez 4. Esse bloco de buffer é o que se chama de sliding window ou janela deslizante, porque é como só desse pra ler o trecho do texto onde está essa janela. E os ponteiros só podiam referenciar dentro dessa janela, daí dá pra manter ponteiros usando poucos bits também. Quanto maior o sliding window, maiores as possibilidades de comprimir mais, mas mais RAM vai precisar. Então é um trade off. Hoje em dia RAM é barata, então dá pra ter sliding windows na faixa de megabytes. Porém quanto maior for o sliding window, maior tem que ser os ponteiros, daí ocupa mais espaço no total e comprime um pouco menos. É um balanço.

O primeiro grande sucesso que me lembro desse algoritmo surgiu na era dos BBS nos anos 80 pelo Phil Katz que inventou o formato ZIP, que usa esse algoritmo LZ77. Foi o famoso PKZIP que tinha os utilitário pkzip pra comprimir e pkunzip pra descomprimir. Quem daquela época não usou? Com a adoção pela Microsoft já naquela época o formato zip se popularizou, e embora outras coisas melhores tenham surgido, meio que virou o padrão até hoje. Com o tempo ganhou funcionalidades como encriptação, os famosos zips com senha que todo mundo que manja tem medo quando baixa, porque pode ser a pornografia que queria ou um malware.

Não confundir porque existem diversos formatos de compressão como zip, arj, rar, 7zip e outros que usam variações do algoritmo Lempel-Ziv. Uma coisa é o formato de arquivo, a estrutura de dados e metadados, outra coisa são os algoritmos que usam por dentro. E cada um usa estratégias diferentes pra tentar ultrapassar os concorrentes. Nos anos 80 mesmo surgiram diversas melhorias em cima do LZ77 como o LZSS ou Lempel-Ziv-Storer-Szymanski de 1982 criado por James Storer e Thomas Szymanski usado no bom e velho RAR. Lembram? WinRAR? O shareware que ninguém nunca pagou. Quem nunca baixou pirataria quebrada em vários arquivos de RAR?

No mundo Windows mais recente se popularizou o formato e ferramenta 7-zip, que é versátil e consegue lidar com outros formatos como o RAR ou ZIP originais, mas tem um formato próprio que usa outras variações do LZ77 como o Lempel-Ziv-Markov chain ou LZMA e LZMA2 criado pelo russo Igor Pavlov no fim dos anos 90. O Rar foi criado por outro russo, Eugene Roschal no começo dos anos 90. Naquela época pelo menos a gente falava que não podia subestimar um russo quando a questão era compressão de dados, porque entre RAR e 7zip eles contribuíram com alguns dos melhores formatos de compressão de arquivos.

Muitos desses formatos usam uma mistura de Huffman pra substituir letras ou palavras mais frequentemente usados por símbolos guardados num dicionário, aquela árvore binária de frequências e uma variação de Lempel-Ziv como LZSS ou LZMA2 pra substituir repetições por ponteiros dentro de um sliding window. E como cada um ajusta essas diversas combinações de dicionários, sliding windows, tamanho de ponteiros e tudo mais é que varia tanto quanto conseguem comprimir, quanto de CPU e RAM vão gastar no processo. Mas em geral, quanto menor consegue fazer o arquivo ficar, mais processamento e memória vai gastar.

Desenvolvedores web devem estão mais acostumados com o formato gzip, que é do começo dos anos 90 e é o mais usado em servidores web. Caso não saibam, toda página web que vocês navegam provavelmente vem compactada em gzip. Se não vem, deveria. O gzip usa o algoritmo deflate, que foi criado pelo Phil Katz pro PKZIP original. A patente dele já expirou e por isso podemos usar hoje de graça. Deflate e gzip são muito comuns no mundo Linux e é uma combinação do LZ77 e Huffman como expliquei. Aliás, toda linguagem de programação ou já tem ou tem bibliotecas pra todos esses algoritmos, deflate, huffman e tudo mais. Pesquisem.

Huffman, Lempel e Ziv são as fundações pra tudo que é compressão lossless, ou seja, que não jogamos fora nada dos dados originais e quando descomprime volta exatamente como era antes, diferente do esquema de JPEG em imagens. E falando em JPEG, o objetivo dessa longa tangente de história foi só pra poder voltar a falar do seu GIF de memes. Como falei antes, criado pela Compuserve em cima de outra variação do LZ77, o LZW que é Lempel-Ziv-Weich, do Terry Weich. Estamos falando de uma era antes da idéia de software livre. E naquela época patentear software era mais importante ainda, ninguém sabia como as coisas iam evoluir.

O erro foi que a Compuserve criou o GIF usando o LZW do Weich e deu certo, o GIF começou a se popularizar, especialmente quando a Web comercial começou a crescer e surgiram navegadores como o antigo Netscape, que adotou o GIF com um dos formatos de imagem suportado. Antes disso, no meio dos anos 80 o Weich vendeu as patentes pra Sperry Corporation, que fez merge com a antiga Burroughs, famosa por mainframes e pelo UNIVAC e que depois se tornou a Unisys, que existe até hoje. Pois bem, a Unisys ficou sabendo desse tal de GIF usando as patentes deles sem pagar nada e em 1987 começou a negociar com a Compuserve.

Ninguém tava muito ciente disso e todo mundo continuou usando. Aí em 1994 eles anunciam que esperam que todo mundo que usasse e distribuisse GIFs precisaria pagar licenças. Imagina se tivesse Twitter em 1994, todo mundo ia ficar putaço e ia cair matando cancelando a Unisys. Como assim querem taxar meus memes?? Aí em 1995 o Thomas Boutell anunciou na usenet, que era tipo nosso Reddit da época, uma proposta pra resolver isso. Que seria todo mundo largar saporra de GIF e trabalhar num formato melhor e mais moderno. E daí nasceria o PNG ou Ping.

Deu tão certo que já em 1996 a W3C, que é quem define os padrões da Web, adotou e oficializou o PNG. Mas então significa que todo mundo distribuindo GIFs de memes hoje tá infringindo patente da Unisys? Felizmente não, porque a patente já expirou lá por 2004 e a gente voltou a usar GIFs porque apesar do PNG ser infinitamente superior, ele não suportava animações. A única função que GIF tem é pra memes animados. Até existe um formato de PNG animado que é o APNG mas demorou muito pros navegadores adotarem. Ele já foi criado tarde, pela Mozilla, em 2008. Mas Chromium só adotou em 2017 e por tabela navegadores baseados em Chromium como Microsoft Edge só vieram a adotar depois. Você sabia que tinha APNG? Pois é, nem eu.

PNG é bem versátil, suporta imagens de poucas cores como GIF, só com 8-bits de cor, mas dá pra subir pra imagens pra 24 bits ou 32 bits. Também suporta um canal de alpha pra transparência de qualidade infinitamente superior ao GIF e por isso é muito adequado pra desenvolvimento Web. E ele usa um sistema de otimização da paleta de cores pra facilitar ter sequências de repetições, é tipo filtros que não degradam a qualidade da imagem mas facilita depois usar o algoritmo Deflate. Lembra? Baseado em Huffman e LZ77, que o gzip usa? PNG é comprimido com Deflate, portanto, diferente de JPEG, ele é lossless.

Depois do PNG surgiram outros formatos como o WebP do Google. Mas nem vou falar do WebP, WebM, codecs como VP8 ou VP9 porque apesar de bons não se tornaram populares. Aliás, toda vez que esbarro numa porcaria de WebP quero xingar porque a adoção é tão baixa que pro Photoshop abrir eu preciso instalar um plugin por fora. Um JPEG faz compressão na casa de 20 pra 1. Um PNG faz compressão na casa de 4 pra um. São ordens de grandeza menos. Mas um WebP é só uns 25% melhor em compressão que um PNG. Eu sei que tem outras vantagens, mas a diferença é muito pequena pra trocar tudo de PNG pra WebP e por isso continuo usando PNG pra tudo. Se eu quero uma foto altamente comprimida, vou usar JPEG. Se quero uma foto razoavelmente comprimida mas mantendo os detalhes do original, vou usar PNG e ponto.

Vamos voltar pro assunto principal. Lembram o objetivo? Eu quero assistir um filme de 2h em 4K na minha TV nova. Mas o arquivo não comprimido de video, a gente fez as contas, e ia precisar de uns 5 teras. O máximo que conseguimos fazer foi converter de RGB pra YUV 4:2:0, que joga fora informações do canal de chroma que a gente não percebe, que é o chroma subsampling. Mas mesmo assim o tamanho do arquivo cai só pra 3 teras, que continua sendo coisa pra caramba.

O que é um video. É basicamente uma sequência de imagens. Por que não comprimir cada imagem em PNG então? Já cairia o tamanho de tudo 4 vezes. Não muda muita coisa porque isso só diminui o video de 5 pra 1 terabyte. 1 tera é o tamanho total dos HDs de metade de vocês aí assistindo. Eu chuto que a maioria deve estar com HDs de no máximo uns 512 giga. Ou seja, tá chegando perto, mas ainda não dá. Então a próxima escolha óbvia é comprimir cada quadro do frame em JPEG, e aí vai ficar 20 vezes menor né? Sim, isso diminui os 5 teras originais pra 256 gigabytes!

Caraca olha só! Significa que se eu comprimir em JPEG já cabe 2 filmes no HD de vocês. Sucesso. Fim do episódio, deixem seu like e assinem o canal! Tô zoando. 256 gigas é um puta avanço, mas ainda não dá. Com conexão de 50 megabits que é o que a maioria de vocês aí deve ter, ia levar nada menos que 12 horas pra baixar. Não rola fazer streaming disso porque assistir um filme de 2 horas precisando de 12 horas pra baixar, só se você assistisse beeeeem em slow motion.

Falando em velocidade de internet, esse é o requisito pra streaming. 50 megabits é por volta de 6 megabytes por segundo, no máximo. Pra eu conseguir assistir um filme de 2h nessa velocidade, considerando uma conexão perfeita, que não engasga nem desconecta, ou seja, sem considerar buffer, significa que o tamanho máximo do arquivo do filme teria que ser menos 6 megabytes por segundo vezes 7200 segundos, ou seja, 42 gigas. Esse é o máximo, na realidade tem que ser menos que isso. Então precisamos dar um jeito de pegar o video compactado com JPEG que deu 256 gigas e comprimir 6 vezes ainda.

Aliás, realmente existe formato de video que comprime os quadros em JPEG. O Motion JPEG ou M-JPEG. É um dos componentes que depois se torna o que você conhece como MPEG1 que se usava nos antigos Video-CD, ou MPEG2 que se usava nos antigos DVDs. Ou o MPEG4 também chamado de AVC, Advanced Video Coding, que você conhece como H.264 que é o codec que a maioria dos videos aqui do YouTube, Netflix e outros usam. Na verdade a gente tá migrando pro H.265 mas já falo dele. Aliás, nomenclatura de tecnologias de imagens, áudio, video, é uma bosta. Tem três nomes diferentes pra mesma coisa, com um monte de versões diferentes, diferentes empresas usando nomes diferentes. É uma confusão mesmo. Se esses nomes te confundem, você não tá sozinho. Mas vamos nos ater ao básico.

Não necessariamente a compressão é o JPEG igualzinho das suas fotos mas sim um algoritmo de compressão baseado em DCT, transformada discreta de cosseno, então seria tipo variações das técnicas usadas pelo JPEG. Mas como já vimos, precisamos de mais que isso. Como estamos chegando no final, não vou entediar demais com todos os detalhes, mas o pulo do gato é simples. Presta atenção aqui em mim. Como são meus videos? É esse meu cenário aqui atrás que fica imóvel e não muda absolutamente nada do começo ao fim do video, e sou eu bobão aqui na frente, falando e se mexendo que nem um idiota. Concorda que precisa só de um quadro com a imagem inteira e depois pode recortar só eu aqui na frente pro resto do video?

O que é um video? É um conjunto de imagens. A grosso modo uma câmera de video que nem essa aqui na minha frente tá tirando fotos de mim, 60 vezes por segundo. Num video de 1 hora tem 216 mil fotos. Toda a parte da imagem que é o cenário tá repetido em todas essas fotos, 216 mil vezes. Se eu arrancar fora esse cenário de todas as fotos, só de bater o olho você pode chutar que daria pra jogar fora pelo menos metade da imagem, concorda? Lembra como é mais fácil comprimir sequências repetidas de zeros? Olha quantos zeros tem aqui ao redor de mim agora.

É exatamente isso que um codec como o H.264 vai fazer. Ele vai primeiro gravar um interframe ou keyframe que é uma foto completa, como essa. Daí os próximos frames vai gravando o que se chama de intraframes, que são deltas. Sabe commit de Git, que é só o trecho que você mudou no código e não o arquivo original inteiro? Mesmo conceito. Então vai ter um interframe e vários intraframes na sequência com deltas. O correto da imagem inteira é falar interframe, mas vou falar keyframe pra ficar mais fácil de distinguir de intraframe.

Eu não lembro se a quantidade de intraframes era fixo ou se o codec detecta quando teve tanta mudança que é melhor pegar um keyframe inteiro de novo. Dependendo do codec ele pode escolher ser conservador e pelo menos o keyframe comprimir usando um algoritmo lossless como equivalente de PNG pra aumentar a qualidade e os intraframes usando um derivado de DCT, como um JPEG. Indo direto aos finalmentes, quanto que aqueles 5 terabytes consegue diminuir somando um esquema de JPEG com um esquema de inter e intrarames?

Normalmente um filme por volta de 2h, em H.264 que é o codec mais usado atualmente, numa qualidade boa, próxima de Blu-Ray UHD que é a versão 4K, seria por volta de 20 a 25 gigabytes. Naquela mesma conexão de 6 mega por segundo daria pra baixar esse filme em aproximadamente 1 hora e 18 minutos. Ou seja, dá pra baixar todos os bits do video em menos tempo que a duração do video, que é o pré-requisito pra ser possível fazer streaming, que é poder começar a assistir enquanto o video vai baixando no fundo. Ou seja, atingimos nosso objetivo de conseguir assistir o filme via streaming na TV nova 4K!

E é exatamente isso que acontece no YouTube ou Netflix. Os videos em 4K de 30 quadros por segundo são encodados em H.264 com um bitrate de 35 a 45 megabits por segundo, dependendo do video. Lembrando que o tamanho final de um video não é linear com a duração do video. Depende do tipo de conteúdo. Desenho animado, por exemplo, vai ser mais fácil de compactar do que um filme de ação com câmera que balança o tempo todo, famoso shaky cam, como nos filmes do Jason Bourne, porque fica bem mais difícil fazer delta intraframes. A qualidade da imagem também importa porque senão fica qualidade ruim quando faz color downsampling ou DCT. Por isso que vários filmes diferentes de 2h vão dar tamanhos de arquivos bem diferentes um do outro.

Tem bem mais otimizações que codecs modernos fazem. Eles avaliam movimentos rápidos entre frames pra tentar normalizar, diferente de cenas que são só pessoas paradas conversando por exemplo. Tem técnicas como compensação de movimento, que existe desde o MPEG2 dos DVDs. O H.264 ou AVC que é o codec de video mais difundido pra consumo foi lançado oficialmente por volta de 2003 e levou desde 1998 até chegar no formato final. E mesmo depois saíram revisões do formato.

E já em 2004 começou os estudos pro sucessor que hoje conhecemos como H.265 ou HEVC de High Efficiency Video Coding que foi lançado por volta de 2013 e só em anos recentes a adoção ficou significativa. Na prática, se você edita videos, exporte em HEVC que os arquivos tendem a ficar quase 50% menores e com qualidade pelo menos similar ao H.264, mas pra isso ele gasta bem mais processamento do que o H.264. Lembram o que eu expliquei antes que podemos ajustar o algoritmo pra criar arquivos menores ao custo de mais processamento e mais memória?

Falando em quem edita videos, H.264 e H.265 são o que se chama de codecs de consumo. Assim como eu falei que JPEG é ótimo pra guardar suas fotos mas não pra editar, esses codecs de consumo é mesma coisa, ótimo pra poder baixar rápido e assistir, mas péssimos pra editar. Primeiro porque assim como JPEG eles fazem chroma downsampling, porque pra TV YUV 4:2:0 é mais que suficiente e você não vai notar que jogamos fora metade da informação de chroma. Mas pra editar faz diferença, porque agora não temos cores suficientes pra trabalhar.

Fotógrafos profissionais devem tirar fotos no formato RAW que usa compressão lossless, por causa do algoritmo deflate. Daí edita no Lightroom da vida e no final exporta em JPEG pra postar no Instagram. Mesma coisa video, o formato correto pra gravar nunca deve ser H.264 ou H.265 e sim Apple ProRes ou DNxHR ou CineForm ou outros formatos proprietários como o REDCODE, se usa câmeras da RED. Todos esses formatos são similares a zip, 7zip, rar, compressão lossless, que não joga informação fora. Eles tem diferentes taxas de compressão caso queira sacrificar qualidade de video por espaço de armazenamento.

Por exemplo, eu gravo meus videos aqui em DNxHR. E gravo no perfil que comprime mais e mesmo assim dá 1 gigabyte por minuto de video. Então se eu gravar 2 horas de video vai dar pelo menos 120 gigabytes. E se gravar com menos compressão pode chegar lá no 1 terabyte fácil. Quem edita videos profissionalmente precisa disso. Num H.264 final vai estar em YUV 4:2:0, mas no meu video gravado em DNxHR vai estar em YUV 4:2:2, ou seja, mais informação de cor. E pra ser agressivo era só gravar em ProRes 4:4:4 que é zero perda de informação de chroma. Agora você sabe o que significa ProRes 4444 versus ProRes 422.

Além disso H.264 usa o esquema de inter e intraframes. Acho que todo mundo já viu como se edita videos? Num programa como Adobe Premiere ou DaVinci Resolve. São programas de uma categoria que se chama NLE ou Non Linear Editing, edição não linear, ou seja, que eu posso editar qualquer ponto do video que quiser. Só que toda vez que eu peço um frame pra editar, só vai ter o intraframe, que é o delta, a imagem incompleta. Então precisa voltar alguns frames pra trás e localizar o keyframe completo, mesclar os dois e aí eu tenho a imagem inteira. Imagina navegar num clip de video pra frente e pra trás e toda horas precisar processar frames assim.

Com um codec profissional como o Apple ProRes ou DNxHR ele vai ter só keyframes. Então esses codecs são mais parecidos com o M-JPEG original, o Motion JPEG onde todo frame é um JPEG completo, sem deltas. Por isso, apesar do tamanho do arquivo de video ser ordens de grandeza maior, pra editar é muito mais performático, porque não precisa reconstruir os frames o tempo todo, eles já estão inteiros, é só ler. Um H.264 atrapalha pra editar e exige mais processamento e mais memória da máquina, por isso não compensa. Espaço em disco é barato, melhor plugar um SSD externo via Thunderbolt. Lembra dos meus videos explicando NAS e armazenamento?

Além de tudo isso que expliquei, nem toquei no assunto de áudio direito, mas assim como imagem crua de alta qualidade de câmera se usa o formato RAW, que comprime de forma lossless com alguma variação de LZ77, assim como video tem formato lossless como Apple ProRES, áudio também tem formato crú comprimido lossless como o FLAC ou os antigos WAV e AIFF. Mas também assim como imagem tem formato lossy de consumo como JPEG, video tem formato de consumo H.265, áudio tem alta compressão lossy com MP3 ou AAC, Advanced Audio Coding, que é o que costuma ir com video H.265 ou Blu-Ray.

No final os conceitos básicos são os mesmos: não tem como guardar a informação analógica original 100%, por isso pegamos samples, como pixels no caso de imagens. Quadros por segundo no caso de video. E sample por segundo no caso de áudio. Ajustamos resolução, frequência, e fazemos transformações pra simplificar os dados quando queremos alta compressão. Ou só tentamos reduzir repetições se não queremos perder informação.

Tem várias outras coisas sobre compressão que nem mencionei, por exemplo, sistemas de arquivo que suportam compressão. No Windows com NTFS é possível ligar compressão e todos os arquivos no seu sistema vão ser comprimidos. Significa que toda vez que salvar vai levar um tempo a mais pra comprimir, e toda vez que tentar ler um arquivo vai levar outro tempinho pra descomprimir, e isso vai ser o tempo todo. Não sei quanto de overhead isso adiciona, até imagino que é rápido o suficiente pra não se notar na maior parte do tempo, mas considerando que espaço em disco hoje é super barato, não acho que compensa fazer isso. É muito mais inteligente comprar um HD externo USB barato e jogar o que não precisa pra lá em vez de deixar seu sistema inteiro lento o tempo todo por conta de poucos megabytes economizados. E ele provavelmente vai usar o equivalente de um zip na menor compressão pra não demorar demais, então não comprime nem de perto tanto quanto um zip de verdade.

Enfim, o objetivo do video de hoje era usar a desculpa de video pra explicar o básico de tudo que existe sobre compressão de dados, incluindo as peças básicas mais fáceis que você pode treinar em qualquer linguagem de programação como Run-Length, Huffman, Lempel-Ziv, pra comprimir textos e depois ficar curioso pra aprender mais sobre séries de Fourier e transformada discreta de cossenos que, como vimos, você usa diariamente e nem sabia disso. Agora que sabe, se é de ciências da computação, não custa nada ir perguntar pro seu professor de algoritmos ou pesquisar por conta própria. Espero que isso tenha aumentado sua percepção do que acontece por trás dos panos das atividades mais simples que fazemos no dia a dia, como assistir este video no YouTube. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video pra ajudar o canal. A gente se vê, até mais.

DESCRIÇÃO

Transformando Limão em Limonada é o tema. Finalmente vou mostrar o setup que eu vim fazendo upgrade pra fazer videos melhores. Em particular meu novo Atomos Ninja V. E vou aproveitar pra explicar um pouco sobre CODECs de video. E no final vou mostrar meu cenário em mais detalhes.

Pra quem tinha curiosidade de saber como eu faço meus videos, este é o video!

Conteúdo

• 00:00 - Intro
• 01:24 - Perdi minhas gravações, de novo!
• 03:19 - Sony a7iii
• 05:11 - Europeus fazem leis idiotas
• 06:06 - Captura de video no PC
• 06:29 - Setup do meu PC atual
• 10:39 - Setup do áudio
• 11:12 - Telepromper
• 11:24 - Meu processo de gravação antigo e chato!
• 12:59 - Solução: Atomos Ninja V
• 14:22 - Codecs e Containers
• 16:57 - Como um video é estruturado?
• 17:28 - Compressão. Imagens, áudio e video
• 22:25 - Codecs de delivery vs de edição
• 26:20 - Chroma Subsampling. Monitor vs TV
• 28:51 - iPhone 13
• 29:30 - Comparando Codecs
• 33:28 - Tour pelos detalhes do meu Cenário
• 36:22 - Final

Links

• Video Codecs & Compression Guide (Feat. Atomos Ninja V) (https://www.youtube.com/watch?v=wX9KGRHaMEY)
• Playlist: Computerphile - Digital Imaging - Mike Pound (https://www.youtube.com/watch?v=06OHflWNCOE&list=PLboJFH3ATn0yC9uLuRLhaezUvtVPLtQvv)
• This Is What Happens When You Re-Upload a YouTube Video 1000 Times! (https://www.youtube.com/watch?v=JR4KHfqw-oE)
• Have we gone MAD?? (12k video - https://www.youtube.com/watch?v=pocfGBQZUSI)
• Do TVs Suck As Monitors? (https://www.youtube.com/watch?v=Jcd07Fndqus)

SCRIPT

Olá pessoal, Fabio Akita

Desde que abri o canal, uma das perguntas mais frequentes, tipo que eu recebo no mínimo uma vez por semana é sobre quais cursos eu recomendo pra quem tá começando. E como eu já disse em vários videos: eu não recomendo nenhum, e na prática tanto faz qual. Nenhum curso vai ser completo, eles servem só pra ter dar um empurrão, mas nunca vão te ensinar tudo de qualquer assunto. A segunda pergunta que mais recebo complementa a primeira que é quais livros eu recomendo.

Muito do que você não vai aprender via cursos ou tutoriais está em livros. E não ache que dá pra pegar essa lista e sair lendo tudo de uma vez. Boa parte deles você vai lendo aos poucos ao longo dos seus primeiros 10 anos de carreira, porque você ainda não tem nem o conhecimento e nem a experiência pra entender de fato o que estão tentando te dizer.

Hoje vou listar alguns livros que eu pessoalmente acho importantes. Não é uma lista nem completa e nem definitiva, são livros que eu fui usando ao longo dos anos e que acho que podem te ajudar. E vou apresentar mais ou menos na ordem que conheci eles, cronologicamente, porque faz diferença quando eles foram lançados e em qual contexto. Prestem atenção ao contexto que vou falar mais do que na lista em si.

(…)

Vamos lá. Nenhum livro é obrigatório. Então não saiam por aí dizendo pros outros que o Akita falou então é pra ler. Os livros que vou falar hoje eu não li tudo de uma vez só, muitos nem li inteiro, e vim acumulando ao longo dos primeiros 10 a 15 anos da minha carreira, durante e depois da faculdade.

Ninguém vai conseguir ler e principalmente entender esses livros numa só leitura. Isso não é literatura, são livros de aprendizado e referência. Alguns temas dentro desses livros você só vai entender de verdade depois que passar por projetos reais e só daí vai vir o “ahhhh, era isso que o livro queria dizer”, aquele momento “ahá”.

Isso dito, se você assiste meu canal já deve imaginar que minha primeira recomendação é o livro do Cormen de Introdução a Algoritmos. Eu tenho esta terceira edição, não sei se tem mais novo, mas não importa. O maior problema de começar estudando e usando frameworks e bibliotecas pré-prontas é que elas evitam que você precise saber como são feitos, porque já vem tudo pré-pronto e escondido pra só usar.

Eu falei disso em videos anteriores e até mostrei, mas se usa uma lista ou collection em Javascript, você não tem idéia se por baixo tá implementado uma lista ligada, ou uma árvore Red Black ou o que. Você só adiciona elementos, remove elementos, manda ordenar e pára por aí. E isso vale pra qualquer outra coisa funcionalidade. Você usa uma biblioteca de caching do seu framework favorito, mas como é implementado? É uma fila simples? É uma fila circular? É uma árvore B-Tree? Que tipo de hashing ele usa? Pra você tanto faz, você só empilha e desempilha elementos e deixa o framework cuidar de tudo pra você.

Então toda vez que usa listas, manipula strings, usa threads ou fibers, caching e tudo mais, só confia que o framework sabe o que tá fazendo e não se preocupa. E isso é ok pra 80% dos casos, por isso que muito iniciante consegue ir até longe em alguns projetos sem nunca ter lido um único livro sobre algoritmos e estruturas de dados. Esse é o nível de um junior. Porém um sênior precisa lidar com problemas diferentes.

Otimização de performance, otimização de carga, reorganização e refatoração do código pra ser ao mesmo tempo mais fácil de dar manutenção e também mais performático, diminuir tempo de latência, diminuir uso de memória por requisição, resolver conflitos de versões de bibliotecas externas, fechar buracos de segurança e mais. E pra isso, você precisa saber como essas bibliotecas e frameworks funcionam por baixo, e pra isso, precisa da fundação, que começa em algoritmos e estruturas de dados.

Um livro como do Cormen não é completo. Ele fala de bastante coisa que você deveria saber, mas nenhum livro nunca vai ter tudo. E antes que vocês perguntem nos comentários ou fiquem me mandando DMs, não, não precisa ser o livro do Cormen. Eu mesmo não usei ele na faculdade. Eu aprendi o básico com um muito mais simples, este do Niklaus Wirth. Olha como é menor.

Diferente do Cormen, o livro do Wirth sequer entra no assunto de grafos, por exemplo. Além disso o Wirth escreveu o livro dele em 1986, já o Cormen e seus co-autores escreveram o deles em 2009. Por isso, no livro mais novo tem assuntos mais modernos, como multithreading, que ainda era um assunto que engatinhava nos anos 80.

Se você acha que precisa ter o livro mais completo de todos, ele não existe mas o mais próximo não é um livro, mas uma coleção de livros, do lendário Donald Knuth, o famoso The Art of Computer Programming, o magnum opus da ciência da computação que ele começou a escrever em 1962 e até hoje não terminou. Eu já falei dele em outro video mas os livros que eu tenho são do 1 ao 3 mais o 4A. Segundo a Wikipedia ele tá escrevendo os fascículos 5 e 6 que são os primeiros dois terços do volume 4B.

E quanto ainda falta pra acabar? Bom, depois do 4B ainda vai ter os volumes 4C e 4D e depois os volumes 5, 6 e 7. Ou seja, o que eu tenho aqui ainda não é nem metade do que seria a obra completa. Essa coleção é o Game of Thrones da computação, e o Knuth é o George R R Martin da nossa área. Todos cruzando os dedos pra ele conseguir terminar tudo. Os livros do Wirth e do Cormen eu diria que são um resumão do que seria os livros de 1 a 4D do Knuth.

Ou seja, os temas dos primeiros 7 volumes do Knuth, que incluem os volumes 4B a 4D que ele ainda não escreveu são o que você encontra no sillabus dos primeiros anos de um curso de ciência da computação. Começa com coisas como matemática básica, números, potências, logaritmos, teoria dos números, permutações, fatoriais, coeficientes binomiais, ou seja, não só o assunto de algoritmos mas temas de matemática que você aprende nos primeiros 2 anos de ciências da computação em matérias como Álgebra, Estatística e probabilidade.

No primeiro volume do Knuth você tem coisas básicas como pilhas, filas, listas ligadas, listas circulares, arrays, árvores binárias, que foram assuntos que eu detalhei alguns videos atrás. Por isso o primeiro volume se chama Algoritmos Fundamentais. Já o segundo volume complica um pouco mais. Ele se chama Algoritmos Seminuméricos e logo de cara o primeiro assunto no livro é definir números aleatórios.

Fazendo uma tangente, números aleatórios gerados por computador não são puramente aleatórios, são pseudo-aleatórios. Em qualquer linguagem moderna de programação você só usa uma função como Random e esquece, mas nesse livro você pode estudar como isso funciona. E nos capítulos seguintes ele vai discorrer sobre sistemas posicionais de números como aritmética de ponto flutuante, que foi outro assunto que já expliquei alguns videos atrás. E continua em assuntos como aritmética racional, aritmética polinomial.

E sim, essa coleção inteira é bem pesada em notação matemática. Se você não tá acostumado é absolutamente intimidador. Entendida toda a base matemática fundamental, só no volume 3, que é chamado de Ordenação e Procuram, é que vamos finalmente encontrar os algoritmos de ordenação como inserção, seleção e procura com temas como pesquisa binária e árvores balanceadas que eu também já mostrei alguns videos atrás.

Finalmente chegamos ao volume 4A que é chamado de Algoritmos de Combinatória Parte 1 que explica o básico de álgebra booleana, truques e técnicas de operações bitwise, diagramas de decisão binária e geração de todas as possibilidades onde entramos no assunto de n-tuplas, permutações, combinações, partições, conjuntos e muito mais. E isso é parte 1 porque o tema de Algoritmos de Combinatória vai se esticar nos próximos volumes ainda não escritos, do 4B ao 4D.

Só esses 4 volumes somam quase 3 mil páginas. Pra colocar em perspectiva, o livro do Cormen é menos da metade disso. Mas se prestou atenção vai notar que os livros do Knuth cobrem mais assuntos, em particular a base matemática. Livros mais focados só em algoritmos e estruturas de dados, como do Cormen, se preocupam menos com as provas matemáticas e mais em como cada elemento é implementado e funciona. Eu diria que é mais prático pra gente. Você só vai realmente ler página a página do Knuth se for se especializar em matemática aplicada ou algo assim.

Mas pra assuntos específicos, vale como referência se quiser descer a fundo. Por exemplo, como realmente números aleatórios são matematicamente definidos? Eu repito, a grande maioria de nós não tem o vocabulário de matemática teórica suficiente pra realmente conseguir absorver tudo do Knuth, por isso qualquer coisa perto do livro do Cormen é mais prático. Mesmo o Cormen é um pouco pesado em matemática, então qualquer livro de algoritmos e estruturas de dados é suficiente.

Mas e os livros de 5 a 7 que o Knuth ainda não escreveu? Os títulos parecem que vão ser Algoritmos Sintáticos, teoria de linguagens livres de contexto e técnicas de compiladores. Linguagens livres de contexto você vai cair no trabalho mais importante do Noam Chomsky - e na minha opinião, a única coisa que você precisa ler dele. Enfim, na realidade já existem livros que cobrem esses assuntos. Se você fez ciência da computação já sabe. Essa é minha segunda recomendação: o famoso livro do dragão, o Compiladores - Princípios, Técnicas e Ferramentas, do Aho, Ullman e outros, publicado em 1986.

Eu já falei em outros episódios sobre compiladores como GCC, e principalmente sobre uma das tecnologias mais importantes deste século: o LLVM, que se você pelo menos acompanha artigos técnicos, já ouviu falar diversas vezes. Eu explico sobre LLVM no episódio sobre a Apple e recomendo que assistam pra entender o contexto, mas é graças a LLVM que você tem linguagens como Swift, Rust, Crystal, Julia, linguagens de shaders pra GPU e muito mais. E pra entender LLVM você precisa entender compiladores e realmente como linguagens de programação são criadas.

Na prática, a menos que você pretenda criar sua própria linguagem do zero, não precisa saber o livro do Dragão de cabo a rabo. É mais pra entender os principais conceitos. Esse livro vai te explicar o que é análise léxica e ferramentas como Lex e você mesmo vai descobrir outras como o GNU Flex depois. Daí vai pular pra análise sintática e ferramentas como o Yacc e outros como o GNU Bison. O livro usa os antigos Lex e Yacc, na minha época da faculdade no meio dos anos 90 era Flex e Bison, mas hoje em dia existem ferramentas mais modernas.

Isso é só pra desenhar a linguagem e criar um parser, mas a partir daí tem que fazer a geração do código binário propriamente dito que passa por um código intermediário, otimizações independentes de máquina, paralelismo em nível de instrução, localidade, análise interprocedural. Se você me perguntar se eu ainda sei essas coisas, não, não lembro nem uma fração mais hoje. Mas os conceitos que guardei me ajudam a avaliar toda vez que uma nova linguagem aparece, eu consigo entender como funciona, o que procurar na linguagem, no compilador, no código final gerado e tudo mais.

Compiladores é um tema que você não deveria tentar aprender tudo de uma só vez. Compensa até começar com algum livro mais simples, curso online ou até um tutorial com ferramentas de mais alto nível que te permitem criar linguagens simples que não necessariamente vão ser performáticas, mas vão ajudar a “molhar os dedos” no assunto antes de aprofundar nos detalhes que tem no livro do dragão.

De qualquer forma, só faz sentido ter a ambição de escrever a própria linguagem se você estudou um pouco mais a fundo sobre linguagens. E não só “ah, eu gosto de parênteses” ou “ah, eu prefiro não ter ponto e vírgula no fim das linhas”. Design de linguagem é muito mais que isso. Um livro que talvez ajude a entender as features de uma linguagem é o The Design and Evolution of C++, do Bjarne Stroustrup que é o pai do C++.

Ele conta um pouco a história de como o Stroustrup se inspirou em C with Classes pra chegar ao C++ e justifica as funcionalidades que criou em cima disso como o gerenciamento de memória, herança múltipla, casting, templates, exceptions, namespaces e tudo mais que forma a base do C++ e depois serviu de inspiração pra implementar muitas das linguagens modernas que você usa como um Java ou C#.

Entender o pulo do C pro C++ pela visão do autor é interessante e também as primeiras interpretações sobre o que é orientação a objetos. C++ é uma linguagem que eu mesmo nunca usei muito profissionalmente, então eu mesmo sou amador, mas acho fascinante entender como se encaixa na história das linguagens de programação. Ela ainda é uma das linguagens mais usadas pra código de sistemas, tudo de mais importante que você usa é escrito com C e C++, seu Javascript é escrito em C++. E isso não vai mudar por um bom tempo ainda.

Daí pulamos um pouco do tema de ciências da computação e vamos um pouco pra engenharia de software. Eu já expliquei a diferença em outro video, mas aproveitando o gancho da orientação a objetos do C++ vale pelo menos mencionar outro livro, o Object Oriented Analysis and Design with Applications do Booch e outros autores.

Orientação a objetos é um tema super longo, bem mais complexo do que você aprende na faculdade e eu não vou detalhar tudo hoje. Dependendo da era que estudar você vai ter interpretações diferentes de muitos conceitos, mas o que muita gente chama de orientação a objetos deriva do vocabulário criado pelo Grady Booch, Ivar Jacobson e Jim Rumbaugh. Cada um deles tinha uma versão de definição de orientação a objetos e eles se juntaram pra compilar seus trabalhos numa obra só. O que se publicou dos anos 90 em diante deriva disso.

Esse livro em particular não é a obra definitiva nem nada disso, mas eu acho interessante que ele tenta justamente definir muito desse vocabulário, definir o que exatamente é uma classe, o que é um objeto, qual é a notação que se deveria usar pra comunicar um modelo de objetos. Algumas partes, em particular a seção 3 do livro que pode estar um pouco defasado porque ele tenta explicar esses conceitos usando exemplos de cinco aplicações que vão de um sistema de navegação de satélite até um sistema de rastreio de férias via web, definido com essa notação de objetos.

Eu digo defasado porque a forma como desenvolvemos aplicações e até a forma como modelamos classes e objetos mudou daquela época até hoje então alguma coisa ficou obsoleta mesmo, não tem jeito, mas muitos dos conceitos ainda valem hoje e principalmente o raciocínio e história por trás de porque eles definiram as coisas daquele jeito. Esse livro em particular vale mais pra capturar um momento da história do que pra ensinar todas as técnicas que você precisa saber.

Esse livro, na real, é opcional e complementar a outro livro mais conhecido que é o The Unified Software Development Process escrito pelos mesmos Los 3 Hermanos, o Jacobson, Booch e Rumbaugh. Ele define a famosa e famigerada notação UML mas, mais importante, define o processo de desenvolvimento de software conhecido como Unified Process ou até hoje o que você conhece como Rational Unified Process ou RUP.

Lembrando, esses livros foram escritos antes de 2001, nos anos 90, portanto antes do Manifesto Ágil, antes de cloud computing, antes de smartphones, antes ainda da primeira bolha da internet, literalmente na infância da Web. Então tudo que você conhece como formas modernas de desenvolvimento de software, que só nasceram nos últimos 20 anos, ainda não existiam nessa época. Mesmo assim, eu ainda acho que vale a pena ler o começo desse livro, porque muitos dos conceitos de engenharia de software que você usa são derivados dessa época.

Em particular, eu já falei em outros episódios que pra mim um bom exemplo de linguagem orientada a objetos, por incrível que pareça é o Erlang, em particular o Elixir. Muita gente pensa em Elixir como uma linguagem funcional, mas pra mim é o contrário. Ele é primeiro uma linguagem orientada a objetos que por acaso tem aspectos funcionais. Eu argumentaria que Elixir e Erlang são mais orientados a objetos do que Java, que muita gente ainda pensa como a referência em objetos. Se você não entendeu isso, ainda precisa estudar mais.

Um dos argumentos sobre Erlang é que logo no prefácio desse livro, eles contam sobre o case da Ericsson, que é a inspiração do Unified Process. Se você não sabe, o “ER” de Erlang é de Ericsson. Os autores argumentam que o sistema de telecomunicações deles era tão bom porque modelaram o sistema inteiro como um conjunto de blocos interconectados, o que em UML se chamaria de componentes ou sub-sistemas. E eles foram montando blocos de baixo nível e subindo pra sub-sistemas de alto nível pra tornar o sistema mais fácil de gerenciar e foram encontrando esses blocos trabalhando pelos casos de tráfego anteriores - o que hoje se chamaria em UML de “casos de uso”.

O caso da Ericsson é relevante pro assunto de orientação a objetos porque quem trabalhou lá foi justamente um dos co-autores desse livro, o Jacobson, que saiu em 1987 e fundou a empresa Objectory e nos anos seguintes ele e alguns colaboradores desenvolveram um processo chamado Objectory também pra servir pra mais casos além de telecomunicações, e foi aí que coisas como “casos de uso” ganharam esse nome.

Alguns anos depois, em 1995 a empresa Rational Software Corporation comprou a Objectory e eles trabalharam em juntar os dois processos que tinham e chegaram primeiro no Rational Objectory Process. Depois disso que o Booch, Rumbaugh e Jacobson colaboraram pra criar o Unified Modeling Language, o UML, pra ter uma linguagem visual pra comunicar as idéias sobre objetos e finalmente chegaram no Unified Process ou Rational Unified Process, que é o RUP, que muitos que fizeram engenharia de software devem ter estudado.

Em 2021 raramente você vai ver alguma empresa usando fortemente UML e RUP em projetos. Pelo menos eu espero que não. Talvez em empresas antiquadas e altamente burocráticas, mas em tech startups é bem raro encontrar. Mas muito do vocabulário e notações que usamos até em rascunhos numa lousa são derivados do UML. Muito da engenharia de software moderna ainda usa os nomes originais, como “casos de uso” por exemplo, ou diagrama de componentes. O que eles chamavam de sub-sistemas você poderia chamar hoje de micro-serviços e assim vai.

Se quiser aprender esse vocabulário sem perder muito tempo no detalhamento do processo em si, que ninguém mais usa como antigamente, você pode pular direto pra outro livro bem menor, de menos de 200 páginas, chamado UML Distilled do Martin Fowler, que é basicamente um resumão de UML e RUP. Ele tem só o que o Fowler acha que é mais relevante alguém saber, é quase um cheat sheet sobre UML.

Levou alguns anos, até demais na minha opinião, pras pessoas entenderem que seguir algo como um RUP ao pé da letra era absolutamente burocrático e improdutivo. A gente tava mais preocupado em rastrear, gerenciar e aprovar artefatos, como diagramas, do que com o código em si. É uma das grandes críticas em relação ao campo da orientação a objetos em geral.

Falando em Martin Fowler, ele foi um dos escritores mais prolixos e influentes do fim dos anos 90 até pelo menos o meio dos anos 2000 e um dos seus livros mais importantes parece uma reação contra o que um RUP representa. Esse livro obviamente é o Refactoring, publicado em 1999. E hoje em dia todo mundo fala em refatorar, refatorar, mas quantos de vocês conseguem definir o que é refatorar? Qual a diferença entre refatorar e reescrever?

Nas palavras do próprio Fowler, refatorar é o processo de mudar um software de tal maneira que isso não altere o comportamento externo do código e mesmo assim melhore a estrutura interna. É uma forma “disciplinada” de limpar código que minimiza as chances de introduzir bugs. Em essência, quando você refatora, está melhorando o design do código depois que ele foi escrito. Muita gente falando “refatoração” na verdade está querendo dizer “reescrever”, que não é um processo disciplinado de melhoria sem mudar comportamento, é literalmente jogar fora e escrever de novo de outro jeito, com outro comportamento, e não garante nenhuma melhoria.

E não é à toa que o Martin, junto com outros autores como Kent Beck, são signatários do Manifesto Ágil. Em metodologias antigas de engenharia de software, onde o RUP se inclui, a ideia principal é primeiro criar o design inteiro do software, por exemplo desenhando com diagramas com UML. E só depois que o design estiver perfeito que se começa a escrever o código. Ou até mesmo daria pra gerar automaticamente esse código a partir dos diagramas. Eles consideram design e codificação como duas etapas separadas. Mesmo tendo coisas como iteração no processo, as etapas em si ainda são conceitualmente separadas. Muitas empresas tentaram criar ferramentas que partiam dos diagramas de classes e tudo mais de UML e geravam código em Java da vida.

Essa ideia nunca funcionou direito e a gente foi entendendo melhor porque depois da virada do século, depois que começamos a ideia de agilidade. A premissa errada é achar que é possível criar um design perfeito em papel primeiro e depois o código seria só um reflexo direto desse design. Na realidade o código “é” o design e ele nunca vai estar perfeito, muito menos na primeira vez. Daí vem a ideia de fazer o primeiro código que funciona primeiro, que provavelmente vai ser um código ruim, e só depois, disciplinadamente, refatorar esse código até termos uma estrutura que seja livre de bugs e de mais fácil manutenção.

Aliás, vale aproveitar pra dizer que muita gente pensa que primeiro nasceu o Manifesto Ágil em 2001 e só depois começamos a entender o que são técnicas ágeis, mas é o contrário. Primeiro os signatários do manifesto passaram anos praticando, formulando as técnicas e documentando, durante os anos 80 e 90 principalmente, e só depois que isso deu origem ao Manifesto. Essa ordem é importante, porque o Manifesto é só um resuminho de 20 anos de experiência de cada um deles que veio antes.

Na indústria mais tradicional, por décadas sempre se tentou o conceito de design primeiro e código depois. Lá atrás a gente desenhava software com fluxogramas em linguagens procedurais, por exemplo. E isso fazia sentido porque debugar software depois era custoso, difícil, tedioso. As linguagens antigas eram fortran, cobol, algol, Ada ou C. Nenhum programador nos anos 70 e antes tinha um notebook multi-core com gigabytes de RAM. Não, eles tinham que compartilhar um único computador grande com vários outros engenheiros e programar a partir de terminais remotos.

Esses terminais eram lentos, ninguém tinha um VS Code ou Sublime Text da vida. O editor VI original foi criado justamente pra ser super otimizado pra desenhar o mínimo possível na tela e permitir navegar no código com o mínimo de comandos. Porque cada comando navegava numa rede lenta até um computador compartilhado lento que tinha no máximo kilobytes de RAM. Portanto, você gostaria que o código funcionasse de primeira, não era produtivo ficar debugando e “refatorando” o código depois.

O que aconteceu nos anos 90 até os 2000 é que microcomputadores apareceram e ficaram consideravelmente potentes, internet e rede mais veloz apareceu, e agora era factível você rodar um sistema inteiro no seu computador pessoal antes de rodar no servidor da empresa. Fazer o design antecipadamente era crucial nas décadas de 60 a 80, mas depois disso a tecnologia avançou o suficiente pra gente conseguir fazer código ruim primeiro e refatorar depois pra ter código bom, então o design e o código passaram a ser um processo orgânico de melhoria contínua. Isso é uma interpretação minha, mas eu diria que “Agile” marca quando separávamos design e código em etapas distintas pra serem unidos em design emergente.

Falando em processos ágeis, se tiver só um livro que você queira ler, que seja o Extreme Programming Explained, do Kent Beck, também de 1999. Veja que em 1999 e 2000 que começou a aparecer mais livros sobre esse novo jeito de programar que vinha sendo praticado fazia mais de 10 anos, que culminaria com o manifesto ágil em 2001 e muito do que você considera técnicas de engenharia de software modernas como pair programming, test driven development, continuous integration, refactoring, small releases, nascem nele.

Engenharia de software é um campo em constante mudança. Dependendo de que ano é a literatura que você está estudando, vai cair nos RUP da vida ou vai cair em derivados de Extreme Programming. A ideia não é dizer que os conceitos dos anos 90 estavam errados. Eles faziam sentido pras circunstâncias da época e vale a pena entender porque.

Vocês podem ver que alguns livros e temas envelhecem melhor que outros. Uma coisa que me ocorreu gravando esse video é que se você prestou atenção, note que livros de ciência da computação tendem a envelhecer melhor que livros de engenharia de software. Livros de ciência da computação de 30 anos atrás ainda se aproveitam hoje, mas livros de engenharia de software de 30 anos atrás, estão obsoletos.

Até hoje ainda não temos “o” melhor jeito de escrever software, estamos constantemente mudando os processos de como transformar idéias em código. Mas as peças fundamentais que usamos pra construir essas idéias ainda continuam válidas. Na ciência da computação o conhecimento meio que vai se estendendo mas não jogando muita coisa fora pelo caminho.

Uma parte disso é porque as teorias matemáticas que embasam coisas como algoritmos, uma vez provadas, variam muito pouco na implementação. É o trabalho de caras como Knuth. Uma árvore balanceada, seja feita em C ou seja em Kotlin, continua sendo uma árvore balanceada. Linguagens diferentes mas as características continuam as mesmas. É um dos motivos de porque linguagens funcionais ganharam algum destaque nos últimos anos. Muitos tentam trazer esse rigor matemático, como de lambda calculus, pros processos de como escrever código. Mas escrever código não é uma ciência exata, é um processo aberto à interpretação.

O problema é que código não é só rápido, ou seguro. Em engenharia a gente tenta buscar várias características como mantenabilidade, flexibilidade, portabilidade, reusabilidade, legibilidade, testabilidade, segurança e assim por diante. Você pode escrever o código mais seguro possível, mas vai prejudicar a flexibilidade e reusabilidade, e assim por diante. O desafio de um programador é balancear essas características, e isso é difícil porque depende de quais problemas você precisa realmente resolver com esse código. E pior, os requerimentos desse código mudam conforme o software é usado.

Num primeiro momento a prioridade pode ser eficiência, mas depois de um tempo a prioridade passa a ser segurança, depois passa a ser mantenabilidade. Então o código precisa ser modificado ao longo do tempo, o design desse código vai mudando conforme as necessidades vão mudando. Por isso, nenhum código está 100% pronto e congelado pra sempre. E repetindo, por isso é quase impossível fazer um design perfeito antes do código.

Muito amador ainda acha que código, se rodar, tá ótimo, não importa se tá sujo, com nomenclaturas toscas, com alta complexidade. “Ah, roda, então foda-se”. Código que roda, mas é sujo, com baixa mantenabilidade, é lixo, pode jogar fora. Não adianta nada rodar se amanhã você precisar estender, consertar, reusar. Daí mais atrapalha que ajuda. É lixo. Não basta rodar, precisa estar limpo o suficiente pra quando outro programador for reusar, não vai sofrer.

Se você quiser um livro mais estruturado com a melhor forma de escrever código e como se comportar como um bom profissional, o melhor livro pra começar é de outro agilista, o controverso Robert Martin, vulgo Uncle Bob. Ele é outro escritor prolixo e seu livro mais conhecido é sem dúvida o Clean Code, ou Código Limpo. E o conteúdo é parecido com o Code Complete do McConnell mas bem mais atual.

Ele toca em coisas tipo, como criar nomes de variáveis, funções que sejam fáceis de entender. E segue falando de todas as boas práticas que deveriam ser óbvios pra todo profissional: escrever funções com corpo curto, código bem formatado e legível, como escrever código que lida com exceções, como criar fronteiras claras entre diferentes módulos, como fazer testes unitários, um pouco sobre organização de classes em linguagens orientadas a objetos, noções de design emergente, ou seja, design que emerge à medida que você escreve código, testa e refatora.

Eu diria que se você quer ser um bom profissional, no mínimo tem que escrever código limpo como o Bob Martin ensina E falando em profissionalismo, um livro mais recente dele que lida com temas mais sobre como trabalhar em equipe, como gerenciar tempo, como fazer estimativas e coisas assim é o Clean Coder, ou Programador Limpo. Esse eu mesmo não cheguei a ler, mas pelo pouco que vi, acho que pode ser útil pra quem tá começando na profissão e ainda não sabe exatamente quais são suas responsabilidades perante seus colegas e projetos.

Outro livro com tema similar é um grande clássico que fez 20 anos recentemente, escrito por outros dois agilistas, Dave Thomas e Andy Hunt, o famoso The Pragmatic Programmer. Se o Clean Code e o Clean Coder do Bob Martin são meio que um manifesto do profissional de código, o The Pragmatic Programmer é uma mistura dos dois e tenta explicar a filosofia de um programador pragmático. Eles discorrem sobre como lidar com resolução de problemas de software, tocam em assuntos de agilidade de novo como testes, como escrever código limpo.

Se você assistiu meu episódio intitulado Esqueça Metodologias Ágeis, já sabe que estamos numa era pós-Agile. Os conceitos e técnicas originais de agilidade são simples, mas diversas empresas e consultorias sequestraram o termo “ágil” e inventaram um monte de metodologias e ferramentas burocráticas que nos levaram de volta à época do RUP e UML.

Se você quer saber o que é realmente ser Ágil, deve ler os autores originais e não trabalhos derivados. Em particular Martin Fowler, Kent Beck, Bob Martin, Dave Thomas e Andy Hunt, que são todos os livros que eu recomendei até agora. Leia os livros deles e você vai estar meio caminho andado pra conseguir distinguir ágil de verdade das bullshitagens de coach de consultoria ágil por aí.

Muitos já me pediram pra falar sobre alguns desses temas, como testes. Ainda não sei se vou fazer um video disso porque é um tema tão bem documentado já que você só não aprende se fizer esforço pra ignorar. E repetindo: leia sobre assuntos de agilidade a partir dos autores originais. Quer saber sobre testes? Comece com Kent Beck e seus livros de Extreme Programming, não tem que inventar moda.

Tem três outros livros que vale mencionar. Uma coisa que vocês só vão realmente entender lendo e escrevendo muito código de verdade é sobre a diferença entre design e código e como design emerge a partir do código e de seu uso, como eu já disse. Num primeiro momento, se está começando os estudos, não pense que vai conseguir pré-planejar todos os aspectos de um software antes de escrever uma linha de código. Não vai. E os próximos livros podem confundir vocês nisso.

O primeiro é o clássico Design Patterns, escrito pelo Erich Gamma e sua gangue dos quatro. No tema de achar que dá pra planejar em detalhes antes de codificar, esse é o primeiro livro mal interpretado. Cansei de ver amador com esse livro embaixo do braço querendo pagar de arquiteto e falando bullshitagens como “vamos fazer esse módulo usando alguns decorators pra montar um adapter que vai sair de um factory que vai ser um singleton derivado de um command de um chain of responsability suportado por um observer”. Bleh.

Eu já expliquei isso no fim do meu video sobre como aprendi inglês, mas vou repetir. A tradução do título desse livro em português é “Padrões de Design”. Dá a impressão que esse livro tem todos os padrões, no sentido de as melhores peças, ou as peças definitivas, pra se fazer design de software. O problema é que a palavra “padrão” em português pode ser traduzida em 3 palavras diferentes em inglês, standard, default ou pattern.

Muita gente pensa que “padrão” é o standard. E standard é como você pensou mesmo: um padrão oficial, uma definição definitiva sobre alguma coisa. Mas estamos falando de “pattern”, e pattern é só alguma coisa que se repete muito, independente se é boa ou ruim e definitivamente não é o “padrão definitivo”. O livro de Design Patterns é um catálogo de patterns, de repetições que os autores viram muito em diversos projetos, e simplesmente deram um nome pra eles. Só isso, nada mais, nada menos.

Esse livro foi publicado em 1994, um ano antes de entrar na faculdade. E eu só fui conhecer ele alguns anos depois, lá por 1998. Nesse momento eu já tava programando faz alguns anos e quando vi o livro, em inglês, foi exatamente o que pensei. “Oras, o livro só dá nome pra coisa que já vi várias vezes”. Por exemplo, quem mexia com emuladores naturalmente reconhecia o Design Pattern Adapter. Toda vez que troco a biblioteca opengl do game por um directx é meio que um Adapter.

Design Patterns é um catálogo, e não um manual de como fazer design. Se você já programou tempo suficiente, só vai descobrir que alguns trechos de código que já viu várias vezes por acaso tem nomes, como Singletons, ou Visitors. Esse livro é útil somente pra nos dar um vocabulário comum pra ficar mais fácil pra dois programadores comunicarem um conceito com um nome comum. E ele nem é o catálogo mais completo, existem diversos outros patterns que não estão nesse livro. Vide livros como Patterns of Enterprise Applications Architecture do próprio Martin Fowler.

Falando em arquitetura, outro livro que alguns podem usar errado pensando que é um manual de instruções é o Domain Driven Design do Eric Evans, publicado em 2003. Nas palavras do Martin Fowler, esse livro descreve uma forma de desenvolvimento de software centrado num modelo de domínio que tem um entendimento rico dos processos e regras desse domínio. Em resumo bem resumido, é mais um livro que orienta em como dar nome pras coisas e como organizar essas coisas.

Assim como Design Patterns, ele nos dá novos vocabulários pra descrever sistemas como Ubiquitous Language, Aggregates, Bounded Contexts e outras classificações, mas enxergando mais o big picture de um sistema em vez de só pequenos componentes. Bounded Contexts em particular é interessante porque descreve um pattern que aparece em muitos sistemas.

Por exemplo, imagine que você tem um sub-sistema que tem contexto de Vendas e outro sub-sistema com contexto de Suporte. No de vendas você tem entidades como Vendedor, Oportunidade. No de suporte tem entidades como ticket, defeitos. Mas no bound, na fronteira entre os dois sub-sistemas ele compartilham entidades como o usuário ou o produto.

Começa a ficar difícil de lidar com sistemas que crescem se num sub-sistema você chama usuário de cliente e no outro sub-sistema você chama de comprador, por exemplo. Parte da idéia de DDD é criar um linguagem ubíquita, comum entre desenvolvedores e usuários. Enfim, como eu disse antes, ele se preocupa muito com a arte de dar bons nomes pras coisas. Não é à toa que a gente brinca que uma das coisas mais difíceis da computação é dar nomes pras coisas.

O terceiro e último livro, por incrível que pareça acho que é a cola que une todos os livros de engenharia que falei até aqui. É o famigerado The Lean Startup, do Eric Ries, publicado em 2011. Foi exatamente quando começou a atual bolha de tech startups e esse livro apareceu na hora certa pra se tornar meio que a bíblia das novas tech startups. É um livro meio que de empreendedorismo, é superficial, e por causa disso muita gente interpreta do jeito errado. Próxima pessoa que falar que “validou” a idéia fazendo pesquisa com uma dúzia de pessoas, eu juro que eu chuto.

De qualquer forma, ele fala algumas coisas que são relevantes pra engenharia de software. Você pode estudar orientação a objetos, processos de desenvolvimento de software, metodologias ágeis, como fazer código limpo, como modelar sistemas com DDD, mas se você não entende o mínimo de negócios, seu software sempre vai ser ruim. Porque o melhor software é aquele que resolve problemas do mundo real, e não do mundo teórico.

Um conceito importante que o The Lean Startup ajudou a popularizar foi o de Minimum Viable Product ou MVP, ou simplesmente Protótipo. A ideia ultrapassada, vinda de processos monumentais como RUP da vida, é de tentar fazer o design do melhor software possível, o mais complicado, com mais opções, com maior número de funcionalidades possíveis. Eu não sei se alguém aqui já passou por isso, mas eu já tive que avaliar calhamaços, literalmente pilhas de quinhentas páginas de especificações e diagramas de UML.

Nunca vi um design assim no papel que desse pra traduzir em software, sempre tinha um monte de buracos pelo caminho. É impossível desenhar 100% de um software antes de construir, é sempre mais prático começar com um design mínimo, construir, aprender com os erros e ir estendendo e refatorando, ou seja, fazendo o design emergir do software.

Casos que já vi várias vezes, seja a partir de um software legado já existente ou um MVP, povo sempre fica com a ideia de “agora sim, eu já sei como que o design de verdade deveria ser” e aí segue tentando desenhar a versão 2.0 “perfeita”, e cai na armadilha do “Segundo Sistema” que nosso amigo Fred Brooks já avisou no livro The Mythical Man-Month, que eu já fiz um video inteiro a respeito meses atrás. Dêem uma olhada.

É muito difícil fazer uma lista com TODOS os livros que eu acho que todo mundo deveria ler. Acho que uma lista assim seria impossível. Dependendo da sua escolha de carreira ou mesmo dos seus gostos, alguns são mais interessantes que outros. Essa lista é a que pessoalmente acho que é relevante, embora incompleta, pra maioria. Minha recomendação é sempre ir atrás dos autores originais de um determinado tema, autores que têm mais de décadas de experiência em projetos reconhecidos. Evitar ao máximo derivativos que costumam simplificar demais ou até alterar o que o original dizia.

Mas como eu disse antes, em particular livros de engenharia de software tendem a envelhecer mais rápido do que livros técnicos de ciências da computação. Mas ambos os temas são importantes pra qualquer programador. De qualquer forma, se ficaram com dúvidas mande nos comentários abaixo, se curtiram o video deixem um joinha, não deixem de assinar o canal e compartilhar com seus amigos. A gente se vê, até mais!

06:52 - o que vem depois hello world 09:50 - Apple GPL

DESCRIPTION

Semana passada eu fui pra Miami e resolvi trazer alguns upgrades de equipamento pro canal. No caminho tive que aprender mais algumas coisas sobre fotografia que eu só sabia na teoria mas nunca tinha praticado.

O vídeo de hoje vai ser uma introdução a esses conceitos de fotografia e como eu configurei os brinquedos novos de Miami pra criar um novo “look” pro canal (que só vou mostrar mais pro fim do vídeo, claro)

Semana que vem também vou viajar de novo, então perdoem-me por estar semana sim, semana não com vídeos. Já já vamos voltar ao normal.

Links:

• THE BEGINNER’S GUIDE TO USING GRIDS WITH SOFTBOXES (https://www.diyphotography.net/beginners-guide-using-grids-softboxes/)

• What is ISO? Camera settings explained (https://www.digitaltrends.com/photography/what-is-iso/)

• Understanding Aperture in Photography (https://photographylife.com/what-is-aperture-in-photography)

• Introduction to Shutter Speed in Photography (https://photographylife.com/what-is-shutter-speed-in-photography)

• What is ISO? The Complete Guide for Beginners (https://photographylife.com/what-is-iso-in-photography)

• Photography 101: Crop vs. Full Frame Cameras (https://thewirecutter.com/reviews/the-first-canon-lenses-you-should-buy/)

• Canon EOS Rebel T7i / 800D Specifications (https://www.the-digital-picture.com/Reviews/Camera-Specifications.aspx?Camera=1111)

• Canon 5D Mark III vs Sony A7 II (https://www.apotelyt.com/compare-camera/canon-5d-mark-iii-vs-sony-a7-ii)

• Should I Get the Canon EOS 6D Mark II or the 5D Mark III? (https://www.the-digital-picture.com/News/News-Post.aspx?News=20836)

• FIVE REASONS TO CONSIDER F/1.8 OVER F/1.4 LENSES (https://www.diyphotography.net/five-reasons-to-consider-f-1-8-over-f-1-4-lenses/)

SCRIPT

Olá pessoal, Fabio Akita

Semana passada eu tava viajando, acabei de voltar de Miami. Semana que vem estarei no sul, então vai ter outra semana de intervalo. Este mês tá mais complicado que o normal, acabou juntando viagens e palestras tudo na sequência. Paciência que em breve volto ao normal aqui no canal.

O episódio de hoje vai ser mais simples. Aproveitando que fui pra Miami resolvi tentar fazer mais alguns upgrades aqui pro canal. Se você assistiu meu episódio de um ano que soltei no fim de Agosto já tem uma idéia de como eu produzo meus vídeos. Mas eu ainda queria fazer algumas mudanças. Meu cenário é bem claro como vocês podem ver e eu queria mudar pra um cenário mais escuro, até o fim do vídeo vamos ver se consigo fazer isso.

Hoje vou ser mais geek sobre o equipamento e o que eu resolvi comprar pra ver se melhora um pouco mais a qualidade técnica dos vídeos e também consigo facilitar um pouco minha vida pra gravar e editar. A imagem final não necessariamente vai ficar melhor, mas diferente e eu vou explicar o processo do que eu queria fazer.

O vídeo de hoje vai repetir algumas coisas que já contei no vídeo de um ano do canal pra dar contexto. Pra variar, não vou só mostrar as coisas, quero aproveitar pra registrar o que eu aprendi pra não esquecer. Lembrando que eu não sou fotógrafo profissional, nem tenho treinamento em fotografia, tudo que eu sei eu aprendi sozinho e por isso eu sei que ainda tem várias coisas que eu não sei. Se tiver fotógrafos mais experientes assistindo, não deixem de me mandar mais dicas nos comentários! Enfim, em agosto de 2018 eu ainda não sabia se ia ou não conseguir mesmo manter a frequência necessária pra se ter um canal decente com vídeos no mínimo semanais. Por isso fui colocando equipamentos aos poucos. Eu comecei usando esta DJI Osmo, nenhum motivo em especial, só porque eu já tinha ela. Se não tivesse estaria usando meu celular mesmo, com um tripezinho vagabundo qualquer de 50 reais.

Mas depois de meia dúzia de vídeos, eu senti que comecei a pegar o ritmo, daí achei que era hora de comprar uma câmera de verdade. E sim, câmeras de verdade são BEM diferentes de câmeras de celular, mesmo do seu melhor iPhone 11 Pro ou Huawei P30 Pro. Antes de continuar, vamos repetir o que todo profissional deve estar cansado de repetir: megapixels não significa imagens melhores. Entre uma câmera de sessenta e oito megapixels com um sensor bosta versus um sensor de doze megapixels com um sensor decente, obviamente sempre escolha o sensor decente. Por isso, pelo custo benefício, eu escolhi a Canon Rebel T7i que em outros mercados também é chamada de 800D. Ela é uma câmera de vinte e quatro megapixels, mas ela é crop, não é full frame, é o tal custo benefício que eu falei.

Muitos youtubers melhores do que eu usam uma linha acima da Rebel, como as Canon 5D Mark III ou Canon 6D Mark II que em termos de megapixel é um pouco menos que a Rebel de vinte e quatro pra vinte e dois megapixels se não me engano. Porém, a 5D e 6D são full-frame. Além disso a Rebel grava vídeos de 1080p e a 6D grava 4K. A diferença é que a Rebel T7i custa 800 dólares e a 6D Mark III custa 1500 dólares, é quase o dobro de diferença.

Mas a escolha não foi só o preço. Se eu gravar em 4K só vai aumentar o peso pra edição e o tempo pra processar e exportar o vídeo depois. Ou seja, vai aumentar meu trabalho sem ganhos significativos. Na prática, existem duas grandes vantagens de se gravar em 4K, a primeira é que depois que você faz downsampling de 4k pra 1080p, a imagem vai ficar mais nítida. A segunda vantagem é que eu posso fazer zoom em alguns shots e não perder resolução se eu estabelecer a base de 4K, porque daí consigo fazer zoom de até 2 vezes sem as desvantagens de supersampling.

YouTubers, vamos dizer, semi-profissionais como um Peter McKinnon ou Casey Neistat usam algo como a Canon 5D Mark II ou a Sony A7 II. Na verdade, se você for investir em algo como a 5D eu altamente recomendo ver a Sony A7 II, ela é menor, mais leve, e pra coisas como vlog tende a ser melhor porque ela tem in-body stabilization, enquanto as Canon dependem de estabilização que vem na lente.

Youtubers, vamos dizer, mais profissionais, como o pessoal da Linus Tech Tips, MKBHD, Corridor Digital, usam o topo de linha das câmeras como as Hasselblad, ou BlackMagic que é a mesma que faz o editor DaVinci Resolve, ou as lendárias RED. São câmeras superiores que gravam 6K a 8K, mas uma Hasselblad acho que não tem por menos que 15 mil dólares, as BlackMagic já são mais acessíveis começando lá pelo 1,400 dólares mas você vai precisar de acessórios caros. Já a RED você precisa comprar o Brain que é o núcleo da câmera mais diversos acessórios também como os Mini-Mags de SSDs, o monitor, baterias. Algo como o Gemini Camera Kit pra começar não sai por menos que 27 mil dólares!

Definitivamente são câmeras pra quando se tem 1 milhão de inscritos pra mais com muitos patrocinadores. Como eu disse antes, não é só a câmera, fora o tanto de acessórios caros que essas câmeras exigem, agora você tem um workflow que exige editar videos em 8K que dependendo do codec como o REDCODE ou Cinema DNG ou Apple ProRes e da taxa de compressão pode ser algo na faixa de 200 GB por hora de vídeo e você precisa dar um jeito de editar e processar isso. Agora você precisa de uma workstation realmente potente, ainda mais potente do que o meu que eu já considero muito bom.

Esse é o teto que dá pra chegar, acima disso seriam câmeras como as Arri Alexa que Hollywood usa, mas tecnicamente falando, na grande escala das coisas, eu sou ainda um canal hiper pequeno, então a escolha de equipamentos tem que levar isso em consideração. Voltando ao que eu comprei, pra vídeos curtos, só o que vem na Canon Rebel seria suficiente, mas ultimamente eu ando tendo problemas. Meus vídeos estão começando a estabilizar em 40 minutos pra cima, alguns indo pra cima de uma hora. A bateria de uma Canon eu acho MUITO ruim, eu acho que ela não aguenta mais que uma hora de vídeo. Algumas vezes eu estou gravando, e dependendo do script eu acabo errando e esticando e pode chegar a 2 horas ou mais que eu preciso cortar depois, mas aí chegando perto do fim a bateria não aguenta e a câmera desliga. E quando isso acontece eu fico assim: (XINGANDO)

Primeiro que ele corta o que eu tava falando, daí eu tenho que regravar esse trecho. Mas o que mais me incomoda, pra trocar a bateria eu preciso mexer na câmera, e mesmo tendo cuidado é muito difícil manter a câmera exatamente na mesma posição. Olha só o mecanismo pra abrir o compartimento da bateria.

Esses cliques vão tirar a câmera da posição e se você estiver prestando atenção vai notar quando o cenário desalinha de um shot pra outro. Mesmo que vocês não notem, eu noto, e isso me incomoda muito. Então pra resolver isso comprei esse grip com compartimento pra duas baterias! Pro tamanho dos vídeos que eu gravo, duas baterias é mais que suficiente pra ir até o fim sem eu precisar trocar no meio e isso já me alivia muito!

O próximo item é a lente. As lentes não são só pedaços de vidro num case. As lentes da Canon são motorizadas pra ter estabilização e auto foco, ou seja o que eles chamam de AF Motor. E aqui vem o primeiro erro que eu fiz na minha compra, vocês vão dar risada. Eu jurava que estava usando a 50mm f/1.8 e por isso comprei uma 50mm f/1.4. Porém só quando voltei que fui ver que na verdade eu já estava usando a f/1.4 então no final acabei ficando com duas lentes …. Puta burrice. De qualquer forma, vou aproveitar a deixa pra falar um pouco sobre o que aprendi sobre lentes.

Lentes 50mm dizem que é uma das melhores pra coisas como portrait ou retrato mas mais do que isso ela é boa porque parece que é a que mais se assemelha com como nossos olhos vêem então deve ser mais natural. A lente que vem com a câmera também pode ser ajustada pros 50mm já que ela tem um range de 18-55 mas o f-stop dela é maior em f/4 ou seja, não é boa pra ambientes pouco iluminados, daí aqui no meu quarto eu sou obrigado a aumentar o ISO ou o shutter speed. Vou falar disso já já.

Aliás, se você queria saber a diferença de full-frame e crop, ou seja, entre a 5D e a Rebel T7i, é que a lente de 50mm na minha câmera na realidade seria como uma lente 80mm numa full-frame, ou seja, quase um short telephoto. Agora fodeu né? Relaxa, não é tão difícil assim. Deixa eu tirar a lente da câmera.

Olhem no centro, este é o sensor da câmera. Esta é a parte mais importante da câmera, aliás, NUNCA, JAMAIS enfie seu dedo nojento e gorduroso em cima do sensor. É este sensor que vai se sensibilizar com a luz e captar a imagem. Ela é que define os megapixels, por exemplo. Quanto mais luz cada pixel receber, melhor vai ser a imagem, essa é a regra. Por isso mais megapixels não se traduzem em imagem melhor se ela não recebe mais luz por pixel. Veja o tamanho de um celular em comparação, o sensor dela é muito menor, ou seja, a área física que recebe luz por pixel é muito menor.

Numa câmera full-frame, de cara você vai ver que o sensor é maior. Fora isso a câmera se chama “crop” porque ela faz um crop do frame completo. Por isso cada fabricante tem um fator de multiplicação, no caso da Canon é 1.6 então você precisa multiplicar a distância focal, no caso de 50mm, por 1.6 e por isso eu disse que a 50mm na realidade seria equivalente a uma lente 80mm numa full frame. Aliás, distância focal é a distância da lente pro sensor.

E isso é outra coisa que me confundia no começo. Maior distância focal não é só zoom. Existe diferença entre zoom e telephoto. Zoom pode ser wide-angle ou telephoto. Mas a maioria das pessoas acaba chamando quando tem mais milímetros de telephoto. Eu achei um exemplo bom no Quora pra explicar.

300mm é telephoto mas não é zoom porque ele tem longa distância focal mas não cobre um range de distâncias focais, por exemplo, não dá pra ir pra 250mm ou 400mm, é o que se chama de lente prime, que só cobre uma distância focal.

Uma lente 10-20mm não é uma lente telephoto mas é zoom, porque cobre um range de 10 a 20 mas com baixa milimetragem, por isso é wide-angle. Uma lente de 18mm não é nem telephoto e nem zoom porque é de baixa milimetragem e não tem range. Poderíamos chamar de lente prime wide-angle.

Já uma lente tipo 18-200mm é estranho. Ela é uma lente com zoom porque tem range mas pode ser considerada tanto wide-angle a 18mm quanto telephoto a 200mm.

Enfim, telephoto é bom pra esportes por exemplo, quando você tá na arquibancada e quer tirar a foto da cara do jogador em campo. Por isso você vê aquelas lentes gigantes na frente da camera, porque ele precisa de uma distância focal enorme pra conseguir enxergar tão longe. E por isso nenhum celular, por si só, tem capacidade de telephoto.

Pra dar uma idéia, a câmera da minha Samsung S10e só tem 12mm com f/2.2 de abertura. Aliás, é hora de falarmos de abertura, porque é grande diferença em lentes, eu achava que estava com a f/1.8 por exemplo mas era a f/1.4. A primeira coisa que sempre me confundiu é essa maldita medida de f-stops. Na prática aperture ou abertura é exatamente o que o nome diz, a abertura do shutter ou objetiva que é por onde a luz vai passar quando você aperta o botão de shutter. Quanto maior, mais luz passa.

No artigo que vou deixar linkado nas descrições abaixo você tem uma explicação melhor e mais detalhada mas na prática pense na objetiva fechada. Agora divida a área por esse número de f-stops, por exemplo, na lente padrão acho que ela é f/4 então a abertura seria um quarto dessa área. Se fosse uma lente f/16 seria 1 dezesseis-avos, ou seja, um buraquinho bem pequeno por onde passa pouca luz. Então num f/1.4 seria a área dividida por 1.4, ou seja, um buraco bem maior do que a metade da área por onde passa mais luz.

Então, um f-stop grande significa uma abertura menor, menos luz, e um campo de profundidade maior, em inglês seria large depth of field, onde você vê nítido tanto objetos próximos quanto objetos à distância como prédios ou montanhas. É bom pra ambientes iluminados, fotos de natureza, com muito sol. Daí a abertura tem que ser menor, ou a imagem vai ficar clara demais e vai estourar os brancos por causa de exposição demais à luz, que é o que chamamos de over-exposed.

Quando tiver um f-stop pequeno, como essa minha lente de f/1.4 a abertura é bem maior, então entra o máximo de luz possível, e também oferece um campo de profundidade mais raso, em inglês seria o tal shallow depth of field, onde você tem objetos próximos mais nítidos mas tudo no fundo fica blur, borrado, que é o tal efeito bokeh ou bokah que os celulares começaram a oferecer com o tal modo retrato ou portrait.

Só que em celular é um blur artificial feito digitalmente recortando a pessoa e aplicando blur digital no fundo, por isso o efeito é normalmente ruim se comparado a uma lente de abertura grande de verdade. E com abertura grande significa também que entra mais luz, mesmo em ambiente com pouca luz, como fotos durante a noite ou em ambientes fechados e pouco iluminados. Novamente, os celulares oferecem o tal night mode, que é outro processamento digital tirando várias fotos e recombinando pra conseguir extrair o máximo de detalhes mesmo com pouca luz. Aberturas grandes custam mais caro e por isso camera de celular normalmente são f/2 ou no máximo f/1.8.

Isso é um dos motivos de porque recomenda-se a lente 50mm f/1.8, pois ela tem abertura grande suficiente pra maioria das fotos em lugares menos iluminados e oferece o tão desejado efeito bokeh de verdade, sem processamento digital. Uma lente dessas tá na faixa dos 100 dolares. Agora qual a diferença desses 0.4 f-stops? 200 dólares! É isso mesmo, uma lente 50mm f/1.4 custa uns 300 dólares.

Deixa eu fazer outra tangente em fotografia. Exposição de fotos estão fundadas em três grandes pilares: aperture, ISO e shutter speed. Aperture eu acabei de explicar, basicamente objetiva que abre mais ou menos e deixa entrar mais ou menos luz. ISO varia de 100 a 12000 ou 50 mil em lentes mais caras ou 100 mil em lentes mais caras ainda. Mas ela é tipo você ir no Photoshop e aumentar o brilho ou exposure, você consegue tirar fotos em lugares escuros e aumentar o ISO se a imagem estiver muito escura, só que a contrapartida é que quanto mais você aumentar o ISO mais cheia de noise e grain ela vai ficar, sabe aquela sujeira digital que aparece em imagens escuras?

Pois é, idealmente você quer estar o mais próximo possível de ISO-100, raramente você quer subir pra mais que ISO-1000, eu não sei onde ISO acima de 12 mil é útil porque eu não sou fotógrafo, mas no meu caso acho que eu estou em ISO 600 ou 800 e pro meu caso acho que isso já é limite.

Quanto maior for a abertura, ou seja, quanto menor for o f-stop como meu f/1.4, menor pode ser o ISO e melhor vai ser a imagem, em ambientes escuros. Em ambientes claros uma abertura menor, ou seja f-stop 2 ou acima vai deixar entrar luz suficiente e também seu ISO pode ser menor. Idealmente, se você vai filmar ou tirar fotos em ambientes escuros, de noite principalmente, menor tem que ser o f-stop da lente, então esta minha lente 50mm f/1.4 seria boa pra tirar fotos mais nítidas a noite, evitando eu ter que subir o ISO demais.

A terceira variável é shutter speed. Aqui depende do efeito e da situação. Shutter speed é quanto tempo a objetiva vai ficar aberta coletando luz. Ela é medida em frações de segundo como 1 dividido por 4000, ou seja a objetiva fica aberta por 1 quarto de milisegundo. Shutter speed faz mais diferença quando você tá tirando fotos ou filmando objetos em movimento, tipo uma corrida, ou animais ou pessoas e você quer que apareça o blur do movimento na imagem em vez de congelar o movimento e tirar uma foto nítida de um instante do movimento.

Quanto mais lento for o shutter speed, ou seja, quanto mais tempo a objetiva fica aberta, mais desse movimento é registrado em cada frame, e isso causa blur de movimento. Quanto mais rápido for o shutter speed mais nítido é a imagem em movimento e menos blur. Aqui eu não tenho ainda muita sensibilidade de qual o melhor shutter speed pro meu caso, mas na prática, quanto mais rápido for o shutter speed, maior você quer que seja a abertura, porque o tempo pra luz entrar vai ser menor. Então a lente f/1.4 teoricamente deve ser melhor pra conseguir imagens mais nítidas de coisas em movimento também, onde você vai querer shutter speeds cada vez mais rápidos, sem aumentar o ISO.

Em resumo, você quer o menor ISO possível, sempre. Você quer a maior abertura possível, ou seja, menor f-stop, principalmente se quiser tirar fotos a noite, e você quer escolher shutter speeds rápidos pra imagens mais nítidas a menos que queira um efeito mais artístico de blur de movimento. As câmeras tem diferentes modos pra te ajudar, no padrão ele vem no modo automático, onde a câmera vai escolher shutter speed e aperture automaticamente pra você.

Pra maioria dos casos simples isso deve ser suficiente pra amadores como eu. Daí existe o modo manual, onde você deve escolher tudo manualmente, ISO, shutter speed, aperture e outras configurações de balanço de cor e tudo mais. Mas existem modos intermediários como o modo AV que é o modo Aperture-priority autoexposure, onde eu posso escolher o aperture manualmente e a câmera vai escolher o shutter speed e eu acho que vou testar mais esse modo, assim como também tem o modo TV que é Shutter-priority Autoexposure, onde eu poderia escolher o shutter speed e a câmera escolhe o aperture mais adequado.

Eu sou amador então eu estava usando o Creative Auto, que é um pouco menos automático mas eu deixo a câmera escolher o shutter speed e aperture. Como eu estou usando um softbox com muita luz e vocês podem ver que o ambiente fica bem claro, então mesmo no modo automático a câmera não precisa subir o ISO e por isso não fica com sujeira ou noise na imagem. Eu acho que ele deve manter o shutter speed por volta de 60, ou seja 1 sessenta-avos de segundo a um ISO de uns 200 usando o f/1.4 máximo da lente. Nas modificações que estou testando vou começar a usar modo manual mesmo e já já vou explicar como estou configurando tudo isso.

O desafio é escolher o exposure, a exposição adequada, ou seja, quanto de luz vai atingir o sensor e como. Quanto mais luz é melhor até o ponto onde não fique over-exposed. Mas você quer que o tempo de exposição seja o mais curto possível pra ter imagens nítidas. Falando em estático, quanto mais devagar for o shutter speed menos você pode mexer a câmera e vai precisar de um tripé. No meu caso eu quero evitar blur o máximo possível. O correto na realidade não é forçar os limites da câmera e da lente pra sugar a pouca de luz que eu tenho no meu quarto. Em vez disso a coisa mais óbvia que se precisa num ambiente de pouca luz é colocar mais luz. E agora a coisa fica mais complicada.

Você não quer qualquer luz, você quer luz soft e direcionada, ou seja, key light através de um difusor. Manipular a luz é uma ciência em si só. Desde o começo eu venho testando algumas luzes, mas na maior parte dos episódios do canal eu estou usando este softbox barato que comprei no mercado livre, e hoje ela tem quatro lâmpadas brancas fluorescentes de uns 1000 lumens cada. Isso seria mais ou menos equivalente a uns 16 watts por lâmpada. Existem diversos tipos de lâmpada, como lâmpadas incandescentes de tugstênio, halogênio, LED e assim por diante.

Quando se fala em luz pra estúdio, a maioria dos YouTuber semi-profissionais vai automaticamente dizer Aputure. É uma marca altamente reconhecida e toda vez que eu pesquiso esbarro neles. E o produto mais recomendado é o Aputure Light Storm C120D II, um canhão de LED voltado pra temperatura de luz do dia a 5500 kelvin e com capacidade de iluminação de 135 mil Lux. É a luz perfeita pra ser key light de qualquer YouTuber, especialmente se combinar com filtros opcionais como Fresnel.

O problema é que ela custa nada menos que uns 700 dólares. Assim como eu não preciso ainda de câmeras Blackmagic ou RED eu também ainda não preciso de uma Light Storm. Só se um dia eu decidir usar um estúdio mesmo. Felizmente existem outras opções, e eu achei a marca Godox. A mais ou menos equivalente à 120D II seria a Godox SL-200w.

A 120D tem LEDs de 180 watts e a Godox tem LEDs de 200w e custa quase a metade do preço, entre 300 a 400 dólares. Mas mesmo assim eu não preciso de tanta luz assim, as minhas pobres lâmpadas fluorescentes são só uma fração disso e iluminam razoavelmente bem. Aliás, as Aputure tem lâmpadas de tungstênio e LEDs, acho que a 120D é LED e a 120t é tungstênio ou algo assim, mas posso estar dizendo besteira.

Por isso eu escolhi esta Godox SL-60 watts, que deve ser mais ou menos equivalente às lâmpadas que já tenho. Isso aumenta minhas opções de trabalhar a luz a 100 dólares. Nada mal. E isso porque meu espaço é pequeno. Mas mais importante do que só a luz é o difusor e por isso eu resolvi parear essa Godox com um domo difusor da Aputure, o Light Dome Mini II. De novo, o ideal seria a versão maior, mas eu não ia conseguir trazer na mala então escolhi a mini mesmo por agora. O que eu achei interessante foi que eles incluíram o grid pra colocar na frente do difusor.

Aqui mais um pouco de tangente pra explicar. A luz que sai de uma fonte como uma lâmpada ou LED, pense nela como se fosse uma substância saindo em forma de jato direcionada pra frente. Quando ela bate em você ela vai projetar uma sombra bem definida, dura, ou “hard”. Pra situações como a minha, luz na minha cara diretamente, isso destaca demais os defeitos faciais, buracos na pele, espinhas, ou qualquer coisa que torna a superfície irregular. Ela define suas características de forma muito dura, sombra do nariz, da boca, do pescoço. Luz hard é uma luz que mostra tudo, mais do que devia.

Pra melhorar essa cara feia aqui, começamos colocando um modificador. Modificadores são coisas como um Fresnel, space light, barn doors, no meu caso começo com o Light Dome e na frente dele um difusor. Assim o tal jato de luz que sai da lâmpada reflete no modificador e é quebrado no difusor que vai dividir essa luz pra tudo que é direção diferente.

Ela diminui a intensidade desse jato e ao mesmo tempo aumenta a área de iluminação porque agora a luz vai pra tudo que é lado, e por isso se diz que a luz vai ao seu redor, e com isso as sombras se tornam mais suaves e todos os seus defeitos também se tornam mais suaves, e por isso você pensa que eu sou muito mais novo do que eu realmente sou, porque essa luz apaga muitos defeitos. E é assim que eu venho filmando até agora.

Mas pro meu caso, o problema da luz ir pra tudo que é direção, como o meu softbox antigo também já fazia, é que ela ilumina meu cenário inteiro. Isso pra mim sempre foi um inconveniente porque eu acho que meu ambiente fica meio boring, chato, sem contraste entre as camadas da frente e de trás. Por isso eu coloquei os leds coloridos lá atrás pra deixar o fundo um pouco mais interessante.

Mas existe um segundo item que eu posso colocar na frente do difusor, que é um grid, e a função do grid é devolver controle, pra onde a luz vai iluminar. Ela ainda vai ser uma luz soft mas agora direcionada mais pra mim e menos pro fundo. Em teoria, no meu caso, isso deveria me destacar mais do que o fundo, criando duas camadas na composição. Além de colocar o grid que já veio no Light Dome Mini, eu também resolvi trocar o tripé que eu estava usando por um tripé girafa. A idéia é que em vez da luz ficar na minha frente, eu quero colocar ela mais pra cima de mim, dessa forma a luz vai ficar direcionada mais pra mim e menos pro resto do ambiente. Então deixa eu trocar meu softbox antigo por esta nova configuração e vamos ver no que dá.

(TESTE DE LUZ)

O que acham? Acho que todo fotógrafo e videógrafo profissional vai concordar que não tem nada mais importante do que o key light, e eu acho que a combinação desse Godox SL-60w com o Aputure Light Dome Mini deve ser o upgrade mais interessante até agora, embora isso tenha deixado minha configuração mais complicada e a qualidade da imagem não necessariamente tenha ficado melhor. O problema é que do ponto de vista da lente, o ambiente ficou de fato mais escuro. Como eu já estava usando o máximo da abertura em f/1.4, pra não subir o ISO e manter ela em 100, eu fui obrigado a diminuir o shutter speed de 60 pra 30.

Eu passei horas e horas testando essa configuração, mantendo o aperture fixo em f/1.4 eu comecei tentando aumentar o máximo do shutter speed pra mais de 500 pra ver se a imagem fica mais nítida. Mas aumentando o shutter speed tem menos tempo pra luz entrar e por isso eu era obrigado a aumentar meu ISO pra 1600. Só que eu já falei que aumentar o ISO aumenta a sujeira na imagem. O ideal é o ISO estar em 100. E a única configuração que chegou nisso foi shutter speed em 30 e isso mantendo a ilumintaçao da Godox em 100%. Eu preferia conseguir manter a luz da Godox em 50% ou menos, talvez aumentar o ISO pra uns 200 ou 400 e aumentar o shutter speed pra 125 a 250.

Só que nenhum dos testes que eu fiz com todas as combinações dessas variáveis me deixou muito contente. Então até eu testar mais vezes, por enquanto vou manter o Godox em 100%, o aperture em f/1.4, o ISO fixo em 100, e o shutter speed fixo em 30. Aqui é a hora que se alguém que tem mais experiência quiser mandar sugestões, não deixe de comentar abaixo.

Eu sempre quis meu fundo mais escuro mas isso significa forçar mais a câmera. A idéia da nova luz foi ter um difusor direcionado mais em cima de mim e com mais força mesmo colocando um grid na frente, por isso a Godox. Uma desvantagem que eu não sabia é que o Godox tem uma ventoinha barulhenta pra caramba e por isso eu preciso aumentar o filtro de redução de barulho em pós-produção, no Premiere. No futuro um upgrade seria trocar a ventoinha dele pra uma da Noctua por exemplo, que é mil vezes mais silenciosa. Aumentando o filtro de som em pós provavelmente a qualidade do som pode cair um pouco, espero que não dê pra notar.

Finalmente, vamos ao terceiro e último upgrade, e a segunda coisa mais importante depois da luz: o som. Muito antes de começar o canal, quando eu só tinha idéias de um dia gravar alguma coisa, eu já sabia que o som seria fundamental e eu também sabia que o som gravado num mísero celular ou mesmo em qualquer câmera como minha Canon Rebel seriam medíocres. No mínimo eu precisaria ligar um microfone com cabo ou wireless direto na câmera e deixar esse microfone o mais perto possível da minha boca. Mesmo gravando num ambiente fechado, sem barulho ambiente, como vento, e com pouco eco, só a distância de mim até a câmera já é suficiente pra garantir um som porcaria.

Por isso desde o primeiro episódio eu gravo o som separado num gravador com um microfone de lapela da Sony. Eu mostrei no episódio de um ano que eu uso este gravador da Tascan DR-05. Não chega a ser um problema mas é um inconveniente ter que gravar separado porque eu continuo gravando o som na câmera pra servir de referência pra sincronizar com o áudio do gravador e eu preciso fazer essa sincronia em pós-produção, na edição. É um passo extra que não consome tanto tempo porque a sincronização do Premiere é bem rápida, mas é um passo extra e mais uma variável pra causar problemas. Por exemplo, mais de uma vez eu tive problemas em esquecer de ligar o gravador numa pausa. Lembra que a câmera tem um tempo limite de 30 minutos? Então, a cada 30 minutos eu preciso religar a gravação do video e do áudio, e adivinha se eu já não esqueci de religar o áudio. Quando isso acontece eu tenho que falar tudo de novo. Quando eu vejo que não está gravado eu saio assim (XINGANDO)

A outra opção é um microfone wireless ligado direto na câmera e sendo gravado junto com o vídeo. Existem boas opções pra isso como o Senheiser 112P com microfones Lavalier pra ligar na câmera. Mas, como tudo até agora, essa opção é tudo menos barato. Iria me custar uns 600 dólares. Outra marca muito reconhecida é a Rode, muita gente usa o Boom Kit deles. Se você não sabe o que é um microfone boom é aqueles que fica em cima da gente usando um tripé girafa e que a gente coloca numa posição em cima da cabeça e que não aparece no vídeo.

Eu pensei em usar um boom kit mas eu fiquei com medo dele gravar eco junto e eu não estava muito a fim de encapar todas as minhas paredes com placas acústicas pra cortar eco. Sem contar que agora essa Godox faz um barulho enorme e ia ficar bem do lado do Boom. A Rode também tem outro produto que muito YouTuber usa, o RodeLink Wireless Filmmaker Kit, que é um microfone sem fio que eu posso colocar perto de mim e outro componente que liga na entrada de áudio da câmera. O problema é que esse kit não sai por menos de 400 dólares, não muito longe da opção da Senheiser.

Mas recentemente a Rode lançou um novo produto, o Rode Wireless Go, que é este conjunto de dispositivos. Essa parte vai ligada em cima da câmera e esta outra parte fica junto de mim. É um conjunto sem fio. Claro, a qualidade técnica é menor do que o Filmmaker Kit ou a Senheiser mas ela custa só 200 dólares. E eu comprei também este microfone de lapela Rode smartLav+ Omnidirecional Lavalier de 65 dólares com o adaptador 3.5 milímetros Rode SC3 de 15 dólares.

Ou seja, uma solução de 280 dólares versus uma solução de potenciais 600 dólares por uma qualidade razoavelmente similar pra substituir meu gravador Tascan de 100 dólares. Andei fazendo alguns testes e eu até acho que o som da Tascan é um pouco melhor e mais encorpado, e isso faz sentido considerando que é um equipamento dedicado só pra processar e gravar áudio. Mas considerando o passo extra que estou cortando na produção, é menos trabalho e menos possibilidades de eu errar, e isso já compensa.

Pronto, agora sim, som novo, luz nova, lentes novas, e é esta a nova qualidade técnica do canal pelos próximos meses. Em resumo então o upgrade inclui o pack de baterias pra câmera, o canhão de luz Godox SL 60w com o Light Dome Mini II da Aputure, o tripé girafa que eu comprei aqui no Brasil mesmo porque era grande demais pra trazer na mala, o Rode Wireless Go com o microfone de lapela Lavalier. O que vocês acharam? Fez alguma diferença esse novo estilo visual?

Eu também ia trocar o teleprompter por um Glide Gear TMP-500 mas esse foi o único item que a Amazon errou e me mandaram outra coisa nada a ver. E aqui vai uma diferença grande da logística nos Estados Unidos. Na mesma hora que eu recebi e vi que estava errado, entrei no site e cliquei em Refund. A UPS vai buscar no hotel onde eu estava, eu não preciso fazer mais nada, e em alguns dias o valor retorna pro meu cartão de crédito. Posso estar errado, mas se fosse no Brasil, eu ia precisar ir pessoalmente nos Correios pra mandar de volta, o que seria um puta saco. Pra qualquer e-commerce ir pro próximo nível a gente precisa de uma UPS que vem até aqui em casa buscar, não faz nenhum sentido eu ter que me deslocar até uma agência de correios pra devolver um ítem que foi entregue errado. Ter que ir até uma agência é muito anos 80.

De qualquer forma, fiquei contente com essa nova configuração. Ah sim, e por último uma coisa que esqueci mesmo de mencionar no episódio de bastidores de um ano, eu acabei de explicar sobre difusão da luz, mas não é só isso. Pra ajudar eu também uso outro truque que é este pó branco na cara. Isso é outro componente que ajuda a suavizar os defeitos dessa cara feia. Some isso à luz soft e o efeito é que parece que você tem pele boa, na verdade é tudo truque.

Enfim, tudo que falei hoje é aspecto técnico. Equipamentos não fazem um canal, é o conteúdo que faz e a forma de apresentar esse conteúdo. Não importa quantos milhares de dólares de equipamento você gaste se essa parte não está resolvida primeiro. Da mesma forma um Macbook Pro caro Não vai te tornar um bom programador. Um Porsche não vai te tornar um bom motorista. O máximo que um bom equipamento pode fazer é ajudar a ir um degrau mais longe se você já subiu os mil degraus anteriores da prática e do conteúdo. Eu só comprei esse equipamento todo depois de mais de um ano fazendo videos praticamente toda semana. E eu só comecei o canal quando eu acumulei mais de 20 anos de conteúdo e quase uma década de prática falando em público pra ter certeza que eu ia ter coisas úteis pra dizer que não é só copy e paste do que se acha facilmente googlando um pouco.

Como eu disse no começo, eu não sou nem fotógrafo e nem videógrafo profissional, eu ainda sou nível junior aqui e mesmo depois de muitas horas recombinando e reconfigurando tudo, ainda não está 100%, então se você tem dicas de como eu posso usar melhor ainda esses equipamentos novos, não deixe de mandar nos comentários abaixo, se curtiram o vídeo deixem um joinha, compartilhem com seus amigos pra ajudar. E não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódio. Provavelmente semana que vem de novo não vai ter vídeo porque vou viajar de novo. Então mais um motivo pra clicar no sininho pra serem notificados quando eu soltar os próximos videos. A gente se vê, até mais!

Finalmente!! Chegamos a 1 ANO do Canal Akitando!

Foi uma jornada incrível, absolutamente difícil, eu praticamente me coloquei na missão de fazer o equivalente a 1 palestra completa, densa e detalhada, TODA SEMANA ao longo de 1 ano inteiro!

Quero compartilhar com vocês um pouco de como eu pensei no conceito do canal, como eu produzo os vídeos e um pouquinho de bastidores.

O vídeo de hoje não tem nenhuma grande missão a não ser comemorar! Obrigado a todos vocês que acompanham o canal e espero que continuem compartilhando os vídeos pra que esse acumulado de informações consiga chegar a mais pessoas.

Continuem compartilhando os videos pra ajudar o conteúdo a chegar a mais pessoas!

== Links:

• Instagram: nova lente Canon 50mm (https://www.instagram.com/p/BopuVbIlDmy/)

• Instagram: teleprompter quebrado (https://www.instagram.com/p/BnSlwbLFKvu/)

• Instagram: Tascam audio recorder (https://www.instagram.com/p/BnNSxYflB_c/)

• Instagram: Softbox (https://www.instagram.com/p/BnCmByVFn-A/)

• Instagram: lente 50mm chinesa - hórrível (https://www.instagram.com/p/Bmt1wlxlQhr/)

• Instagram: Canon Rebel EOS T7i (https://www.instagram.com/p/Bmg9hrClWIE/)

• Instagram: Meu 1o setup (https://www.instagram.com/p/Bmb6pr7FEm5/)

• Workstation Rocketz (https://rocketz.com.br/workstation)

• AkitaOnRails: Transcripts dos episódios (https://www.akitaonrails.com/akitando)

=== Script

Olá pessoal, Fabio Akita

Se eu não errei minhas contas, o canal completa um ano esta semana. Eu tinha algumas metas na minha cabeça quando comecei o canal e hoje é o dia de falar dos bastidores. Acho que a meta mais interessante é a quantidade de inscritos, no momento que estou gravando este video o canal está com mais de 26 mil inscritos. Ainda tá longe de eu ganhar uma plaquinha, mas quando comecei o canal eu tinha na cabeça que se eu conseguisse chegar em 10 mil assinantes depois de um ano, já seria suficiente. Então eu diria que mais do que o dobro da minha meta não é nada mal. Obrigado a todos vocês pela ajuda e espero que continuem compartilhando os videos pra ajudar a levar o conteúdo pra mais gente.

Este canal não é a primeira vez que eu busco canais diferentes pra compartilhar meu conhecimento. Quem me acompanha faz tempo já leu os posts do meu blog, já deve ter ouvido o podcast de Ruby on Rails que eu fazia com o Carlos Brando ou minhas participações no Grok Podcast do camarada Rafael Rosa, os screncasts de Git e Vim que soltei em 2011, o primeiro livro de Ruby on Rails em 2007, enfim, é meio que uma obsessão pessoal documentar as coisas que aprendi de alguma forma. Eu acho um desperdício ter aprendido um monte de coisas que até hoje não são tão óbvias e esse conhecimento acabar em mim quando eu morrer.

Todo mundo já deve ter tido vontade de escrever um livro. Se você assistiu meu episódio sobre o Diário de Henry Jones, já sabe que eu sempre quis. Nos anos 2010 a mídia é video, e o canal é YouTube, então o objetivo foi começar a dar um dump do meu cérebro em forma de video. Vocês já devem saber que os videos não são monetizados e nunca foi objetivo eu tirar meu sustento do canal no futuro nem nada disso. Inclusive vocês vão notar que eu sequer uso pra fazer propaganda das minhas próprias empresas, porque eu quero que os videos sejam atemporais, que se você assistir em 2030 eles continuem valendo. Espero que o YouTube dure até 2030. Por isso também já recusei algumas propostas de patrocínio. Agradeço a quem teve interesse mas eu não quero colocar coisas no video que se tornem obsoletas com o tempo, como anúncios.

Na realidade o objetivo original do canal é que um dia eu termine. Ainda não tenho certeza de como as coisas vão andar, mas se for conforme eu visualizei um ano atrás, em breve vai acabar as coisas que eu tenho a dizer, e quando escrevi o primeiro episódio meio que comecei um rascunho do que seria o último capítulo também. Mas vou dizer que quanto mais gente aparece pra assistir menos me dá vontade de terminar o canal, então vamos ver.

(…)

Todo mundo quando pensa em bastidores de video começa imaginando um Adobe Premiere, ou Final Cut X e eu editando os diversos clips. Como eu já disse no episódio sobre os problemas que tive com o Premiere um mês atrás, a parte da edição na realidade é a mais fácil. A parte difícil começa antes. Quando eu sei o que eu quero escrever eu simplesmente sento na frente do computador, abro o Google Docs, e começo a escrever como se não houvesse amanhã. Se for um dia que eu estou na zona de concentração, eu consigo escrever 20 páginas de word de uma só vez. É a melhor sensação do mundo. Em particular, estou escrevendo os episódios 56, 57 e 58 tudo de uma só vez, meio porque eu já sabia o que queria falar.

O problema são as semanas que eu não tenho tanta certeza sobre o que dizer. Eu assisto dezenas de canais do YouTube e achei engraçado quando vi um no canal do Gigguk que fala de animes. Assim como eu, ele também escreve scripts antes e o processo dele é muito parecido com o meu, então olhem como a gente faz pra escrever scripts:

(…. video gigguk ….)

Pois é, a parte mais chata é escrever os episódios. Muitos episódios eu escrevo e reescrevo múltiplas vezes. Eu estou na página 6 ou mais, e resolvo que tudo que eu escrevi tá uma droga, apago tudo e começo tudo de novo. Vários episódios foram assim. No começo do canal eu ainda não tinha idéia de quanto tempo os videos deveriam ser. Algum lugar alguém falava que o ideal eram vídeos de não muito mais que 10 minutos, ou 15 minutos no máximo. Isso são umas 6 páginas de Word. Por isso vocês vão ver que meus primeiros vídeos são curtos.

Eu também odeio, odeio o formato de vlogs ou simplesmente videos que o autor dilui o conteúdo demais. Sério, tem videos por aí que entre apresentação, introdução, propaganda, leva uns 5 minutos pra chegar no assunto do vídeo, daí esse assunto é super simples e dava pra resumir em um slide de 30 segundos, mas aí ele dilui mais ainda esse conteúdo pra mais 5 minutos e finalmente leva outros 5 minutos fazendo gracinha e piada sem graça. E assim foram 15 minutos jogados fora. Horrível, fora o pacing lento, ritmo irregular, dicção ruim, áudio não normalizado que fica saltando o volume toda hora. Horror, horror.

Se eu ia fazer um video de 15 minutos eu faço questão que no mínimo 14 minutos sejam de conteúdo, e não mais que 1 minuto pra apresentação, intro e finalização. Eu como consumidor de conteúdo prefiro esse formato então é assim que eu ia fazer.

O nome do canal veio numa conversa com o povo do escritório. Eu ia gravar no meu quarto, como gravo até hoje, então num momento cheguei a pensar em “No quarto com o Akita” …. Éee eu sei! Felizmente camarada Harry deu a idéia de fazer o nome como um verbo e virou Akitando. Com o nome definido eu procurei algumas intros pré-prontas de After Effects, comprei, editei e assim você tem a intro que aparece em todos os videos. E o formato seria um Olá pessoal logo no começo e direto ao assunto. E no final eu queria parodiar fazendo a mesma coisa que todo YouTuber faz que é pedir o joinha e pra assinar o canal, e no final acabou ficando no formato também.

Os primeiros videos foram bem experimentais. Eu queria aproveitar que tinha acabado de começar uma peregrinação pelo mundo de blockchain, tinha acabado de lançar minha própria exchange de criptomoedas e comecei fazendo um vídeo sobre minha viagem pra Coréia do Sul. Assisti alguns tutoriais de Premiere, achei um site de teleprompter que é o easyprompter e coloquei no monitor. Como câmera eu tinha uma DJI Osmo que serve como estabilizador mas como eu não tinha uma câmera de verdade e nem tripé pro celular, acabei usando esse DJI como câmera, por isso a composição e foco são bem diferentes dos videos de hoje. Eu coloquei o DJI na frente do monitor e ficava lento o monitor atrás dele.

Os primeiros videos foram feitos assim, a camera na frente do monitor e lendo. Foi horrível fazer assim porque obviamente a camera uma hora ficava na frente do texto passando atrás. Mas eu ainda nem sabia se ia continuar com o canal mesmo ou não. Apesar de eu já ter estabelecido o conceito que eu não ia monetizar o canal e que não importava quantas pessoas assistissem, eu só queria tentar gravar alguma coisa, mesmo assim publicar o video e não ter mais que algumas pessoas assistindo, dói um pouco. Porque pra fazer cada video demora algumas horas de trabalho. Todo canal começa do zero, zero pessoas, zero views, zero interesse. Inscritos, visualizações e likes são métricas de vaidade, eles não são e não devem ser o objetivo, mas todo mundo gosta de ter um pouco mais de visualizações.

Enfim, independente disso, com zero views ou não, o processo de fazer um video realmente era divertido. Mas com o equipamento que eu tinha até então tava difícil. Foi quando decidi investir em comprar uma câmera de verdade, nada super fancy, só uma Canon EOS Rebel T7i e um teleprompter de verdade. No 6o video só que comecei a usar o novo equipamento, e já melhorou um pouco a qualidade mas a lente padrão que vem na câmera era bem ruinzinha. Então comprei uma lente 50mm chinesa via mercado livre que usei em alguns vídeos, mas vocês vão ver que a qualidade da imagem era uma droga. Acho que foi só no video do Diário de Henry Jones que comecei a usar a lente 50mm original da Canon e o auto foco é ordens de grandeza melhor. Daí venho usando a mesma configuração de câmera desde então.

Um bom video de conteúdo deve ser feito com um teleprompter, a menos que seja show ao vivo, claro. Todo bom YouTuber profissional deve planejar o conteúdo antes de apresentar. Eu acho um desrespeito sair filmando de qualquer jeito e ficar só enchendo linguiça. Eu não gosto de perder tempo e também não quero que quem assista meus vídeos perca tempo. Por isso eu gasto tempo escrevendo e refinando os scripts e depois uso um teleprompter. A dificuldade foi acertar a velocidade do prompter. Os primeiros videos ficaram mais lentos do que eu gostaria, levou alguns videos pra achar a velocidade certa, que na verdade é a velocidade máxima que eu consigo falar e manter a dicção correta sem mastigar palavras. Eu gosto de pessoas que falam corretamente, então o mínimo que eu devo fazer é falar o mais corretamente possível pra que todos possam entender.

O problema de usar um teleprompter é que ele é um sistema de espelhos e uma câmara escura. A gente coloca o tablet deitado, tem um espelho em 45 graus que vai refletir o que tem no ipad pra que eu possa ver mas não reflete pra dentro que é onde a câmera está posicionada, dentro de uma câmara escura. O segredo de uma boa imagem em qualquer câmera é dar a ela o máximo de luz possível e esse setup na realidade reduz a quantidade de luz que chega na câmera.

Eu também prefiro filmar de noite, depois das 20h pra garantir que tem menos movimento no prédio, nos vizinhos, na rua. Meu apartamento felizmente é bem vedado contra som, mas mesmo assim dá pra ouvir alguma coisa. Eu odeio barulho de fundo, então só me resta gravar de noite mas não tão tarde que eu fico com sono. Já notei que quando eu filmo com sono minha dicção piora bastante, daí eu sou obrigado a repetir vários trechos do texto, várias vezes e demora bem mais pra gravar.

Somando o prompter e filmar de noite, significa que eu preciso de luz artificial, muita luz artificial. Eu comecei com um ring light mas ele é muito fraco e só depois eu entendi que esse ring light é pra pessoas que querem aparecer com os olhos brilhantes. Mas como eu uso óculos isso nem ia funcionar. Finalmente comprei um bom soft box, que é um difusor de luz, e testei vários tipos de lâmpadas frias e finalmente consegui uma configuração de uns 4 mil lumens, que é o mínimo que meu ambiente precisa pra câmera conseguir captar boas imagens. O ideal seria ter mais um softbox com a mesma potência, mas por enquanto eu estou usando o ring light do meu lado esquerdo fora do frame pra criar edge light, que é uma delineação de luz no meu rosto de um lado.

(apagar ring light)

Falando no ambiente, meu quarto é um quarto normal, branco, tédio. Aos poucos fui colocando alguns elementos pra tentar criar camadas na composição. Vocês já devem ter visto meu lava lamp que não funciona no fundo. Eu quebrei o primeiro e comprei um segundo que não funciona. E falando em quebrar coisas, já quebrei um ou dois teleprompters na real. Eles ficam num tripé e são pesados em cima, então gravar com sono a noite tem outro problema além da qualidade: você esbarra nas coisas e quebra, pois é.

Recentemente eu resolvi comprar leds pra colorizar o fundo. Eu já tava de saco cheio do fundo branco. Outro erro que cometi aprendendo a editar foi errar no color grading, eu queria tentar deixar a imagem um pouco mais quente e exagerei em alguns videos que vocês podem ver que são um pouco demais alanranjados ou avermelhados. Só alguns meses atrás que eu finalmente acertei o color grading pra algo mais neutro, com mais saturação. Veja a diferença do que a câmera grava e de como fica quando eu coloco a correção de cores. Até aqui você está vendo com correção, agora vamos remover a correção …… e …. Colocar de volta, viram a diferença?

Ah sim, e vocês devem ter visto meus amiguinhos de pixel art que eu sempre deixo no fundo. Finalmente vou mostrar em maior qualidade. Eu comprei eles na Comic Con do ano passado, que aliás é onde eu comprei todas as camisetas que eu uso no canal. Todo mundo me pergunta onde comprei, e foi em lojas como Piticas, Geek, Riachuelo, e outras marcas que não lembro agora, e alguns eram exclusivos pra Comic Con então não se acha fácil. Além disso eu tinha comprado algumas em galerias da Liberdade também, como no Sogo. Este ano eu vou na BGS e na Comic Con de novo então vou acabar comprando mais camisetas suficientes pros videos do ano que vem.

Com o tempo também eu fui acertando a posição da câmera. Antes aparecia uma parte da minha cama, eu preciso jogar ela pro fundo do quarto pra dar distância pra câmera. Com o tempo eu achei uma composição que não preciso mais mostrar a cama. E com as luzes de fundo fica algo um pouco mais abstrato e com texturas. Não sei se todo mundo gosta, mas eu acho que pelo menos cria uma identidade diferente do que só um fundo branco. Eu particularmente não gosto de fundo verde e chromakey feito com câmeras como a minha. Eu só usaria chromakey num ambiente maior, onde eu posso jogar spots de luz no fundo verde pra tirar as sombras e mais softbox na minha frente com uma câmera 4K de verdade onde posso ajustar melhor a separação. Um dia eu vou tentar fazer isso mas não vai ser com esse equipamento e nem no meu quarto. Se um dia eu mudar pra um estúdio aí sim. Não tem nada pior que um chromakey amador, que fica cheio de aliasing nas bordas tipo cabelo, acho horroroso e jamais faria com o equipamento atual.

Uma coisa que realmente dá trabalho na edição é ficar toda hora pesquisando google images e outros bancos de imagens e mesmo capturar algum clipe de video pra colocar do meu lado no video. Eu sempre escrevo os textos já assumindo alguma ajuda visual pra reforçar algumas partes do que estou falando e dar referências pra quem está assistindo. E é um dos motivos de porque eu não transformo meus vídeos em podcasts. Muita gente pediu esse formato, mas eu não pretendo fazer agora porque eu escrevi todos os scripts assumindo a midia de video. Sem isso só o audio fica incompleto. Eu teria que reescrever os scripts considerando uma midia só audio e realmente não tenho tempo pra fazer isso agora.

A mesma coisa é sobre gravar uma versão em inglês. Seria o dobro de trabalho, e eu realmente não tenho tempo pra fazer isso agora. Uma coisa que pretendo fazer a partir de agora é começar a liberar os textos dos scripts no meu blog. Estou protelando isso faz algum tempo, mas é mais preguiça do que qualquer outra coisa. Daí se alguém se interessar em contribuir, poderia adicionar legendas em inglês por exemplo, eu ia achar bem da hora se alguém tivesse tempo pra fazer isso.

A gravação é feita em etapas, em clipes de no máximo 30 minutos porque as câmeras fotograficas como a Canon que eu uso, pra poder ser considerada uma câmera de fotos na Europa, não pode gravar clipes de video maiores que 30 minutos. É mais uma dessas regulamentações que a Europa adora inventar. O que eu faço é deixar meu celular conectado na câmera e me mostrando o que a câmera está vendo e aí eu fico monitorando o tempo e páro antes dos 30 minutos. O problema era quando eu gravava com sono como eu falei e esquecia de verificar o tempo. Várias vezes eu ficava falando que nem um idiota achando que tava gravando mas a câmera tinha batido nos 30 minutos e parou de gravar… Quando eu via que não gravou os 20 minutos que eu fiquei falando a mais, dá aquela vontade de pegar a câmera e jogar no teto.

Eu cheguei a comprar um capturador da Elgato pra ligar a câmera diretamente no computador e capturar o feed, que é o que os streamers de Twitch fazem. Mas eu nunca confiei muito nesse setup, fora que meu computador ligado faz barulho e eu preferia não ter que editar o barulho depois, então ainda estou gravando direto na câmera só. Outra coisa que eu faço é usar um gravador de áudio bom, no caso eu tenho esse Tascan que eu ligo um microfone de lapela simples da Sony. A câmera grava o áudio ambiente mas é um áudio porcaria que não dá pra usar, mas serve como referência pra sincronizar com o áudio melhor. Áudio é extremamente importante, uma imagem ruim é até perdoável, mas se o áudio for ruim todo mundo pára de ouvir. Por isso eu acho o equipamento de áudio e a acústica do ambiente muito mais importante do que a câmera. Felizmente tenho pouco eco no meu quarto então não precisei colocar placas pra cortar eco.

No geral, se eu estou inspirado, um script leva entre 4 a 8 horas pra ficar pronto. Algo na média de 20 páginas de word revisados. Depois eu levo algo entre 1 hora a 1 hora e meia pra gravar. Finalmente mais umas 5 a 8 horas pra editar o video. Primeiro eu sincronizo o video da câmera com o áudio do Tascan. Coloco um adjustment layer pra adicionar a correção e graduação de cores, e agora vou cortando fora os trechos que eu errei e toda pausa entre parágrafos pra ficar o mais compacto e linear possível. Depois do rough cut eu começo a assistir e vou adicionando os elementos visuais e efeitos especiais se precisar. E só no final eu escolho uma trilha sonora pro começo e pro fim do video. Antes, quando os videos eram mais curtos, eu tentava manter uma música tocando em background pelo video inteiro, mas eu já percebi que sou muito ruim pra acertar a música e o volume em todo episódio, teve vezes que acertei, teve vezes que errei, mas no fim já vi que não é necessário ter música pela maior parte do video, por isso reduzi.

Aqui entra também o workstation que eu comprei pra editar. Faz muita diferença. Eu noto uma diferença clara na responsividade do Premiere se rodar nesse workstation ou se rodar no meu notebook, que não é fraco, sendo um Thinkpad X1 Extreme. Um vídeo de uma hora no meu workstation leva tempo real ou menos pra renderizar, ou seja no máximo uma hora. Mas no meu Thinkpad o mesmo video pode levar quase 2 horas. E quando você está terminando de editar 1 hora da manhã, essa 1 hora faz muito diferença, especialmente se você erra e precisa renderizar de novo. Eles não me patrocinam mas eu comprei a workstation online na Rocketz, que tem configurações muito boas pra quem mexe com edição de video ou renderização 3D profissionalmente e precisa de uma máquina decente. Fiquei surpreso quando depois de comprar recebi um e-mail do dono da Rocketz dizendo que já lia meu blog. O mundo é mesmo bem pequeno!

Finalmente, eu escolho um frame do video e uso em cima de um template de thumbnail que eu fiz no Photoshop. Escolho uma cor diferente por video, só no final eu decido qual vai ser o título, e daí a última coisa a fazer, normalmente 2 horas da manhã é subir o video pro YouTube, subir o thumbnail, descrições, cards e é isso aí, tudo pronto!

Todo mundo diz que é fácil começar a ser YouTuber, que basta pegar seu smartphone, gravar de qualquer jeito e subir. E de fato, se você for algum desses com carisma natural, talento de presença de câmera e tempo de comédia ou algo assim, talvez consiga mesmo atrair audiência mesmo com baixa qualidade técnica. Mas isso é exceção, não é regra. Dá pra começar barato, mas precisa investir o quanto antes se quer levar isso a sério. E não espere ganhar a vida fazendo YouTube, isso é super raro de acontecer e eu não recomendo como carreira. Se eu tivesse aberto monetização eu ainda não estaria ganhando mais que alguns poucos reais por video, e não estou nem falando centenas de reais, eu diria que seria menos que isso. No meu caso eu já disse que não tenho expectativa nenhuma de ganhar a vida no YouTube. Eu estou usando o YouTube pra hostear meus videos e só, meu único objetivo é fazer meus videos do jeito que eu quero fazer, independente se vai atrair muita gente ou não, porque pra mim é como se eu estivesse escrevendo um tipo de biografia, com começo, meio e eventualmente um fim.

A vantagem do jeito que eu estou fazendo é que eu já tenho mais de 40 anos, eu já tenho uma carreira que está ótima, eu economizei, acumulei recursos e finalmente tenho tempo pra poder contar sobre experiências e pesquisas de verdade. Como eu falei nos meus videos, tudo tem seu tempo. Eu não vejo nenhuma vantagem de falar sobre programação quando eu ainda nem tinha anos de experiência suficiente. Eu gosto de ver gente que tem experiência falando. Se for pra ver tutoriais básicos, eu leio um post de blog ou a documentação oficial, não precisa de video pra isso. Por isso eu quis falar sobre coisas que não se encontra facilmente por aí.

E também por isso chegou uma hora lá no começo que eu estava fazendo 2 videos de 15 minutos por semana, resolvi fazer um video semanal de 30 minutos. Quando eu vi que ninguém reclamou, fui subindo, 40 minutos, 45 minutos, 50 minutos e alguns batendo uma hora. O video de Ubuntu tem uma hora e vinte quase e é o segundo video mais assistido do canal nos últimos tempos. Portanto eu vou fazer os videos do tamanho que eu quiser mesmo. Na prática, quem prefere videos mais curtos pode simplesmente pausar e continuar depois. Se eu fosse obrigado a manter os videos no tamanho de 15 minutos o de Ubuntu teria levado umas 5 semanas pra todo mundo ver tudo. Isso é muito devagar! A série de Começando aos 40 que levou mais de 10 semanas pra ficar pronto teria levado 30 ou 40 semanas pra publicar tudo, eu teria ficado o ano inteiro falando só disso. É muito tedioso! Eu quero falar de outras coisas rápido.

E tudo isso é uma faca de dois gumes. Porque num formato longo eu me vejo na obrigação de quase escrever papers em cada script. Eu não queria só dizer “é assim que as coisas são e pronto” eu quero explicar em detalhes o processo de como se chega nessa conclusão, e aí os scripts vão ficando mais e mais complicados. O da semana passada por exemplo compila num único script argumentos que saíram de mais de meia dúzia de livros diferentes. E eu escrevi tudo em 2 dias. Pensa a dificuldade de lidar com esse tipo de densidade de informações de uma só vez. Por isso mesmo eu acho que nesse design, uma hora essa série vai ter um último capítulo.

No começo do canal eu tentei falar de outros assuntos como filmes, mas acho que eu não tenho vocação pra falar desse tipo de conteúdo, então vou me focar nos temas que eu me sinto mais a vontade falando, que são os videos que vocês viram durante este ano. E se você ainda não assistiu todos eu recomendo que veja, eu estou fazendo de um jeito que sejam complementares uns aos outros, especialmente todos a partir de janeiro de 2019. Se você assistir em sequência eles vão fazer mais sentido.

E é isso aí, é assim que eu penso sobre meus videos e como eu produzo. Espero que tenha satisfeito a curiosidade de vocês e, claro, se ficaram com dúvidas não deixem de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios especialmente porque vou tirar uma pausa de 2 semanas este mês por conta do evento The Conf e outras palestras, mas eu volto em breve. Aproveitem pra assistir os videos do canal que ainda não assistiram e compartilhem com seus amigos pra ajudar o canal. A gente se vê, até mais!

No episódio sobre Ubuntu pra Devs da semana passada, quem me acompanhou pelas redes sociais (que é @akitaonrails em todas) viu que eu passei por um perrengue pra conseguir editar o vídeo e isso me custou uns 2 dias de atraso. Por isso o vídeo foi entregue só na sexta-feira e eu dormi mal duas noites.

Neste vídeo quero falar duas coisas. A primeira é explicar o que aconteceu e como eu resolvi o problema, pra quem tem interesse em edição de vídeo aprender também.

A segunda coisa é usar esse episódio pra refletir sobre como eu penso sobre resolução de problemas de modo mais amplo, sobre o processo investigativo e sobre a avaliação das minhas próprias capacidades, e como vocês também podem usar os mesmos conceitos quando encararem problemas difíceis e inesperados.

Se você me mandou mensagens no Insta, talvez veja sua mensagem no video hoje :-) Vou agrupar as sugestões em categorias e explicar porque elas não funcionam. Mas calma, não vou criticar não!

== Links

• Screencasts Liberados Gratuitamente! (https://www.akitaonrails.com/2012/04/09/screencasts-liberados-gratuitamente)
• Iniciando com Git (https://www.youtube.com/watch?v=jdinE9SkUnE&list=PLevVxVF0KI-DZM6IyBXop7FV6nJeC90hd)
• From the Macbook Pro to the Dell XPS. Arch Linux for Creative Pro Users (https://www.akitaonrails.com/2017/01/31/do-macbook-pro-para-o-dell-xps-arch-linux-para-usuarios-criativos)

== Videos antigos (em private)

• Rubyconf 2014 Website Teaser (https://youtu.be/yhqDBekgISU)

• Speakers Rubyconf 2014 Teaser (https://youtu.be/g8mpq30qlAI)

• Rubyconf Brasil 2014 - Teaser Trailer (https://youtu.be/vzYEsj1Ze4A)

• AMV - Rurouni Kenshin - Sanbum - capturado de VHS (https://youtu.be/EzidwCO-L2I)

• Mesmo AMV só que reeditado com clips um pouco melhores (https://youtu.be/PCrg29XEA1c)

=== Script

Olá pessoal, Fabio Akita

O último vídeo sobre ambiente dev em Ubuntu deu bastante trabalho pra fazer e parece que vocês gostaram! Em dois dias ele já ultrapassou os views do vídeo anterior. E isso porque o diabo tem uma hora e vinte minutos! Esse vídeo foi bem sofrido de fazer e me custou aproximadamente umas 40 horas de trabalho.

Eu tive um problema técnico que me fez quase varar 2 noites e atrasou o lançamento em quase 2 dias, por isso acabei lançando só sexta feira passada. Meio que sem pensar eu fui compartilhando o que estava acontecendo nas stories do meu Instagram e Facebook, então quem me segue nas redes sociais viu acontecendo em tempo real. Aliás, se vocês ainda não me seguem, agora é uma boa hora pra fazer isso!

Como curiosidade de bastidores eu fiquei com vontade de explicar o que aconteceu e como eu resolvi o problema, se por acaso vocês tenham interesse de como funciona um Adobe Premiere, mas em paralelo eu pensei no video de hoje por causa dos comentários que alguns de vocês me mandaram em privado. Como esse vídeo é dividido meio que em duas partes, se a parte mais técnica de edição de vídeo não interessa tanto, pulem pra este tempo aqui embaixo pra ir direto pra segunda parte.

Alguns me deram boas dicas, outros mandaram sugestões enlatadas kkk Eu sei que alguns foi piada pra quebrar o gelo e nenhum foi com má intenção. Porém achei um bom gancho pra um tipo de recomendação que se vocês ainda não ouviram, vão ouvir centenas de vezes durante toda a carreira de vocês. E em como você organiza um pouco a resolução de problemas técnicos, que vai ser válido se você for programador também.

(…)

Então, o que diabos aconteceu? Como background, eu comecei o canal em Agosto de 2018, este é o episódio 55 então eu já editei mais de 50 vídeos em 1 ano. Mas essa não é a primeira vez que eu edito vídeos. Eu já editava videos de forma ainda mais amadora no passado. Em 2010 eu experimentei com a ideia de tentar vender cursos em video, eu fiz uns 3 videos que divulguei pelo meu blog, eu acho que cobrei R$ 10 reais? Não lembro.

Foram os videos ensinando Git, outro ensinando Vim e uma palestra. Porém, o volume de compra foi tão baixo que ficou claro que eu não ia ganhar a vida vendendo video, então eu liberei os videos gratuitamente logo depois. Vou deixar os links nas descrições abaixo caso alguém tenha interesse em ver video velho. Apesar de não terem viralizado nem nada, até hoje eu ainda encontro pessoas que falam que aprenderam Git por esse video. Não lembro se foi o de Git ou de Vim mas um deles tinha umas 3 horas de duração. Se por acaso você aprendeu Git ou Vim por esses vídeos mandem nos comentários abaixo!

Antes disso, vira e mexe eu brincava de fazer curtas. Por exemplo, quando eu organizava a Rubyconf Brasil eu fiz alguns videos pra divulgação. No fundo era mais uma desculpa pra eu brincar com isso. Eu gosto de fazer essas coisas faz anos. A primeira vez que vi edição de video foi quando amigos meus faziam AMV ou Anime Music Video no fim dos anos 90 usando dois VCR, sim VHS mesmo. Fitas de video tinham duas trilhas, uma de video e outra de audio e era possível em alguns gravadores de video mais caros gravar as trilhas separadamente, então dava pra colocar um VHS no primeiro player, gravar o trecho de video no segundo e ir concatenando os pedaços de video um atrás do outro e no fim adicionar o audio de uma vez na trilha separada. Aliás, de curiosidade eu disse que eu comecei este canal em Agosto de 2018 mas se você olhar no About do canal vai ver que ele está aberto desde Junho de 2007. Eu devia ter aberto um segundo canal, mas eu só escondi os videos aleatorios que eu subia aqui pra começar a subir os do Akitando. Os links do music video e videos de Rubyconf que eu mencionei ficavam aqui e vou manter privado pra não poluir o canal mas vou deixar os links nas descrições se alguém tiver curiosidade de ver.

Eu mesmo cheguei a conseguir um capturador de video pra PC que eu ligava o VCR e fiz meu primeiro AMV numa das primeiras versões do Adobe Premiere lá por 2000 ou algo assim. E desde então eu sempre me interessei por isso no nível de hobby, eu nunca cheguei a tentar ganhar a vida com isso. Edição de video digital segue o mesmo principio até hoje. Numa fita você podia ter 2 trilhas, uma trilha de video e outra de audio. É a mesma coisa digitalmente, mas você pode editar em múltiplas trilhas pra ser compilado em uma no final. As coisas avançaram bastaram nos últimos 20 anos. Codecs foi uma delas. Eu queria fazer um video falando só de Codecs de audio e video, mas só de pensar que ia virar um video de 3 horas eu desisto kk Um dia, um dia …

Enfim, eu ainda vou fazer um video só sobre os bastidores do canal, mas eu posso dizer que a parte de editar os videos é a que menos dá trabalho. Normalmente eu levo uma média de 5 a 6 horas entre começar a editar, exportar, fazer upload, colocar os cards e fazer thumbnail. Em videos mais simples que não tem tanta imagem pra procurar e colocar eu demoro menos. Ultimamente eu gravo o video domingo ou segunda, daí chego em casa terça e começo a editar lá pelas 19h e até 1h ou no máximo 2h terminei tudo. Agora, o video da semana passada de Linux, só a parte de edição deve ter levado mais de 20 horas!

O sintoma foi assim: eu comecei a editar normalmente como sempre faço. A diferença desta vez é que tinha um video mais longo, de 3 horas, que foi a parte que eu capturei com o programa OBS. São todas as cenas do Ubuntu, que eu gravei da minha tela seguindo o script. As partes onde eu apareço e o audio que acompanha as telas eu já tinha gravado antes. Eu vou recortando e editando de acordo com o script. A gravação da tela ficou com 3 horas porque tem muita parte do apt install e compilação das linguagens que é basicamente ficar esperando até terminar. Se vocês assistiram o video devem ter visto que eu acelerei bastante essas partes pra vocês não ficarem esperando.

Então eu fui cortando, sincronizando o audio com a gravação da tela. Aos poucos eu notei que o preview ia ficando um pouco lento pra iniciar, tipo um lag. Mas fui indo mesmo assim e chegou uma hora quando eu tinha editado uns 50 minutos de video que eu não conseguia fazer mais nada. Qualquer coisa travava a interface e eu tinha que fechar forçado o Premiere inteiro e reiniciar. Simplesmente não conseguia mais editar.

O script que eu escrevi foi o mais longo até agora. Na média meus scripts tem umas 10 páginas de Word. Os mais compridos que eu já tinha feito era umas 20 páginas. Mas dessa vez eu me superei e escrevi nada menos que 30 páginas. Eu falei que gravo domingo ou segunda, mas desta vez eu já estava atrasado. Eu deixei pra terminar de escrever, gravar e editar tudo na terça que foi feriado, na minha cabeça eu tinha estimado que ia dar tempo pra soltar na quarta como sempre. Porém chegou na terça de noite e começou a acontecer essas travadas. Quem nunca passou por isso? Tá tudo andando bem, você vai cumprir o prazo que estimou, mas aí aparece uma situação que você não esperava, um bug inesperado ou um problema de BIOS mesmo, e aí seu prazo vai pelos ares.

Fica a dica: quando isso acontece, como meu sócio diria, Inês é morta. Além disso vale lembrar: eu sou amador em edição de video. Eu nunca trabalhei profissionalmente com video. Então eu sou no máximo nível junior. E junior sempre se fode. Eu sei os 20% sobre edição de video que resolve 80% dos meus problemas e eu consigo entregar os videos toda semana. Lembram que eu expliquei esse conceito no meu video de Devo Fazer Faculdade, versão de 22 anos depois? E eu disse que pra resolver os últimos 20% vai precisar dos 80% de conhecimento que eu ainda não tenho. Essa regra é quase uma lei. E uma hora eu ia passar por isso. Qualquer um que trabalha com video profissionalmente vai ver o que aconteceu e dar risada porque foi um erro trivial pra quem é sênior nisso.

E sim, eu sei que no Preview você deve fazer ele apresentar em metade ou um quarto da resolução se o video original for 1080p ou até 8 ou 16 vezes menor se a resolução original for 4K pra cima. Também sei que é pra desabilitar alta qualidade. Também me certifiquei se a configuração de memória estava adequada com o máximo de memória reservada pro Premiere. Chequei se o cache de media estava apontando pro HD mais rápido porque eu tenho um SSD SATA-3 Samsung EVO como drive principal mas ainda tenho um HD mecânico como drive secundário.

Também chequei se por algum acidente ele estava usando o renderizador de preview Mercury via software que usa OpenGL. Como eu tenho uma placa de video decente que é a Nvidia GTX 1070Ti o certo é usar a versão do Mercury que usar CUDA que é o jeito programático de usar os cores da NVIDIA. Se estiver em Mac ou estiver usando placas AMD como as Radeon ou Vega, o certo é escolher o OpenCL.

E por último, eu sempre crio as sequences com a mesma configuração do video principal que estou editando, ou seja, mesma resolução, mesma taxa de quadros por segundo. Tudo isso estava ok como deveria. Então não era problema de configuração. Aliás, bônus pra você porque todo video ou artigo sobre otimizar Premiere que você procurar vai dizer exatamente esses mesmos pontos que acabei de falar então já te economizei pesquisa.

Engraçado que as primeiras idéias que vem na cabeça eu até sei que a probabilidade é baixa, mas o lado geek quer tentar elas primeiro. O OBS grava por padrão os videos em H.264 mas ele coloca no envelope MKV, o Matroska. Diferente do MP4 que é o container padrão hoje em dia, derivado do Quicktime da Apple, o Matroska é muito flexível pra ser um container universal de dezenas de codecs. Por isso o suporte a MP4 costuma ser mais estável, porque ele é mais restrito então fica mais fácil de dar suporte. Ao contrário, suportar Matroska direito é mais complicado. Hoje em dia, eu até acho que um editor como o Premiere não deveria ter problemas com isso.

Mas, eu resolvi tentar fazer Proxy files. Isso era uma feature do Premiere que eu sabia que existia mas nunca tentei usar. A idéia de Proxy é que se você filmar numa camera profissional da RED ou da Hasselblad como os YouTubers profissionais fazem, ele vai gravar arquivos de 8K. É impossível editar 8K em tempo real e ter preview, especialmente se adicionar efeitos por cima como Adjustment Layers pra color grading e color correction. Por isso o comum é exportar os videos 8K em resolução mais baixa que 1080p ou Full HD. Só que fazer isso manualmente pra todo clip seria muito trabalhoso então o Premiere oferece a opção de Proxies. Daí você edita na versão de baixa resolução mas na hora de exportar ele vai usar os originais.

Problema de fazer proxy é que tem o tempo de exportar os videos. Pensa que demorou quase 1 hora pra exportar o video de 3 horas de captura de tela do OBS. E pensa que já tinha passado da 1 da manhã quando tentei fazer isso. Péssima opção porque durante 1 hora eu não podia fazer nada. Daí terminou e, claro, não fez diferença nenhuma. Interessante que eu tentei mudar pro renderizador via software em vez de via GPU e aí ficava tudo lento mas pelo menos não travava a interface. Fiquei contemplando a idéia de editar tudo lento mas pelo menos não crashear. Mas isso seria um inferno porque ainda tinha mais meia hora de video pra editar das 2 horas restantes de material. Depois de ficar tentando outras coisas já tava dando 5 horas da manhã, então resolvi ir dormir pra conseguir ir pro escritório de manhã.

E aqui vai outra dica: eu demorei mais do que devia, o certo era ter ido dormir antes. Eu não posso julgar quem faz isso porque passei a vida inteira varando 1 ou 2 ou até 3 noites sem parar às vezes. Mas não adianta, todo mundo falava a mesma coisa pra mim e eu nunca ouvia. Especialmente quando a gente é mais novo, a tendência é achar que temos stamina infinita, ainda mais se for arrogantão como eu que tem confiança que não importa o problema, sempre vou conseguir resolver. Enfim, lembre-se que é sempre melhor dormir quando já tá tarde e você tá travado.

Fui dormir com uma suspeita, pensei nisso durante o dia seguinte, e quando cheguei em casa voltei pra editar. Como eu expliquei antes, tinha os clips onde eu estava acelerando os videos pra vocês não ficarem esperando, as partes de instalação e compilação. Eram trechos que eu queria mostrar sem cortes, só acelerado. Só que pra caber em 10 segundos eu precisava acelerar 1000 porcento, mil e quinhentos porcento, às vezes 6000 porcento! Mesmo sem estar em cima desses clips, o preview de nada funcionava e travava tudo.

Parece um bug na realidade, porque pelo menos os clips sem efeito deveria tocar o preview, por isso eu não tinha certeza. Mas daí eu imaginei que devia ter uma forma de pré-renderizar os clipes com efeitos como esse de aceleração. E de fato tem, aprendi só nesse dia sobre o recurso de Render and Replace que é parecido com a idéia de Proxy, mas ele vai usar o mesmo render na exportação final também. Serve pra clips com efeitos complicados que também custam caro de dar preview em tempo real. E eu tinha dezenas de clipes acelerados. Podia ser mais uma aposta que ia me custar o tempo de esperar renderizar tudo mas fazia sentido.

Eu tinha feito isso em alguns clipes na noite passada também e por isso só fui dormir 5 da manhã. Mas também não deu diferença nenhuma, a timeline continuava travando tudo. Mas na minha cabeça tinha que funcionar. Não fazia sentido não funcionar. Primeiro pensei que podia ser o codec. De repente se eu usasse um codec que não comprimisse tanto não usaria muito processamento pra fazer o preview então fiquei entre o GoPro Cineform e o Apple ProRes. Ambos ocupam espaço pra caramba mas acabei escolhendo o ProRes, e eu sei que foi um canhão pra matar uma mosca. Mas aí que me toquei que tinha um maldito checkbox que renderiza com os efeitos aplicados.

Duh, óbvio que na noite anterior não tinha feito diferença nenhuma renderizar porque acelerar o tempo do video é um efeito, e até mais caro do que eu pensava, e se não marcasse esse checkbox ele estava só trocando seis por meia dúzia, de um codec pra outro, mas o efeito ainda tava sendo processado em tempo real. Dito e feito, umas 2 ou 3 horas fazendo Render and Replace, o preview ainda estava com um lag de 6 a 10 segundos mas pelo menos tocava e não travava tudo!

Daí segui uma dica que me deram no Instagram. O cara que mais me deu dicas úteis foi o limas, aliás se estiver assistindo valeu por me ajudar! Não sei o nome dele, o usuário é Limas então vou chamar de Limas. Ele fez certinho, ouviu os sintomas e fomos por eliminação em possíveis causas. Ele trabalhou com edição de video e a última coisa que eu fiz que ajudou bastante foi criar uma segunda sequence já que mesmo não travando mais ainda tinha o lag de 6 a 10 segundos que falei antes. Daí eu conseguia ir editando novos trechos, recortar e colar na sequence principal. Na segunda sequence o preview funcionou em velocidade máxima, na sequence principal mesmo depois de renderizar todos os efeitos ainda dava o tal lag, então teria sido super sofrido se tivesse que continuar assim, mas com a segunda sequence em velocidade normal eu consegui prosseguir sem dores de cabeça.

Além de dormir, outra dica muito importante, quando você trava num problema é falar com alguém. Não é obrigatório que essa pessoa tenha a capacidade de resolver seu problema. Só que não diga muita besteira de volta. Só de repetir o que você mesmo disse já ajuda. E mesmo que algumas das sugestões não ajudem, não importa.

Esse diálogo faz parte do processo investigativo, eu falo comigo mesmo quando não tem ninguém por perto, mas não é a mesma coisa. Se eu for ser mais técnico, quando você tem um problema difícil de resolver o método socrático pode ajudar, é uma forma de diálogo onde você leva a pessoa à resposta fazendo perguntas simples pra guiar o processo investigativo. Você já viu algo parecido se assistiu séries como House ou qualquer adaptação de Sherlock Holmes, é pra isso que serve o Watson, a segunda metade do método socrático.

É um dos motivos de porque eu falo que se você é iniciante ou inexperiente, não vá direto pro caminho de ser freelancer ou trabalhar home-office. Você precisa de outra pessoa pra dialogar, não necessariamente só pra te ensinar, mas pra ser o espelho no seu processo de aprendizado. Outra dica, se na emergência você está sozinho e não tem ninguém pra dialogar, escreva no papel todos os sintomas e hipóteses, mesmo as mais triviais. Não é eficiente, mas vai ajudar a colocar as peças no lugar. É o equivalente ao que você também já viu em séries como CSI ou séries de investigação jornalística onde o investigador vai colocando as pistas num quadro e vai ligando com um barbante.

De qualquer forma, mesmo assim teve 2 bugs na edição, logo depois da intro acabou ficando um pequeno espaço preto que vocês nem devem ter notado, e na seção que inicio falando de Docker faltou uns segundos de áudio. Eu coloquei na errata nas descrições do video. Mas considerando o tamanho do video e o tanto de problema, até que ficou bom. Em resumo, o problema todo foi não ter tido a noção que acelerar video é um efeito que pode ficar caro e um conjunto grande de clipes com esse efeito por alguma razão cria lag na timeline inteira da sequence, e isso parece um bug do programa.

Agora, a segunda parte deste video foi justamente os comentários dos usuários. Primeiro de tudo, agradecimentos a todo mundo que ficou acompanhando meu sofrimento nas stories do Insta e mandou mensagens de apoio! Tirando o Limas que teve uma paciência de Jó de ficar pensando comigo, todo mundo que mandou sugestões infelizmente errou. Mas eu não estou aqui pra criticar não, porque eu sei que todo mundo só mandou alguma coisa porque se importou em tentar ajudar. Mas eu quero salientar que muitas das respostas são conclusões automáticas que muita gente tem pra vários outros tipos de problemas. E muitos, perigosamente, levam isso a sério.

Se eu for resumir, as sugestões tinham 3 padrões: os que assumiam que eu precisava de uma máquina ou algum componente melhor ou mais potente, os que lembraram que eu uso Windows então já vieram falando que eu devia usar Mac, ou os que sugeriam que eu mudasse do Premiere pra Final Cut do Mac ou Da Vinci Resolve ou Sony Vega. Aliás, curioso que duas pessoas me falaram do Vega, e eu nunca tinha ouvido falar.

Muita gente chega nas mesmas conclusões pra todo problema, incluindo em programação: 1) trocar pra hardware mais potente; 2) trocar de sistema operacional; 3) trocar de ferramentas. Tirando casos extremos, raramente qualquer uma dessas três respostas deve ser a primeira da lista, na realidade eu diria que seriam as últimas opções. O raciocínio que vou usar agora serve não só pro meu caso imediato de edição de video mas pra tudo, incluindo programação, então acompanhem pra entender e usem pro seu dia a dia também.

Trocar de hardware raramente ajuda. O raciocínio é simples: muito filme muito mais complexo já foi editado em hardware muito inferior ao meu. Eu tenho um PC que comprei especificamente pra editar video, e como eu disse no video anterior, você não precisa disso se for iniciante, mas no meu caso eu tenho a escolha de comprar mais do que preciso, então montei uma torre com Core i7 8a geração com 6 cores e 12 threads, tenho 32 GB de RAM, 1 Terabyte de SSD mais 2 Terabyte de HD mecânico secundário, uma placa GTX 1070Ti com 16GB de VRAM e um sistema de watercooling da Corsair pra CPU nunca ter thermal throttle, que é quando a CPU derruba o clock quando detecta temperaturas muito altas. Quem mandou mensagem não sabia necessariamente disso. Mas mesmo se fosse um notebook mais fraco, não seria esse o caso. Em todos os 30 anos que fui programador, o hardware raramente me impediu de fazer alguma coisa. Podia funcionar mais lento, mas não crashear. E o sintoma que falei é que tudo trava, não que fica lento.

O segundo caso é a reputação de estabilidade de Mac e Linux comparado à má reputação que o Windows acumulou ao longo dos anos. E isso começou principalmente com o Windows Me ou Millenium que foi o pior sistema operacional nos anos 90. O Windows 2000 ajudou a não derrubar a reputação porque ele era estável, como o Windows NT 4 antes dele. O Windows XP era usável em 2001 mas manter ele vivo por tantos anos destruiu a reputação. A demora no projeto Longhorn que se tornaria o Windows Vista e o resultado catastrófico de prometer demais e entregar muito de menos prejudicou ainda mais essa já horrorosa reputação. O Windows 7 e 8 não ajudaram. Foi só agora no Windows 10 e mesmo assim depois de vários updates que eles finalmente acertaram a mão, mas ele veio uma década mais tarde do que deveria.

O Windows 10 ainda não atingiu os mesmos níveis de estabilidade do MacOS ou de qualquer Linux, porém com um hardware bom e principalmente drivers bons, eu não tenho nenhum problema de estabilidade faz muito tempo. Se eu disser que só vi uma tela azul em 2 anos não estou exagerando. E com a opção de agendar pra aplicar updates que exigem reboot só de madrugada, também nunca travei por conta de updates. Claro, na minha ordem de escolha eu continuo preferindo o MacOS mas desde 2014 eu não gosto do jeito que a Apple vem lidando com o hardware e por isso mudei pra hardwares PC. Eu gosto muito do Linux mas eu também gosto dos programas que tem no MacOS e no Windows que não tem no Mac. Por isso eu uso Linux em máquina virtual pra desenvolver. Apesar disso, eu não considero mais o Windows como primeiro fator pra um problema. Eu ainda não usaria Windows como servidor, mas como desktop ele está muito bom.

Finalmente, terceiro ponto, trocar de ferramenta. O Adobe Premiere é como o Windows, ele tem mais problemas que seus concorrentes. O Final Cut X é o melhor de todos em usabilidade e fluxo de trabalho apesar de ter um pouco menos funcionalidades. A combinação Final Cut com Motion é o equivalente do Premiere com AfterEffects. Mas em Windows não tem Final Cut então a primeira opção é o Premiere. Hoje em dia existe a opção do Da Vince Resolve, cuja reputação é excelente e ele tem versões pra Mac, Windows e até Linux, fora que ele tem uma versão gratuita que compete com as versões pagas.

Eu já estava de olho no Da Vince, que nasceu como uma ferramenta pra fazer color grading e color correction, por isso ele é o melhor de todos nesse departamento, mas ao longo do tempo ele embutiu o equivalente das funcionalidades do Premiere, AfterEffects e Audition tudo numa mesma ferramenta, então ele é extremamente poderoso. Não existe nenhum motivo pra eu não mudar pro Da Vince a não ser preguiça mesmo. Mudar o workflow de trabalho não é exatamente trivial, mas eu pretendo fazer isso em breve nem que seja só pra aprender uma ferramenta nova.

Porém, eu estava no meio de uma edição. Mudar de ferramenta no meio da edição não é a melhor resposta. Mudar de linguagem de programação, jogar fora o projeto atual que está funcionando, pelos possíveis benefícios de performance ou escalabilidade ou estabilidade não é uma escolha tão trivial quanto parece. Se eu tivesse mudado pro Da Vince naquela quinta-feira, vocês não teriam tido o video pronto na sexta. Talvez levasse mais dias ainda até eu aprender o workflow do Da Vinci e migrar tudo pra ele. Além disso eu ainda podia ter problemas inesperados no futuro próximo.

A grande vantagem das ferramentas da Adobe é o ecossistema. Tem muito mais documentação em foruns e sites explicando como resolver as coisas, tem muito mais assets como videos, audio, efeitos, composições em dezenas de site. A intro do meu video é uma composição de After Effects que eu comprei. E eu tenho essa opção sempre que precisar. No Da Vince não vou ter, dai eu teria que comprar pra After Effects, exportar num video e importar no Da Vince de qualquer jeito, daí o fator preço já não é uma vantagem tão grande. O mesmo raciocínio vale pra frameworks ou linguagens de programação. Mudar não é trivial. Não quer dizer que não vale a pena, só que o contexto precisa ser levado em consideração e o melhor momento de fazer isso não é justo quando você tá com prazo apertado e no meio de uma emergência.

Agora a conclusão que devia ser a primeira e mais óbvia: milhares de pessoas estão neste instante usando o mesmo Premiere que eu. O Premiere é usado pra editar filmes e documentários, muito mais longos e complicados que um video de YouTube, com muito mais efeitos, muito mais tomadas de VFX, com dezenas de composições de AfterEffects, ou dynamic links com Audition. E eles conseguem editar e exportar tranquilamento. A conclusão mais óbvia é que “eu” não estou sabendo usar a ferramenta, não que a ferramenta, ou o sistema operacional ou o hardware são ruins. Essas 3 opções partem da premissa que não tem nada de errado comigo e sim com as ferramentas que estou usando.

Mas na grande maioria das vezes é o oposto: considere sempre como primeira hipótese que é você que não está sabendo usar as ferramentas. Considere sempre que todo bug, todo crash, toda lentidão, todo lag, todo atraso é sempre culpa sua. A última opção é a ferramenta, o sistema ou o hardware, a última da última opção. Todas as vezes que tive problemas desse tipo, raramente a culpa não era minha. E esse foi justamente mais um caso: só porque eu já editei e entreguei mais de 50 videos ao longo de 1 ano não significa que eu já sou senior, muito pelo contrário, só significa que eu aprendi um jeito de fazer as coisas e repeti esse mesmo jeito por 1 ano, e finalmente esbarrei num projeto que desafiou esse caminho e me obrigou a repensar minha forma de trabalhar. Se eu mudasse de ferramenta não teria aprendido nada. Ao longo do processo de resolver o problema eu aprendi mais e treinei coisas como Proxy files, Render and Replace, otimizações do Premiere, estudei sobre outros codecs e muito mais. Nada disso resolveu o problema imediato, mas eu ganhei mais conhecimento pro futuro.

Ainda tem outro ponto a se considerar, e aqui é um princípio pessoal. Vocês sabem que eu não monetizo o canal. Quem define quando um vídeo vai ficar pronto, em que ritmo, sou eu. Por princípio eu decidi que eu só iria gravar e editar a noite, depois que volto do trabalho. Considere que eu sou dono da minha própria empresa, tecnicamente não existe nenhum problema se eu usasse o dia pra fazer isso. Mas por princípio eu escolhi fazer dentro dessas restrições e decidi que eu entregaria um video por semana salvo quando eu tivesse que viajar ou fazer eventos por exemplo. Eu sou o meu próprio chefe e o meu próprio cliente. Eu não conseguir cumprir os deadlines que eu mesmo decidi vai contra meus princípios. Não estou dizendo que todo mundo deve fazer isso, mas se você realmente quer ir um nível acima, deveria ter padrões mais elevados do que desistir e se justificar dizendo “ah, eu nem ganho o suficiente pra ter essa dor de cabeça”. Lógico esse princípio estou exagerando na explicação, mas acho que vocês entenderam o ponto.

A moral da história: sempre assumir que você ainda não sabe tudo e não inventar desculpas esfarrapadas. Mas também não adianta só ter falsa-humildade. Ai, tadinho de mim. Falso-humilde é um inútil. Eu preciso saber objetivamente quais itens eu ainda não sei e aprender e treinar um de cada vez. Alguém comentou no meu video sobre Conhecimentos Básicos que depois de assistir viu que não sabia nem esse básico e se questionou “eu devo ser burro mesmo”. E eu digo, não necessariamente, antes você não sabia que não sabia. Agora você sabe o que não sabe, faz uma enorme diferença, porque agora você tem uma meta pra cumprir. É um passo que vai te deixar melhor do que é hoje. A pior coisa é não ter consciência que não sabe. Como você vai melhorar, se não sabe o que não sabe?

Por fim, outro motivo que eu quis usar este exemplo: eu venho fazendo videos por quase 1 ano. Nesse período eu saí do 0 pros tais 20% em 3 meses. Dali em diante eu venho basicamente repetindo o mesmo processo. Ter feito 10 videos ou 50 videos ou 100 só seguindo o mesmo processo, não me torna muito melhor hoje do que eu já era em Janeiro. Esse problema que eu tive semana passada foi a primeira vez em meses que eu finalmente subi mais um nível. Isso é o aviso que eu dou a todo estagiário, trainee, junior. É muito, mas muito fácil, sair do 0 e ir pros 20% o suficiente pra conseguir entregar coisas que parecem produtos finais. Veja meus videos, se você só bater o olho ia dizer que eu sou que nivel? Sejam objetivos, seu nível em 1 ou 2 anos continua sendo junior, o meu nível aqui em edição continua sendo junior. Eu preciso apanhar mais vezes como semana passada se eu quiser subir de nivel. E pra isso eu mesmo preciso caçar problemas novos pra resolver em vez de voltar pra zona de conforto e evitar fazer os videos difíceis.

E é isso aí, era essa a história e o processo de pensamento que eu queria compartilhar com vocês hoje, se ficaram com dúvidas ou tem outras sugestões mandem nos comentários abaixo, se curtiram o video mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos videos e compartilhem com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!

No episódio sobre Ubuntu pra Devs da semana passada, quem me acompanhou pelas redes sociais (que é @akitaonrails em todas) viu que eu passei por um perrengue pra conseguir editar o vídeo e isso me custou uns 2 dias de atraso. Por isso o vídeo foi entregue só na sexta-feira e eu dormi mal duas noites.

Neste vídeo quero falar duas coisas. A primeira é explicar o que aconteceu e como eu resolvi o problema, pra quem tem interesse em edição de vídeo aprender também.

A segunda coisa é usar esse episódio pra refletir sobre como eu penso sobre resolução de problemas de modo mais amplo, sobre o processo investigativo e sobre a avaliação das minhas próprias capacidades, e como vocês também podem usar os mesmos conceitos quando encararem problemas difíceis e inesperados.

A comunidade do Blender é tão apaixonada e comprometida que frequentemente produz curtas-metragens de alta qualidade, com nível quase hollywoodiano, usando o próprio Blender. A ideia é justamente estressar a ferramenta e identificar gargalos e problemas de usabilidade num fluxo de trabalho real.

Este post é, principalmente, para o “eu do futuro” poder voltar a uma lista de recursos centralizada. Como modelagem 3D não é meu trabalho em tempo integral, vou ter longos intervalos entre as sessões com o Blender. E eu sei que vou me arrepender se não descarregar o que aprendi num post enquanto ainda está fresco :-)

Primeiros Passos para Iniciantes

Antes de mais nada: se você está neste blog, provavelmente é programador. E deixa eu te dizer que o pessoal de gráficos tem uma visão de “usabilidade” bem diferente da nossa. A quantidade absurda de customizações, opções, atalhos e combinações rivaliza até com usuários de Vim e Emacs.

Ah, e a propósito: você vai precisar de um mouse com 3 botões de verdade. Touchpad não serve pra nada no Blender, e o mouse do Mac é horrível. Qualquer mouse barato de PC resolve.

Por padrão, o botão principal é o da direita, não o da esquerda como estamos acostumados. Mude isso nas preferências do usuário para selecionar com o botão esquerdo, e aí as coisas começam a fazer sentido. Enquanto estiver lá, habilite também a emulação do Numpad.

Aliás, vale muito a pena ter um teclado com numpad ou até um numpad separado. Você pode usar a fileira de números do teclado normal, mas o Blender foi projetado presumindo tanto um mouse de 3 botões invertido quanto um numpad.

Se você nunca estudou Blender antes, não vai conseguir descobrir nada explorando a interface por conta própria. A UI é inútil até alguém te ensinar o básico. Há centenas de termos que você simplesmente não vai entender, como Meshes, Edges, Seams, Nodes, Viewport, Subsurface, Modifiers, etc.

A coisa mais importante que você PRECISA fazer antes de continuar é assistir essa série completa de 9 partes do Blender Guru, chamada Blender Beginner Tutorial Series. Opcionalmente, você pode fazer depois, com calma, os Intermediate Blender Tutorials.

A série para iniciantes vai te ensinar o suficiente para você finalmente começar a se sentir confortável com a interface e as ferramentas. E não esqueça de imprimir e pendurar esse “cheat sheet” tão útil. Você não vai acreditar como a vida fica mais fácil quando incorpora os atalhos de teclado mais importantes.

Configurações Padrão Melhores

Por razões históricas, algumas configurações padrão não são as ideais. O conhecimento na área de renderização 3D evolui muito rápido.

A primeira coisa a fazer: trocar o motor de renderização padrão de Blender Render para o Cycles Raytracing Engine.

Depois, tratamento de cor. O sRGB EOTF padrão é basicamente errado. Você precisa baixar a configuração filmic-blender do Sobotka. No Arch Linux, basta fazer:

pacaur -S filmic-blender-git

Criei um script em ~/bin/filmic-blender com o seguinte:

env OCIO=/usr/share/blender/2.78/datafiles/filmic-blender/config.ocio blender

E sempre inicializo o Blender pelo terminal assim:

optirun ~/bin/filmic-blender

Isso faz duas coisas: primeiro, pré-configura o OpenColorIO para usar o substituto Filmic. Segundo, habilita a GPU externa do meu notebook para uso no Blender. Leia meu post “Enabling Optimus NVIDIA GPU on the Dell XPS 15 with Linux, even on Battery” para mais detalhes. No Windows ou Mac isso não é necessário, mas você ainda vai precisar carregar a configuração filmic.

Na aba Scene, você deve reconfigurar o “Color Management” assim:

Em seguida, configure o Cycles. Se você está no Linux com o Optimus instalado corretamente como expliquei antes, a opção CUDA deve aparecer nas preferências do usuário:

Na aba Render, você deve ter algo assim:

Na seção Dimensions, você vai ver que está configurado para Full HD (1920x1080 px) mas com apenas 50% (ou seja, vai renderizar metade do tamanho). Aumente para 100%. Se quiser um shot em 4K, ajuste as dimensões para 3840x2160 px. O 4K torna a renderização 4 vezes mais lenta que o 1080p, obviamente.

Na seção Performance há 2 campos para “Tile size”. O Blender vai dividir sua imagem em tiles, e cada tile renderiza em paralelo num core de CPU ou GPU disponível. Meu notebook tem 8 cores de CPU, então 64 é um bom tamanho, porque vai renderizar 8 tiles de 64 pixels cada em paralelo.

Quanto menos cores você tiver, maior deve ser o tile. Para minha GPU NVIDIA, só tenho 2 cores disponíveis (e não muita memória de vídeo!), então vale aumentar os dois campos para 512. Na GPU ela só renderiza 2 tiles por vez, e tiles maiores otimizam a renderização.

Como você provavelmente já adivinhou, o Blender Guru tem um tutorial muito útil: “18 ways to speed up Cycles Rendering”.

Isso cobre o básico das configurações padrão.

Você Precisa Pensar como Fotógrafo!

Você vai querer assistir MUITOS tutoriais online, porque realmente não é óbvio como usar melhor as ferramentas. Outro canal que gosto bastante é o BornCG e o CG Masters. Pegue alguns vídeos deles para ter uma visão mais aprofundada de ferramentas específicas, técnicas de modelagem e por aí vai.

E de verdade: você precisa praticar o máximo possível enquanto estuda. Uma área importante é a Fotografia. Isso é o que você vê quando seleciona a aba Camera:

Tem muita customização disponível aqui. Por exemplo: Focal length: 35.00, que é o que os fotógrafos conhecem como lente de 35mm, uma boa escolha padrão. Você pode usar grande angular de 200mm ou 300mm também, e shots internos, em salas pequenas, podem usar 24mm ou até 18mm. O artigo “Understanding Color Lenses” cobre o básico.

Depois, você precisa entender “Profundidade de Campo” (Depth of Field). Isso pode ser feito nessa configuração antes de renderizar, ou simulado após a renderização (se você escolheu separar o render em camadas), no Compositor.

Falando nisso, outra forma de controlar a Profundidade de Campo é reconfigurar o “f-stop”, que é a medida de exposição, ou abertura. O padrão é “128.0”, ou seja, “f/128”. Como referência, a câmera do iPhone 7s tem abertura f/2.2. Novamente, vale estudar mais sobre isso começando pelo artigo “What’s the Best F-Stop?”

Tirar uma foto (ou renderizar um still, no nosso caso) é muito mais do que simplesmente apontar e clicar. Você também precisa se preocupar com técnicas adequadas de composição, como a Regra dos Terços, a proporção áurea, e por aí vai. Você pode configurar isso no combo box “Composition Guides” mostrado acima.

Vale muito a pena se aprofundar no campo da Fotografia para melhorar o resultado final dos renders. Sou um amador e é muito empolgante conseguir aplicar técnicas do mundo real na renderização 3D.

Design de Materiais e Physically-Based Render (PBR)

O padrão ouro em modelagem e renderização 3D é certamente o Disney/Pixar RenderMan. Todos os filmes premiados da Pixar foram feitos com ele.

Mas o Blender aprende rápido. Todo paper da Pixar eventualmente vira parte do próprio Blender. O design de materiais, por exemplo, sempre foi bastante trabalhoso na ferramenta. Fiz alguns dos tutoriais eu mesmo, e criar materiais com as características corretas do mundo real, como Fresnel adequado e a distinção certa entre dielétrico e metálico, era um desafio.

Se você assinou o canal do Blender Guru, assista os tutoriais “How to Make Photorealistic PBR Materials - Part 1” e “Part 2”. E você vai acabar com essa configuração complicada de Nodes para materiais PBR:

E o Blender Guru acabou de postar um novo vídeo apresentando um recurso do próximo Blender 2.79 (ainda no 2.78 na época): a implementação do paper “Physically-Based Shader at Disney” como um novo shader nativo e otimizado chamado “Principled Shader”. É literalmente o Shader Definitivo, porque torna a criação e personalização de materiais realistas muito mais fácil, além de ser compatível com Renderman e Substance.

Conclusão

Ainda sou iniciante no Blender, tem uma estrada muito longa pela frente. Mas é um ambiente muito empolgante e estou aprendendo coisas novas e úteis o tempo todo. Todo mundo deveria experimentar!

Com o tempo, espero encontrar espaço para integrar o fluxo de trabalho do Blender com outras ferramentas como Unreal Engine ou Unity3D para criar coisas interativas também.

Esse post não é de forma alguma um tutorial completo ou referência definitiva. A ideia foi destacar algumas coisas que não são imediatamente óbvias quando você começa com o Blender e que podem te dar uma noção mais ampla do que ele é capaz de fazer.

Se quiser se aprofundar de verdade nas configurações, assista esse vídeo de setup do CG Master: