Os desenvolvedores de língua russa sempre têm algo a dizer: compartilhar algumas de suas experiências e opiniões únicas. Porém, no formato do blog de vídeo, devido à alta complexidade da gravação, apenas alguns o fazem agora.

Sob o corte, ele falou sobre seu difícil caminho para gravar e editar vídeos usando software livre, scripts Ruby e ferramentas improvisadas.

Teoria

Comecei estudando a teoria da gravação de blogs de vídeo em vídeos do YouTube em inglês. E a partir de materiais em russo, este curso acabou sendo bastante útil (em particular, o módulo sobre blogs de vídeo e o primeiro vídeo sobre como criar um quadro a partir do módulo sobre relatórios). Também me familiarizei fluentemente com os recursos populares dos editores de vídeo proprietários, a fim de abordar mais conscientemente a escolha de um editor gratuito.

Não me atrevi a investir em luz: não há tempo suficiente para estudá-la e procurar a melhor opção, e um estudo superficial de opções baratas fala de possíveis riscos, como cintilação e baixa reprodução de cores. Com a luz do dia, não tive grandes dificuldades, basta apenas vídeos curtos.

Editor de vídeo

As ferramentas de edição de vídeo gratuitas existentes contêm vários problemas conhecidos: de soluções malsucedidas na interface do usuário e congelamentos que transformam a edição em infinito, a vazamentos de memória, falhas e artefatos inesperados que aparecem somente após a renderização final.

Existem muitos problemas e levou tempo para selecionar um editor de vídeo e estudar seus bugs, apenas para aprender a lidar com coisas básicas. Por fim, ele parou em Pitivi , simplesmente porque passava muito tempo pesquisando e experimentando.

Som de Flatpak

O método de instalação suportado pelo Pitivi requer o Flatpak. Por um tempo eu andei em volta dele, porque Não tenho o systemd e o PulseAudio no meu sistema.

Acontece que o systemd não é necessário há muito tempo. Bem, PulseAudio - eu tive que instalar e configurar , era mais fácil modificar o Flatpak . Mas seria mais correto colocar o PulseAudio, é um pouco entediante e não está claro se é esperado problemas com a gravação de som no hardware existente ou não.

Instale o Pitivi, exclua as configurações do PulseAudio, execute:

$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo $ sudo flatpak install flathub org.pitivi.Pitivi $ sudo find {/var/lib,~/.local/share}/flatpak/runtime -type f -name '*pulseaudio*.conf' -delete $ flatpak run --device=alsa --branch=stable --arch=x86_64 --command=pitivi org.pitivi.Pitivi 

Não há som. Vamos tentar executar algo mais simples, por exemplo, aplay :

 $ sudo find /var/lib/flatpak/app/org.pitivi.Pitivi/x86_64 -type d -path '*/files/bin' -exec cp `which aplay` {} \; $ flatpak run --device=alsa --branch=stable --arch=x86_64 --command=aplay org.pitivi.Pitivi /dev/urandom ALSA lib dlmisc.c:162:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_empty_open ALSA lib dlmisc.c:283:(snd1_dlobj_cache_get) symbol _snd_pcm_empty_open is not defined inside [builtin] aplay: main:828: audio open error: No such device or address 

Provavelmente a alsa-lib incluída no Flatpak foi compilada com --with-versioned . Uma solução rápida é substituir o libasound.so sistema:

 $ sudo find /var/lib/flatpak -type f -name libasound.so.2.0.0 -exec cp /usr/lib64/libasound.so.2.0.0 {} \; $ find ~/.local/share/flatpak -type f -name libasound.so.2.0.0 -exec cp /usr/lib64/libasound.so.2.0.0 {} \; #      - 

Para mim, isso não foi suficiente:

 $ flatpak run --device=alsa --branch=stable --arch=x86_64 --command=aplay org.pitivi.Pitivi /dev/urandom ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.6-r1/work/alsa-lib-1.1.6/src/pcm/pcm_direct.c:1943:(snd1_pcm_direct_parse_open_conf) The field ipc_gid must be a valid group (create group audio) aplay: main:828: audio open error: Invalid argument 

Precisa de outra configuração do ALSA:

 $ sudo find /var/lib/flatpak -type d -name etc -exec cp /etc/asound.conf {} \; $ find ~/.local/share/flatpak -type d -name etc -exec cp /etc/asound.conf {} \; #      - $ flatpak run --device=alsa --branch=stable --arch=x86_64 --command=aplay org.pitivi.Pitivi /dev/urandom 

Finalmente, você pode usar o Pitivi.

Outros efeitos

Faço alguns efeitos de animação para o texto usando o screencast das páginas em tela cheia, dispostas usando o discover.js e o animate.css. No discover.js de alguns slides, adiciono um som de transição:

 <section style="font-size: 5em"> <audio data-autoplay src="/path/to/sound.wav"></audio> #1 </section> 

Acabou sendo importante gravar um screencast com 60 FPS se o texto for muito grande. O Screencast faz isso:

 #!/bin/sh SOUND_INPUT=shared_input_loopback CHANNELS=2 SOUND_RATE=48000 FRAMERATE=60 DRAW_MOUSE=0 VIDEO_SIZE=$(xdpyinfo | awk '/dimensions:/ { print $2; exit }') OUTPUT="${HOME}/video/screen/$(date --rfc-3339=seconds).mp4" ffmpeg \ -thread_queue_size 512 \ -video_size "${VIDEO_SIZE}" \ -framerate "${FRAMERATE}" \ -f x11grab \ -draw_mouse "${DRAW_MOUSE}" \ -i :0.0+0,0 \ -thread_queue_size 512 \ -f alsa \ -ac "${CHANNELS}" \ -i "${SOUND_INPUT}" \ -ar "${SOUND_RATE}" \ -vcodec libx264 -preset ultrafast -crf 18 \ -acodec alac \ -f ipod \ "${OUTPUT}" 

No meu caso, shared_input_loopback é o dispositivo da configuração asound.conf .

Ainda assim, esse complemento sobre ffmpeg para transições entre clipes foi útil.

Gravação de vídeo

Na mão estava um telefone Meizu MX4, no qual decidi usar uma câmera frontal e gravar usando a Câmera Aberta. Demorou algum tempo para se treinar a olhar para a câmera e controlar sua posição no espaço sem cometer erros típicos, como cortar a cabeça. Ao mesmo tempo, fale claramente, em voz alta, gesticule e gere pelo menos algum tipo de expressão facial. Mas isso foi apenas o começo.

O que me levou a cortar o vídeo automaticamente, e mesmo na fase de gravação?

1. O Pitivi freia e falha ao editar, especialmente ao usar a ferramenta Ripple Move / Edit , levando à necessidade de reiniciar periodicamente o Pitivi.
2. Para mim, o processo de cortar manualmente o vídeo é uma das coisas mais chatas. É claro que não é muito possível automatizar isso totalmente (pelo menos sem um cenário em que as pausas necessárias para entender o que foi dito não sejam explicitamente indicadas), mas pelo menos esse processo pode ser otimizado.

Aqui estão os requisitos para a futura bicicleta que eu me propus:

1. Grave vídeo usando um telefone Android e áudio usando um laptop.
2. Controle de foco da câmera.
3. Capacidade de parar a gravação para salvar ou excluir o último fragmento gravado.
4. Baixe o vídeo do telefone via USB, com tentativas repetidas e reinicie , sem bloquear a capacidade de gravar o próximo fragmento.
5. Sincronização de som.
6. Determinando a presença de voz e jogando pausas.
7. A capacidade de reproduzir rapidamente os últimos videoclipes gravados, com pausas já pausadas.

Por que tanto controle sobre os dispositivos durante a fase de gravação? Por que não começar a gravar por várias horas seguidas e depois editá-lo? Existem muitas razões:

1. Banal falta de espaço em disco.
2. A tendência do telefone superaquecer e descarregar rapidamente durante a gravação por um longo período de tempo.
3. Mau funcionamento da tela de toque devido ao telefone estar na água. Mas de alguma forma você precisa controlar o foco. Sim, e a prensa seguinte criaria vibração desnecessária do dispositivo.
4. Problemas ao carregar arquivos grandes devido à falta de energia da porta USB no meu laptop. Em teoria, isso pode ser resolvido usando um hub USB com energia adicional. O uso de uma rede é muito lento.
5. O desejo de revisar rapidamente os últimos fragmentos registrados para garantir que não haja erros e reescrevê-lo rapidamente antes que o planeta vire no lugar errado na frente do sol.
6. O desejo de lançar duplicatas obviamente ruins o mais cedo possível, para não perder tempo e espaço em disco com elas no futuro.
7. Precisa sincronizar o áudio longo gravado por telefone e laptop. Isso pode causar uma incompatibilidade com o vídeo devido ao fato de que os quadros do fluxo de áudio são ejetados durante a gravação de um laptop ou durante a gravação de um telefone (que você provavelmente pode resolver de alguma forma, mas não deseja arriscar e perder tempo experimentando). É mais fácil sincronizar pequenos fragmentos separadamente, então uma possível dessincronização não será perceptível.
8. A necessidade de lidar com uma situação em que o Open Camera reinicia a gravação devido a um tamanho de vídeo de 4 GiB. Você provavelmente precisaria modificar o Open Camera. Se essa restrição em 4 GiB não puder ser removida ou aumentada, você deverá lançar um evento no laptop para perceber que a gravação foi reiniciada neste local.

É mais fácil gravar em pequenos fragmentos e tornar a automação primitiva de tudo o que é possível. Ruby foi escolhido como o principal idioma para o desenvolvimento de uma bicicleta. Na verdade, agora eu provavelmente escolheria o Python, mas naquele momento estava aprendendo Ruby e estou executando novas linguagens para mim em experimentos tão estranhos.

Corte de vídeo automático

As informações na rede sobre este tópico não são muito. Sobre as pesquisas que Stanford e Adobe lembraram mais tarde (o que não é assustador, ainda preciso de uma solução menos sofisticada).

O fatiamento ocorre em 2 estágios: no estágio de gravação - grosso, no estágio de renderização - mais preciso, com a capacidade de corrigir manualmente muitos fragmentos aparados. Áspero implementado usando o VAD do WebRTC. Mais preciso - com a ajuda do Google Speech (mais especificamente - com a ajuda de uma modificação do projeto autosub , para gerar legendas para vídeo). Estou certo de que haverá soluções mais bem-sucedidas; acabou sendo o melhor do que conseguimos fazer rapidamente.

Se você deseja desenvolver algo assim usando o ffmpeg , ffmpeg o princípio de não tentar fazer muito em uma chamada para o ffmpeg . Crie arquivos intermediários e controle todas as etapas para não precisar procurar bugs estranhos que não sejam do Google, como corte incorreto ou efeito não aplicado.

Começo a desgraça resultante de alguma forma assim:

 $ bin/vlog-recorder \ --project /path/to/project \ --debug true \ --sound-settings ' --device=usb_card --format=dat' #   arecord r - (RE)START recording s - STOP and SAVE current clip S - STOP and SAVE current clip, don't use auto trimming d - STOP and DELETE current clip p - PLAY last saved clip f - FOCUS camera on center h - show HELP q / Ctrl+C - QUIT [ stopped ] [ battery: 100% / 36°C ] 

Preciso dos argumentos a serem arecord para indicar explicitamente o dispositivo, a fim de evitar falhas periódicas provavelmente devido ao plug-in dsnoop baseado em ALSA. Você também pode abrir o log para controlar o processo de download de arquivos do telefone: tail -f /path/to/project/log.txt .

Renderize rapidamente em um vídeo para visualização, você pode fazer o seguinte:

 $ bin/vlog-render \ --project /path/to/project \ --language ru \ --video-filters 'hqdn3d,hflip,curves=psfile=/path/to/curves.acv,vignette' \ --speed 1.3 \ --fps 60 \ --preview true 

O argumento --video-filters são os filtros passados ​​para o ffmpeg . O vídeo será aberto automaticamente no player mpv .

Você também pode trocar ou eliminar as duplicatas desnecessárias restantes, editando o arquivo /path/to/project/render.conf exibido, que pode ser detectado graças à voz reconhecida. A ideia, a propósito, não é nova . Lá, você pode acelerar fragmentos individuais e editar cortes de vídeo sem êxito, se houver. Na próxima vez que o vlog-render reler o render.conf aplicará as alterações.

Para preparar fragmentos para um editor de vídeo, você precisa especificar --preview false . Além dos fragmentos que estarão na output , ele os mesclará em um arquivo output.mp4 , porque inicialmente eu não tinha certeza:

• vou usar pequenos clipes no pitivi
• ou faça upload de um vídeo longo para obter mais fatias (para que você possa aplicar vários efeitos ao "grupo" de clipes).

Eu uso principalmente a primeira opção. O segundo foi útil em um vídeo com pouca luz: lá usei apenas um pedaço de output.mp4 . Para a segunda opção, o script vlog-play-segments também pode ser útil: com ele, você pode ver rapidamente todas as pausas entre os clipes em ordem decrescente de duração. Isso ajudará a render.conf com mais precisão o render.conf e economizará tempo mais tarde, ao editar este longo pedaço de vídeo no Pitivi.

Os pequenos clipes resultantes podem ser baixados uma vez por linha do tempo no Pitivi: selecione todos os clipes importados e arraste-os usando arrastar e soltar.

Montagem do telefone

Eu não queria procurar um suporte de telefone adequado e minhas mãos já arranhavam meu rosto para gravar pelo menos alguma coisa. Pegamos um pedaço de papelão que vem à mão e cortamos o suporte do telefone para nossas necessidades:

O suporte é montado em uma tela de laptop para minimizar a distância entre o script e a câmera.

Gravação de som

Som aceitável é muito crítico . Na mão estava um microfone Boya BY-M1. Embora seja anunciado como um microfone omnidirecional, na prática, o bom som é obtido apenas quando você o usa como unidirecional.

É ainda mais fácil colocar o microfone em pé: pegamos uma garrafa de suco de romã que vem à mão, um rolo de fita adesiva e montamos esse construtor:

Você também pode colocar uma toalha sob esse design para suprimir parte das vibrações da mesa e, ao mesmo tempo, ajustar a altura.

Placa de som

No meu caso, este é o ASUS Xonar U3. No entanto, descobriu-se que não é compatível com esse microfone: o microfone possui um plugue CTIA projetado para telefones. O problema foi resolvido pelo adaptador nos plugues TRS para microfone e fones de ouvido. E achar que não era fácil: os fabricantes desses adaptadores raramente escrevem detalhes. No meu caso, um Cablexpert CCA-418W ajudou.

Outro problema com esta placa está no deslocamento CC no canal correto durante a gravação. O que não interfere, porque Estou gravando de qualquer maneira em mono. E para softwares que não permitem definir mono, redirecionei um bom canal para um canal ruim usando o ALSA.

Este cartão também tem medo de superaquecer. Você precisa mantê-lo afastado do refrigerador, caso contrário, ele diminuirá a velocidade e gravará o som em movimentos bruscos.

Processamento de som

Eu edito o som nos fones de ouvido (no meu caso, é o Pioneer SE-M390), em um volume maior do que aquele em que costumo ouvir música. O algoritmo é algo como isto:

1. Usando Pitivi, renderizo separadamente o som (usando todos os mesmos ALAC e MP4). Frequentemente faço várias trilhas separadas, escolhendo camadas específicas no Pitivi e removendo temporariamente as desnecessárias.
2. Se os arquivos recebidos forem enviados imediatamente para o Audacity, perderemos o alongamento / compactação do fluxo de áudio, o que pode levar ao vídeo e ao áudio fora de sincronia. O que não é óbvio, isso não acontece com todos os vídeos. Para impedir que isso aconteça - basta aplicar estes ffmpeg -async 1 -i input.mp4 output.flac / compactação: ffmpeg -async 1 -i input.mp4 output.flac
3. Faça o download de todas as faixas no Audacity. Adicione música de fundo, se necessário.
4. Para todas as faixas, defina o volume desejado usando Gain.
5. Na faixa com a voz, aplique os efeitos de Redução de ruído (no meu caso duplo), Compressor e Equalização de acordo com as dicas deste vídeo .
6. Equalizamos e aumentamos o volume da faixa com a voz. Uma das formas clássicas é Normalizar, Amplificar, Limitador e Normalizar novamente, mas com essa abordagem ainda não consegui obter a qualidade de som desejada. Eu ajo temporariamente assim: primeiro faço o ganho de toda a faixa para que a parte mais alta pareça sem sobrecargas e depois aplico manualmente o Amplify para fragmentos individuais. Atualização : Outra maneira poderosa é RMS Normalizar, Limitador e Normalizar normal. As configurações de Normalização e Limitador do RMS podem ser obtidas aqui . No entanto, esse método não foi útil para mim, porque de qualquer maneira, decidi mudar para outro microfone (Zoom H1n) com o Limiter embutido, o que me convém (então, com o novo microfone, provavelmente tenho que fazer apenas Normalizar normal, em vez de todas essas coisas).
7. Às vezes, o microfone grava o som com alguns defeitos que parecem cliques. Eles podem ser removidos usando o efeito de ferramenta múltipla Spectral edit. Na maioria das vezes, é necessário aplicá-lo várias vezes seguidas na área selecionada, usando Ctrl + R. Atualização : graças ao novo microfone, descobri que esses defeitos estão conectados a algo externo, provavelmente essa é uma combinação de ruído na boca e outros sons estranhos.
8. Exportamos do Audacity para FLAC e ffmpeg -i sound.flac -an -i video.mp4 -c copy output.mkv tudo em um arquivo: ffmpeg -i sound.flac -an -i video.mp4 -c copy output.mkv
9. Pelo menos o primeiro vídeo que testei em diferentes volumes e dispositivos diferentes.

Resultado

Aproveitando a oportunidade para relaxar as regras, convido você a visitar o canal resultante do YouTube , onde compartilho idéias sobre o estudo eficaz da programação e disciplinas relacionadas.

Boa sorte no desenvolvimento de programas e na criação de blogs de vídeo!

Atualização : traduziu este artigo para o blog em inglês.