Los desarrolladores de habla rusa siempre tienen algo que contar: compartir algunas de sus experiencias y opiniones únicas. Pero en el formato del video blog, debido a la alta complejidad de la grabación, solo unos pocos lo hacen ahora.
Debajo del gato, habló sobre su difícil camino para grabar y editar videos usando software libre, scripts de Ruby y herramientas improvisadas.
Teoría
Comencé estudiando la teoría de grabar blogs de video en videos de YouTube en inglés. Y a partir de materiales en idioma ruso, este curso resultó ser bastante útil (en particular, el módulo sobre video blogging y el primer video sobre cómo construir un marco desde el módulo sobre informes). También me familiaricé con fluidez con las características populares de los editores de video propietarios para acercarme más conscientemente a la elección de un editor gratuito.
No me atreví a invertir en luz: no hay tiempo suficiente para estudiarlo y buscar la mejor opción, y un estudio superficial de opciones baratas habla de posibles rastrillos como parpadeo y mala reproducción del color. Con la luz del día, no tuve grandes dificultades, es suficiente solo para videos cortos.
Editor de video
Las herramientas de edición de video gratuitas existentes contienen una serie de problemas conocidos: desde soluciones fallidas en la interfaz de usuario y bloqueos que convierten la edición en infinito, hasta fugas de memoria, bloqueos y artefactos inesperados que aparecen solo después de la representación final.
Hay muchos problemas y tomó tiempo seleccionar un editor de video y estudiar sus errores, solo para aprender cómo lidiar con cosas básicas. Finalmente, se detuvo en Pitivi , simplemente porque pasó mucho tiempo buscando y experimentando.
Sonido de Flatpak
El método de instalación compatible para Pitivi requiere Flatpak. Por un tiempo lo rodeé, porque No tengo systemd y PulseAudio en mi sistema.
Resulta que systemd no ha sido requerido por mucho tiempo. Bueno, PulseAudio: tuve que instalarlo y configurarlo , fue más fácil modificar Flatpak . Pero sería más correcto poner PulseAudio, es un poco tedioso y no está claro si esperar problemas con la grabación de sonido en el hardware existente o no.
Instale Pitivi, elimine las configuraciones de PulseAudio, ejecute:
$ 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
No hay sonido Intentemos ejecutar algo más simple, por ejemplo 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
Probablemente alsa-lib
incluido en Flatpak fue compilado con --with-versioned
. Una solución rápida es reemplazar libasound.so
sistema uno:
$ 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 mí, esto no fue 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
Necesita otra configuración de 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 {} \;
Finalmente, puedes usar Pitivi.
Configuración de representación para Pitivi que vino como resultado- formato de contenedor: MP4
- video
- códec x264enc
- avanzado
- pase / tipo de codificación: cuantificador constante
- cuantificador constante: 18
- velocidad de bits: 16384 kbit / s
- calidad de velocidad preestablecida: ultrarrápida
- ajuste preestablecido psicovisual: película
- audio
- bajo mi propio riesgo y miedo uso "Nunca renderizar desde archivos proxy"
- todo lo demás es el predeterminado
Otros efectos
Hago algunos efectos de animación para el texto usando el screencast de las páginas de pantalla completa, presentado usando revelar.js y animate.css. En revelar.js para algunas diapositivas agrego un sonido de transición:
<section style="font-size: 5em"> <audio data-autoplay src="/path/to/sound.wav"></audio> #1 </section>
Resultó ser importante grabar un screencast con 60 FPS si el texto es muy grande. Screencast hace esto:
En mi caso, shared_input_loopback
es el dispositivo de la configuración asound.conf .
Aún así, este complemento sobre ffmpeg
para transiciones entre clips fue útil.
Grabación de video
A la mano estaba un teléfono Meizu MX4, en el que decidí usar una cámara frontal y grabar usando Open Camera. Tomó algún tiempo entrenarse para mirar a la cámara y controlar su posición en el espacio sin cometer errores típicos, como cortarse la cabeza. Al mismo tiempo, habla con bastante claridad, en voz alta, gesticula y genera al menos algún tipo de expresión facial. Pero eso fue solo el comienzo.
¿Qué me impulsó a hacer un corte de video automático, e incluso en la etapa de grabación?
- Pitivi frena y corrige errores al editar, especialmente cuando se usa la herramienta Ripple Move / Edit , lo que lleva a la necesidad de reiniciar periódicamente Pitivi.
- Para mí, el proceso de cortar videos manualmente es una de las cosas más aburridas. Está claro que no es muy posible automatizar completamente (al menos sin un escenario en el que las pausas necesarias para comprender lo que se dijo no se indican explícitamente), pero al menos este proceso puede optimizarse.
Estos son los requisitos para la futura bicicleta que me puse:
- Grabe video usando un teléfono Android y audio usando una computadora portátil.
- Control de enfoque de cámara.
- Posibilidad de detener la grabación para guardar o eliminar el último fragmento grabado.
- Descargue el video del teléfono a través de USB, con intentos repetidos y reanude , sin bloquear la capacidad de grabar el siguiente fragmento.
- Sincronización de sonido.
- Determinación de la presencia de voz y pausas de lanzamiento.
- La capacidad de reproducir rápidamente los últimos videoclips grabados, con pausas ya pausadas.
¿Por qué tanto control sobre los dispositivos durante la fase de grabación? ¿Por qué no simplemente comenzar a grabar durante varias horas seguidas y luego editarlo? Hay muchas razones:
- Falta banal de espacio en disco.
- La tendencia del teléfono a sobrecalentarse y descargarse rápidamente cuando graba durante mucho tiempo.
- Mal funcionamiento de la pantalla táctil debido a que el teléfono está en el agua. Pero de alguna manera necesitas controlar el enfoque. Sí, y la siguiente presión crearía vibraciones innecesarias del dispositivo.
- Problemas al cargar archivos grandes debido a la poca potencia del puerto USB en mi computadora portátil. En teoría, esto se puede resolver utilizando un concentrador USB con alimentación adicional. Usar una red es demasiado lento.
- El deseo de revisar rápidamente los últimos fragmentos grabados para asegurarse de que no haya errores y reescribirlos rápidamente antes de que el planeta gire en el lugar equivocado frente al sol.
- El deseo de lanzar duplicados obviamente malos tan pronto como sea posible para no perder tiempo y espacio en disco en el futuro.
- Necesita sincronizar audio largo grabado por teléfono y computadora portátil. Esto puede causar una falta de coincidencia con el video debido al hecho de que los cuadros de las transmisiones de audio se expulsan tanto al grabar desde una computadora portátil como al grabar desde un teléfono (que probablemente pueda resolver de alguna manera, pero no quiere arriesgarse y perder el tiempo experimentando). Es más fácil sincronizar pequeños fragmentos por separado, luego, una posible desincronización no se notará.
- La necesidad de manejar una situación en la que Open Camera reinicia la grabación debido a un tamaño de video de 4 GiB. Probablemente tendría que modificar Open Camera. Si esta restricción en 4 GiB no se puede eliminar o aumentar, tendría que lanzar un evento en la computadora portátil para notar que la grabación se reinició en este lugar.
Es más fácil grabar en pequeños fragmentos y hacer una automatización primitiva de todo lo que es posible. Ruby fue elegido como el idioma principal para desarrollar una bicicleta. De hecho, ahora probablemente elegiría Python, pero en ese momento solo estaba aprendiendo Ruby, y estoy ejecutando nuevos idiomas para mí en experimentos tan extraños.
Corte automático de video
La información en la red sobre este tema no es mucha. Sobre la investigación que Stanford y Adobe recordaron más tarde (lo cual no da miedo, todavía necesito una solución menos sofisticada).
El corte se produce en 2 etapas: en la etapa de grabación, gruesa, en la etapa de renderizado, más precisa, con la capacidad de corregir manualmente demasiados fragmentos recortados. Rough implementado usando VAD de WebRTC. Más preciso, con la ayuda de Google Speech (más específicamente, con la ayuda de una modificación del proyecto autosub , para generar subtítulos para el video). Estoy seguro de que habrá soluciones más exitosas, simplemente resultó ser lo mejor de lo que logramos hacer rápidamente.
Si desea desarrollar algo como esto usando ffmpeg
, ffmpeg
con el principio de no intentar hacer demasiado en una llamada a ffmpeg
. Cree archivos intermedios y controle cada paso para que no tenga que buscar errores extraños que no sean de Google, como un corte incorrecto o un efecto no aplicado.
Comienzo la desgracia resultante de alguna manera así:
$ 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 ]
Necesito los argumentos para que arecord
indique explícitamente el dispositivo para evitar las fallas periódicas que probablemente se deban al complemento dsnoop basado en ALSA. También puede abrir el registro para controlar el proceso de descarga de archivos desde el teléfono: tail -f /path/to/project/log.txt
.
Renderice rápidamente en un video para la vista previa, puede hacer esto:
$ 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
El argumento --video-filters
son los filtros pasados a ffmpeg
. El video se abrirá automáticamente en el reproductor mpv
.
También puede intercambiar o desechar los duplicados innecesarios restantes editando el archivo /path/to/project/render.conf
aparecido, que se puede detectar gracias a la voz reconocida. La idea, por cierto, no es nueva . Allí puede acelerar fragmentos individuales y editar cortes de video fallidos, si los hay. La próxima vez, vlog-render
a leer render.conf
y aplicará los cambios.
Para preparar fragmentos para un editor de video, debe especificar --preview false
. Además de los fragmentos que se encontrarán en la output
, los fusionará en un archivo output.mp4
, porque inicialmente no estaba seguro:
- voy a usar pequeños clips en pitivi
- o suba un video largo para cortarlo más (para que pueda aplicar una serie de efectos al "grupo" de clips).
Principalmente uso la primera opción. El segundo fue útil en un video con poca luz: allí utilicé solo una pieza de output.mp4
. Para la segunda opción, el script vlog-play-segments
también puede ser útil: con él puede ver rápidamente todas las pausas entre clips en orden descendente de duración. Esto ayudará a render.conf
con mayor precisión render.conf
y a ahorrar tiempo más adelante al editar este largo video en Pitivi.
Los pequeños clips resultantes se pueden descargar una vez por línea de tiempo en Pitivi: seleccione todos los clips importados y arrástrelos usando arrastrar y soltar.
Soporte para teléfono
No quería buscar un soporte para teléfono adecuado, y mis manos ya se rascaron la cara para grabar al menos algo. Tomamos un trozo de cartón que viene a mano y cortamos el soporte del teléfono para nuestras necesidades:
El soporte está montado en una pantalla de computadora portátil para minimizar la distancia entre el guión y la cámara.
Grabación de sonido
El sonido aceptable es muy crítico . A la mano había un micrófono Boya BY-M1. Aunque se anuncia como un micrófono omnidireccional, en la práctica solo se obtiene un buen sonido cuando se usa como unidireccional.
Es aún más fácil hacer que el micrófono se pare: tomamos una botella de jugo de granada que viene a la mano, un rollo de cinta adhesiva y armamos este constructor:
También puede colocar una toalla debajo de este diseño para suprimir parte de las vibraciones de la mesa y al mismo tiempo ajustar la altura.
Tarjeta de sonido
En mi caso, este es ASUS Xonar U3. Sin embargo, resultó que no es compatible con dicho micrófono: el micrófono tiene un enchufe CTIA diseñado para teléfonos. El problema fue resuelto por el adaptador en los enchufes TRS para micrófono y auriculares. Y encontrarlo no fue fácil: los fabricantes de tales adaptadores rara vez escriben detalles. En mi caso, un Cablexpert CCA-418W ayudó.
Otro problema con esta tarjeta es el desplazamiento de CC en el canal derecho al grabar. Lo cual no interfiere, porque Estoy grabando de todos modos en mono. Y para el software que no le permite configurar mono, redirigí un canal bueno a un canal malo usando ALSA.
Esta tarjeta también teme el sobrecalentamiento. Debe mantenerlo alejado del refrigerador, de lo contrario, disminuirá la velocidad y grabará el sonido en tirones.
Procesamiento de sonido
Edito el sonido en los auriculares (en mi caso es el Pioneer SE-M390), a un volumen más alto que aquel en el que generalmente escucho música. El algoritmo es algo como esto:
- Usando Pitivi, renderizo por separado el sonido (usando todos los mismos ALAC y MP4). A menudo hago varias pistas separadas, eligiendo capas específicas en Pitivi y eliminando temporalmente las innecesarias.
- Si los archivos recibidos se cargan inmediatamente en Audacity, perderemos el estiramiento / compresión de la transmisión de audio, lo que puede provocar que el video y el audio no estén sincronizados. Lo que no es obvio, esto no sucede con todos los videos. Para evitar que esto suceda, simplemente aplique estos estiramientos / compresión:
ffmpeg -async 1 -i input.mp4 output.flac
- Descarga todas las pistas en Audacity. Agregue música de fondo si es necesario.
- Para todas las pistas, ajuste el volumen deseado usando Gain.
- Para la pista con la voz, aplique los efectos de Reducción de ruido (en mi caso doble), Compresor y Ecualización de acuerdo con los consejos de este video .
- Ecualizamos y aumentamos el volumen de la pista con la voz. Una de las formas clásicas es Normalizar, Amplificar, Limitar y Normalizar nuevamente, pero con este enfoque todavía no he podido obtener la calidad de sonido deseada.
Actúo temporalmente de esta manera: primero hago la ganancia de toda la pista para que la parte más fuerte suene sin sobrecargas, y luego aplico manualmente Amplify para fragmentos individuales. Actualización : Otra forma poderosa es RMS Normalizar, Limitar y Normalizar normal. La configuración de RMS Normalizar y Limitador se puede tomar desde aquí . Sin embargo, este método no me fue útil, porque de todos modos, decidí cambiar a otro micrófono (Zoom H1n) con el Limitador incorporado, que me conviene (por lo que con el nuevo micrófono es probable que solo tenga que normalizar normal, en lugar de todas estas cosas). - El micrófono a veces graba sonido con algunos defectos que parecen clics. Se pueden eliminar con el efecto Edición múltiple de herramienta espectral. Muy a menudo es necesario aplicarlo varias veces seguidas para el área seleccionada, usando Ctrl + R. Actualización : gracias al nuevo micrófono, descubrí que estos defectos están conectados con algo externo, lo más probable es que sea una combinación de ruido en la boca y otros sonidos extraños.
- Exportamos desde Audacity a FLAC y fusionamos todo en un solo archivo:
ffmpeg -i sound.flac -an -i video.mp4 -c copy output.mkv
- Al menos el primer video que probé en diferentes volúmenes y diferentes dispositivos.
Resultado
Aprovechando la oportunidad para aflojar las tuercas de las reglas, los invito a visitar el canal de YouTube resultante, donde comparto ideas sobre el estudio efectivo de la programación y las disciplinas relacionadas.
¡Buena suerte en el desarrollo de programas y la creación de video blogs!
Actualización : tradujo este artículo para su blog en inglés.