Categoría: Homelab

  • Automatizando la conversión de video a 720p con find, ffprobe y HandBrake

    Script para reducir automáticamente la resolución de una biblioteca de video de 1080p (o superior) a 720p, aprovechando la aceleración por hardware de una GPU AMD para acelerar la codificación — útil para liberar espacio en disco en una biblioteca personal grande sin monopolizar la CPU durante horas.

    El script completo

    #!/bin/bash
    
    CARPETA_DESTINO="./Pelis_720p"
    
    # 1. Crear la carpeta de destino si no existe
    mkdir -p "$CARPETA_DESTINO"
    
    echo "=========================================================================="
    # 2. Buscar videos >= 1080p y procesarlos uno a uno
    find . -type f \( -name "*.mp4" -o -name "*.mkv" -o -name "*.avi" \) -exec sh -c '
        for f; do
            # Obtener el ancho del video de forma rápida
            w=$(ffprobe -v error -select_streams v:0 -show_entries stream=width -of default=nw=1:nk=1 "$f")
    
            # Filtrar solo si es igual o mayor a 1920px (1080p o superior)
            if [ "$w" -ge 1920 ] 2>/dev/null; then
                base=$(basename "$f" | sed "s/\.[^.]*$//")
                ext="${f##*.}"
                out="./Pelis_720p/${base}_converted.${ext}"
    
                # Si el archivo ya existe en el destino, saltarlo (protección anti-interrupciones)
                if [ -f "$out" ]; then
                    echo "Saltando (ya existe): $base"
                    continue
                fi
    
                echo "------------------------------------------------------------------"
                echo "Procesando: $f ($w px)"
                echo "------------------------------------------------------------------"
    
                # Ejecución optimizada con HandBrakeCLI + GPU AMD + baja prioridad de CPU
                nice -n 19 HandBrakeCLI --encoder-encoder-fallback \
                    -e vce_h264 \
                    -q 22 \
                    -w 1280 -l 720 \
                    --audio-lang-list any \
                    --aencoder copy \
                    -i "$f" \
                    -o "$out"
            fi
        done
    ' _ {} +
    
    echo "=========================================================================="
    echo "Proceso finalizado. Revisa la carpeta '$CARPETA_DESTINO'."
    echo "=========================================================================="

    Cómo funciona cada parte

    find + exec: procesar archivos en lote de forma segura

    find . -type f \( -name "*.mp4" -o ... \) -exec sh -c '...' _ {} + busca recursivamente todos los archivos de video con esas extensiones, y en vez de ejecutar el comando una vez por archivo (lo cual sería lento con bibliotecas grandes), usa -exec ... + para agrupar múltiples archivos en menos invocaciones del subshell. El sh -c '...' _ {} + es el patrón estándar para pasar una lista de archivos a un script embebido dentro de find, donde _ ocupa el lugar de $0 (el nombre del script, no usado aquí) y {} se expande a la lista real de archivos encontrados.

    ffprobe: detectar la resolución sin decodificar el video completo

    ffprobe -v error -select_streams v:0 -show_entries stream=width -of default=nw=1:nk=1 "$f"

    ffprobe (parte del proyecto ffmpeg) lee únicamente los metadatos del contenedor de video, sin decodificar los fotogramas — esto lo hace extremadamente rápido incluso en archivos grandes. -select_streams v:0 apunta específicamente al primer stream de video (ignorando pistas de audio o subtítulos embebidos), -show_entries stream=width pide solo el ancho en píxeles, y -of default=nw=1:nk=1 formatea la salida como un valor plano, sin encabezados ni etiquetas — listo para asignarse directamente a una variable de Bash.

    Filtrar solo videos de 1080p o superior

    La condición [ "$w" -ge 1920 ] compara el ancho detectado contra 1920 píxeles (el ancho estándar de 1080p) — cualquier video ya en 720p o menor se salta automáticamente, evitando procesar (y perder calidad innecesariamente) contenido que ya está en una resolución igual o menor a la deseada.

    Protección contra interrupciones

    La verificación if [ -f "$out" ]; then ... continue; fi es clave para bibliotecas grandes que pueden tardar horas en procesarse: si el script se interrumpe (por un corte de energía, un cierre accidental de la terminal) y se vuelve a ejecutar, salta automáticamente los archivos que ya fueron convertidos exitosamente, retomando el trabajo donde quedó sin reprocesar nada innecesariamente.

    HandBrakeCLI: los parámetros de codificación

    ParámetroFunción
    -e vce_h264Usa el encoder por hardware VCE (Video Coding Engine) de AMD para H.264, en vez del encoder por software (x264) — mucho más rápido, a costa de una eficiencia de compresión ligeramente menor
    -q 22Factor de calidad constante (menor número = mayor calidad y mayor tamaño de archivo). 22 es un valor moderado, buen balance para HD
    -w 1280 -l 720Fuerza el ancho y alto de salida a 720p exacto
    --audio-lang-list anyIncluye todas las pistas de audio disponibles, sin filtrar por idioma
    --aencoder copyCopia el audio original sin recodificarlo — solo se recomprime el video, preservando la calidad de audio intacta y acelerando el proceso al evitar una recodificación innecesaria

    Aceleración por hardware: por qué usar la GPU

    Codificar video en H.264 por software (usando la CPU) es una tarea intensiva que puede tardar varias veces la duración real del video, especialmente en equipos sin muchos núcleos. Las GPUs modernas (AMD VCE, Intel Quick Sync, NVIDIA NVENC) tienen bloques de hardware dedicados específicamente para codificación/decodificación de video, capaces de procesar la misma tarea en una fracción del tiempo — el costo es una eficiencia de compresión ligeramente menor a igual calidad percibida, comparado con encoders por software altamente optimizados como x264 en su configuración más lenta.

    nice -n 19: prioridad mínima de CPU

    nice -n 19 ejecuta el proceso con la prioridad de CPU más baja posible en Linux (el rango va de -20, máxima prioridad, a 19, mínima). Aunque la codificación se hace principalmente en la GPU, el proceso HandBrakeCLI sigue usando CPU para tareas de coordinación, demuxing y manejo de audio — nice -n 19 asegura que esas tareas cedan el paso a cualquier otra aplicación que esté usando el equipo activamente en primer plano, dejando la conversión corriendo en segundo plano sin afectar la experiencia de uso normal de la máquina.

    Notas

    • El script mantiene el archivo original intacto — el resultado se guarda en ./Pelis_720p/ con el sufijo _converted, por lo que la limpieza de los originales (si se desea liberar espacio) debe hacerse manualmente después de verificar la calidad del resultado.
    • --encoder-encoder-fallback permite que HandBrake recurra al encoder por software si la GPU no está disponible o falla, evitando que el script se detenga por completo ante un problema puntual con el driver de video.
    • Este enfoque es ideal para bibliotecas grandes de video donde se prioriza velocidad de conversión y ahorro de espacio en disco por encima de exprimir al máximo la eficiencia de compresión.
  • Herramientas de monitoreo para homelab: vnStat, cAdvisor, Netdata y más

    Un recorrido por las herramientas de monitoreo de red y contenedores más comunes en un homelab, desde lo más simple (vnStat) hasta stacks completos de observabilidad (Prometheus + Grafana), pasando por opciones intermedias que dan buena visibilidad sin tanta configuración.

    1. vnStat: monitoreo básico de tráfico de red

    vnStat es un contador de tráfico ligero que corre como servicio en segundo plano, acumulando estadísticas de consumo por interfaz sin necesidad de capturar paquetes activamente — esto lo hace muy liviano en recursos comparado con herramientas de captura en tiempo real.

    Verificar que esté funcionando

    sudo systemctl status vnstat
    sudo systemctl start vnstat
    sudo systemctl enable vnstat

    Consultar tráfico

    vnstat              # resumen general
    vnstat -h            # por horas
    vnstat -d            # por días
    vnstat -w            # por semanas
    vnstat -m            # por meses
    vnstat -l            # en tiempo real (modo "live")
    vnstat -i ens6       # interfaz específica
    vnstat -i ens6 -hg   # gráfico horario en texto
    vnstat --iflist      # listar interfaces monitoreadas

    Interpretando las interfaces detectadas

    En un host con Docker, vnstat --iflist típicamente muestra algo como:

    ens6
    docker0
    veth55b218c
    vetha4d99c4
    vethcb08ffb
    InterfazDescripción
    ens6Interfaz de red física principal del servidor
    docker0Bridge virtual principal que usa Docker por defecto
    vethXXXXInterfaces virtuales, una por cada contenedor conectado al bridge

    2. Docker: comandos básicos de inspección

    # Contenedores activos
    docker ps
    
    # Solo IDs
    docker ps -q
    
    # Detalle completo de un contenedor
    docker inspect <container_id>
    
    # Nombre y MAC address de todos los contenedores activos
    docker ps -q | xargs -n1 docker inspect --format '{{.Id}} - {{.Name}} - {{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}'
    # Ver todas las interfaces de red del sistema
    ip link show
    ip -o link show   # formato de una línea por interfaz, más fácil de leer en scripts

    3. Monitoreo por proceso o por conexión

    nethogs — tráfico por proceso

    Muestra qué proceso específico está generando el tráfico de red, en tiempo real — útil para identificar qué aplicación está consumiendo ancho de banda cuando no está claro a simple vista:

    sudo apt install nethogs
    sudo nethogs ens6

    iftop — tráfico por conexión

    En vez de agrupar por proceso, muestra el tráfico desglosado por cada conexión activa (IP origen/destino), ordenado por consumo — más útil para identificar con qué host específico se está intercambiando más datos:

    sudo apt install iftop
    sudo iftop -i ens6

    4. La limitación real de Docker: sin historial por contenedor

    Un punto importante a entender: Docker no mantiene estadísticas históricas por contenedor de forma nativa. Las interfaces vethXXXXXX son temporales — se crean y destruyen dinámicamente con cada contenedor, cambian de nombre al reiniciarlo, y por diseño no suelen quedar registradas de forma persistente en herramientas como vnStat. Esto significa que, si se necesita saber «cuánto tráfico consumió tal contenedor la semana pasada», vnStat por sí solo no puede responder esa pregunta — para eso hacen falta herramientas específicas de monitoreo de contenedores.

    docker stats: métricas en tiempo real, sin historial

    docker stats

    Muestra CPU, RAM, tráfico de red (Network I/O) y disco por contenedor, pero solo mientras el comando está corriendo — no guarda ningún historial una vez que se cierra la terminal.

    5. cAdvisor: métricas Docker con algo de historial

    cAdvisor (Container Advisor, de Google) sí guarda un historial reciente de métricas por contenedor y las expone en una interfaz web propia, sin necesidad de configurar nada adicional:

    docker run \
      --detach \
      --volume=/:/rootfs:ro \
      --volume=/var/run:/var/run:ro \
      --volume=/sys:/sys:ro \
      --volume=/var/lib/docker/:/var/lib/docker:ro \
      --volume=/dev/disk/:/dev/disk:ro \
      --publish=8080:8080 \
      --name=cadvisor \
      gcr.io/cadvisor/cadvisor:latest

    Acceso vía navegador en http://IP_SERVIDOR:8080. Los volúmenes montados en modo solo lectura (:ro) le dan a cAdvisor visibilidad sobre el sistema de archivos raíz, los procesos, cgroups y discos del host — necesarios para poder atribuir el consumo de recursos a cada contenedor individualmente.

    6. Netdata: monitoreo integral con la instalación más simple

    bash <(curl -Ss https://my-netdata.io/kickstart.sh)

    Acceso en http://IP_SERVIDOR:19999. Netdata destaca por dar visibilidad amplia (CPU, RAM, disco, red, Docker, procesos, servicios, ZFS, temperaturas) con una sola instalación y configuración mínima — es la opción con mejor relación esfuerzo/beneficio para un homelab que no necesita retención de datos a muy largo plazo ni dashboards altamente personalizados.

    Centralizar varios servidores con Netdata Cloud

    sudo netdata-claim.sh \
      -token <TOKEN> \
      -rooms <ROOM_ID> \
      -url https://app.netdata.cloud

    Permite ver el estado de múltiples nodos Netdata desde un único panel centralizado en la nube, sin tener que abrir cada instancia por separado.

    7. Alternativa «enterprise»: Prometheus + Grafana

    Cuando se necesita retención de métricas a largo plazo, dashboards altamente personalizables, y alertas configurables con reglas propias, el stack recomendado combina varias piezas especializadas:

    ComponenteFunción
    PrometheusBase de datos de series temporales que almacena las métricas
    Node ExporterExpone métricas del sistema operativo host para que Prometheus las recolecte
    cAdvisorExpone métricas específicas de contenedores Docker
    GrafanaCapa de visualización, dashboards y alertas sobre los datos de Prometheus

    La diferencia clave frente a Netdata: este stack separa la recolección (exporters), el almacenamiento (Prometheus) y la visualización (Grafana) en piezas independientes — más trabajo de configuración inicial, pero mucho más flexible y con retención de datos configurable a voluntad (semanas, meses), en vez de la ventana más corta que suele manejar Netdata por defecto.

    8. Opción ligera adicional: Glances

    pip install glances[all]
    glances -w

    Acceso en http://IP_SERVIDOR:61208. Glances es una alternativa liviana en Python, útil como panel rápido de estado general del sistema sin necesitar instalar un stack completo.

    Recomendación para un homelab típico

    Para una infraestructura con Proxmox como hipervisor, corriendo Docker y varios contenedores/servicios en un único nodo físico, la mejor relación esfuerzo/beneficio suele ser progresiva:

    1. Netdata — cubre aproximadamente el 80% de lo que normalmente se necesita para administrar un homelab completo, con la instalación más simple de todas.
    2. cAdvisor — se agrega cuando se necesita métricas Docker más detalladas y con algo más de historial que docker stats.
    3. Grafana + Prometheus — se justifica cuando se necesita histórico avanzado, dashboards personalizados a medida, y alertas con reglas propias — el paso natural cuando un homelab crece más allá de unos pocos servicios.