¿Cómo debo codificar mi transmisión de video 4K?

Estoy capturando video 4K sin comprimir desde mi Sony A7R II a través de un dispositivo de captura de video y estoy usando ffmpeg para guardar el video.

Mi problema es que no sé qué códec usar. Las dos opciones que probé son:

  • Sin comprimir : esto ocupa demasiado espacio, algo así como 1Gb cada pocos segundos.
  • h264 : esto muy rápidamente comienza a saltar fotogramas. Lo he intentado libx264, nvency qvxtodos esencialmente llenan el búfer y luego comienzan a saltar fotogramas después de menos de un minuto de disparo.

Estoy haciendo todo esto en una computadora portátil, por lo que tengo pocas posibilidades de agregar codificación de hardware, especialmente considerando que las soluciones de Intel y Nvidia, al menos en mi máquina, son claramente insuficientes para 4K.

Mis requisitos son que el códec permita:

  • Alrededor de 4 a 5 horas de metraje capturado caben de manera confiable en un SSD de 500 Gb
  • La codificación puede ocurrir en tiempo real sin que se eliminen fotogramas
  • El códec es compatible con el posprocesamiento

Por si te sirve, mi laptop tiene un i7-4710MQ y 32Gb de RAM.

Actualización : alguna aclaración: grabo a 30FPS, mi dispositivo de captura es INOGENI, el muestreo es 4:2:0. Y no, no quiero perder más calidad de la necesaria. Si tengo que gastar 100 Gb/hora para grabar, estoy de acuerdo con eso.

¿Qué comando(s) ffmpeg has probado? ¿Estás capturando audio también? ¿Sabes qué muestra de croma emite la cámara? Supongo que ejecuta un HDMI desde la cámara a su computadora portátil.
Además del submuestreo de croma (4:2:0 o 4:2:2 o 4:4:4), especifique el número de fotogramas por segundo.
Agregue también su prioridad entre perder calidad o disminuir la capacidad de grabación
@RawBean agregó aclaraciones
@Mulvya He intentado cosas comoffmpeg -f dshow -rtbufsize 2000M -video_size 3840x2160 -i video="2318-INOGENI 4K2USB3":audio="Digital Audio Interface (2318-INOGENI 4K2USB3)" -c:v nvenc -preset slow -loglevel info r:\4k.mp4
Algunas cosas: supongo que la grabación directa en tarjetas SD no es aceptable: la cámara guarda XAVC-S como una transmisión de 100 Mbps en tarjetas SD, es decir, 5 horas en ~225 GB. Más pertinentemente, ha aplicado el preajuste lento: ffmpeg debe poder consumir paquetes lo suficientemente rápido. Usar libx264con veryfasto ultrafastpreestablecido y perfil maino baseline.
@Mulvya ja! la grabación directa en SD es imposible debido al terrible límite de 30 minutos. eso simplemente mata todo el asunto por completo.
@Mulvya veryfastparece funcionar, nada más lento no

Respuestas (1)

Como mencionó @Mulvya, creo que el problema es el preajuste "lento".

Una opción es codificar una transmisión comprimida que también no tenga pérdidas. Por ejemplo, el codificador x264 puede hacer esto usando "-preset ultrafast -qp 0". Esto probablemente resultará en el incumplimiento de su tercer requisito (compatibilidad), pero dado que no tiene pérdidas, puede transcodificar más tarde en discos giratorios baratos. También puede considerar usar el codificador sin pérdidas huffyuv, que podría ser mejor compatible. Hay algunos errores con este método, por lo que definitivamente desea probar su flujo de trabajo de principio a fin. En particular, vea esta pregunta: El uso de h264 en modo sin pérdida trae pequeños resultados inesperados

Si sigue esta ruta, también experimentaría eliminando el submuestreo y codificando en 4: 4: 4. Es posible que no aumente tanto el tamaño de su archivo y lo ayudará si planea realizar algún trabajo de posproducción.

Otra opción, dependiendo de tu presupuesto, es comprar un codificador. Me encanta FFmpeg, pero está diseñado para funcionar en todas partes, no para aprovechar al máximo tu hardware. Mainconcept no es demasiado caro y podrá usar mejor el procesador i7 que ya pagó. (Consulte https://software.intel.com/en-us/articles/using-the-intel-media-sdk-within-mainconcept-h264avc-encoder-for-intel-quick-sync-video , por ejemplo). también ofrece un codificador HEVC que reduciría aún más el tamaño de su archivo. Sin embargo, no puedo responder por la calidad, ya que mi experiencia es con Ateme. Pero creo que al menos puedes evaluarlo gratis.

x264 produce una salida sin pérdidas. Agregué una respuesta a la pregunta a la que se vinculó.