Actualización: Si estás usando HandBrake 0.9.9 y prefieres usar los nuevos «x264 Presets», tengo una guía actualizada para HandBrake 0.9.9 que se enfoca en eso en la sección de codificación de este sitio. Sin embargo, si sigues con los «Ajustes avanzados» o quieres información más detallada sobre los ajustes de audio, de imagen, etc. (que no he repetido en la nueva guía), sigue leyendo….
Los viejos y mejores ajustes H.264 / x264 para HandBrake no eran muy completos, y se volvieron obsoletos. Aquí trataré de tomar un pico más completo de los ajustes aquí para ayudarte a obtener los mejores ajustes x264 / Handbrake posibles para tu codificación. Advertencia: el escrito anterior era corto. Esta es increíblemente larga y detallada. Si te sientes abrumado (no te sientas mal, hay mucho que asimilar), hazlo lo mejor que puedas en HandBrake y usa esto como referencia cuando llegues a una opción de la que no estés seguro.
El enfoque aquí es obtener la mejor calidad usando x264 a través de HandBrake, incluso si toma mucho tiempo codificar (dentro de lo razonable en un procesador moderno de todos modos).
Que el cielo te ayude si estás usando un viejo Athlon…
Empezaré con los ajustes avanzados y trabajaré hacia atrás.
Configuración avanzada
Marcos de referencia: el máximo posible
Esto sube a 16. Desafortunadamente, el 16 romperá la reproducción en muchos dispositivos de hardware (y posiblemente en algunos reproductores de software). Así que si estás usando digamos… un iPad3, WDTV, Roku, AppleTV3, etc, tendrás que encontrar el máximo para ese reproductor. La forma más fácil es ver qué «Perfil» soporta tu dispositivo.
Usaré un ejemplo. El iPad3. La página de especificaciones lista el «Nivel de perfil 4.1» bajo la sección «TV y Video» (ahora mismo de todos modos – esa página podría cambiar cada vez que salga el iPad4). Así que no queremos ir más allá de lo que el «Nivel 4.1» soporta si queremos que el video se reproduzca en el iPad3.
Luego llevamos ese «Nivel 4.1» a la página de MPEG4 en Wikipedia donde veremos un montón de cosas crípticas bajo la parte de «Nivel 4.1». Cuando se trata de los marcos de referencia, tenemos que mirar lo siguiente en la última columna:
1280×720@68.3 (9)
1920×1080@30.1 (4)
2048×1024@30.0 (4)
Lo que está entre paréntesis (máximo de marcos almacenados) significa marcos de referencia.Un DVD típico cabrá dentro de los límites de 1280×720 y puede usar hasta 9 marcos de referencia*.
Para un BluRay de 1080p, hasta 4 cuadros de referencia.
Si pasamos por encima de esto, el iPad 3 (usando el nivel 4.1) podría ahogarse al intentar reproducirlo.
*Por el bien de la simplicidad, estoy siendo conservador al mencionar 9 cuadros de referencia para un DVD. Si miran un nivel más bajo como el 3.1 notarán que en realidad lista la resolución de un DVD de 720×480, y manejará 13 cuadros de referencia. Por lo tanto, es posible que puedas empujar 13 cuadros de referencia (o más) a nivel 4.1 en un DVD. Basta con decir que encontrar los verdaderos cuadros de referencia máximos a tu resolución y velocidad de cuadro particular puede ser muy difícil. La página de wikipedia sólo enumera algunos ejemplos para cada nivel. Si eres muy exigente a la hora de encontrar los cuadros de referencia máximos reales para tu fuente, puedes intentar hacer cálculos o simplemente hacer un poco de prueba y error.
Así que mira las especificaciones de tu dispositivo para encontrar el «Nivel del Perfil» y luego compáralo con el enlace de Wikipedia de arriba para averiguar los marcos de referencia máximos que puedes usar. Recuerda, esto depende de la resolución y como vimos en el ejemplo anterior, un DVD puede salirse con 9 marcos de referencia en el iPad 3, mientras que un BluRay sólo puede salirse con 4 marcos de referencia.
Si sólo estás reproduciendo tu contenido en un ordenador decente (a través de VLC, por ejemplo), no dudes en subirlo hasta 16. Sólo recuerda que probablemente no se reproducirá en muchos (si es que hay alguno) dispositivos de hardware actuales. Y un HTPC realmente lento podría incluso ahogarse.
Ten en cuenta que los valores altos tardarán mucho más en codificarse, incluso en una máquina rápida. Si 16 hace que la codificación tarde demasiado tiempo, no dudes en bajar a algo así como 8 (el valor predeterminado para el preset «más lento» en x264).
Máximo B-Frames: 16
16 se considera un ajuste de «placebo» en x264. Dicho esto, no añade una ridícula cantidad de tiempo a la codificación.
Esto sólo le dice al codificador cuántos bframes consecutivos puede usar. Lo más probable es que el codificador no encuentre una situación en la que tenga sentido usar 16 bframes consecutivos. Si los tiempos de codificación son realmente dolorosos, 8 podrían ser más razonables.
Codificación de Entropía de CABAC, Transformación 8×8, P-Frames ponderados: sí (comprobado)
Son todos diferentes, pero casi todo lo relativamente reciente los respalda. Si intentas reproducir el vídeo en un dispositivo muy antiguo o muy débil (donde muchos de los otros ajustes que estoy enumerando probablemente también serán problemáticos), es posible que tengas que desactivarlos.
CABAC simplemente usa una mejor compresión para ciertos datos en la codificación.
8×8 Tranform permite al codificador hacer otra cosa técnica ingeniosa con los i-frames.
Los P-frames ponderados tienden a mejorar la compresión cuando se produce un desvanecimiento.
B-Frames piramidales: Por defecto (Normal)
Si estás creando un disco BluRay real a partir de tu código, usa «Strict». De lo contrario, la mayoría de los dispositivos más recientes lo admiten (si estás usando algo antiguo/débil, es posible que tengas que apagarlo).
Los B-Frames son geniales. Esto los hace aún mejores. Esto permite que los B-Frames se utilicen como referencia para otros marcos (¡como otros B-Frames!).
B-Frames adaptables: Óptimo
Nuestro objetivo es bombear la misma calidad en un tamaño de archivo, así que ponlo en óptimo.
Por lo que entiendo, si lo pones en «ninguno», los B-Frames se pondrán en un orden simplista de «cortador de galletas», lo cual no es probable que sea lo ideal. Tanto «rápido» como «óptimo» permiten al codificador usarlos de manera efectiva/eficiente, con el óptimo haciendo un mejor trabajo.
Modo Directo Adaptativo: Auto
Esto tiene que ver con la «predicción del vector de movimiento». Asumo que lo espacial mira a cuadros individuales mientras que lo temporal mira a través de múltiples cuadros. Se supone que lo espacial es lo más útil, pero como eso no es *siempre* el caso, el uso de Auto es la mejor manera de que el codificador pueda usar lo que sea más útil.
Método de Estimación de Movimiento: Multi-Hexágono Desigual (umh)
La UMH es lo más alto que se puede alcanzar sin tener que pasar por tiempos de codificación locos.
El codificador utiliza ciertos patrones de estimación de movimiento (busca en Google si quieres saber cómo es cada uno). Si vas más allá de esto a exhaustivo (o transformado en exhaustivo – considerado el ajuste de «placebo»), se convierte en algo así como una búsqueda de fuerza bruta tonta.
Si intentas ir con Exhaustivo o Transformado Exhaustivo, tu codificación incluso en una máquina rápida puede tardar días, así que considera si realmente vale la pena para el efecto «placebo».
Subpíxel ME & Decisión de modo: 10 QPRD en todos los cuadros
Basta con decir que más alto es mejor, pero el 11 tomaría un poco más de tiempo y se considera un «placebo».
Rango de estimación de movimiento: 24-64
A pesar de que el 64 se considera mucho más allá incluso de la configuración de «placebo», mis códigos de DVD han tenido tiempos de codificación bastante razonables (menos de una hora para un episodio de 44 minutos), que es la única razón por la que he permitido que se mantenga tan alto. Los códigos de BluRay por otro lado…. se acercan a la mayor parte del día en una configuración de 64.
Algo en el rango de 16-24 es probablemente más sensato.
Este es el máximo rango en píxeles que el codificador buscará para el movimiento. Los ajustes más altos deberían ser más valiosos con resoluciones más altas (ya que una mano que se mueve en un BluRay viaja más píxeles que una mano que se mueve en un DVD, a pesar de viajar la misma distancia en su pantalla). Obviamente, un vídeo de alta resolución tenderá a ser más sensible a esta configuración que un vídeo de baja resolución.
Tipo de partición: Todos
Según entiendo, la configuración «más» (por defecto) permite 4 tipos de particiones primarias, y «todas» permite una quinta, que se supone que tiene una utilidad insignificante y ralentiza la codificación. La configuración «some» sólo permite las 2 más críticas/beneficiosas.
Si estás usando un moderno procesador 2011/2012, me inclinaría a configurarlo en «todo». Yo mismo no he notado efectos adversos en los tiempos de codificación (y también usé «todos» hace 3 años en sistemas más antiguos), así que si puede ayudar a veces, también puede mantenerlo.
Espaldera: Siempre
Es requerido por el ajuste de Subpixel ME & Mode Decision de 10 que se usó anteriormente. Si estás haciendo codificaciones de 2 pasos y encuentras que el primero es dolorosamente lento, podrías considerar ajustarlo a «Sólo Codificar»
Desbloqueo:
-1, -1 para cine (tv/películas) y animación 3d (cosas de Pixar)
1, 1 para la animación (Bambi, etc.)
-2, -2 para altos niveles de grano de película
Tenga en cuenta que si está tratando de sintonizar para conservar la película/grano, debe leer los ajustes manuales adicionales en http://forum.handbrake.fr/viewtopic.php?f=6&t=19426.
Lo anterior son pautas típicas de los ajustes de «afinación» de x264. No es sorprendente que esto esté diseñado para reducir el «bloqueo» en tu video final. Sin embargo, se hace a expensas de «suavizar» la imagen general.
En general, sigue las sugerencias anteriores. Si en tu vídeo ves un «bloqueo» que no existía en la fuente, es mejor que primero aumentes la configuración de RF (o la tasa de bits media) y/o que juegues con la configuración de AQ/Trellis que menciono a continuación.
Fuerza de Cuantificación Adaptativa: (deslizador)
1.0 (Por defecto) para tv/film y animación 3d (Material de Pixar)
0,6 para la animación (Mikey Mouse, Bambi, etc.)
0.5 para altos niveles de grano de película (necesitarás un alto bitrate o ajuste de calidad)
Estos son x264 «sintonía» por defecto y son buenas pautas. La forma más fácil de explicarlo es que los valores más altos tienden a quitar algunos trozos de las áreas más detalladas y ponerlos en áreas más bajas (más planas). Lo he visto explicado como anillado (alta fuerza AQ) vs. anillado (baja fuerza AQ), aunque incluso eso depende de la fuente.
Por lo que he probado, no parece tener mucho impacto visual para las codificaciones de películas de baja tasa de bits, aunque puede afectar al tamaño del archivo. A menos que estés dispuesto a hacer tus propias pruebas/investigaciones, te recomendaría usar la configuración recomendada para un «tamaño único».
Distorsión de la tasa psico visual: (deslizador)
1.0 (Por defecto) para tv/película y animación 3d (Pixar Stuff)
0,4 para la animación (Mikey Mouse, Bambi, etc.)
De nuevo, x264 «afinación» por defecto, y buenas pautas. Esto tiene similitudes con el ajuste «AQ» anterior en que se mueve alrededor de los bits. Los valores más altos tratan de mantener el «detalle» de la forma en que lo verías en la escena, a expensas de la calidad general.
Espaldera Psicovisual: (deslizador)
0.15 por tv/film y animación 3d (Pixar Stuff)
0 (por defecto) para la animación (Mikey Mouse, Bambi, etc)
0,25 por los altos niveles de grano de película
Atado en el entorno del enrejado de arriba. Los valores por defecto son buenas pautas.
Otras cosas:
Hay un montón de configuraciones personalizadas que puedes añadir en el cuadro de texto, pero puede que tengas que buscar un poco.
Es posible que tengas que modificar algunos de ellos ligeramente para que se ajusten a HandBrake. Los ajustes en el cuadro de texto tienden a estar en el formato settinga=1:settingb=5:settingc=32:etc con dos puntos (:) separando los ajustes. Echando un vistazo a la caja de texto en HandBrake, probablemente se puede averiguar el formato.
rc-lookahead – Si hace clic en el preajuste «High Profile» en HandBrake, verá que esto aparece en la caja de texto (no hay caja de opciones o deslizador). Hay un par de sistemas en el codificador que hacen uso de esto, y más alto es generalmente mejor (el máximo es 250). Dicho esto, rc-lookahead=60 es más o menos el máximo recomendado (incluso el ajuste «placebo» no va más alto).
Un par de razones para esto… Primero, se traga la RAM. Si tienes más de 8GB de RAM y te encuentras deseando que HandBrake utilice más, esto lo hará. Del mismo modo, si estás en un sistema de 32 bits o tienes 2 o 4 GB de RAM, me imagino que si aumentas demasiado esta cantidad, probablemente el codificador se caerá.
La siguiente razón es que los valores enormes no tienen mucho beneficio – los valores grandes toman un poco más de tiempo para la codificación, y el tamaño y la calidad del archivo no parecen cambiar. Tiendo a fijarlo alrededor de 120, pero no puedo decir que haya notado ningún beneficio.
nr – esto no es tocado/referenciado por HandBrake, pero puedes usarlo añadiendo manualmente nr=100 al cuadro de texto. Es un denotador incorporado en x264. La buena noticia es que está incorporado, con compensación de movimiento, es mínimo en cuanto a efectos secundarios negativos, reducirá ligeramente su tamaño de archivo, y es rápido. La mala noticia es que no es terriblemente bueno (los devs de x264 están abiertos a esto) – por lo que deduzco que sólo lo añadieron porque ya tenían datos de compensación de movimiento en el codificador, así que fue fácil de implementar.
Usé nr=100 y valores de hasta nr=1000 en un codificador con una fuente muy ruidosa/granulada. No había una diferencia masiva entre 100 y 1000 (aunque la calidad tampoco se resintió, y el tamaño del archivo disminuyó).
Sorprendentemente, está bien en la única cosa en la que el denotador de HandBrake es malo: el ruido en la fuente durante el movimiento. El dispositivo de eliminación de ruido incluido en HandBrake (hqdn3d) es bueno para la eliminación de ruido temporal durante las escenas estáticas, pero bastante malo para el ruido durante el movimiento. Normalmente tienes que aumentar el dispositivo de eliminación de ruido espacial para limpiarlo, pero es un gran gasto para tu imagen.
Sin embargo, el dispositivo x264 funciona bien para captar el ruido durante el movimiento, lo que complementa bastante bien al dispositivo hqdn3d de HandBrake. Me imagino que todavía palidece en comparación con otros denotadores de movimiento compensado, pero es mejor que nada, y como dije, no parece dañar mucho al resto de la imagen (si es que lo hace… Realmente no podría decirlo – tendría que probarlo en una fuente limpia para ver si noto algo).
Hay un número de otros ajustes x264 que puedes conectar manualmente en HandBrake también, pero los 2 de arriba son los únicos con los que he jugado.
Capítulos:
Por defecto, si cargas una fuente que incluye capítulos, estos serán incluidos aquí, a menudo llamados Capítulo 1, Capítulo 2, etc. No es muy descriptivo.
Aquí, puedes editar los nombres de los capítulos.
En los programas y películas de televisión en DVD/BluRay, algunos tienen una función de «selección de escena» en el menú que enumera todos los nombres de las escenas y te permite saltar a una escena (que en realidad es saltar a un capítulo). Si lo deseas, puedes introducir manualmente estos nombres de capítulo en HandBrake. También es posible importar un CSV con los nombres de los capítulos si se obtiene uno.
HandBrake NO soporta la edición de nada más que los nombres. Así que si tu video no tiene capítulos (o quieres añadir/quitar algunos), tienes que usar un programa diferente para hacerlo.
Dicho esto, en la parte superior de HandBrake, puedes elegir qué capítulos codificar. A veces un DVD/BluRay tendrá el último capítulo donde comienzan los créditos. Si no quieres codificar los créditos, comprueba el DVD/BluRay en un reproductor de vídeo (salta al último capítulo), y si son todos los créditos, no dudes en dejarlos fuera de la codificación.
Ten en cuenta que los créditos no necesitan una gran cantidad de velocidad de transmisión, pero en el caso de algo como la codificación de «El Señor de los Anillos», sí que llevan mucho tiempo (y recortarlos puede ahorrar un buen número de archivos). En otros casos, cortarlos es muy conveniente – no soy fan de ver créditos constantes cuando veo 2-3 episodios de un programa seguidos.
Subtítulos:
Si HandBrake encontró pistas de subtítulos en tu fuente, puedes añadirlas aquí (tantas como quieras). La selección «por defecto» hará que sea la pista por defecto que se reproduzca cuando el vídeo lo haga (si no hay ninguna por defecto, ninguna se reproducirá automáticamente a menos que la actives).
Sin embargo, no todos los dispositivos reproducirán las pistas de subtítulos. Esto puede ser particularmente frustrante cuando tienes subtítulos «extranjeros» o «forzados». Por ejemplo, cuando Jabba the Hutt habla en La Guerra de las Galaxias o alguien habla ruso en un programa de televisión. En estos casos, puedes «quemar» una pista para que forme parte de la imagen.
¿Pero cómo sabes qué pista tiene subtítulos de «audio extranjero»? HandBrake lo hace fácil – selecciona «Foreign Audio Search» junto con «Forced Only» y «Burned In». Esto buscará en las pistas de subtítulos cualquier cosa que se reproduzca un 10% o menos del tiempo (que son generalmente los subtítulos forzados). Si encuentra algo que cumpla con este criterio, lo grabará directamente en la imagen para que siempre esté ahí, sin importar en qué dispositivo se esté reproduciendo. La única desventaja es que si también añades subtítulos normales, se superpondrán mientras se reproduce el vídeo. Así que si estás grabando en «subtítulos forzados», deberías considerar dejar fuera otros.
El beneficio de la «Búsqueda de audio foráneo» es que si no estás seguro de si tu video tiene una o dos escenas con audio foráneo, puedes activar esto de todas formas – si lo hubo, HandBrake lo encontrará. Si no había ninguna, no se añadirá nada.
Ten en cuenta que en algunas fuentes, los subtítulos ya están grabados en la imagen. Un buen ejemplo es el BluRay de la región de EE.UU. para El Señor de los Anillos (Edición extendida). Así que no te asustes si no ves una pista de subtítulos separada en tu vídeo… puede que ya esté grabada.
Audio:
HandBrake listará las pistas de audio de su fuente y añadirá automáticamente la que crea que es la principal (normalmente en inglés con la mayoría de los canales). Puedes añadir más pistas si quieres – a menudo habrá una especie de 5.1ch principal, un canal principal 2.0, tal vez unos 2 canales con comentarios del director, otros idiomas, etc.
Para el códec de audio, la mayoría de los dispositivos reproducen AAC o MP3. La CAA se considera generalmente de calidad superior hoy en día, aunque la mayoría de la gente no notará la diferencia.
Para la CAA, el códec «CoreAudio AAC» se considera generalmente como el mejor. Sin embargo, se limita a los que codifican en el Mac (aunque se reproducirá en cualquier cosa que soporte AAC, incluyendo las máquinas de Windows). Si te quedas atascado en Windows, el «faac AAC» es la mejor opción aquí, a menos que estés dispuesto a usar algo como MeGUI en lugar de HandBrake (que soporta un codificador AAC Nero que se considera tan bueno como CoreAudio)
Dolby Pro Logic II es una opción de mezcla muy común – se reproduce en cualquier cosa en 2 canales, y está bien cuando se trata de «fingirlo» si se reproduce en digamos… un sistema de cine en casa con múltiples canales, aunque quieres leer más para los detalles de «pasar» que puedes preferir.
Samplerate – generalmente puedes dejarlo en «Auto». Si tienes una razón para especificar algo específico (como 44.1), adelante y hazlo, pero ten en cuenta que al configurarlo manualmente, te arriesgas a que el audio de baja muestra sea innecesariamente subido de tono, y viceversa.
La tasa de bits – 160 es común. 128 suele considerarse demasiado bajo (varias personas pueden notar la diferencia entre 128 y 160). Se podría aumentar, pero algunos dispositivos no están clasificados para ello. Es muy difícil distinguir las bitrates por encima de 160, y es increíblemente difícil distinguir cualquier cosa por encima de 192. Ten en cuenta que si añades pistas de «comentarios», puede ser una buena idea reducir la tasa de bits de éstas simplemente para no desperdiciar espacio: la calidad de un par de personas que hablan no es tan crítica como la de la pista principal de la película, no necesitas una tasa de bits alta para obtener una buena calidad de voz simple de todos modos, y a menudo no se escuchan con frecuencia.
También hay opciones «Passthru» – son un poco más arriesgadas de usar ya que dependerá del soporte del dispositivo para reproducirlas. Por ejemplo, puedes pasar por el AC3, o el DTS, pero si tu reproductor no lo soporta, puede que no tengas suerte. Además, estos no comprimen el flujo de audio, por lo que el passthrough es una idea terrible si lo que buscas son codificaciones de bajo tamaño. Sin embargo, si reproduces tu contenido extensamente a través de un sistema de cine en casa de 5.1 canales, el passthrough puede ser tu mejor opción.
Video:
Para el códec, x264 (¡esperemos que no hayas leído hasta aquí sin comprometerte!).
Para el framerate, «Same As Source» (Framerate variable) es generalmente lo mejor a menos que tengas una muy buena razón para apuntar a una tasa específica. Esto se duplica si haces algo como deseleccionar la fuente. En realidad, «igual que la fuente» es increíble. Establecer algo manualmente sólo corre el riesgo de crear problemas.
Calidad constante vs. Tasa de bits media – Ambos funcionan de manera similar. Ambos varían la tasa de bits a lo largo de la codificación, usando más bits cuando son necesarios y menos cuando no lo son.
La diferencia es que la calidad constante apunta a un cierto nivel de calidad, mientras que la tasa de bits promedio apunta esencialmente a un tamaño de archivo.
Tenga en cuenta que las mejoras del «tipo de compresión» en las configuraciones avanzadas tienden a afectarlas de diferentes maneras. Con Calidad constante, los ajustes más altos (como pasar de 1 a 5 fotogramas de referencia) tenderán a mantener el nivel de calidad establecido, pero reducirán el tamaño del archivo. Con una tasa de bits media, una mejora (como pasar de 1 a 5 fotogramas de referencia) tenderá a mantener el tamaño de archivo elegido, pero aumentará la calidad.
Un gran ejemplo de un beneficio de CQ aquí es si estás codificando una serie de TV con Calidad Constante. El Episodio 10 se verá tan bien como el Episodio 1, incluso si el Episodio 10 tuvo un millón de explosiones, mucho movimiento, etc. Claro, el Episodio 10 podría terminar siendo un poco más grande, pero el Episodio 15, que tuvo gente parada hablando durante la mayor parte del episodio, probablemente fue un poco más pequeño.
Por otro lado, si hubieras usado una tasa media de bits, los episodios 1, 10 y 15 probablemente tendrían el mismo tamaño de archivo. El episodio 1 podría verse bien, pero el 10 podría verse terrible. El Episodio 15 podría tener el mismo aspecto que el Episodio 1, pero podría ser más grande de lo que habría sido de otro modo si hubiera usado en su lugar una Calidad Constante.
En realidad, el único beneficio tangible de la tasa media de bits es que se dirige a un tamaño de archivo específico. Si necesitas que todos tus programas tengan 350mb para que quepan 2 por CD, la única manera de hacerlo es sacando una calculadora y calculando la Tasa de bits promedio. Y como el Average Bitrate necesita 2 pasadas para funcionar mejor (ya que tiene que averiguar cómo exactamente debe empaquetar todos los bits de forma óptima en la botella de tamaño de archivo), también estás pasando más tiempo durante la codificación – si hubieras optado por la Calidad Constante (que no necesita una segunda pasada), habrías ahorrado tiempo – tiempo que podrías haber dedicado a una configuración avanzada de mayor calidad, si no fuera por otra cosa.
La Calidad Constante parece más confusa en la superficie al principio. Tienes un ajuste de RF, y si eres nuevo en esto, probablemente no tengas idea de lo que significa. Para empezar, los ajustes más bajos significan una mayor calidad. RF:16 será de mucha mejor calidad (y de mayor tamaño) que RF:24, por ejemplo.
Como guía básica, RF:20 es un punto de partida común para los codificadores de DVD y RF:22 para los codificadores de BluRay. Si eres un verdadero fanático de la calidad, el 16-18 para un DVD podría ser más ideal (o incluso números más bajos si estás decidido a hacerlo indistinguible). Por otro lado, si buscas archivos de tamaño realmente bajo y estás dispuesto a aceptar que no se verá tan bien como la fuente, el 22-25 puede funcionar para los DVD.
Después de unas cuantas codificaciones con Calidad Constante, deberías tener una buena idea de qué configuración prefieres, tanto si buscas alta calidad, como si buscas tamaños de archivo bajos.
Sin embargo, si necesitas una tasa de bits media, elige la opción de dos pasadas. El codificador realmente necesita esa primera pasada para aprender qué escenas son complejas (y necesitarán más bits), y qué escenas son simples (y necesitarán menos bits) antes de que realmente vaya y empiece a asignar cosas.
Piénsalo de esta manera. Si estás organizando una fiesta y tienes 350mb de pizza para repartir (sé que la pizza no se mide en MB – tened paciencia), es bueno saber de antemano cuánta gente va a llegar, e idealmente cuántos son niños (comedores pequeños) y cuántos son adultos (comedores grandes). 2-pass es así – hace un poco de investigación de antemano (durante la 1 ª pasada) para que pueda cortar la pizza correctamente para que todo el mundo se alimente (durante la 2 ª pasada). Sin esa investigación, podrías empezar a repartir demasiadas porciones a la gente al principio y se te acabaría cuando los adultos lleguen más tarde.
Ok, no es la mejor analogía (mejor que la de la leche que iba a usar, claro), pero te haces una idea. 2-pasos es bueno si vas a «Average Bitrate». Si codificar el tiempo es un problema, puedes usar «Turbo first pass» – hace una investigación menos exhaustiva de antemano, pero sigue siendo mucho mejor que ninguna.
Filtros de video
(Recomendado)
Deténgase: Por defecto
Desenterrar: Por defecto
Desentrelazar: Fuera de
Deniose: depende
Deblock: Apagado (normalmente)
HandBrake es hermoso en esta área.
Tanto para Detelecine como para Decombinar, en la configuración por defecto HandBrake busca contenido telecinado y entrelazado, y luego detelecina/desentrelaza según sea necesario (y sólo SI detecta estas cosas). Eso significa que puede establecer y olvidar. Si tienes un problema realmente raro con un código puedes ir y encenderlo manualmente, pero el 99% de las veces no es necesario. Configúralos como predeterminados y deja que HandBrake haga el trabajo de determinar si son necesarios.
Denoise…. La versión corta es que si tienes ruido (o grano de película) en tu FUENTE de la que quieres deshacerte, empieza con el ajuste «Débil». Esto «suavizará» un poco tu imagen, pero normalmente al menos reducirá el ruido/film. Si «Débil» no es suficiente, le sugiero encarecidamente que lea el texto y utilice los ajustes personalizados porque «medio» y «fuerte» tienden a suavizar demasiado la imagen, haciendo que la gente se parezca a los muñecos Ken y Barbie.
Vale la pena señalar que como el ruido suaviza los detalles, también reduce el tamaño del archivo (o aumenta la calidad) de la codificación. Si estás de acuerdo con los resultados del filtro «Débil», es un gran truco para reducir el tamaño del archivo de tu codificación de manera sustancial. Sin embargo, corres el riesgo de que se suavice demasiado o de que se forme una banda, así que no te pongas demasiado entusiasta.
Desbloquear…. esto se supone que elimina el «bloqueo» que existe en tu FUENTE. Realmente suaviza el video hasta el punto de que probablemente cause más daño del que arregla (no lo soporto). Si tu FUENTE tiene un bloqueo fuerte por alguna razón, puede valer la pena usarlo.
Ten en cuenta que el desbloqueador de HandBrake tiene un efecto similar al de los ajustes de ruido alto. Debido a que suaviza drásticamente, tiende a destruir el grano y otros ruidos. Eso significa que podrías usarlo efectivamente como un denotador. En algunos casos, hará un mejor trabajo de eliminación de ruido que el dispositivo de eliminación de ruido.
Foto
Asumiré que no estás tratando de cambiar el tamaño del video (si lo estás, estoy seguro de que eres capaz de averiguar cómo).
El anamórfico casi siempre se usa, ya que actúa como lo haría un DVD, y se reproduce bien tanto con reproductores de software de computadora como con varios dispositivos. La lectura del sitio HandBrake es probablemente la forma más fácil de ir aquí para obtener más detalles sobre lo que significa.
Antes se recomendaba el Anamorphic LOOSE porque hace que todo sea divisible por 16 para el codificador. Sin embargo, por lo que deduzco, el codificador ha mejorado, y Anamorphic STRICT es generalmente la forma preferida de hacerlo ahora (ya que loose puede hacer un ligero cambio de tamaño que normalmente no queremos).
Recorte – Automático está bien. HandBrake básicamente busca (y luego corta) cualquier barra negra en la fuente. Casi todos los jugadores añadirán sus propias barras negras (ya que el vídeo está configurado en anamórfico), así que codificarlas no tiene sentido.
Por supuesto, puedes configurarlas manualmente si tienes una buena razón para hacerlo.
—
Bueno, eso es todo. Todo en una (muy larga) página, así que no estás expuesto a un millón de anuncios en un artículo de varias páginas.
Debería terminar señalando que esto puede no ser 100% correcto. He reunido la información de todas las fuentes posibles, pero es probable que lea algo que no debería haber tomado al pie de la letra.
Así que tómalo con calma y haz tus propias pruebas antes de pasar una semana codificando una serie de televisión, sólo para descubrir que todo salió terriblemente mal porque cometí un error en alguna parte.
¡Buena suerte!
Pero obligué a subtítulos a Star Wars III para obtener cualquier discurso alienígena
Sin embargo, también se quemó en el nombre de Directores en la parte superior de la pantalla cada vez que alguien nuevo en el Directors Cut habló
El audio no contenía el comentario, ya que no lo quería, pero ahora tengo una copia con los nombres de Directores que aparecen cada par de minutos más o menos
¿Alguna forma de obtener los subtítulos alienígenas que quiero sin los nombres de los comentarios?
Supongo que esto sucedería con la mayoría de los DVDs que tienen una pista de comentarios
Sí, eso es un caso un poco arriesgado. Freno de mano escanea cada pista de subtítulos en busca de algo que aparece el 10% de las veces o menos. Normalmente funciona muy bien, pero como encontraste, si encontraron alguna otra razón para mostrar los subtítulos menos del 10% de las veces... no es tan bueno.
Una cosa que *debería* funcionar (aunque consume mucho tiempo) es reproducir parte del DVD a través de algo como VLC (es gratis, reproduce casi todo) y averiguar qué pista de subtítulos contiene los subtítulos forzados. Mientras el DVD se reproduce en VLC, en el menú superior, elige "Video / Pista de subtítulos" e intercámbialos, preferiblemente en el momento en que Jabba esté hablando. Creo que encontrarás dos pistas de subtítulos que se reproducen para su voz: una que sólo tiene subtítulos forzados y otra que lo tiene todo. En ese punto, puedes intentar hacer coincidir la correcta con la lista de subtítulos de Handbrake.
Haz una codificación rápida la primera vez (por si acaso no lo has hecho bien).
Si por alguna razón sigues teniendo problemas, házmelo saber: codifiqué La Guerra de las Galaxias hace mucho tiempo, pero puedo volver a desenterrar los DVD y ver si puedo reducir las cosas para ti si es necesario.
Usé HandBrake 0.9.8, y recuerdo que en HandBrake 0.9.5 tenía la opción de usar pequeño (tamaño de archivo personalizado). ¿Alguna idea mate?
gracias por su respuesta:)
alguna idea de hacer el tamaño más pequeño (la mitad de antes) pero no reducir la calidad de imagen en absoluto?
gracias por su respuesta
nota: desde su configuración anterior, el tamaño de mi archivo de serie de televisión ahora el 80% del tamaño anterior
Dicho esto, algunas cosas que podrías intentar...
-activar el filtro de ruido (débil o personalizado) en la configuración de la imagen. Esto probablemente suavizará un poco la imagen, pero debería ayudar a reducir el tamaño del archivo. Asegúrese de que se vea aceptable.
-utilizar 16 fotogramas b
-utiliza tantos marcos de referencia como puedas. Ten en cuenta que esto hará que la codificación tarde más tiempo (y si usas demasiados, puede que sólo se reproduzca en el ordenador y no en los dispositivos portátiles)
-...sube la radiofrecuencia a lo más alto que puedas soportar.
Ten en cuenta que si tus vídeos xvid ya son de tamaño pequeño (baja velocidad de bits) va a ser muy, muy difícil reducir el tamaño del archivo aún más sin perjudicar notablemente la calidad de la imagen al recodificar. Es mucho más fácil si se utiliza un xvid de mayor tamaño con una tasa de bits más alta (o idealmente, el bluray de la fuente o el DVD que tendrá una tasa de bits enorme). Cuantos más bits haya en la fuente que estés usando, ¡mejor trabajo puede hacer el freno de mano y x264!
Mucha suerte.
Si usas algo como "Playon" para transmitir tus películas a una PS3, Google TV o WII (o incluso a tu Tablet o teléfono), no suele ser una buena idea "pasar" un audio codificado en DTS, ya que tiende a causar temblores o pausas en el vídeo y otros problemas de sincronización con los dispositivos DLNA. Lo mismo ocurre con los contenedores MKV. Es mejor quedarse con el MP4. En cuanto al audio, probablemente tu mejor apuesta sería codificar en AAC o AC3, lo que me lleva a otro problema. Necesitas un mínimo de 320 a 384Kbits/s para preservar el sonido envolvente completo 5.1, así que si planeas escuchar el woosh del Halcón Milenario pasar primero de tu altavoz frontal izquierdo a tu altavoz trasero izquierdo, 160Kbits/s no lo va a cortar. Los canales tienden a fusionarse cuando no hay suficiente ancho de banda para mantenerlos separados. Dependiendo de su fuente, normalmente puede codificar AAC hasta unos 320 y AC3 hasta unos 640.
Generalmente lo que tiendo a hacer es tomar el DTS y codificarlo a AC3, luego elegir 640Kbits/s
Algo se ha implantado en x264 que se llama 'Macroblock Tree Ratecontrol' (mbtree). Esto está habilitado de forma predeterminada. Y si está habilitado, atornilla escenas oscuras. Para desactivarlo, existe la configuración no-mbtree que debe establecerse en 1:
no-mbtree=1
Simplemente agregue esto al cuadro 'cadena de opciones avanzadas'. Entonces podría verse algo como esto, por ejemplo:
weightp=1:subq=9:rc-lookahead=10:trellis=0:b-adapt=2:deblock=-1,-1:no-mbtree=1
No hay una casilla de verificación para la cosa mbtree, por lo que debe hacer esto a través de la cadena avanzada. Para mí, este escenario funcionó maravillas para escenas oscuras. Al menos para mi Madame Bovery DVD፦)
http://forum.doom9.org/showthread.php?t=159259
Alguien escribió:
«[...] He notado que con mb-tree en la codificación a la misma velocidad de bits que el no-mbtree uno tiene menor calidad en áreas granuladas oscuras, [...]»
Y otro tipo:
«[...] MB-tree básicamente rastrea los detalles a través del tiempo. Algo que «está ahí» para varios cuadros... es más importante que algo que está ahí para un solo fotograma.
Grano, por cuasi definición, es «detalle que cambia cada fotograma». Así que no es difícil imaginar lo que MB-tree «piensa» sobre el grano. Y, por supuesto, en un paisaje oscuro cada desviación no deseada es mucho más obvia [...]»
Sólo para que la gente sepa sobre mi prueba de codificación:
Llegué a la conclusión de que la codificación de 2 pases combinada con no-mbtree=1 es una idea mucho mejor para las películas en las que las escenas oscuras son un problema. Especialmente cuando tienes películas en las que las escenas oscuras son algo granulosas y borrosas. Por ejemplo, mi DVD de Madame Bovary es un material de origen bastante pobre, la película es de 1991 y se ve descolorida. Un Bluray sería mucho mejor, por supuesto. Pero sólo tengo un DVD por ahora.
¿Cómo lo abordé? Puse no-mbtree=1 en la caja de opciones avanzadas de la cadena. Luego usé una codificación de dos pases y restringí el bitrate. Porque si estableces no-mbtree=1, la tasa de bits para cada cuadro aumenta, no sólo para las escenas oscuras, sino también cuando no se necesita no-mbtree=1. Así que con una codificación de calidad constante, terminarías con un tamaño de archivo significativamente mayor. Para controlar esto, la tasa de bits tiene que ser restringida. ¿Pero qué bitrate usar? Bueno, simplemente hice algunas pruebas con codificación de calidad constante, renderizando 1 o 2 capítulos del dvd para averiguar cuál podría ser el tamaño de archivo esperado. Luego, con una calculadora de bitrate, obtuve el promedio de bitrate de video. Hay muchas calculadoras de bitrate en Internet. Yo usé esta:
http://www.dr-lex.be/info-stuff/videocalc.html
Entonces introduje la tasa de bits de vídeo para la codificación de 2 pases, establecí todos los demás ajustes en la configuración de la codificación (importante: debido a las escenas oscuras, Subpel & el modo ME debería estar configurado al menos en 9) y empecé a codificar. Y el resultado fue muy satisfactorio: un tamaño de archivo resonante y una calidad buena o al menos aceptable también en escenas oscuras difíciles.
Además, ¡muchas gracias! Sus informaciones fueron muy útiles. Antes de descubrir el artículo de tu blog, no sabía nada sobre el ajuste de la codificación de Handbrake. Después de leer tu resumen, entendí mucho más y fui capaz de buscar más por mi cuenta. Ahora soy capaz de conseguir codificaciones mucho mejores con un tamaño de archivo igual o inferior.
Ten en cuenta que si por "atascado" te refieres a tartamudeo, dependiendo del tamaño del archivo, podría ser simplemente que tu disco duro no pueda mantener la velocidad de datos que el vídeo necesita, sobre todo si otro programa está accediendo al disco duro en segundo plano. Esto también se aplica si el archivo está muy fragmentado, aunque generalmente esto sólo se convierte en un problema en OSX si el disco duro comienza a llenarse mucho. Por supuesto, si usas un disco duro USB2 externo, siempre existe la posibilidad de que las velocidades del USB2 no sean suficientes para mantener la velocidad.
Si terminas sospechando que se trata de un problema de velocidad de datos, puedes intentar aumentar el valor de RF (disminuyendo la calidad, pero también disminuyendo la velocidad de datos y el tamaño del archivo en el proceso). Si estás usando una radiofrecuencia de, por ejemplo... 18, intenta aumentarlo hasta digamos... 25 para una prueba. Si funciona bien en RF25, puedes empezar a ajustar desde allí hasta que encuentres un buen equilibrio entre no tartamudear y verse bien.
Otra posibilidad que probablemente debería mencionar (aunque es algo improbable)... He oído que añadir metadatos (MetaX, por ejemplo) a veces puede hacer que los vídeos se comporten mal en algunos reproductores. Así que podrías intentar reproducir el archivo en iTunes justo después de la codificación, no lo pases por MetaX. Si funciona, puedes intentar algo como iDentify en lugar de MetaX - contiene una opción en las preferencias para "Optimizar archivos después de etiquetarlos" que reescribirá el archivo para ayudar a evitar que el borde del caso particular con la etiqueta.
¡Buena suerte!
También creo que es un problema de disco duro. pero funciona bien con VLC. He comparado mi video con el video de la tienda itunes. mi video tiene una tasa de bits total de 3574 kbps, video de la tienda tienen 412 kbps. por lo que podría b el problema. Entonces, ¿cómo puedo establecer el modo de velocidad de bits en constante no variable y cómo establecer la tasa de bits total en HandBrake? ¿Hay alguna diferencia entre el modo de birate y el modo de velocidad de fotogramas? uno más, ¿alguna diferencia entre 'bitrate' y 'bitrate total'?
Lo siento por mi mal inglés
GRACIAS de antemano
"Total bitrate" es específico, y generalmente se referiría a la tasa de bits promedio en todo el video (3574 en su caso). La "tasa de bits" por sí misma no es tan específica, y su significado dependerá del contexto.
La tasa de bits y la tasa de fotogramas son cosas completamente diferentes que no están directamente relacionadas entre sí. Sospecho que puede estar mirando "RF" y quizás leyéndolo incorrectamente como "tasa de fotogramas". RF en realidad significa "factor de velocidad", y el higher lo fijas en el bajo que será la tasa de bits.
Preguntaste cómo establecer el modo de bitrate a constante en tu codificación, pero para ser honesto probablemente no quieras eso. Resulta en archivos enormes que tienden a verse muy pobres cuando llegas a escenas complejas de alto movimiento. Esencialmente, desperdicia bits en escenas en las que no necesita muchos y no tiene suficientes bits cuando llegas a escenas que necesitan mucho. También es mucho más difícil de hacer/usar en Handbrake - creo que hay formas de imitarlo a través de algunas Advanced Option Strings (estableciendo una tasa variable mín/máx), pero no hay nada en el GUI. Tu mejor apuesta es probablemente elegir una tasa de bits media más baja (esta será tu nueva "tasa de bits total"), o si has estado usando Calidad Constante sube el valor de RF a un número más alto.
Intenté esto
Codificación de entropía CABAC, Transformación 8×8, Marcos P ponderados, Pirámide B Frames, CABAC => Todo apagado
Marcos de referencia, Máximo de fotogramas B =>2
Modo directo adaptable: automático
Estimación de movimiento = Multihexágono desigual
Subpixel ME y decisión de modo = 10
Calidad => Avg bitrat, 4122 kbps
velocidad de fotogramas: constante, 29,97
Ahora itunes lo reproduce muy bien y el tamaño del archivo está bien para mí (la película de 105 minutos es 3.57GB), de todos modos, no sé mucho sobre lo que hace esa configuración..
y de nuevo gracias a u, el maestro de HandBrake
Si mi archivo fuente es un archivo AVC TS (Level Main 3.1) con 2 marcos de referencia, ¿hay algún beneficio de empujarlo más allá de 2 en HandBrake? Gracias.
Me encontré con un problema si puedes ayudarme, por favor. Estoy haciendo una copia de seguridad de mi Bluray, el video es VC1 Advanced @L3, cuando codifico usando estas configuraciones termino con un alto @L3 .1 (también redimensiono a 720p). ¿Hay alguna manera de codificar esto y dar como resultado High @L4 .1?
Gracias por todo su conocimiento y gran sitio:)
Recientemente he empezado a capturar y codificar contenido deportivo 1080i (NRL en Australia) para fines de archivo y me gustaría obtener la mejor calidad posible! Sin tener enormes tamaños de archivo obviamente.
Ahora estoy usando su configuración como plantilla:)
¿Sugiere algún ajuste adicional que sea más efectivo específicamente con los deportes?
Después de leer, supongo que debería establecer el rango de estimación de movimiento en al menos 64.
¿Desbloqueo a -1, -1?
rc-lookahead a al menos 60.
Cualquier sugerencia sería genial y gracias por esta increíble guía!
Me inclinaría a verificar dos veces y asegurarme de que decomb y detelecine estén configurados como predeterminados; podría intentar experimentar con un par de ejecuciones de prueba para ver si obtiene mucha diferencia entre eso y configurar manualmente el desentrelazado, tenga cuidado.
Si va a archivar, es posible que desee utilizar una configuración de RF más baja de la que normalmente lo haría (mayor calidad). Tendrás tamaños de archivo más grandes, pero debido a que las emisiones deportivas son algo que no puedes ir a la tienda exactamente 10 años después y comprar un DVD/BluRay de... realmente quieres asegurarte de que la calidad se mantendrá con el tiempo. Solo tienes 1 oportunidad con ese tipo de contenido (una vez que hayas eliminado la fuente, tendrás dificultades para encontrarla de nuevo), así que asegúrate de estar contento con él.
Sí, originalmente estaba usando el Deinterlace hasta que leí esto. Entonces lo comprobé con Decomb y estaba bien; se veía igual y el registro mostraba que desentrelazaba todos los cuadros excepto el 1.
Podría intentar probar los tiempos de codificación para ver si el Deinterlace es más rápido (tal vez porque no tiene que comprobar cada fotograma) ya que sé que el vídeo de origen está entrelazado de todos modos.
Ese es un gran consejo en cuanto a los ajustes de calidad, me has convencido de bajar a RF 19 o incluso 18. Originalmente estaba haciendo RF 20 y obteniendo tamaños de archivo de alrededor de 6,5g pero estoy feliz de usar un poco más de espacio con eso en mente. Es imposible conseguir juegos antiguos aquí, a menos que sea una final, e incluso entonces tendrías suerte de conseguirlo si tuviera 10 años.
Anoche pasé un rato probando diferentes configuraciones en mi archivo de muestra. Grabé todos los detalles como los tiempos de codificación y los tamaños de los archivos.
Mi suposición original era que como estoy usando CRF la calidad del video sería la misma, pero el tamaño del archivo cambiaría con cada ajuste.
Este era el caso en general, pero había una anomalía, que era la Espaldera Psicovisual; cuando la aumenté a 0.15 (desde el valor predeterminado de 0), en realidad aumentó el tamaño del archivo en un 4%. ¿Esto aumenta la calidad del video, aunque esté usando CRF?
Además, cuando cambié el Deblock(-1 -1) y el Motion Estimation Range (16, 24, 32 y 64) el tamaño del archivo se mantuvo igual en todas las instancias, por lo que supongo que no está recogiendo ningún otro movimiento(MER) o artefactos(Deblock).
Soy realmente nuevo en todo esto, así que todas las suposiciones anteriores podrían ser totalmente incorrectas. Enviaré mis resultados en un nuevo mensaje y puedes ponerlo si crees que alguien puede encontrarlo útil.
Sólo probé los Cuadros de Referencia; Cuadros B; Rango de Estimación de Movimiento; Subpixel ME & Decisión de Modo/Trellis (combinado); Espaldera Psicovisual; y Deblock.
En primer lugar, Deblock no alteró el tamaño del archivo ni aumentó los tiempos de codificación.
Marcos de referencia:
4 - (valor base)
9 - 40% Aumento del tiempo de codificación; 0,35% Reducción del tamaño del archivo
Marcos B:
4 - (valor base)
16 - 32,5% Aumento del tiempo de codificación; 1,27% Reducción del tamaño del archivo
El rango de estimación de movimiento NO alteró el tamaño del archivo, pero sí aumentó los tiempos de codificación:
MER 24 - (valor base)
MER 16 - 3% Disminución del tiempo de codificación
MER 32 - 6,5% Aumento del tiempo
MER 64 - 23,5% Aumento del tiempo
Subpixel ME y Mode Decision/Trellis (combinados) tuvieron el mayor impacto beneficioso en el tamaño del archivo:
9 & Codificar sólo - (base)
10 & Siempre - 26.5% Incremento en el tiempo; 5.96% Disminución del tamaño del archivo
Espaldera psicológica (Aumento del tamaño del archivo en lugar de reducción):
0 - (valor base)
0.15 - 6.5% Incremento en el tiempo de codificación ; 3.97% Incremento en el tamaño del archivo
Obviamente esto es sólo una prueba menor, y cada uno podría llegar a diferentes resultados dependiendo de su video fuente.
Sólo para que quede claro, mientras que el CRF se mantiene para mantener la calidad, no es siempre el caso. En particular, cosas como el enrejado psicológico (cosas que se mueven alrededor de los bits para tratar de aumentar la calidad percibida) pueden tirar una llave inglesa en las cosas, como habéis notado. Visualmente también hay una diferencia entre la codificación con 0 y la de 0.15, aunque probablemente sea leve, ya que se utiliza un valor de CRF bajo (tal vez ni siquiera lo suficiente como para notarlo visualmente). Haciendo las cosas más emocionantes, una no será necesariamente "mejor" que la otra tampoco - si a la gente le gusta el resultado de las mejoras de la calidad percibida a menudo se reduce a la preferencia personal. Por cierto, si tratas de comparar x264 contra otros codificadores y comparar el SNR entre ellos, por lo que recuerdo PSY Trellis es una de las cosas que se supone/permite usar.
Los cambios en los fotogramas de referencia, estimación de movimiento, etc. deberían mantener la misma calidad visual.
Probablemente debería haber mencionado en el escrito... el Deblock en la configuración avanzada (listado como 0,0 etc) de lo que recuerdo en realidad almacena la información que se envía al decoder cuando estás reproduciendo el archivo, por lo que no tiene (o no debería de todos modos) un efecto en el tamaño del archivo - sólo le dice al decodificador cuánto debe desbloquear el vídeo final. Supongo que podría haberte ahorrado un poco de tiempo si hubiera sido más específico al respecto en la redacción (¡lo siento!). Sin embargo, el desbloqueo en "ajustes de vídeo" tendrá un impacto sustancial en el tamaño del archivo si se utiliza, ya que desbloquea la fuente antes de la codificación (aunque se ve terrible la mayoría de las veces imo - ¡no lo uses!).
Dulce, así que PSY Trellis está aumentando la calidad percibida, eché un vistazo rápido y no pude notar ninguna diferencia, pero comprobaré la televisión en lugar de la pantalla.
Todo bien con el Deblock, ahora puedo hacer algunas pruebas con el archivo de mi reproductor de medios y ver si noto alguna diferencia, así que gracias por esa información también, y por confirmar en los otros ajustes.
Es interesante saber que cambiar los marcos de referencia fue en realidad la peor relación costo/beneficio de esos ajustes, considerando que es la más conocida. Tal vez este es sólo el caso de los deportes.
También debo mencionar que estoy codificando a 720p, pero probablemente lo hayas descubierto porque usé 9 fotogramas de referencia para la prueba. Si hago 1080p a CRF 20 me da un archivo de 12 gigas :0
Estoy archivando cada partido de la temporada para el equipo que sigo, así que no puedo permitirme usar tanto espacio; el tiempo de codificación también se duplica.
Por lo que puedo reunir un archivo de 6-8g se ve mejor en 720p, incluso en mis 52". Un archivo de ese tamaño en 1080p sólo sería alrededor de CRF 24-25 (no estoy seguro porque usé dos pasadas al comparar las resoluciones) así que parece lógico, supongo.
Una vez más, gracias por tu ayuda, seguiré jugando con los ajustes. Espero que finalmente pueda tomar una decisión para poder deshacerme de estos archivos de captura originales de 20g de la temporada pasada :)
Sólo quería darte un gran agradecimiento por armar esta guía HandBrake - es el más claro, más completo de su tipo que he encontrado en línea, y ha sido increíblemente útil en la tarea de convertir mi colección de películas a archivos!
En primer lugar. ¡Gran guía de Handbreak!
Tengo una pregunta sobre los submarinos.
Utilizo los «ajustes básicos» para una rip mp4 de alto perfil con recorte anamórfico y automático estricto. Cuando veo la película con los submarinos encendida en VLC, los subs se mueven hacia arriba en la película. Alrededor de la misma distancia que cuando no se recorta.
¿Puedo hacer algo para colocar los subtítulos en la posición correcta para que no cubran la película?
(Soy de Suecia así que por favor no juzgue mi inglés:D)
Dicho esto, es posible añadir un "relleno" negro en la parte inferior del vídeo durante la reproducción. Tendrías que navegar por los ajustes avanzados de VLC, pero si añades suficiente relleno, los subtítulos deberían llegar hasta allí. (Edit: Supongo que si tu fuente ya tiene barras negras, otra opción sería deshabilitar el recorte en la configuración de imagen de Handbrake, aunque ten en cuenta que codificar las barras negras a menudo no es lo ideal debido al "window boxing" que obtendrás en algunas pantallas).
La otra opción es usar otro reproductor de video - VLC no es conocido por ser muy flexible en cuanto a los subtítulos, pero algunos otros reproductores de medios sí lo son.
¡Gracias!
b-adapt=2:rc-lookahead=120:direct=auto:trellis=2:ref=4:bframes=16:me=umh:subq=10:merange=64:analyse=all:psy-rd=1.0,0.15:deblock=-1,-1:nr=200Nota:
- ref=4 es para un BluRay de 1080p para que se reproduzca en mi AppleTV, iPad3, etc. Lo he subido a ref=12 para DVD's (480p) pero de vez en cuando tengo unos cuantos bloques de macros confusos en el AppleTV y Quicktime/iTunes, así que lo bajo a 9 si no creo que lo vea enseguida para asegurarme de que ha sobrevivido.
- nr=200 que uso comúnmente porque no puedo notar la diferencia en la calidad visual. Si intento reducir el tamaño de los archivos aún más (series de TV o películas que no me importan tanto), subiré esto a 400. Si la fuente es realmente ruidosa, usaré 800 sin dudarlo mucho.
- Cuando me sienta impaciente, reduciré la estimación del movimiento y el subpíxel a sus valores por defecto (Hexágono, y 7) para acelerar la codificación.
- Tiendo a hacer uso de la configuración de Denoise en las "Opciones de Imagen" porque los píxeles de baile me vuelven loco, por lo que limpia eso mientras baja el tamaño del archivo. 0:0:3:2, 0:0:2:1, y 0:0:4:1 son algunos de los ajustes que uso con frecuencia en casi cualquier fuente (sólo la eliminación de ruido temporal - no usaré la espacial a menos que sea una fuente ruidosa). Es muy raro que no use nada aquí.
Ten en cuenta que, especialmente cuando se trata de cosas como el entorno del psiquiátrico, se convierte tanto en un arte como en una ciencia, tus preferencias personales van a empezar a entrar en juego.Perfil personalizado
b-adapt=2:rc-lookahead=50:bframes=16:ref=4:direct=auto:me=umh:subq=10:merange=24:analyse=all:trellis=2:deblock=-1,-1
El perfil alto no debería golpearlo así suponiendo que esté usando el mismo valor de RF para ambos: vea si agregó una segunda pista de audio cuando la seleccionó (después de seleccionar un ajuste preestablecido, a menudo es una buena idea mirar a través de las opciones y asegurarse de que no se hayan agregado pistas de audio y que la resolución no haya cambiado).
¿Suena correcto que tardaría 2 a 2,5 veces más en codificar usando la configuración personalizada frente a Normal o Alto perfil?
2,5 horas es algo largo para un episodio de 30 minutos (voy a aventurar una suposición de que no estás en una Ivy/Sandy-bridge i5/i7). Si vas a dejar caer algo para reducir el tiempo, probablemente empezaría con los fotogramas B y el subpíxel ME / Decisión de modo (déjalo caer a 7, similar a la opción por defecto de alto perfil). Eso debería acercarte a los tiempos de codificación que estabas viendo con High Profile.
Ten en cuenta que si usas "Calidad constante" (RF), dejar de hacer esas cosas probablemente no afectará a la calidad. Sólo verás archivos de mayor tamaño - ya que de todos modos estás dentro del área de 315-341MB (no es una gran diferencia), el tiempo puede ser más importante para ti que los ~25-30mb.
Tengo una pregunta sobre tu cadena de opciones avanzadas de "punto de partida". ¿No son la mayoría de esos ajustes los mismos que se establecen a través de menús desplegables y deslizadores en el panel Avanzado de Freno de mano? Por ejemplo, ¿no es "ref=" lo mismo que el menú desplegable "marcos de referencia"? ¿No es "deblock=" lo mismo que los dos desplegables de "Deblocking"? Por lo que puedo decir, las únicas opciones únicas en su cadena son rc-lookahead y nr.
Si son iguales, ¿por qué es necesario repetir estos parámetros en la cadena? Y si estableces diferentes parámetros para la misma opción en el panel frente a la cadena (por ejemplo, estableciendo el desplegable de marcos de referencia en 6 pero escribiendo "ref=4" en la cadena), ¿qué tiene prioridad?
Por último: ¿alguna vez usas vbv-bufsize o vbv-maxrate? Me di cuenta de que aparecen automáticamente en la cadena para la configuración de Alto Perfil, pero todo lo que he leído en línea indica que ambos reducen la calidad de la imagen. ¿Alguna idea?
Gracias, gracias. Muchas gracias!
De hecho, esa cadena de opciones se deriva de los desplegables del panel avanzado. Rellenar el panel avanzado es lo que realmente propaga esa cadena (he añadido manualmente el "nr" como has notado).
Lo había pegado porque Zac había pedido específicamente el código en la parte inferior de la pestaña avanzada - es posible que buscara una línea corta que resumiera todo lo que yo usaba y que él pudiera convertir manualmente en desplegables.
A tu pregunta sobre la repetición de esos parámetros desplegables en la cadena, Handbrake lo hace automáticamente. No deberías repetirlos manualmente ni nada: sólo confía en los desplegables donde puedas (la mayoría de los ajustes), y añade manualmente todo lo que no haya desplegables para lo que quieras usar (nr, etc).
En cuanto a vbv-bufsize y vbv-maxrate, no los asigno manualmente - se rellenan automáticamente según el perfil y el nivel. Si los omites (quizás además de omitir "level=x.x"), tu video podría causar que ciertos dispositivos se ahoguen. Por ejemplo, un iPhone 4 sólo está clasificado para soportar el nivel principal 3.0. Eso dará opciones avanzadas que incluyen "level=3.0:vbv-bufsize=10000:vbv-maxrate=10000". Si eliminas esos valores (o los incrementas), el video podría ahogarse al reproducirse en el iPhone 4.
En lo que respecta a la calidad, lo que vbv-bufsize y vbv-maxrate actualmente do es "tapar" el tamaño del búfer y la tasa de bits instantánea. Así que en una situación en la que el codificador realmente quiere superar ese tope (pero no puede), sí, generalmente perderás calidad. Pero en situaciones en las que el codificador no iba a llegar a ese tope de todas formas, tendrá un impacto nulo en la calidad.
Puedes ver un ejemplo extremo de esto codificando un clip corto (digamos 10 segundos) de un video en el Nivel Principal 1.0 . Restringirá tanto la tasa de bits (vbv-bufsize=175:vbv-maxrate=64) que el video se verá horrible o no tendrá suficiente tasa de bits para funcionar. Los niveles más altos elevan el límite, pero un nivel demasiado alto (o no usar ningún nivel) puede hacer que la complejidad del video sea lo suficientemente alta como para no reproducirse en algunos dispositivos.
Espero que eso ayude!
¡¡Muchas gracias!!
Me preguntaba que pasaría con las opciones del codificador del panel de video una vez que la casilla de opciones avanzadas esté marcada. Mencionaste que "afinar" básicamente coincide con los deslizadores avanzados. Así que añadir cadenas para el nivel y los vbv es la única manera de anular los valores por defecto que aparecen en gris ("x264 Unparse"), ¿correcto? Lo mismo se aplica para "Preset" y "Perfil" - ¿necesitas cadenas?
Además, no tengo una opción para "Rango de Estimación de Movimiento" en mi panel avanzado (Freno de mano 0.10.0). No puedo encontrar nada en línea sobre por qué falta. ¿Esta opción fue descontinuada con la v.10? Supongo que podría añadirlo como una cadena como se muestra en su ejemplo.
Gracias de nuevo por su detallada ayuda, ¡se lo agradezco mucho! He usado Handbrake en el pasado y he quedado satisfecho con él, pero ahora estoy intentando entender las opciones para conseguir resultados de mejor calidad. Sus mensajes han ayudado mucho!
Ten en cuenta que ciertos perfiles también restringen algunas cosas como los marcos de referencia, b-frames, etc. Por lo tanto, combinar los perfiles con los ajustes avanzados puede resultar un poco peligroso... por ejemplo, si estableces un perfil que solo admite 3 fotogramas de referencia pero seleccionas manualmente 16 fotogramas de referencia en las opciones avanzadas, no sé qué tiene prioridad. Es una de las razones (de las cuales hay algunas) por las que he cambiado a usar los preajustes x264 y sólo profundizo en las opciones avanzadas hoy en día cuando busco hacer algo bastante específico. La guía que estás leyendo aquí fue hecha antes de que existieran los presets del x264, y también antes de que empezara a preocuparme por la reproducción en dispositivos que no fueran PC. Algunas de las cosas que he enumerado aquí pueden ser ciertamente útiles cuando se reproduce/aprende/entiende, pero cuando se trata de sacar códigos (particularmente para la reproducción en dispositivos) los preajustes hacen la vida mucho más fácil.
El "Rango de Estimación de Movimiento" (de nuevo, 1.0.7) sólo aparece en los Métodos de Estimación de Movimiento más altos (UMH, Exhaustivo, Transformado).
Gracias de nuevo por ayudarme. Ahora he realizado muchas conversiones de prueba usando tanto su configuración avanzada como los preajustes, sólo para comparar el tamaño del archivo, la reproducción, la calidad, etc. He encontrado que el CQ18 resulta en un archivo más o menos del mismo tamaño que el original, mientras que el CQ22 es más o menos la mitad del tamaño. La cantidad de fotogramas de referencia es el principal factor en el tiempo de procesamiento. El preajuste más lento fue el más cercano en tiempo a su configuración avanzada, mientras que el muy lento tardó unos 20 minutos más (probablemente los 16 fotogramas de referencia).
Tuve una observación extraña para compartir con ustedes. He estado usando cuadros de referencia en el vecindario 6-8 (conversiones SD de DVD). Estoy principalmente en un Mac, que reproduce las exportaciones de HandBrake sin problemas. Sin embargo, en mi ordenador Windows (Windows 7 ultimate), ni Windows Media Player ni RealPlayer pueden manejar los MP4 de HandBrake con más de 6 marcos de referencia. La imagen está bloqueada, horriblemente pixelada, se rompe....unwatchable. He confirmado que definitivamente es el ajuste del marco de referencia.
Probablemente podría descargar un paquete de códecs que lo arreglara pero me interesaba que un sistema operativo bastante reciente en un ordenador decente se atragantara con los marcos de referencia. Tenía entendido que esto era más un problema con los dispositivos más antiguos y que los ordenadores estaban más avanzados en su soporte de perfiles y niveles. ¿Alguna vez se ha encontrado con un problema como este? Es suficiente para convencerme de que me quede con 6 como valor de mis marcos de referencia. :-)
Gracias de nuevo - sus posts de HandBrake fueron absolutamente invaluables mientras aprendía este programa!
Jen
Esto podría importar si el perfil es más alto de lo que el decodificador de la CPU/GPU permite, pero el reproductor de vídeo está tratando de bombear los vídeos a través de ellos de todos modos en lugar de volver al software.
Potencialmente podrías probar esto creando 2 videos de baja resolución (déjalos caer para decir... alrededor de 430x240), usa Main/3.0, y confía en los preajustes de velocidad. En el video #1 usa una velocidad que empujará cuadros de referencia >= 7 (probablemente lento, muy lento, o placebo pero mira la línea ref=x para verificar). En el video #2 usa una velocidad más rápida que mantenga los cuadros de referencia < =6 O mantén el preajuste de velocidad igual y escribe manualmente algo como "ref=5" en el cuadro de "Opciones adicionales" (presiona Enter después o cambia otra opción para asegurarte de que se recoja en el no-parado).
En cuanto a los problemas que son muy similares, los Apple TV 2 & 3 (no saben de un TV 4) tienen un error que les impide reproducir vídeos con 16 fotogramas de referencia. O al menos los míos lo hacen. 15 marcos de referencia funcionan bien. La mejor suposición es que alguien en Apple se equivocó en una situación de 1-16 -> 0-15 -> 1-15 que a veces ocurre cuando se codifican bucles, pero sólo puedo especular aquí.
¿Algún consejo para que mis archivos codificados tengan el mismo aspecto que los de mi reproductor de DVD?
vbv-maxrate=25000:vbv-bufsize=31250
-Neil
No importa la configuración, sigo experimentando un sutil problema con los juicios durante el movimiento que se mueve a través de la pantalla. Siempre es peor con las codificaciones de DVD que con las de BluRay. Tengo un doble núcleo de 3GHz con 6GB de RAM junto con una GeForce 210 510mb de NVIDIA ejecutando HDMI a un receptor Denon y luego a un LCD LED de 55". He tratado de aumentar la prioridad de VLC a alta en la tarea Mgr. También he tratado de puentear el receptor. Estos mismos códigos funcionan perfectamente en mi portátil más lento al copiar el archivo en la unidad local.
Algunos han mencionado que el AC3 Passthru Audio podría ser el problema. Lo he considerado y he intentado diferentes formatos de audio, pero no parece que haya ninguna diferencia. La ventaja del AC3 Passthru, como está escrito en la guía del freno de mano, es que no se pierde el canal del subwoofer como en otros formatos. Sin pass-through terminas con algo como el sonido Dolby 5.0.
También he intentado copiar el archivo en el disco duro del sistema operativo local (más de la unidad de datos "verde", también interna) y lo he probado allí donde es un SSD. Así que la IO no es un problema que se vea.
Ya he actualizado la tarjeta de vídeo una vez y lo haría de nuevo si supiera que ayudaría. O puedo considerar construir una máquina más robusta con un núcleo cuádruple de 64. El actual procesador de doble núcleo es un Intel y el sistema operativo funciona a 64 bits. VLC es una versión de 64 bits. Parece que la reproducción de Windows Media Player puede ser ligeramente superior, pero no reproduce el audio del AC3 Passthru. Cuando se prueba una película codificada en Windows Media Center que tiene AAC por ejemplo, todavía hay algo de juerga, aunque ligeramente reducida.
Cualquier sugerencia que alguien pueda ofrecer será muy apreciada. He pasado incontables horas investigando y tratando de llegar al fondo del asunto. Gracias de nuevo por un gran video.
Si ese es el caso (sólo estás tratando con una película de 2.35:1), la respuesta a tu pregunta sobre una solución simple es esencialmente "no", pero si tuvieras la intención de hacerlo de todos modos, básicamente tendrías 3 opciones. Podrías:
- Cortar un poco del lado izquierdo/derecho del video (está en la configuración de la imagen) lo que equivale a cortar parte de la imagen. Para hacer que esta película llene completamente la pantalla de tu iPad2 necesitarías recortar aproximadamente 126 píxeles de la izquierda y 126 píxeles de la derecha (si el freno de mano ya ha sido recortado desde arriba/abajo, deja esos valores).
- Elige la relación de aspecto en Handbrake (de nuevo, ajustes de la imagen) e intenta que sea algo que se asemeje a 1.33:1 (la relación de aspecto total de tu iPad). Esto hará que todo se estire verticalmente. Tendrías que experimentar aquí - sólo ajustarlo a Anamorphic None podría ser suficiente, aunque si el iPad todavía lo pone en un buzón, podrías tener que desactivar también "Keep Aspect Ratio" y ajustarlo a 468x352. Alternativamente, podrías intentar "Custom Aspect Ratio" y jugar con el ancho y alto del PAR.
- Mezclar una relación de aspecto personalizada con el recorte. No recortar tanto, y no ajustar la relación de aspecto tanto. La noción aquí es que las cosas podrían verse un poco menos mal que si fueras a toda velocidad en una de esas direcciones.
El recorte es la opción menos terrible en mi opinión, pero aún así no es genial - tienes que recortar un *mucho* de la imagen para conseguir desde 2.35:1 hasta 1.33:1 (la relación de aspecto de tu iPad). Como referencia tu MBP si es reciente es probablemente 1.6:1 .Para ser honesto, si puedes lidiar con ello, lo dejaría estar. Más allá de la enorme cantidad de trabajo/tiempo que toma (y el hecho de que para cuando termines probablemente se verá mal en todo excepto un iPad2), cortar o estirar partes de la imagen nunca me ha sentado bien para empezar.
Edit: acaba de estropear un video de 2:35:1 en mi iPad3 y se ha dado cuenta de que hay un botón que se asemeja a una función de "zoom" situado al lado del deslizador de tiempo. Es probablemente lo más fácil de usar, el resultado final es similar al recorte, pero es más rápido y no es necesario cortar el vídeo en sí.
Confiando en su excelente guía, sentí por un tiempo que me estaba volviendo muy hábil para alcanzar mis objetivos de tamaño y calidad de archivo, al arrancar mis rayos azules. Estaba feliz de envejecer, las películas más granulosas bajaban alrededor de 7 a 10 GB, y las nuevas películas alrededor de 4 a 6 GB. Eso fue hasta que adquirí un .mp4 de una película reciente, hecha por el tipo del torrente / grupo YIFY. Realmente me voló la peluca - 1h58 de tiempo de ejecución, 1.72 GB de video streaming, a 1080p sin prácticamente ninguna pérdida de calidad. La imagen puede ser un poco más suave que la fuente original (pura especulación, no he visto el original) y el audio definitivamente no está a la altura de mis estándares (142 Kbps máx. AAC estéreo). Puede que se haya perdido algo de precisión de color. Pero tío... sigue siendo MUY mejor de lo que he podido conseguir con Handbrake.
Hay algunas cosas en línea sobre la técnica YIFY, pero nada terriblemente detallado o convincente.
¿Restringirlo a un núcleo mejora la calidad? ¿En serio? Soy escéptico...
De todos modos - ¿Alguna opinión sobre cómo YIFY hace lo suyo?
Saludos
cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0. 00 / mixed_ref=1 / me_range=16 / chroma_me=1 / espaldera=1 / 8x8dct=1 / cqm=0 / zona muerta=21, 11 / fast_pskip=1 / chroma_qp_offset=- 2 / hilos=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1862 / ratetol=1. 0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Tengan en cuenta que este fue sólo un código que encontré (del 2012 sin embargo), y son sólo las configuraciones que alguien publicó en TPB (probablemente sacado a través de MediaInfo u otro programa similar). Es muy posible que sus codificaciones varíen, normalmente los grupos de lanzamiento tienen múltiples colaboradores y los envíos se basan en unas pautas mínimas y "reglas de la escena".
En cuanto al bit de un solo núcleo, yo también sería muy escéptico. Tendrías que preguntar en los foros de doom9.org para estar seguro, pero hasta donde yo sé, el impacto de calidad de los múltiples hilos es extremadamente marginal a menos que tengas un * montón* de hilos siendo utilizados (lo cual sólo ocurre por defecto si tienes muchos núcleos). Según el wiki x264, por encima de 16 hilos, que por lo que entiendo no sucedería a menos que tuvieras más de un sistema de 11 núcleos. E incluso entonces dudo que el efecto sea notable. En realidad, en el código YIFY que saqué, de los ajustes publicados parecía que corrían 3 hilos, así que presumiblemente estaban usando una máquina de doble núcleo.
Por lo que recuerdo, los códigos YIFY (así como la mayoría de los grupos) tienden a ser un poco más suaves, probablemente como resultado de la caída de detalles de x264 al llegar a tasas de bits bajas, pero siempre es posible que preprocesen sus cosas, pasándolas por un desacoplador o algo así de antemano para ayudar a que las cosas se vean bien a una tasa de bits baja. Puedes intentar codificar tu fuente a una tasa de bits similar a la que encontraste y ver cómo se ve, si no se ve similar, empieza a ajustar algunas opciones. Si acabas usando ajustes idénticos a los que ellos han usado y ves resultados diferentes, es probable que estén haciendo algún preprocesamiento (o falsificando los valores del codificador almacenados en los metadatos por lo que deduzco que normalmente está mal visto en la comunidad).
1. Mi teoría se basa en obtener el máximo de todo, y por lo tanto de las enzimas, 2kb menos es 2kb menos.
2. eyeffa actualizó el código postal de clear the confucius, ahora anna mate it clear dat 4 single thread encodes más rápido que un solo código de 4 hilos, así que ¿tu bajo cumme sum slackware?
3. (cansado de hablar en jerga, así que) aparentemente el grupo YIFY utiliza un entorno unificado que se actualiza de forma centralizada, pero lo que me molesta es que a veces parece que hacen codificaciones basadas en RF mientras que otras veces hacen codificaciones basadas en bitrate (como su codificación 720p de TPBAFK es 699mb), y las codificaciones basadas en bitrate me cabrean.
4. Como no estoy afiliado ni respaldado por YIFY, asumo que utilizan la magia para hacer videos con una tasa de bits amigable para poder ofrecer videos de baja tasa de bits sin perder la compatibilidad con ciertos dispositivos.
5. Obviamente no tengo una idea real de cómo funciona x264, aparte de que "convierte mi dvd en un pequeño archivo de 300mb", pero me imagino que hay una configuración que pone una CPU multinúcleo al 100% de carga completa, lo que resulta en una reducción de la calidad.
6. no relacionado pero 1080p de Youtube ¡Chupa! No sé tú pero yo creo que el tipo con el PC de alto rendimiento debe ser capaz de obtener una mejor calidad que el tipo con la tableta, odio las codificaciones CUDA maldita sea!
1) Una ejecución de un solo hilo podría muy bien reducir unos pocos KB (o añadir unos pocos KB de calidad) - la única forma de saberlo con seguridad sería hacer la pregunta en uno de los x264 devs o hacer algunas pruebas de SSIM/PSNR en hilos=1 y compararlo con el valor por defecto en un sistema de varios núcleos. Personalmente soy escéptico porque si hubiera algo realmente tangible que se pudiera tener limitando los hilos, habría esperado que lo lanzaran en el preset --placebo. Pero de cualquier manera, usar un hilo/núcleo no puede dañar la calidad.
2) Buen punto. En realidad, si se hace esto con una codificación por lotes y múltiples instancias, me inclinaría mucho por probar threads=1 aquí simplemente porque ya no debería haber ninguna desventaja (e incluso si sólo terminas guardando un par de KB, no perdiste nada para conseguirlo).
3) El adjunto a las codificaciones basadas en la tasa de bits para golpear ciertos tamaños de archivos es comprensible. Durante mucho tiempo, XviD a 350/700MB fue estándar (con la película grande dividida en múltiples archivos de 700mb) y mucha gente construyó su almacenamiento y configuraciones alrededor de eso. Cuando los grupos de lanzamiento empezaron a hacer la transición de XviD -> x264 no fue bien recibida por todos y espero que los otros restos como los tamaños de archivo de destino estén todavía por un tiempo. Los grupos de lanzamiento pueden hacer la transición rápidamente, pero su... uhh.... "Clientes" .... no siempre están listos para la última tecnología.
4) No sé si me atrevería a decir "magia"...) . Mirando tu escrito parece que el desbloqueo está fijado en 6,6, lo que en realidad es bastante suave. Puedes conseguir una tasa de bits mucho más baja usando algo así en lugar de decir -1,-1 porque cualquier artefacto y/o macrobloqueo será suavizado.
5) No lo he comprobado, pero no me sorprendería que algunos de los presets más rápidos lo hicieran. Por otra parte, según mi experiencia, el uso de otro codificador H264 (no x264) tiende a condicionar el uso de la CPU y termina con peor calidad que x264 la mayoría de las veces, así que técnicamente eso podría contar ;)
6) Estoy de acuerdo - las codificaciones de YouTube son de muy mala calidad en general. Dicho esto, según sus estadísticas tienen 72 horas de vídeo subido por minuto. Lo que es más de una hora por segundo. Y seamos sinceros, se necesita un hardware bastante robusto para transcodificar más de una hora de vídeo por segundo incluso a baja resolución. Para 1080p, también están transcodificando a numerosas resoluciones más bajas al mismo tiempo. Sus opciones van a ser o bien tener tamaños de archivo enormes (que la mayoría de las conexiones de "alta velocidad" no manejan en tiempo real), o bien bajar la calidad para mantener el ancho de banda razonable. Tratar de reducir drásticamente el tamaño mientras se mantiene la calidad sólo requiere demasiada potencia de computación. Dudo que los teléfonos/tabletas sean el problema aquí - la mayoría de las cosas actuales tienen hardware H264 decodificado incorporado que podrían (y probablemente lo hacen) hacer uso de lo que fácilmente supera la potencia de decodificación de un montón de PCs de 2-3 años de edad. El único problema que se encuentra con los actuales smartphones/tablets tiende a ser cuando se pasa del nivel 4.1 de H264 - la mayoría no hace 60fps a 1080p por ejemplo, lo que podría ser la razón por la que YouTube no ha adoptado eso todavía. Pero esa es otra discusión.
2) Parece que aprendo algo nuevo cada día. Lo primero que voy a intentar la próxima vez que transcodifique algo, es añadir thread=1 a la línea de comandos (mírame aquí, sorprendiendo a la gente por la cantidad de cosas que no conozco). Estoy cansado de que x264 inmovilice mi ordenador cada vez que pongo el freno de mano.
3) Aquí hay otra posibilidad (basada en una suposición totalmente poco profesional) - en un código YIFY, a veces los artefactos son obvios mientras que otras veces los artefactos son menos visibles. Creo que YIFY podría estar haciendo codificaciones basadas en bitrate a propósito y con un método más cutre para determinar la distribución de los bits de modo que no sólo ahorren tiempo en la codificación, sino que la distribución de calidad ligeramente desigual significaría que mientras algunas partes del video se verían cutre, otras partes del video se verían muy bien, y esos son los segmentos que los hacen netos que V10
4) "Magia" obviamente significa un software externo que optimiza un video para la codificación haciendo que sea de bitrate amigable.
En cuanto a deblocking=6,6 he experimentado con esto un poco más, y he encontrado que mientras los filtros externos (como el filtro incorporado del freno de mano) suavizan tu video hasta un punto realmente notable, deblock=6,6 no suaviza un video tanto. En lugar de ello, sólo mejora la calidad visual sin poner en peligro los detalles, y también ayuda enormemente cuando se ve un vídeo de baja resolución a resoluciones más altas.
5) me trae algunos recuerdos: la primera transcodificación de h264 que hice fue en un software llamado "ultra video converter", me llevó dos días "convertir" una codificación yify-like 720p de South Park BLU en formato mkv en un celeron 733 basado en una mina de cobre. Aparte de eso, el único otro software h264 que he usado es el formato de fábrica, que usa x264 (creo). También he exportado un proyecto de vídeo a través de quicktime h264, pero eso fue sólo meh. Así que no, en realidad no tengo ninguna experiencia con codificadores h264 aparte de x264, y por lo tanto no puedo comentarlo.
6) aunque la velocidad de codificación es definitivamente una razón, no hay que bajar demasiado la calidad para mantener el ancho de banda razonable. Intenté usar un preajuste normal (ref=1:weightp=1:subq=2:rc-lookahead=10:trellis=0:8x8dct=0) en el freno de mano para transcodificar un brrip de 11GB de memoria total de 130min 1080p (2012) a RF23, y el tamaño del archivo resultante fue menor a 2. 5GB y la calidad fue bastante buena y el tiempo de transcodificación tomó 1 hora en mi procesador ULV. la calidad de la codificación CUDA de 1080p de youtube a 3000kbps es simplemente inaceptable para los videos con movimiento, y a menudo encuentro que las versiones de 480p son mucho más visibles siempre que no haya un detalle intenso en el video.
La opción también funcionó definitivamente, porque antes de mi (Win 7 64 mostrando) 8 núcleos estaban completamente occpied, lo que resulta en una carga total de CPU del 96 al 99%. Con la opción añadida, la carga total de la CPU solo estaba saltando entre el 20 y el 30%.
El archivo fue una vista previa de 30 segundos de una serie de DVD. Usando denoise=ultra light y RF 20 con preset x264 muy lento, el tamaño del archivo sin limitación de subprocesos fue 4.028.992 bytes y con subprocesos = 1 fue 4.022.272 bytes.
A pesar del resultado más pequeño, no limitaré los hilos a 1 en el futuro, sin embargo, porque la mejora resultante del 0,1% no justifica aumentar el tiempo de representación en el factor 4 a 5.
http://mewiki.project357.com/wiki/X264_Settings
hilos
Valor predeterminado: automático (subprocesos basados en tramas: 1.5 * procesadores lógicos, redondeados hacia abajo; subprocesos basados en segmento: 1 * procesadores lógicos)
Permite la codificación paralela mediante el uso de más de 1 subproceso para aumentar la velocidad en sistemas multi-core. La pérdida de calidad de múltiples hilos es en su mayoría insignificante a menos que use un número muy alto de hilos (por ejemplo, por encima de 16). La ganancia de velocidad debe ser ligeramente menor que lineal hasta que comience a usar más de 1 hilo por 40 px de vídeo vertical, momento en el que la ganancia de hilos adicionales disminuye drásticamente.
x264 actualmente tiene un límite interno en el número de subprocesos establecidos en 128, de manera realista nunca debe establecerlo tan alto.
Gracias por explicar algunos de los vudú entre bastidores.
Sin embargo, tengo un par de preguntas -
¿Podría explicar algunos de los ajustes de denoise que mencionó en publicaciones anteriores? Si hay algo que me molesta es tener una transcodificación que de repente se convierte en basura cuando hay un corte en una escena oscura...
También leí en algún lugar (no recuerdo dónde, podrían haber sido los foros HB) donde se indicó que el orden en el que se ingresaron las configuraciones en el cuadro de opciones del codificador x264. ¿Hay algún mérito en eso?
¡Gracias!
Perdón por el puesto. Encontré la discusión de «denoise». Eso es lo que obtengo por quedarme en la discusión HandBrake.
La búsqueda
Es una aplicación para Xbox 360 y Windows 8... Sin embargo, no sé nada de Windows Phone.
Mirando las propiedades de los archivos de mi colección descargada, veo que los estándares visibles de las versiones de escenas h264, tras el cambio de XviD y AVI, se establecieron gradualmente en 720x404 para los rips de HDTV (no 720p) con una velocidad de cuadro de 23,97 y velocidades de datos totales de sólo 1000 aproximadamente. Como resultado, he estado guardando grabaciones de TV usando 720x404 a 23.97 fps (variable), 1000kbps de doble paso, audio AAC (faac) a 48 hz y 128 kbps, y luego todos los ajustes por defecto de Handbrake en la pestaña avanzada. Usando estos ajustes, soy capaz de convertir un programa de TV de 42 minutos recortado (sin publicidad) de 4,5 gb a unos 330 mb en unos 15-20 minutos, suponiendo que mi ordenador no haga nada más (Intel Core I-7, 16 gb de RAM, Win 7, 64 bits, Intel SSD). En general estoy contento con los resultados, y se comparan en calidad bastante bien con los lanzamientos de escenas, pero gracias a esta guía, ¡espero mejorarlos pronto! Hasta ahora, he experimentado cambiando sólo los ajustes avanzados a los valores recomendados anteriormente. Lamentablemente, las mejoras de calidad en una retransmisión grabada de un antiguo episodio de Matlock no justificaban que el tiempo de codificación casi se cuadruplicara. ¡Se agradecería cualquier consejo!
He estado trabajando bajo el supuesto de que la velocidad de cuadro de 23,97 era una parte crítica para lograr una calidad decente con tamaños de archivo más bajos, ya que 23 fps parecería requerir muchos menos datos que 30 fps, que, creo, es lo que la mayoría de mis grabaciones de televisión comienzan como (abrí una grabación de un episodio reciente de "Touch" con el que estaba teniendo dificultades y la herramienta de información que estaba usando informó que el archivo de WTV era de 60 FPS! No sé mucho sobre estas cosas, pero eso me pareció poco probable!) De todos modos, después de leer esto estoy cuestionando mi configuración porque Matt parece ser un gran fan de usar la velocidad de fotogramas original. ¿Alguien podría comentar la diferencia entre la velocidad de fotogramas en relación con el cálculo de calidad/tamaño? Por lo que sé, el ojo humano no debería ser capaz de notar la diferencia, pero nunca lo he investigado, así que lo más probable es que me equivoque.
De todas formas, gracias por esta gran guía, y estoy seguro de que volveré a ella a menudo mientras intento mejorar mis códigos.
Sin embargo, parece que has estado contento con la calidad que tenías antes. Si ese es el caso, tal vez quieras averiguar un tiempo de codificación objetivo con el que aún estarías contento/contenido, y empezar a aumentar los ajustes hasta que lo consigas.
En cuanto a los fotogramas, me atreveré a decir que los 60 fps que viste eran de una emisión 1080/60i (algo común en las emisiones de OTA en EE.UU./Canadá, no estoy seguro del resto del mundo). A menudo para los viejos programas de televisión, es contenido de 30fps que simplemente se entrelaza para obtener el 60i. Para las películas emitidas a 1080/60i (normalmente 24fps por defecto), tiende a ser telecineado a 30fps y luego entrelazado a 60i.
En cualquier caso, soy un fanático de mantener el fotograma original (después de que haya sido desentrelazado y deseleccionado por Handbrake). Para una grabación de TV, debería ser de 30 o 24 fps al final, asumiendo que todo salió como se esperaba. No me gusta cambiar la velocidad de cuadro por un par de razones... Primero, no recuerdo cómo funciona HB/x264, pero tiene que ser o bien bajando o mezclando cuadros (probablemente lo primero). El efecto de esto puede variar desde el tartamudeo de la pantalla durante las panorámicas hasta el empeoramiento de las escenas de alto movimiento a... bueno, un número de cosas. Algunos contenidos pueden salirse con la suya bastante bien, pero otros pueden sufrir.
Segundo, debido a la forma en que funciona x264, no necesariamente equivaldrá a la reducción de tamaño que podrías esperar. Por ejemplo, cuando se deja caer algo de 30 fps a 24 fps se podría esperar un archivo con un 80% del tamaño. Pero en realidad x264 hace un gran trabajo de reutilización de los datos de los cuadros (¡para eso son todos esos cuadros B y cuadros de referencia!) y es poco probable que las cosas salgan tan bien. Por supuesto, podrías probar esto para ver cuánta reducción de tamaño obtienes... Por supuesto que podría estar equivocado, pero sospecho que la reducción de tamaño no será tan sustancial.
muchas gracias por la gran guía
Dicho esto, las noches pueden haber cambiado un poco - no he agarrado una en años, y por lo tanto no puedo decir con seguridad de una manera u otra. Si todas las opciones en la GUI siguen «coincidiendo» con lo que había escrito, probablemente sea seguro suponer que no ha habido ningún cambio significativo. IIRC gran parte del desarrollo hacia los nocturnos la última vez que eché un vistazo parecía estar orientado a la inclusión de OpenCL (o era QuickSync de Intel...? mi memoria me está fallando), lo que no debería hacer nada obsoleto aquí, pero podría agregar algunas opciones adicionales en la GUI que querría examinar si ese fuera el caso.
muchas gracias..:)
A diferencia de la mayoría de los otros ajustes, cuando se aumenta el número de fotogramas B y tamaños GOP, (fotogramas b+p), a pesar de aumentar la eficiencia del códec, en realidad se pierde un poquito de detalles finos. Los cuadros B y P acumulan la información de movimiento de compresión con pérdida redondeada, por lo que se pierde la información de imagen fina original, cuanto más se tenga de entonces, y cuanto más grande sea el GOP, más información fina se perderá de forma acumulativa. Esto es especialmente cierto en fuentes ruidosas/granuladas como un metraje DSLR de alta resolución. Sin embargo, aumentan la eficiencia de compresión general, y por lo tanto, en un tamaño de archivo restringido, la calidad general. Sin embargo, en un ajuste de calidad constante en un escenario en el que la calidad general es más importante que la eficiencia de compresión, se debe considerar la posibilidad de utilizar un pequeño número de fotogramas b o incluso ninguno, a expensas de tamaños de archivo (mucho) más grandes. Este es un escenario común con los videógrafos de bajo presupuesto y semi-amateriales (como yo) que preparan archivos "maestros" para ser editados. La Cámara Panasonic GH2 es bien conocida por su firmware pirateado en el que los usuarios pueden ajustar la configuración del códec para producir la mejor calidad posible de los archivos codificados internamente. La mayoría de los firmwares que buscan esta mejor calidad en las tasas de bits restringidas que una tarjeta SD puede manejar, usualmente implementan los tamaños GOP más bajos posibles (como 2 o 4 cuadros b/p por cada cuadro i).
Todavía queda una pregunta: HB puede usar Perfiles h.264 línea principal + alta o la pestaña avanzada. ¿Hay alguna manera de codificar en 10 bits (alto 10), en lugar de alto sin perder la pestaña avanzada? ¿Tal vez un parámetro de consola?
Que yo sepa, HandBrake aún no es compatible con 10 bits. Ha pasado un tiempo desde que he investigado las cosas, pero la última vez recuerdo, es un binario x264 completamente diferente (que funciona para otros frontales x264 que simplemente llaman a la CLI de x264 y puede intercambiar entre binarios, pero no es tan fácil de implementar en HandBrake porque usa libx264). Dudo que esté en la lista de prioridades para que los desarrolladores de HB implementen ya que el soporte de decodificación H.264 de 10 bits es prácticamente inexistente en hardware/dispositivos independientes, y los dispositivos probablemente no soportarán 10 bits hasta que la decodificación de hardware H265 (HEVC) se convierta en corriente principal.
Alguien puede corregirme si me equivoco, pero sospecho que tendrá que usar otro front-end que canalizará su fuente directamente a través del binario x264 de 10 bits.
Ya veo la diferencia entre un archivo fuente en 720p y 8/10 bit. Como 350MB para 8bit y 294MB para 10 bit - la misma o incluso ligeramente mejor calidad. Lo curioso es que mi viejo Samsung Galaxy S2 puede reproducirlo perfectamente, como todos los dispositivos androides que tienen una velocidad decente. Usé ese archivo en mi TV y también lo reprodujo, ¿quizás un modo alternativo de algún tipo? Intenté seguirlo y terminé con la teoría de que el codificador recoge la fuente de 8 bits, la codifica con una precisión de 10 bits y deja la salida en 8 bits. Si estoy en lo cierto, eso significaría que el único factor limitante para la reproducción es la velocidad del dispositivo, y tal vez algunas opciones elegantes, como los submarinos de estilo tienen que ser ajustadas o al menos consideradas.
Sé que puedo usar el x264.exe en la consola o por ejemplo megui para codificar en 10 bits, si cambio el binario, pero ese es aún más complicado que la versión de consola. Dicho esto, no voy a perder horas tratando de averiguar cuando el freno de mano hace un trabajo decente. En mi humilde opinión, el freno de mano es el más avanzado de los codificadores verdaderamente libres que existen. A otros les gusta limitar sus opciones o incluso peor: cambiar su archivo con anuncios para ser mostrado en el flujo de vídeo codificado.
Gran artículo, pero estoy viendo esto desde una especie de la dirección opuesta, es decir, el archivo máximo y lo más cerca posible del original. ¿Alguna configuración sugerida para esto, por favor?
¡Gracias!
Si el tamaño del archivo no importa, las cosas se vuelven muy simples:
- Si estás usando "Calidad Constante", empuja el deslizador RF a la derecha (número menor).
- Si está usando "Average Bitrate", aumente la tasa de bits.
...en realidad si presionas el deslizador RF hasta "0", el nuevo video será idéntico al video fuente (a menos que actives la eliminación de ruido, cambies la resolución, etc.), aunque el tamaño del archivo será increíblemente grande, mucho más grande de lo que era tu fuente original, por lo general.Por otra parte, si desea que el tamaño del archivo sea razonablemente razonable, el RF:10 normalmente dará algo en el aproximado del tamaño de su fuente original, y a menos que pase cuidadosamente unos minutos examinando ambos videos uno al lado del otro cuando se haga una pausa, probablemente no verá mucha diferencia.
Si se acerca el valor de RF a estos niveles, la mayoría de las opciones avanzadas no importarán mucho si realmente no le importa el tamaño del archivo. Es posible que desee configurar el indicador de desbloqueo en -1/-1 (película/3D) o -2/-2 (película granulada) para asegurarse de que las cosas se mantengan nítidas en la reproducción.
En el caso de que decidas que el tamaño importa al menos un poco... un valor de RF en el rango RF18-RF10 probablemente te dará algo que se parezca bastante al original de todos modos. Selecciona "No DCT Decimation" para asegurarte de que los bloques no se caigan. Escribir manualmente "no-dct-decimate" (sin comillas) probablemente también valga la pena, ya que no debería tener una reducción de velocidad a las altas velocidades de bits a las que tienden a estar estos valores de RF.
1) Descarta el reproductor: Reproduce el vídeo en otro reproductor (VLC) para ver si sigue ocurriendo.
2) Descarta la fuente: Intenta codificar un vídeo completamente diferente (descarga un mp4 de https://sample-videos.com/ y codifícalo).
3) Descarta la versión de Handbrake: Prueba con otra versión de Handbrake.
4) Descarta la configuración: Realiza una codificación de prueba utilizando un preajuste muy sencillo (un dispositivo de baja resolución a una velocidad de fotogramas de 30fps, por ejemplo).
5) Descarta la máquina: Intenta codificar el mismo vídeo en otro ordenador, utilizando el mismo reproductor, versión de Handbrake y ajustes.
Sospecho que uno de ellos dará como resultado un vídeo que funciona, y ayudará a dar una indicación de dónde estaba el problema.