Mi nueva tarjeta de video puede ejecutar 4 sesiones de codificación simultáneas. Verifiqué esto usando FFmpeg Batch AV Converter anteriormente. Ahora estoy ejecutando lo mismo en MCEBuddy y mi uso de CPU es del 100% usando ffmpeg como codificador y la interfaz gráfica de MCEBuddy no responde y mi máquina está lenta. Quiero seguir usando MCEBuddy pero no puedo tener mi máquina paralizada para hacerlo. Tuve que cerrar la interfaz gráfica para poder hacer algo con mi máquina. Luego volví a abrir la interfaz gráfica y mostró el progreso de las cuatro conversiones durante unos 5 segundos antes de que se bloqueara y volviera a ser no responsiva nuevamente. El programa no es utilizable de esta manera. ¿Estoy haciendo algo mal y cómo lo corrijo?
El perfil para MKV HEVC no es compatible con la codificación por hardware, entonces ¿cómo pasa MCEBuddy los parámetros a ffmpeg? ¿O simplemente usa la configuración predeterminada en ffmpeg? ¿Hay alguna forma de cambiar los parámetros para la codificación por hardware?
Acabo de bajar a 2 conversiones simultáneas y eso mantiene el uso por debajo del 90% con las demás cosas que tengo en ejecución, así que al menos mi computadora es utilizable. Me encanta MCEBuddy, pero me gustaría saber cómo reducir el uso de CPU para 4 conversiones simultáneas y obtener el aumento de velocidad. Estaba usando un perfil personalizado en el otro programa y podía hacer 4 en aproximadamente una hora sin problemas y con un uso de CPU de alrededor del 65%.
Si la Aceleración por Hardware está marcada en la tarea de conversión, utilizará el hardware si detecta que está disponible. Si pudieras adjuntar uno de los registros de una conversión que está consumiendo mucha CPU, podríamos ver qué está sucediendo y hacer algunas sugerencias.
Por defecto, ese perfil intenta usar Handbrake primero; sin embargo, dependiendo de tu GPU, puede fallar porque la configuración “medium” no está disponible.
Además, el audio se recodifica, lo que puede consumir algo de CPU ya que no será manejado por la GPU, pero esto debería ser una cantidad muy pequeña. Yo prefiero copiar el audio.
Aquí está el perfil MKV HEVC.
Description=Conversión HEVC en MKV (H.265/AC3). Crea un archivo más pequeño (50% más pequeño que H.264) con calidad comparable pero muy lento.
order=handbrake,ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec libx265 -preset medium -crf 26 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 160k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 256k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-general=--decomb --loose-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e x265 --encoder-preset medium -q 26
handbrake-audio=-E ffac3 -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
Quería un poco más del perfil y quería forzar el codificador a la GPU específica que estaba usando. Solo cambia el order= si prefieres ffmpeg. Aquí hay un par de ejemplos:
Intel:
[HEVC MKV Intel]
Description=HEVC en MKV forzado a usar Intel.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_qsv -preset slow -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e qsv_h265 --encoder-preset quality -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
NVidia
[HEVC MKV AnyStream NVidia]
Description=HEVC en MKV forzado a usar NVidia.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_nvenc -preset hq -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e nvenc_h265 --encoder-preset hq -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-DisableSoftwareEncoderFallback=true
AllowAllCopyRemuxing=true
Además de usar codificadores de hardware y optimizar perfiles, también puedes consultar este tema para obtener detalles sobre cómo limitar los recursos utilizados por la codificación de video:
SystemIdleProcess…¿es [HEVC MKV AnyStream NVidia] un perfil que deba añadir a mi archivo de perfiles para probarlo? Si es así, ¿lo añado simplemente debajo del perfil HEVC actual, que es de codificación por software?
Encontré el punto débil del perfil actual con aceleración por hardware en MCEBuddy mientras veía una película anoche. El problema surge en condiciones de poca luz, donde la mayor parte de la pantalla son tonos de negro, blanco y gris porque está muy oscuro. Hay un efecto de halo o bandas, como anillos o un degradado de tonos que parecen un blanco con el centro de la pantalla siendo la diana o centrado alrededor de una persona que se mueve en la penumbra. En cuanto aparece color real en la escena, este efecto desaparece o se minimiza tanto que no se nota. En condiciones de buena iluminación, la imagen es casi perfecta. Cambiaba repetidamente entre esta codificación H.265 y la misma película en H.264, y en esta última el efecto no se ve.
Voy a usar esta película para experimentar con parámetros de codificación, ya que me gustaría que el efecto desapareciera pero mantener los tamaños de archivo lo más pequeños posible. ¿Tienes alguna sugerencia sobre qué parámetros debería modificar para corregirlo? Pienso codificar la película 5 o 6 veces con calidad ligeramente aumentada hasta que desaparezca y usar ese como mi nuevo perfil, al menos en películas de terror, ya que las de luz normal están geniales como están ahora. Esta es la primera vez que encuentro esta anomalía.
EDIT…Ok, añadí el perfil, lo seleccioné en MCEBuddy y estoy ejecutando solo esa película como línea base.
Gracias
Sé exactamente a lo que te refieres con las escenas oscuras/negras. Aún no he tenido mucho tiempo para experimentar con cómo resolverlo, pero vas por buen camino al aumentar la calidad (técnicamente disminuir el valor del calificador, 26 en el perfil) hasta que desaparezca. Aparte de eso, realmente no tengo sugerencias para ajustes de parámetros. Quizá también tengas que usar software para ese tipo de películas/series. Y tal vez incluso usar un perfil main10 para obtener un rip HDR10 adecuado. O H264 podría ser la solución. Honestamente, no tengo la respuesta.
Gracias por la ayuda; si ambos estamos experimentando, quizás encontremos una respuesta. Si lo resuelvo, quizás cree un perfil para películas de terror, ya que son las que tienen muchas escenas oscuras, especialmente con movimiento. Solo lo noté porque anoche vi The Amityville Murders y la segunda mitad es casi toda oscura. He visto este efecto en películas normales, donde las escenas muy oscuras tienen mucho negro y movimiento, pero como duran un segundo o menos, no merece aumentar el tamaño del archivo por algo que la mayoría no nota… yo lo noto todo.
Mi codificación H.264 de esta película tiene mejor calidad solo en las escenas oscuras, pero también es una codificación por software, así que quizás pruebe una codificación H.264 por hardware y vea si el problema persiste. De una forma u otra encontraré una solución, o quizás solo deje de preocuparme por algo con lo que pueda vivir si el archivo se vuelve demasiado grande. Llevo semanas viendo películas de terror cada noche y esta es la primera vez que el problema es evidente.
Lo noté en Bright y me pasa lo mismo; a mi esposa no le importó ni lo notó, pero a mí me pareció terrible.
Un truco que puedes usar para ahorrar tiempo es emplear la aplicación MCEBuddy Custom Cuts para eliminar las demás partes de la película y quedarte solo con la(s) escena(s) que quieres probar. O usa otro software para recortar el resto y tener solo la(s) escena(s) que deseas probar como archivo fuente.
Esa es una buena idea, puedo quitar un segmento de 5 minutos donde más lo noté y recuerdo ese momento, así puedo hacer todas las codificaciones en menos de una hora.
Ejecuté la película usando tu perfil tal cual, una vez con crf 23 y otra con crf 20, y no hubo diferencia alguna entre los tres archivos resultantes. Todos tenían el mismo tamaño y la misma calidad, con el problema presente como antes.
Hmmm… eso es extraño. ¿Estás seguro de que usó ffmpeg? ¿Puedes adjuntar un archivo de registro para uno de los archivos que convertiste?
[Cargando: The Amityville Murders STZEH.ts-Convert to MP4-2020-11-04T14-25-49.log…]
Este es el registro del último que hice donde establecí el crf en 20
No puedo subirlo por alguna razón, sigue diciéndome que la diferencia entre la hora de la solicitud y la hora actual es demasiado grande.
…Pero según el registro está usando ffmpeg… ¿pero por qué está usando comskip? Nunca ejecuto ese programa, ¿cómo lo desactivo?
Puede que llame a comskip pero no haga nada con él. No te preocupes por eso. ¿Ves “MCEBuddy.AppWrapper.Handbrake” en algún lugar hacia el final del registro?
No, no hay nada así con HandBrake al final; sí utiliza HandBrake al principio para verificar cosas, pero luego pasa a MCEBuddy.Transcode.ConvertWithFfmpeg.
Aquí hay algunas otras opciones para los presets del codificador nvenc_hevc.
-preset <int> E..V..... Establece el preset de codificación (de 0 a 11) (por defecto medium) default 0 E..V..... slow 1 E..V..... hq 2 pasadas medium 2 E..V..... hq 1 pasada fast 3 E..V..... hp 1 pasada hp 4 E..V..... hq 5 E..V..... bd 6 E..V..... ll 7 E..V..... baja latencia llhq 8 E..V..... baja latencia hq llhp 9 E..V..... baja latencia hp lossless 10 E..V..... sin pérdida losslesshp 11 E..V..... sin pérdida hp
Slow hace 2 pasadas de hq que podrían producir mejores resultados. Pero honestamente podríamos estar yendo por mal camino. Tal vez solo busques un poco en internet sobre ffmpeg y nvenc_hevc.
Honestamente, últimamente he estado usando principalmente la codificación por hardware de Intel porque es lo que tengo en mi máquina secundaria donde hago la mayoría de mis capturas/codificaciones.
Descubrí por qué cambiar el valor de crf no afectaba al video resultante…crf es solo para codificación por software, tienes que usar un valor cq con nvenc.
Además, todos esos perfiles que publicaste tienen otro problema…usan codificación por software para todo antes del parámetro nvenc, por ejemplo, el desentrelazado. Puedes usar yadif en nvenc y lo probé en ffmpeg Batch y cuando dejas que la GPU haga el desentrelazado, los tiempos de codificación son la mitad de los que lleva MCEBuddy…solo que aún no he logrado pasar todos los parámetros a nvenc en MCEBuddy de la forma en que están estructurados los perfiles. Sigo recibiendo errores.