Programa de conversión de video de código abierto HandBrake 1.7.0

 (forum.handbrake.fr)
3 puntos por GN⁺ 2023-11-21 | 1 comentarios | Compartir por WhatsApp

Aviso de actualización de HandBrake 1.7.0

  • Antes de actualizar HandBrake, verifica que no haya codificaciones pendientes y se recomienda hacer una copia de seguridad de los presets personalizados y de la configuración de la aplicación.
  • Los usuarios de Windows deben instalar obligatoriamente la versión 6.0.x de Microsoft .NET Desktop Runtime; aunque tengas instalado .NET 7, también necesitas instalar .NET 6.

Notas de la versión de HandBrake 1.7.0

  • La lista completa de mejoras y correcciones de errores puede consultarse en las notas de la versión en GitHub.

Reporte de problemas y envío de comentarios

  • Si encuentras un bug o problema reproducible, o quieres enviar comentarios, se solicita que lo informes a través del rastreador de issues de GitHub.
  • También es posible contactar a través del canal de soporte de la comunidad en IRC.
  • La aplicación HandBrake es desarrollada por un pequeño equipo de voluntarios en su tiempo libre, por lo que puede ser difícil responder de inmediato; aun así, revisan todos los comentarios y agradecen la retroalimentación constructiva.

Agradecimientos y contribuciones

  • Algunas funciones de esta versión fueron aportadas por usuarios o empresas de HandBrake, y las traducciones se realizaron gracias a la participación activa de una comunidad global de voluntarios.
  • A quienes tengan interés en contribuir pero aún no participen, se les recomienda leer la guía de contribución.
  • Hay muchas formas de contribuir incluso si no eres desarrollador.

Opinión de GN⁺

  • La actualización a HandBrake 1.7.0 requiere respaldar la configuración personalizada e instalar el nuevo runtime de .NET.
  • Esta actualización incluye mejoras y correcciones de errores, y es un proyecto impulsado por la comunidad con aportes de usuarios y empresas.
  • Esta nota anuncia el lanzamiento de una nueva versión de HandBrake, un transcodificador de video de código abierto, y resulta interesante porque destaca la importancia de la colaboración y las contribuciones dentro de la comunidad tecnológica.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-21
Opiniones en Hacker News

  • Si te parece una pena que HandBrake no calcule automáticamente el resto cuando especificas el tamaño final del archivo, el cálculo en sí es simple
    Bitrate promedio [kbps] = tamaño objetivo [kilobits] ÷ duración [segundos]
    Por ejemplo, para hacer que un archivo de 2 horas y 48 minutos quede por debajo de 5 GB, 2 horas y 48 minutos son 10,080 segundos y 5 GB son 40,000,000 kb, así que el bitrate promedio es 40,000,000 kb ÷ 10,080 segundos = 3,968 kbps
    Si el audio es de 256 kbps, el bitrate promedio de video debe ser de 3,712 kbps o menos

    • Este cálculo solo es correcto cuando se codifica con bitrate constante
      Normalmente se codifica con calidad constante, y el tamaño de salida depende mucho del video de entrada
      Por eso hice un wrapper en Python que parsea la salida de HandBrakeCLI y estima el tamaño final según el porcentaje completado y el tamaño actual del archivo de salida
      Si parece que el archivo va a quedar demasiado grande, o si la calidad de salida es demasiado mala y se decide que hay que subir el factor de calidad, se puede detener antes

  • Me alegra que el mensaje “Put that cocktail down. Your HandBrake encode is complete!” siga ahí después de tantos años

    • Me gustan esos detalles. Me da la sensación de que le devuelven un poco de alma o algo fantasmal a la máquina

  • Antes, incluso después de que el pipeline de HandBrake pasara a 10 bits, una buena parte de los filtros seguía siendo de 8 bits, así que era fácil degradar la calidad de codificación sin darse cuenta si elegías el filtro equivocado
    Ahora parece que la mayoría, quizá todos, los filtros soportan 10 bits
    Además, como no podían incluir FDK-AAC por su licencia, el códec AAC de las versiones publicadas estaba en desventaja, pero he oído que hoy ese códec ya no es tan malo como antes
    Me pregunto si la versión actual de esta gran app todavía tiene alguna trampa importante

    • Desde la 1.6, todos los filtros soportan alta profundidad de bits. La calidad del encoder AAC también ya es bastante decente, y en macOS se puede usar el encoder AAC de Apple, así que no es un problema
      En todo caso, el problema central es la falta de gente. Muchas funcionalidades deseables están detenidas en el cielo de las funciones
      Supongo que pasa algo parecido con todos los proyectos open source

  • Últimamente le pido a ChatGPT comandos de terminal para ffmpeg
    Es mucho más rápido que cualquier app y lo puedo ajustar como quiero

    • Basta con hacer clic en el archivo, elegir “open with handbrake” y presionar “convert”. No imagino algo más rápido que eso
    • “Lo puedo ajustar como quiero” en realidad significa entender las opciones de ffmpeg y cómo interactúan entre sí
      Es difícil ver cómo hacer prueba y error o leer las páginas del manual puede ser “mucho más rápido” que elegir un preset en HandBrake y marcar casillas o mover sliders
    • Pero ChatGPT no conoce el formato del archivo. A menos que también incluyas la salida de ffprobe en el prompt
      Si la fuente es un DVD, hay muchas cosas a considerar, como problemas de relación de aspecto, desentrelazado, manejo de subtítulos, etc.
    • ffmpeg es el único programa al que de verdad le vendría bien algo de no-code visual
      Ahora termino buscando una opción tipo --help, algo como --chatgpt, para poder navegar cualquier página del manual
    • Es más rápido, pero también más propenso a errores. La app también se puede ajustar como uno quiere, así que en eso están empatados

  • La lista de funciones se ve bien. Me entusiasman especialmente las mejoras de rendimiento en arquitecturas arm64 / aarch64 / Apple Silicon, la decodificación HEVC más rápida del FFmpeg más reciente y el filtro bwdif 30% más rápido, la mejora de rendimiento de hasta 4 veces gracias a las nuevas optimizaciones en assembly de SVT-AV1, y el aumento de la eficiencia de memoria y de la velocidad de conversión de video al eliminar copias de frames innecesarias

  • Mi única queja sobre HandBrakeCLI es que no puede codificar entradas pipeadas por stdin
    FFmpeg sí lo soporta, y pensaba que HandBrake también usaba FFmpeg internamente

    • HandBrake usa libavformat, libavcodec y libavfilter, que son parte de las bibliotecas de FFmpeg
      Aun así, es una app completamente distinta. Los decoders, algunos demuxers y algunos filtros son los mismos, pero la forma en que los conecta es totalmente distinta a la app de línea de comandos de FFmpeg
    • ¿No servirían los named pipes?
      O quizá se pueda hacer alguna magia de Bash como handbrake-cli -i <(cat video-file.mp4)
      Nunca usé HandBrakeCLI, solo la GUI, así que no lo sé bien
    • Cuando conocí HandBrake me sorprendió que, en vez de limitarse a usar FFmpeg, hace muchos componentes por su cuenta
      Por supuesto, en otras partes usa ampliamente las bibliotecas de FFmpeg
      Es uno de los pocos transcodificadores que no se quedan en ser un wrapper de FFmpeg, lo cual es tanto una ventaja como una desventaja

  • ¿Alguien puede explicar de forma simple por qué HandBrake dice que no puede implementar una opción de tamaño de archivo objetivo?
    En apps de compresión de video para Android esta función funciona bastante bien, pero en una solicitud relacionada en GitHub de HandBrake uno de los mantenedores dijo que en la práctica era difícil

    • Esto es literalmente una función que ofrecen todos los encoders subyacentes. Incluso es posible en cadenas de filtros exóticas de ffmpeg/vapoursynth
      Así que no imagino por qué dicen que no se puede
      Si usas Windows, simplemente recomendaría Staxrip: https://github.com/staxrip/staxrip
      También hay una app equivalente para Linux basada en vapoursynth, pero no recuerdo el nombre
      O quizá era una de las GUI de AV1an. Todas estas herramientas soportan tamaño de archivo objetivo y tienen muchas más funciones que HandBrake

  • ¿Por qué todavía no existe una función simple de “limitar el video X al tamaño de archivo Y”?
    Yo solo quiero un archivo de video de 5 GB, pero parece que a HandBrake le importan más 50 presets de Vimeo que ni conozco bien

    • No entiendo por qué quieres específicamente un límite de 5 GB. ¿Tienes el cajón lleno de memorias USB de 5 GB que quieres llenar?
      5 GB es claramente más que un CD y, salvo que quieras meter exactamente 10 en un Blu-ray, es demasiado poco para un Blu-ray
      Así como los presets de Vimeo te parecen raros a ti, al resto del mundo tu caso de uso le parece raro

  • Salvo cuando manejo videos HDR, siempre prefiero ffmpeg antes que HandBrake
    No encontré un comando adecuado de ffmpeg que copie los metadatos HDR de la fuente de entrada a la salida
    La última vez que revisé no era posible, y había que extraer manualmente los metadatos con una herramienta como MediaInfo y luego pasar cada valor como argumento de ffmpeg
    ¿Alguien sabe si sigue siendo así?

    • ¿Probaste usar -movflags y use_metadata_tags?
      ffmpeg -i $input_file -movflags use_metadata_tags -crf 22 $output_file
      Fuente: https://video.stackexchange.com/a/26076
    • Sí, parece que todavía hay que extraer los metadatos uno mismo e ingresarlos manualmente
      Explicándolo un poco más, los estándares comunes de video HDR son dos: Dolby Vision y HDR10. Ambos requieren soporte separado dentro del codificador, y eso es más un tema de libx265 que de libavformat/ffmpeg
      Por suerte, si el video fuente es HDR10, se pueden extraer la función de transferencia y el mapeo de tonos, que no cambian globalmente, y aplicarlos directamente a los metadatos de salida. FFmpeg puede pasar estos valores al codificador, pero por defecto no los copia de la fuente al destino
      Hay un artículo que explica el método en https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...
      Alguna vez recodifiqué a otro formato un video codificado en HDR10 manteniendo los metadatos, y el comando final que quedó en mi historial de shell era más o menos ffmpeg -i Movie-with-HDR.mkv -c:v libx265 -map_metadata:s:0 0:s:0 -map_metadata:g:0 0 -x265-params crf=21:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)":max-cll=1000,240 Movie-output.mkv
      Aquí, las configuraciones master-display y max-cll son la función de transferencia de color que tuve que extraer del primer video con otra herramienta. Estas configuraciones aparecen en la documentación de parámetros de libx265: https://x265.readthedocs.io/en/master/cli.html
      Dolby Vision es más difícil. Como los metadatos son dinámicos, no tengo claro cómo podrían obtenerse desde la fuente, aunque sí pueden suministrarse a libx265 mediante argumentos de línea de comandos. Lamentablemente solo están expuestos por línea de comandos y no en la API, así que por ahora ffmpeg no puede encargarse de eso
      Como referencias relacionadas, el proceso de extraer la función de transferencia y pasarla a ffmpeg está en https://medium.com/@yllanos/how-to-encode-a-4k-hdr-movie-usi... y https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f..., y un texto donde varias personas recopilaron el mismo trabajo está en https://www.reddit.com/r/ffmpeg/comments/g3uucr/how_do_i_enc...
      Para la conversión de Dolby Vision a HDR10, y temas relacionados con HLG y PQ, se puede ver https://www.reddit.com/r/ffmpeg/comments/nkxbay/how_to_conve..., y las sutilezas de Dolby Vision están en https://www.reddit.com/r/ffmpeg/comments/a32yv4/deleted_by_u...

  • Creo que el enlace del lanzamiento en sí habría sido mejor
    Incluye el registro de cambios, que probablemente es lo que la mayoría quiere ver
    https://github.com/HandBrake/HandBrake/releases/tag/1.7.0