Fansub III – Teoría de la codificación

Visto el gran trabajo de Fuliazo para aclararnos el mundo del encode para windows, agregaré mi granito de arena para aquellos que en su día nos decidimos por linux como solución a nuestros problemas. Como veréis, la orientación es muy técnica y no trato de hacer una guía para codificar con megui, virtualdub o los tropecientasmil programas GUI que circulan por ahí.
Estamos aquí para aprender, para intentar dar luz a un mundo bastante oscuro y desentrañar los fundamentos de la codificación.
Como siempre y esto es una constante, en estas guías sólo ofreceré soluciones de código libre. Existen multitud de herramientas para realizar la tarea, pero la utilización de software de código libre me parece la mejor forma de honrar el trabajo de todos esos programadores que nos ofrecen esas herramientas tan fantásticas.
Bueno, llegamos a la parte final de proceso de una serie por el fansub, en la que creamos el contenido para su distribución. Para eso necesitamos codificar el audio y vídeo e introducirlo en un tipo de archivo que pueda ser reproducido por los programas que normalmente utilizamos para ver contenido multimedia.
La codificación no es ni más ni menos que eso, codificar. Es escribir la informacion en un lenguaje que es conocido y compartido por el receptor. Para eso tenemos los codecs o codificadores-decodificadores que se encargan de esa tarea.
Principalmente en la actualidad trabajamos con el codec de vídeo h264 ó mejor, su implementación de código libre x264. También podemos usar XVID, implementacion de código libre para codificaciones compatibles con el estándar DivX.
Para el audio tenemos varias opciones, MP3lame, Faac ó mi recomendación, el códec ofrecido por Nero para codificar en el formato AAC, NeroAACenc que ofrece la mejor calidad.

Y dicho esto comencemos.

Estándares de emisión en TV y distribución.

Según he ido avanzando en la confección de los manuales del taller, me he dado cuenta de la necesidad de explicar los diferentes estándares que nos podemos encontrar y así estar más preparados para dar una solución adecuada.

Todo comienza allá por los años cincuenta cuando se establecen los estándares de emisión para TV. Aparecen el NTSC y PAL (obvio el SECAM por su limitada distribución) principalmente amoldándose a las características de la red de distribución eléctrica. Hablamos de 25 imágenes por segundo para PAL (red eléctrica de 50HZ) y 29,97 para NTSC (red de 60HZ). Me centro exclusivamente en la frecuencia de fotogramas y no en la codificación del color, ya que es lo que nos interesa.

Como estamos centrados en material procedente de Japón, puntualizar que el estándar en Japón es NTSC.

Por otro lado están los cines, en este caso usan un estándar diferente de 24 imágenes por segundo denominado FILM.

Con la entrada de HDTV el panorama cambia ya que nos encontramos con que aumenta el ancho de banda y es posible la emisión de imágenes progresivas sin entrelazar. Pero se mantienen la frecuencia de fotogramas.

Japón adopta el estándar ARIB STD-B32 para el multiplexado y codificación de material audio/vídeo con lo que nos encontramos con los siguientes parámetros:

Formatos ISDB
Emisión Formato Res. H. Res. V. Rel. Asp. Modo Barrido Frec. Fotogramas Frec. Campo
HDTV 1125i 1920 1080 * 16:9 entrelaz. 29.97 Hz 59.94 Hz
1125i 1440 1080 * 16:9 entrelaz. 29.97 Hz 59.94 Hz
750p 1280 720 16:9 progres. 59.94 Hz
SDTV 525i 720 480 16:9 entrelaz. 29.97 Hz 59.94 Hz
525i 544 480 16:9 entrelaz. 29.97 Hz 59.94 Hz
525i 480 480 16:9 entrelaz. 29.97 Hz 59.94 Hz
525i 720 480 4:3 entrelaz. 29.97 Hz 59.94 Hz
525i 544 480 4:3 entrelaz. 29.97 Hz 59.94 Hz
525i 480 480 4:3 entrelaz. 29.97 Hz 59.94 Hz

Bueno, ¿cómo nos movemos entre estándares?

De FILM a PAL -> se aumenta ligeramente el framerate directamente, cambia un poco el pitch de audio pero apenas se nota. De hecho en Europa disfrutamos de menos minutos de metraje que en América para la misma pelicula. (A veces es un alivio)

De FILM a NTSC -> La cosa se complica ya que aumentar de 24 a 29.97 directamente ya no es posible porque es mucho. Utilizamos una transformación que se denomina TELECINE. Primero ralentizamos el vídeo a 23.976 fps y después le aplicamos una transformación denominada 2:3 pulldown, que se basa en combinar campos.

De NTSC a PAL -> Lo contrario a TELECINE que se llama INVERSA-TELECINE. De esa manera le bajamos el framerate a 23.976 y después lo aceleramos a 25 fps.

De NTSC a FILM -> INVERSA-TELECINE

y así sucesivamente…

Así que el material que normalmente nos encontramos procedente de TV tiene aplicada la transformación INVERSA-TELECINE y nos aparece con una frecuencia de 23.976. Si es de Japón no puede ser otra cosa, a no ser que le hayan introducido alguna transformación. El conservar material a 59.94 hablando de anime es un desperdicio de espacio.

Los Blue Ray suelen distribuirse a 23.976, 24 ó 25 fps, dependiendo de la zona de distribución.

Video

Como ya se ha discutido muchas veces en los foros, la primera decisión a la hora de codificar es el número de bits de color que vamos a usar. En anime es muy util la codificación en 10 bits ya que ofrece 2 cosas: En primer lugar crea menos macroblocks (esos cuadrados del mismo color) y además ofrece una reducción del tamaño de los archivos de alrededor de un 20% manteniendo la misma calidad. No ocurre lo mismo con la codificación de material normal, por eso no está tan extendido.

Añadiría que aunque la mejor opción es encontrar fuentes que directamente estén codificadas en Hi10, para anime, la ventaja es tan grande que incluso utilizando fuentes de 8 bits podemos conseguir compresiones muy buenas y mejoras en la imagen.

Y ahora vamos a por las herramientas.

Lo suyo sería que nos bajásemos el código fuente y realizáramos una compilación a medida de nuestras necesidades, pero como no es ése el propósito de esta guía, bajaremos unas versiones ya compiladas y listas para ejecutar.

Para windows.
Para Linux, como depende de la distribucion, para dar una solución universal nos tenemos que bajar el código fuente de aquí.

Para hacer todo el proceso deberíamos introducir en una sesión de terminal lo siguiente:

sudo apt-get remove ffmpeg x264 libx264-dev
#me aseguro de tener los programas desinstalados

sudo apt-get update
#actualizo los repositorios a la última versión

sudo apt-get install build-essential checkinstall git libfaac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev libsdl1.2-dev libtheora-dev libva-dev libvdpau-dev libvorbis-dev libx11-dev libxfixes-dev texi2html yasm zlib1g-dev libass-dev libxvidcore-dev
#instalo los programas necesarios para compilar, he incluido algunos paquetes opcionales que veremos más adelante

cd ~
#cambio al directorio home

git clone git://git.videolan.org/x264
#me bajo la última versión de x264

cd x264
#cambio al directorio en el que me he bajado las fuentes

./configure –enable-static
#configuro la compilación

make
#compilo

sudo checkinstall –pkgname=x264 –pkgversion=»3:$(./version.sh | awk -F'[» ]’ ‘/POINT/{print $4″+git»$5}’)» –backup=no –deldoc=yes –fstrans=no –default
#Creo un paquete de instalación, lo que sería un install.exe de windows y lo instalo en el sistema.

Ya tengo la versión de 8 bits instalada y una copia del archivo de instalación en la carpeta x264, pero también necesito la versión de 10 bits, luego la instalaremos.

Para audio, nos vamos a la página de Nero y nos bajamos el codec. Tiene versiones para windows y linux. Descomprimimos el zip y lo dejamos en algún lugar de conveniencia. En linux hay que acordarse de darle permisos de ejecución al archivo.

Empecemos…

El vídeo. Los niveles

El codec x264 es muy amplio por lo que dependiendo de las opciones que usemos, los equipos reproductores necesitarán de más o menos prestaciones. En definitiva más o menos potencia de proceso. Por eso y para crear unos estándares se crearon los niveles. Así cada cacharro que compramos está certificado para cierto nivel, como pasa por ejemplo con la playstation 2 que es nivel 4.1 ó la PSP que es nivel 3.1, o mi reproductor de salón, una caja WDTV de Western Digital que reproduce hasta 4.1.

Según las opciones utilizadas el codec establece el nivel del video y lo graba en el video final como dato para que los reproductores lo comprueben antes de iniciar la reproducción y no intenten reproducir una cosas que no son capaces. Por eso hay herramientas por ahí para cambiar ese dato y engañar al equipo para que lo reproduzca, pero como veís no es milagroso y no se puede hacer nada serio sin pasar por una recompresión.
A lo que iba con todo esto es a que x264 tiene una opcion que se llama «level». Equivocadamente mucha gente piensa que poniendo ese parámetro en la linea de comando obtendrán un archivo compatible con ese nivel. ¡¡Pues no!!. Se usa sólo para advertirle al códec que queremos ese nivel y si las opciones de codificación no son las adecuadas, entonces el codec emitirá un mensaje de aviso como que nos estamos pasando de la raya, pero nada más.

Bitrate, CRF, QP, Doble pasada.

La segunda decisión. ¿Cómo queremos codificar?
En los tiempos de XVID, todos teníamos claro que las codificaciones a doble o triple pasada ofrecían una calidad mejor con el mismo peso de archivos, pero esa situación a mi entender ha cambiado con x264.

Veamos unos ejemplos:

En el modo CRF el codec busca una calidad media por lo que subirá la calidad en las escenas que lo necesiten y lo bajará en otras. Muy útil y mi recomendación cuando no estamos restringidos por espacio.

Ejemplo de codificación con modo de calidad constante:
x264 –crf 24 -o <output> <input>

Los valores son logarítmicos y van de 0 a 51. Los valores de uso normal andan entre 14 y 24. A menor valor, mayor calidad. Para haceros una idea, las RAW suelen estar codificadas con valores de 16 a 19.5 normalmente. Unos valores normales para codificación se encuentran entre 21 y 24 dependiendo del tipo de vídeo a comprimir. El caso del Anime es especial pues soporta que le bajemos el índice de calidad bastante bien sin perder calidad. De hecho codificaciones con un crf de 24 se ven bastante bien.

El modo QP es como si dijéramos el mismo que en xvid, codificamos a un índice de calidad constante y el codec varía el bitrate para ajustarse adecuadamente. El tamaño final depende de las características del vídeo. No lo uso mucho debido a que el modo CRF ofrece a mi parecer muchas más ventajas. Va de 0 a 69.

Compresión sin pérdida:
x264 –qp 0 -o <output> <input>

Dejaré la codificación a doble pasada sólo para los casos en los que el tamaño sí importe. (¿Dónde he oído eso?)

Doble pasada a un bitrate de 1000kbps:
x264 –pass 1 –bitrate 1000 -o <output> <input>
x264 –pass 2 –bitrate 1000 -o <output> <input>

Las opciones

x264 tiene un montón de opciones. Los creadores del codec son conscientes de ello por lo que nos han regalado unas herramientas para hacernos la vida más fácil. se trata de los -preset, los -tune y los -profile. Con sólo esas tres opciones podríamos realizar codificaciones más que correctas.

Profiles.
Son paquetes de opciones que hacen que el vídeo resultante sea compatible con determinados reproductores. Principalmente usamos dos, high y high10 para codificaciones a 10 bits. No quiero extenderme aquí ya que siempre vamos a usar estas opciones.

–profile <valor> Ajusta los parámetros al límite de cada profile. Tiene prioridad sobre el resto de los ajustes. Aquí tenéis los «paquetes» de opciones que activan.

– baseline:
–no-8x8dct –bframes 0 –no-cabac –cqm flat –weightp 0
No entrelazado.
Con pérdida.

– main:
–no-8x8dct –cqm flat
Con pérdida.

– high:
Con pérdida.

– high10:
Con pérdida.
Soporte para profundidad de color de 8 y 10 bits.

– high422:
Con pérdida.
Soporte para profundidad de color de 8 y 10 bits.
Soporte para submuestreo chroma de 4:2:0/4:2:2.

– high444:
Soporte para profundidad de color de 8 y 10 bits.
Soporte para submuestreo chroma de 4:2:0/4:2:2/4:4:4.

Preset
Aquí elegimos la forma en la que codifica, qué es lo que mira y cómo lo hace. Hay muchas opciones y todas inciden directamente en la velocidad de codificación. Tenemos varias:

–preset <valor> Usa el valor entre corchetes para codificar [por defecto medium].
Si introducimos opciones aparte los valores cambian. Cuando ponemos un preset lo que hace el codec es aplicar el grupo de valores que enumero a continuación.

ultrafast
–no-8x8dct –aq-mode 0 –b-adapt 0 –bframes 0 –no-cabac –no-deblock
–no-mbtree –me dia –no-mixed-refs –partitions none –rc-lookahead 0 –ref 1
–scenecut 0 –subme 0 –trellis 0 –no-weightb –weightp 0

superfast
–no-mbtree –me dia –no-mixed-refs –partitions i8x8,i4x4 –rc-lookahead 0
–ref 1 –subme 1 –trellis 0 –weightp 1

– veryfast:
–no-mixed-refs –rc-lookahead 10 –ref 1 –subme 2 –trellis 0 –weightp 1

faster
–no-mixed-refs –rc-lookahead 20 –ref 2 –subme 4 –weightp 1

fast
–rc-lookahead 30 –ref 2 –subme 6 –weightp 1

medium
Por defecto.

slow
–b-adapt 2 –direct auto –me umh –rc-lookahead 50 –ref 5 –subme 8

slower
–b-adapt 2 –direct auto –me umh –partitions all –rc-lookahead 60
–ref 8 –subme 9 –trellis 2

veryslow
–b-adapt 2 –bframes 8 –direct auto –me umh –merange 24 –partitions all
–ref 16 –subme 10 –trellis 2 –rc-lookahead 60

placebo
–bframes 16 –b-adapt 2 –direct auto –slow-firstpass –no-fast-pskip
–me tesa –merange 24 –partitions all –rc-lookahead 60 –ref 16 –subme 11 –trellis 2

Tune:

–tune <string> Adapta los ajustes predeterminados en preset para un uso en particular.
Los valores de usuario sobreescriben éstos.
Se pueden introducir varios tune separados por comas.
Si es tipo psy sólo se puede usar uno.

Se aplican los siguientes conjuntos de valores.

– film (psy tuning):
–deblock -1:-1 –psy-rd <unset>:0.15

– animation (psy tuning):
–bframes {+2} –deblock 1:1 –psy-rd 0.4:<unset> –aq-strength 0.6 –ref {Double if >1 else 1}

– grain (psy tuning):
–aq-strength 0.5 –no-dct-decimate –deadzone-inter 6 –deadzone-intra 6
–deblock -2:-2 –ipratio 1.1 –pbratio 1.1 –psy-rd <unset>:0.25 –qcomp 0.8

– stillimage (psy tuning):
–aq-strength 1.2 –deblock -3:-3 –psy-rd 2.0:0.7

– psnr (psy tuning):
–aq-mode 0 –no-psy

– ssim (psy tuning):
–aq-mode 2 –no-psy

– fastdecode:
–no-cabac –no-deblock –no-weightb
–weightp 0

– zerolatency:
–bframes 0 –force-cfr –no-mbtree –sync-lookahead 0 –sliced-threads –rc-lookahead 0

Bueno, ahora que tenemos claro los grupos de opciones podríamos desgranar opción por opción las más importantes:

-bframes: Tiene que ver con la forma en que se almacenan las imágenes. Hay tres tipos B, I y P. Tipo I: no se referencia con ninguna otra por lo tanto casi no se comprime. Tipo P: se referencia con imágenes anteriores, por lo tanto se puede comprimir más ya que lo que hace es repetir todos los datos que puede de la imagen anterior. Tipo B: Se referencia con imágenes anteriores y también posteriores por lo que ofrece la mayor compresibilidad. Este parámetro nos indica cuantas imágenes tipo B pueden ir seguidas. A mayor número mayor puede ser la compresibilidad, pero también necesitamos más potencia y el moverse por el vídeo puede acabar siendo difícil, ya que tiene que encontrar las imágenes de referencia para poder construir la imagen.

-ref: Número de imágenes de referencia. Nos indica el número de imágenes antes y después que estudia el codec para comprimir la imagen actual.En anime como podéis suponer podemos subir este parámetro bastante más de lo normal para conseguir compresiones increíbles.

-trellis: Cuantización para los macroblocks. Estudia la forma de comprimir los bloques de imagen. De 0 a 2. Yo lo dejo en 2 siempre para que lo haga en todos los tipos de imágenes.

-deblock: Es un filtro para como su nombre indica hacer deblock. Para anime útil, pues trabajamos con imágenes principalmente de colores planos.

-vbv-maxrate: Esto necesita un poco de aclaración. No es en sí un parámetro de codificación sino más bien un control de flujo de datos. El valor de este parámetro y el siguiente vienen de acuerdo con la siguiente pregunta: ¿Dónde voy a reproducir el vídeo y qué velocidad de transferencia me ofrece el soporte?
En el caso del reproductor de vídeo de mi coche, un Kenwood DDX4038BTM, su bitrate de transferencia máximo es de 4Mbps para DVDs y 2Mbps para el conector USB. Si quiero reproducir un vídeo en el USB tendré que codificar poniéndole este límite o sino podría ir a saltos o incluso cortarse el vídeo. Lo que hace este parámetro es bajar la calidad del vídeo lo suficiente para no subir por encima del límite marcado en los pasajes que sea necesario.

-vbv-bufsize: Íntimamente relacionado con el anterior. El cambio de QP o factor de calidad no es algo inmediato y lleva un tiempo. Por eso necesitamos crear un buffer de datos que alimente la imagen mientras se produce ese cambio y el flujo de datos vuelve a su límite. Normalmente es suficiente poner la misma cantidad que hemos puesto en vbv-maxrate. Si nos queremos atener a los límites del perfil 4.1 estos valores son en ambos casos 62500. Por ejemplo, si comprimimos a un bitrate de 1000, con 62500 tendríamos 62.5 segundos de buffer.

-me: método de estimación de movimiento. Estudia las imágenes para ver si es la cámara la que se mueve y de esa manera mover los pixels para ganar compresión. Hay varios métodos a cada cual más complejo y por ende más costoso en tiempo de compresión.

-subme: Define la forma en que el decodificador toma la decisión de cómo codificar esa imagen. Va de 0 a 11. Cuanto más, mejor, a costa de velocidad de proceso. A partir de 9 ya es un buen parámetro.

Ejemplo de bitrate constante de 1000kbps con un buffer de 2 segundos:
x264 –vbv-bufsize 2000 –bitrate 1000 -o <output> <input>

El resto me lo salto porque normalmente no nos hara falta tocar los valores predeterminados.

Dependiendo de las opciones de compilación tendremos soporte para guardar nuestro archivo en diferentes formatos.
Para saber los formatos soportados por la compilacion de la que disponemos no hay más que llamar al programa con la opción help:

x264 –help

Si hay demasiados datos podéis ponerle a la salida un filtro para paginar:

x264 –help|more

nos saldrá algo así:

x264 core:122 r2184 5c85e0a
Syntax: x264 [options] -o outfile infile

Infile can be raw (in which case resolution is required),
or YUV4MPEG (*.y4m),
or Avisynth if compiled with support (no).
or libav* formats if compiled with lavf support (yes) or ffms support (no).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC support (no)
Output bit depth: 8 (configured at compile time)

—más—

……….
Como podeis ver, la información que nos entrega es muy extensa y nos aclara lo que sí y lo que no podemos hacer. En mi caso como compilé con soporte lbav el codec podrá leer todos los formatos soportados por esa librería que son prácticamente todos los que existen.
Para escribir el archivo final tengo ciertas limitaciones, sólo puedo hacerlo en MKV, 264 (raw) ó flv, ya que no se compiló con soporte gpac que es otro grupo de librerías que dan soporte al formato MP4 por ejemplo. Por eso dice no entre paréntesis.
Bueno, no tengo mucho problema ya que con el mkv me es más que suficiente, o sino puedo siempre grabar el stream directamente en 264.
También se puede ver los bits de codificación, que son 8. Y también una cosa interesante, los filtros disponibles.

Pues entonces vamos a codificar un vídeo. Veamos, vamos a probar con un crf de 24 y con las opciones por defecto:

x264 –crf 24 –profile high –preset medium -o salida.mkv entrada.avi

Ya tenemos un vídeo, pero no suena. Claro, porque el x264 sólo es un codec de vídeo. Tenemos que codificar el audio por otro lado.

Habíamos hablado de NeroAACenc.

Nos ponemos en el directorio donde dejamos el ejecutable y ponemos esto:

neroaacenc -help

Saldrán las opciones de utilización del programa, son unas cuantas, pero de nuevo me centraré en las interesantes:

-q codifica con un factor de calidad. Por defecto es .5, al cambio 160k. (0.45 sería 128k y 0.95 384k)
-br me parece una opción más interesante. ponemos el valor en bites. Para una codificación a 160k sería 160000

vamos a ello:

neroAacEnc -br 160000 -if entrada.avi -of salida.m4a

¿Qué ha pasado? No funciona. Vaya, es que no me he leído bien el help :-). Resulta que el archivo de entrada tiene que ser en formato wav conteniendo un stream pcm. ¡A la mierda con la codificación, me vuelvo a MeGui!

Tranquilos, no hay nada que con tiempo y una caña o dos (y no me refiero a las de pescar) no se pueda hacer.

Todo lo anterior ha sido una excusa para presentaros las herramientas multiuso por excelencia de la codificación. Se trata de Mplayer/Mencoder y de ffmpeg.

Se trata de dos programas que reunen y utilizan las librerías libav. Ya las habíamos visto antes de pasada cuando echamos un vistazo a los parámetros de compilación de nuestro x264.

Bueno, pues estas librerías son pequeños programas empaquetados que los programadores ponen a disposición de la comunidad para que un desarrollador no tenga que reescribir todo el código, así se aprovechan las partes de código ya escritas por otro programador.

Las librerías libav abarcan muchos aspectos, libavcodecs que integra diferentes codecs de compresión, libavformat para dar soporte a los formatos de salida y entrada, libavfilter para los filtros…

No os podéis imaginar la cantidad de programas que hacen uso de estas librerías, entre ellos un gran conocido nuestro como es el aegisub.

Pues vamos a conseguir estos programas tan cojonudos.

mplayer/mencoder
(ya puestos a bajar, bajaros del enlace con el smplayer, es un reproductor que os va a gustar 100%)

ffmpeg

En esta página os encontraréis los enlaces a los dos programas para windows.

Para linux podéis utilizar las versiones de vuestra distribución, o compilar la última versión desde las fuentes con lo que tendréis garantizado el estar a la última como por ejemplo el soporte de 10 bits o los filtros ass para subtítulos, que normalmente no suelen estar incluidos en las compilaciones habituales.

Para linux:
Como siempre abrimos un terminal:

sudo apt-get install mplayer mencoder ffmpeg

ó bien, si queremos compilar ffmpeg con soporte para ass entonces en vez de la orden anterior hacemos:

sudo apt-get install mplayer mencoder

#y ahora instalo ffmpeg por mi cuenta.

cd ~
git clone –depth 1 git://source.ffmpeg.org/ffmpeg
cd ffmpeg
./configure –enable-gpl –enable-libfaac –enable-libmp3lame –enable-libopencore-amrnb –enable-libopencore-amrwb –enable-libtheora –enable-libvorbis –enable-libx264 –enable-libxvid –enable-libass –enable-nonfree –enable-version3 –enable-x11grab
make
sudo checkinstall –pkgname=ffmpeg –pkgversion=»5:$(date +%Y%m%d%H%M)-git» –backup=no –deldoc=yes –fstrans=no –default
hash x264 ffmpeg ffplay ffprobe

#añadir soporte libav para x264. Paso necesario para añadir soporte libav a nuestra compilación de x264

cd ~/x264
make distclean
./configure –enable-static
make
sudo checkinstall –pkgname=x264 –pkgversion=»3:$(./version.sh | awk -F'[» ]’ ‘/POINT/{print $4″+git»$5}’)» –backup=no –deldoc=yes –fstrans=no –default
mv x264 x264-8
#le cambio el nombre al directorio

#ahora es el momento de compilar para 10 bits

cd ~
#vuelvo a cambiar al directorio home
git clone git://git.videolan.org/x264
#vuelvo a bajarme las fuentes
cd x264
#cambio al directorio recién creado
make distclean
#me aseguro que está todo por defecto
./configure –enable-static –bit-depth=10
#vuelvo a configurar la compilación, pero esta vez a 10 bits
make
#compilo
sudo checkinstall –pkgname=x264-10 –pkgversion=»3:$(./version.sh | awk -F'[» ]’ ‘/POINT/{print $4″+git»$5}’)» –backup=no –deldoc=yes –fstrans=yes –default –install=no
#creo el paquete de instalación, pero esta vez no lo instalo.
cd ~
#vuelvo a mi directorio home
mv x264 x264-10
#y le cambio el nombre al directorio por algo que tenga más sentido en este caso x264-10.

Una vez terminado con esto ya tenemos todos los codecs, el ffmpeg y el mencoder. En el caso de linux tendremos los ejecutables en las carpetas ~/x264-10 y ~/x264-8 (en este caso también instalado en el sistema)

Ya que ahora tenemos todos los cañones cargados, es hora de atacar.

Necesito un archivo de audio wav con un stream pcm, que no es ni más ni menos que audio sin comprimir.

Como el número de opciones de ffmpeg y mencoder es x cuando x tiende a infinito, os dejo la labor a vosotros de investigar. Pero os puedo asegurar que podéis hacer absolutamente todo.

Para conseguir un archivo de audio pcm en formato wav:

ffmpeg -i entrada.avi -vn -acodec pcm_s16le temporal.wav

¡voilá!

y ahora sí:

neroAacEnc -br 160000 -if temporal.wav -of salida.m4a

ahora ya podemos borrar el archivo temporal wav que no queremos para nada:
del temporal.wav
ó bien para linux
rm temporal.wav

El «Muxing» o empaquetado.

Ya hemos visto como conseguir un archivo de vídeo con el codec x264 y uno de audio con Nero. Pero sueltos nos sirven de poco, necesitamos poder ver y oír a la vez para que sea divertido.

Cuando Microsoft por los años 90 sacó el revolucionario windows 3.1 se encontró con la incipiente necesidad de reproducir archivos multimedia, esto es, conteniendo múltiples pistas de audio y vídeo. Aunque por aquel entonces la capacidad de los ordenadores era ridícula, se podían reproducir pequeños archivos con resoluciones CGA y por el estilo. De esta necesidad nace el AVI (Audio-Video Interleave). Se trata de un tipo de archivo creado por Microsoft, que establece una forma de empaquetar pistas de audio y vídeo solamente. Como data de los años 90 tiene muchas restricciones. Primero, solo puede empaquetar audio y vídeo, además está el límite de 2GB para el tamaño de archivo. Posteriormente para saltarse esas restricciones, los programadores sacan una serie de hacks para poder seguir usando ese formato. Esta nueva variante AVI se la denominó OPEN-DML y permitía saltarse el límite de los 2GB así como incluir tipos nuevos de pistas de audio y vídeo. Pero sólo era un parche. Pronto nuevas fórmulas mucho más avanzadas asaltaron el mercado. Primero fue OGM y poco despues MKV (que estuvo durmiendo en el sueño de los justos durante unos años, hasta que los usuarios se empezaron a dar cuenta de sus posibilidades) para acabar saliendo MP4. Sin embargo, la batalla de los formatos no la ganaría el usuario. Como siempre los fabricantes dieron su última palabra y para que MKV levantara el vuelo, tuvo que adoptarse como nuevo estándar para todo tipo de reproductores (esto ocurre a partir de DivX7, creo)

Bueno, toda esta batallita para encontrarnos en la actualidad con los dos tipos empaquetados por excelencia, MKV y MP4.

MKV permite empaquetar audio, video, subtítulos, fuentes, vamos, casi todo lo que se nos ocurra. Para empaquetar pistas necesitamos una herramienta fundamental: MKVtoolnix. Tiene frontend y viene con el paquete que os podéis bajar de MKVtoolnix.

En linux viene de serie con las distribuciones, así que teclearemos:

sudo apt-get install mkvtoolnix-gui

También existe un paquete GUI (sólo windows) que permite extraer las pistas o los datos de un MKV bastante práctico, MKVExtractGUI-2.

Para empaquetar en MP4 yo utilizo un programa bien conocido que es MP4Box, como siempre versiones de windows y linux disponibles. Forma parte del paquete gpac, por lo que para instalarlo en linux tendríamos que hacer algo así:

sudo apt-get install gpac

En windows podéis bajaros cualquier frontend que lo tenga (como YAM), o atreveros con la página del proyecto con lo que tendréis que compilar.

Y ahora a mezclar:

MP4Box -add salida.mkv#video -add salida.m4a#audio salida.mp4

ó bien

mkvmerge -o salidafinal.mkv -d 1 -A -S -T salida.mkv -a 1 -D -S -T salida.m4a

En el caso de que queramos un mkv.

(Podéis usar el programa gui para esto)

Ya hemos conseguido crear nuestro primer mp4 y mkv. Como veis es un coñazo, pero era necesario pasar por esto para después poder respirar y una vez teniendo conocimiento de lo que hay detrás hacernos la vida más fácil con las gui.

Nota: Que nadie se asuste al ver el III en el título, no se han perdido los capítulos I y II, estoy preparándolos y se refieren a la creación de archivos de subtítulos, el timeo, manejo de aegisub y karaokes. Pronto verán la luz.

*** Este manual es «live» por lo que está sujeto a cambios y actualizaciones según las necesidades. ***

Acerca de anacleto

Viajero del mundo (En clase turista)
Esta entrada fue publicada en Artículos, Taller de Fansub. Guarda el enlace permanente.

13 respuestas a Fansub III – Teoría de la codificación

  1. Mephisto32 dijo:

    Gracias por los tutos ya que estan bien explicado y de forma sencilla, a ver si me pueden hacer el favor de explicarme de igual manera (sencilla) como hago para identificar los tipos de entrelazado el soft telecine, hard telecine, hibrido (todos) ya que he investigado como hacer un animeIVTC pero lo primero que debo saber es eso el tipo de entrelazado.

    Agradeciendo de antemano

  2. barzx dijo:

    pxa pero desmadre para instalar las cosas en linux D:

    tengo ya cuatro horas con esto, pero al fin terminé

    muchas gracias por el manual, me ha sido muy util 😀

  3. Shiso dijo:

    Bueno ahora que tengo tiempo voy a aventurarme en este mundo, a ver si puedo adaptar alguno de los animes que tengo a las preferencias de mi tablet, por el momento ya tengo las 2 cañas jejeje

  4. xsifz dijo:

    genial…. muy bueno el aporte…!!
    gracias

  5. chejomolina dijo:

    genial. son el primer fansub ke veo ke se preocupa por los linuxeros. buen trabajo sigan asi

  6. Shiso dijo:

    Genial anacleto justo quería ponerme a investigar sobre esto.
    Go go linux!!!

Deja una respuesta