Comparación de Velocidad
100 views
Skip to first unread message
Guillermo Gabrielli
Aug 5, 2015, 3:26:08 AM8/5/15
to OpenFING
Con respecto al script para generar los mp4 para edición, del cual no estábamos seguros que configuración utilizar:
El video tiene 1440x1080, presumo que un video 1920x1080 requeriría 33% más tiempo y tendría un tamaño 33% mayor en crf. Se realiza deinterlazado con yadif de 50i a 25p.
La CPU en la que probé es Core i5-4690 (3500 Mhz a 3900 Mhz en turbo) y GPU Nvidia GTX 960 (pero x264 casi no la usa). La versión de ffmpeg es 2.7.2-1~vivid1 sobre Ubuntu 15.04
x264 (la librería que usa ffmpeg para convertir el video) tiene básicamente 2 modos de operación:
- bitrate: Especifica cuantos bits por segundo promedio tiene permitido usar. x264 determina que partes del vídeo deberían recibir más bitrate y que partes menos. Hay 2 variantes:
- 1 paso: Intenta decidir que bitrate debería asignar a cada escena de acuerdo a lo que ya esté procesado del vídeo. Esto implica que debe actuar conservativamente e ir variando la calidad a lo largo del video de ser necesario para mantenerse cerca del bitrate especificado. Esto hace que la calidad sea un poco inferior a 2 pasos.
- 2 pasos: hace una codificación de prueba (omitiendo algunas etapas) en un primer paso para medir la complejidad y tomar decisiones del tipo de frame, mientras que en un segundo paso realiza la compresión en sí.
- crf: No intenta obtener un bitrate objetivo sino que intenta que la calidad sea consistente. Se considera que crf 18 debería proporcionar una calidad muy buena. A mayor crf menor calidad. Aumentar en 1 el valor del CRF corresponde a reducir el bitrate por aprox. 15%, está calibrado para que aumentar 6 unidades corresponda a reducir el bitrate a la mitad.
La diferencia entre los 2 modos es que elegir el bitrate permite predecir el tamaño por unidad de tiempo. El bitrate es justamente tamaño / duración. Si se tiene en la mente un tamaño por hora basta dividir entre 3600/8=450 y restar el bitrate que se quiera asigar al audio. Así por ej. 1 Gb / hora = 1.07 x 10^9 / 450 = 2360 - 256 = 2100 kbps aprox.
La desventaja es que la calidad no es necesariamente la misma de vídeo a vídeo. Vídeos de mayor complejidad tendrán menor calidad y vídeos de menor complejidad tendrán mayor calidad a fin de mantener el bitrate. Sin embargo no creo que haya demasiada variación en nuestro caso pues las características y complejidad de los vídeos son muy similares (generalmente los profesores no dan clases de baile ni artes marciales), puede depender de que tantos movimientos tenga que hacer la cámara.
El modo CRF intenta mantener una calidad consistente. Así por ejemplo una clase de baja complejidad a calidad 20 podría ocupar 1 GB por hora mientras que una de alta complejidad podría ocupar 2 GB y una normal 1.5 GB, pero la calidad debería ser similar entre las 3. En teoría para el mismo tamaño debería proporcionar la misma calidad que 2 pasos pues se basa en el mismo algoritmo de decisión.
| 1440 x 1080 | 1920 x 1080 (Estimación) | ||||||
| Modo 2 pasos (2000 kbps) | |||||||
| Tiempo (seg) | x Duración | Tamaño (MB) | Tiempo (seg) | x Duración | Minutos por Hora | Tamaño (MB) | |
| ultrafast | 91,39 | 0,30 | 84,9 | 122 | 0,41 | 24 | 84,9 |
| superfast | 107,96 | 0,36 | 144 | 0,48 | 29 | ||
| fastest | 123,54 | 0,41 | 164 | 0,55 | 33 | ||
| faster | 147,67 | 0,49 | 196 | 0,65 | 39 | ||
| fast | 176,22 | 0,59 | 234 | 0,78 | 47 | ||
| medium | 210,31 | 0,70 | 280 | 0,93 | 56 | ||
| slow | 302,02 | 1,01 | 402 | 1,34 | 80 | ||
| slower | 444,97 | 1,48 | 592 | 1,97 | 118 | ||
| Modo CRF preset=medium | |||||||
| Crf 18 | 194,29 | 0,65 | 132,2 | 258 | 0,86 | 52 | 176 |
| Crf 19 | 180,98 | 0,60 | 110,6 | 241 | 0,80 | 48 | 147 |
| Crf 20 | 169,56 | 0,57 | 92,6 | 226 | 0,75 | 45 | 123 |
| Crf 21 | 159,59 | 0,53 | 77,9 | 212 | 0,71 | 42 | 104 |
Conclusiones:
- En 1920x1080 el modo normal demoraría casi 1 hora en convertir 1 hora de video en un CPU con 4 núcleos.
- Slow corresponde a un aumento de 25 minutos mientras que Slower salta a 2 horas por hora de vídeo.
- La ventaja de los modos más rápidos en 2 pasos no es tanta (sobre todo porque hay que desentrelazar 2 veces)
- CRF es unos 10 minutos más rápido por hora de vídeo.
Postdata: probé un video de 32 minutos en 1920x1080 (una clase de arquitectura del 14/11) con crf 20 preset medium film
demoró 26:51 y pesó 822MB. Equivale a unos 50 minutos y 1.6 GB por hora.
Fernando Carpani
Aug 5, 2015, 9:26:29 AM8/5/15
to open...@googlegroups.com
hola a todos.
Excelente esto.
Una pregunta y un anuncio.
Pregunta:
Estás seguro que estás usando NVENC ? en teoría debería usar la tarjeta y acelerar: http://ffmpeg.gusari.org/search.php?keywords=nvenc&sid=12ecf0b92aa9ca1b13180e4f6288d462
Hay bastante doc al respecto pero un poquito dispersa y a veces un tanto contradictoria. Ej. http://www.phoronix.com/scan.php?page=news_item&px=ffmpeg-2.6-released
y http://ubuntuforums.org/showthread.php?t=2265485. Aunque si miramos las fechas, el último es anterior al otro anuncio.
Sin embargo, hay que garantizar igual que el encoder está activado (aparentemente). Debiera acelerar drásticamente.
Anuncio:
Casi casi tenemos máquina !
La estuve probando y funciona muy bien... tiene el lector de tarjetas que anda al pelo. Lo único que falta es que configuren un disco de 3TB interno.
La máquina está al lado de mi oficina por ahora.
Por otro lado, están preparándome una máquina para testear nuevamente lo de las tarjetas. Máquina gentilmente prestada por el grupo de Ezzatti que hacen computación paralela sobre estas tarjetas. La tarjeta es chica y vieja, pero el punto es testear si se consigue que esto funcione y acelere.
La sala ya casi, casi está también. sólo falta un pequeño detallecito.
Saludos
FDO.
Excelente esto.
Una pregunta y un anuncio.
Pregunta:
Estás seguro que estás usando NVENC ? en teoría debería usar la tarjeta y acelerar: http://ffmpeg.gusari.org/search.php?keywords=nvenc&sid=12ecf0b92aa9ca1b13180e4f6288d462
Hay bastante doc al respecto pero un poquito dispersa y a veces un tanto contradictoria. Ej. http://www.phoronix.com/scan.php?page=news_item&px=ffmpeg-2.6-released
y http://ubuntuforums.org/showthread.php?t=2265485. Aunque si miramos las fechas, el último es anterior al otro anuncio.
Sin embargo, hay que garantizar igual que el encoder está activado (aparentemente). Debiera acelerar drásticamente.
Anuncio:
Casi casi tenemos máquina !
La estuve probando y funciona muy bien... tiene el lector de tarjetas que anda al pelo. Lo único que falta es que configuren un disco de 3TB interno.
La máquina está al lado de mi oficina por ahora.
Por otro lado, están preparándome una máquina para testear nuevamente lo de las tarjetas. Máquina gentilmente prestada por el grupo de Ezzatti que hacen computación paralela sobre estas tarjetas. La tarjeta es chica y vieja, pero el punto es testear si se consigue que esto funcione y acelere.
La sala ya casi, casi está también. sólo falta un pequeño detallecito.
Saludos
FDO.
--
---
Has recibido este mensaje porque estás suscrito al grupo "OpenFING" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openfing+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Guillermo Gabrielli
Aug 5, 2015, 11:18:26 AM8/5/15
to OpenFING
Estoy buscando si el build de ffmpeg que tenía tiene NVENC o no, igual la idea es no usarlo. En general se considera que la calidad por bit no es mejor que los presets más rápidos de x264 (aunque eso dicen los desarrolladores de x264, podrían no ser imparciales). Nvidia se olvidó de mencionar ese detalle. Estamos buscando que la calidad por bit sea adecuada, así no editores no tienen que descargar un archivo tan grande.
Con ffmpeg x264 la tarjeta gráfica tengo entendido que puede acelerar de 2 maneras:
1) Ocupándose de decodificar el mts
2) Con el "OpenCL-lookahead" (no me pregunten que es lo que hace) que es la parte que x264 logró migrar a la GPU. Parece que hay que agregar --open-cl a la línea de comandos y no se que hacen los demás parámetros. Hay una mejora de velocidad pero no es demasiada.
Guillermo Gabrielli
Aug 5, 2015, 12:11:45 PM8/5/15
to OpenFING
http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1365
parece que la opción se llama -x264opts opencl en ffmpeg
La probé pero resulta que incluso fue un poquito más lento por lo menos con el preset medium. 27:44.64 vs 26:51.06. La diferencia no fue significativa para decir que enlenteció pero ciertamente no aceleró.
Por otra parte parece que la decodificación por HW está desactivada por defecto. Puede ser que activarla cambie algo.
Fernando Carpani
Aug 5, 2015, 1:28:26 PM8/5/15
to open...@googlegroups.com
Hola.
OK. Pero sin NVENC, no hay tarjeta gráfica que valga. Creo que valdría la pena probarlo si se puede para ver en qué calidad realmente queda.
Por otro lado, tampoco se necesita una calidad espectacular :-) Alguien va a querer ver nuestras caras en 4K ????? :-) preferiría que no :-)
En 1440 x 1080, estamos hablando de archivos de más de 1GB .... creo que es demasiado. Si alguien no tiene una línea como la gente (se que ahora son fáciles, pero bueno)... se le complicaría bastante.
Por otro lado, por ejemplo la clase 4 de teoría, la veo perfecta y está en 1280 x 720 ... y son 400MB y tiene 20 min más.
No se... creo que tenemos que buscar el balance entre que se vea bien, se lea, y el tamaño. El tamaño por dos cosas: transmisión y espacio.
No se... es una opinión nomás. Pero me gustaría saber si alguien ve mal en 1280 x 720 ... con dificultades para leer, etc... o incluso en menos....
Sólo como referencia, revisando mails viejos encontre uno que tiene los parámetros de procesamiento que se usaban a diciembre 2014:
No digo que haya que seguir con esto... sólo digo que es una referencia.
Saludos
FDO.
OK. Pero sin NVENC, no hay tarjeta gráfica que valga. Creo que valdría la pena probarlo si se puede para ver en qué calidad realmente queda.
Por otro lado, tampoco se necesita una calidad espectacular :-) Alguien va a querer ver nuestras caras en 4K ????? :-) preferiría que no :-)
En 1440 x 1080, estamos hablando de archivos de más de 1GB .... creo que es demasiado. Si alguien no tiene una línea como la gente (se que ahora son fáciles, pero bueno)... se le complicaría bastante.
Por otro lado, por ejemplo la clase 4 de teoría, la veo perfecta y está en 1280 x 720 ... y son 400MB y tiene 20 min más.
No se... creo que tenemos que buscar el balance entre que se vea bien, se lea, y el tamaño. El tamaño por dos cosas: transmisión y espacio.
No se... es una opinión nomás. Pero me gustaría saber si alguien ve mal en 1280 x 720 ... con dificultades para leer, etc... o incluso en menos....
Sólo como referencia, revisando mails viejos encontre uno que tiene los parámetros de procesamiento que se usaban a diciembre 2014:
VIDEO BITRATE: 500
VIDEO WIDTH: 720
VIDEO HEIGHT: -1
AUDIO BITRATE: 128
FRAME RATE: 25
VIDEO CODEC: libx264
AUDIO CODEC: aac
No digo que haya que seguir con esto... sólo digo que es una referencia.
Saludos
FDO.
Diego Barreiro
Aug 5, 2015, 1:44:16 PM8/5/15
to open...@googlegroups.com
Hay un tema importante que no sé si están tomando en cuenta. Los editores van a trabajar sobre estos videos, y luego renderizarlos. La idea no es pasarles algo con la calidad que esperamos en el video final, sino algo con mucho más calidad, para que al renderizar tomando eso de fuente, quede todavía con una calidad potable. Lo que le pasamos a los editores debería ser lo más parecido a la calidad original, solo que comprimido. Yo creo que hasta 1 GB sigue siendo un tamaño razonable, y si algún editor tiene inconvenientes lo puede descargar en facultad o podemos hacer una excepción y que lo levante en el SAD.
El tema del tiempo que demore, dentro de parámetros razonables, no debería ser problema. El script puede correr cada noche, por ejemplo. Si demora 15 horas en comprimir los videos de un día, da igual.
Digo, si vamos a perder la calidad ya en una primera pasada, capaz que no tiene sentido que estemos filmando en 1920x1080 25p, ya de pique (que ojo, es algo que se planteó y puede ser válido discutirlo). Personalmente... yo sé que no estamos en holywood, pero no veo motivos para perder calidad innecesariamente. O sea, no es MP3 320 vs FLAC (que la verdad mi oido nunca jamás notó la diferencia), estamos hablando de diferencias que cualquier mortal nota a simple vista.
Saludos
Fernando Carpani
Aug 5, 2015, 3:14:12 PM8/5/15
to open...@googlegroups.com
Hola.
OK. Voy en línea.
OK. Voy en línea.
El 05/08/2015 14:43, Diego Barreiro escribió:
Hay un tema importante que no sé si están tomando en cuenta. Los editores van a trabajar sobre estos videos, y luego renderizarlos. La idea no es pasarles algo con la calidad que esperamos en el video final, sino algo con mucho más calidad, para que al renderizar tomando eso de fuente, quede todavía con una calidad potable. Lo que le pasamos a los editores debería ser lo más parecido a la calidad original, solo que comprimido. Yo creo que hasta 1 GB sigue siendo un tamaño razonable, y si algún editor tiene inconvenientes lo puede descargar en facultad o podemos hacer una excepción y que lo levante en el SAD.
OK. Me lo comí.... de acuerdo.
El tema del tiempo que demore, dentro de parámetros razonables, no debería ser problema. El script puede correr cada noche, por ejemplo. Si demora 15 horas en comprimir los videos de un día, da igual.
Exacto en este momento... Si podemos acelerarlo mejor...
Digo, si vamos a perder la calidad ya en una primera pasada, capaz que no tiene sentido que estemos filmando en 1920x1080 25p, ya de pique (que ojo, es algo que se planteó y puede ser válido discutirlo). Personalmente... yo sé que no estamos en holywood, pero no veo motivos para perder calidad innecesariamente. O sea, no es MP3 320 vs FLAC (que la verdad mi oido nunca jamás notó la diferencia), estamos hablando de diferencias que cualquier mortal nota a simple vista.
mmmmmmm Alguien me puede recomendar un oculista? :-) yo no noto una
diferencia apreciable entre 1080p y 720p...capaz que es por que mis
dispositivos son de baja calidad: (Una tele panavox de 24 (creo) y
un monitor samsung de 20 que no llega a 1920...). al menos para
esto. Si estoy viendo una película en una tele de 48" puede ser...
Sobre todo cuando es animación.... Pero una filmación de una clase
en un monitor de 15? en un monitor de 24? .
Tal vez como dice Diego, no valga la pena filmar en 1920x1080. En todo caso, se podría hacer el experimento de un día, unos minutos, filmar la misma clase con las dos cámaras puestas una al lado de la otra, para comparar en diferentes resoluciones.
Creo que en la calidad de la filmación, no necesitamos la perfección sino "lo razonable" Además hay que tener en cuenta la pérdida de calidad que se produce en transformación, como lo estaba haciendo Guillermo.
Insisto con dos cosas: No soy experto en estas cosas... toco de oído totalmente y lo mió es una opinión y trata de ser un aporta a la discusión, no otra cosa.
En la misma línea, creo que hay que tratar de mantener la simplicidad sin complicarnos (por absurdo que parezca :-) ).
Saludos a todos.
FDO.
Tal vez como dice Diego, no valga la pena filmar en 1920x1080. En todo caso, se podría hacer el experimento de un día, unos minutos, filmar la misma clase con las dos cámaras puestas una al lado de la otra, para comparar en diferentes resoluciones.
Creo que en la calidad de la filmación, no necesitamos la perfección sino "lo razonable" Además hay que tener en cuenta la pérdida de calidad que se produce en transformación, como lo estaba haciendo Guillermo.
Insisto con dos cosas: No soy experto en estas cosas... toco de oído totalmente y lo mió es una opinión y trata de ser un aporta a la discusión, no otra cosa.
En la misma línea, creo que hay que tratar de mantener la simplicidad sin complicarnos (por absurdo que parezca :-) ).
Saludos a todos.
FDO.
Guillermo Gabrielli
Aug 5, 2015, 4:23:16 PM8/5/15
to OpenFING
En el producto final idealmente no se verían muchas diferencias entre 1920x1080 y 1280x720 (o incluso 640x480 que era la resolución inicial de openfing) , porque el principal determinante de la calidad, dentro de ciertos márgenes, es el bitrate, es difícil escaparse de Shannon & Co. El margen inferior es que si se usa un bitrate demasiado bajo para una resolución se alcanzan limitaciones en el formato , pero (sorprendentemente, porque usar 1080p a 500 kbps no es muy canónico) ese no parece ser nuestro caso. En realidad creo que el mayor problema con 1080p es que los dispositivos móviles menos potentes no lo soportan.
Se esta usando 1920x1080 en la versión final porque:
1) a algunas personas (en particular a Diego) parece que no le andaba bien el reescale del kdenlive. Es te creo que es el motivo principal.
2) Algunas versiones del kdenlive, en especial la 0.9.10, no son muy buenas para el multithreading (parece que cambia el tamaño con MLT en vez de ffmpeg y la cantidad de threads de MLT está hardcoreada en 1) así que bajar la resolución no aumentó la velocidad
3) me parece que algún video quedaba mal en 1280x720 (probablemente se arreglaba con 2 pasos porque creo que era una cuestión de distribución de bitrate)
Igual se podría considerar convertir en 1280x720 para editar o para la versión final, pero me parece mejor seguir a 1080 en la grabación, en el caso poco común que la letra fuera pequeña y el zoom amplio con 1080 se puede arreglar, con 720 capaz hay que grabar de vuelta.
...
Fernando Carpani
Aug 5, 2015, 4:38:59 PM8/5/15
to open...@googlegroups.com
OK !
Saludos
FDO.
Saludos
FDO.
--
Guillermo Gabrielli
Aug 6, 2015, 11:06:20 PM8/6/15
to OpenFING
OK. Logré compilar y hacer funcionar un ffmpeg con NVENC para desengañarme. En realidad es bastante mejor de lo que esperaba, pero creo que x264 es un poco mejor.
La fuente es un mts de sistemas lineales (a 1440x1080) que tenía juntos a otros de arquitectura. Es un caso medio complicado porque se mueve mucho la cámara.
El bitrate en las 4 versiones es de 1500 kbps. Son los primeros 10 minutos del vídeo. (120 MB cada vídeo). Después de la flecha pongo el tiempo que demoró en comprimir para referencia.
En 1440x1080
2 pasos libx264 (preset=slow) -> 3:12 + 6:40 = 9:53
2 pasos nvenc -> 1:06
Escalado a 1280x720 (con lanczos):
2 pasos libx264 (preset=slow) 720p -> 2 min + 5 min = 7 min
2 pasos nvenc 720p -> 1:22
Por otro lado probé los distintos filtros de desentrelazado de ffmpeg, si es que se le fuera a entregar video ya desentrelazado en 25p a los editores.
Probé el yadif (que es el que se usa en el script), el kerndeint, el w3fdif y el yadif+mcdeint (en el modo fast, medium y slow) en el primer minuto de ese vídeo (a 5000 kbps)
Pero la verdad es que la diferencia es infima, creo que el yadif es suficiente.
...
Reply all
Reply to author
Forward
0 new messages