[Tokugawa]

El caso es que llevo un par de semanas estudiando de manera intensiva todo lo relacionado a cómo encodear un vídeo desde un BDMV/TS/DVDiso, pero tras leer decenas de guías y tutoriales me quedan unas cuantas dudas sobre temas bastante concretos... así que las escribo por aquí para ver si algún experto sabe solucionármelas

PD: NO espero que un sólo usuario me las responda todas, pues ya sé que son muchas y que habrá quién sepa sobre unos temas y no sobre otros. Del mismo modo, si alguno tiene una opinión distinta a lo que ya se haya hablado, le animo a que dé su propia respuesta a la pregunta en cuestión: así comparamos lo que sabe cada uno y enriquecemos nuestros conocimientos (sobre todo yo, que no tengo ni idea XD).


PREGUNTAS:

1 - A la hora de desmultiplexar/demuxear el BDMV/TS/DVDiso para separar el vídeo y el audio + indexar el vídeo para poder cargarlo con el AviSynth, he visto que algunos usan el DGIndex (o el DGIndexNV / DGAVCIndex, según su tarjeta gráfica y el formato del vídeo a desmultiplexar) para el demux + index, y otros el eac3to (por línea de comandos o con ayuda de alguna interfaz gráfica como HdBrStreamExtractor) para el demux + FFmpegSource2 para el index (y carga, pues FFVideoSource() es una función para AviSynth). La pregunta es, ¿cuál os parece mejor opción? He leído a algunos que -incluso- los intercalan, usando el DGIndex para extraer el vídeo y el eac3to para extraer el audio. Otros, como el capitán Khajiit te recomiendan usar el eac3to únicamente para los BDs y utilizar otros programas para los DVD... ¿qué opináis vosotros?


2 - Relacionado con el anterior, y sólo para asegurarme: si utilizas el DGIndex/DGAVCIndex/DGIndexNV luego el vídeo tienes que cargarlo en el AviSynth mediante la función MPEG2Source() / AVCSource() / DGSource() respectivamente, ¿verdad? ¿O puedes usar cualquiera de esas funciones para cualquiera de esos index? Es que en el blog de Thesis me pareció entender que podías usar DGSource también para cargar los proyectos generados con DGAVCIndex (en vez de estar limitado a usar esa función únicamente para proyectos del DGIndexNV), pero no estoy muy seguro...


3 - Imaginemos que tenemos una pista de vídeo .h264 y una de audio .ac3, ambas metidas en un archivo-contenedor .m2t2. Si usando el eac3to por la línea de comandos pongo: "eac3to 00001.m2ts 1: video.mkv 2: audio.ac3"... ¿estaría únicamente desmultiplexando? ¿O el paso de formato .h264 a .mkv mediante eac3to se considera encodeo? Es decir, yo lo que supongo es que como el .mkv es un formato contenedor, el eac3to lo que hace es desmultiplexar el .m2t2 para sacar una pista de vídeo .h264 y una de audio .ac3 y luego meter (multiplexar) ese vídeo .h264 en un contenedor .mkv, por lo que en ningún momento hay encodeo y no se pierde calidad. Todo esto viene de que he leído que la función FFVideoSource() no carga bien los formatos de vídeo "puros" como .h264, y que es mejor pasarle un formato contenedor como .mkv... ¿es eso verdad?


4 - Por ahora hemos hablado de demux de fuentes tipo BDMV/DVDiso... pero si tengo un capítulo en MKV y otro en MP4, ambos con softsubs... ¿puedo extraerles los subtítulos con DGIndex? ¿Y con eac3to? ¿O es mejor usar otro programa para los MKV/MP4?


5 - Por lo que he leído, al desmultiplexar/demuxear el audio con DGIndex puede quedar con un cierto retraso/delay... la pregunta es, ¿siempre que desmultiplexas con DGIndex te sale escrito en el nombre del audio los ms de delay? ¿Y con el eac3to? ¿También te los escribe en el nombre del audio? ¿O al utilizar el eac3to el audio nunca queda con retraso?


6 - En este hilo he leído que para quitar el delay del audio, lo cargas en MkvMerge y lo "arreglas" con una simple modificación en Opciones (y que tienes que quitar el delay antes de cortar los cachos del audio donde se oyen los comerciales). Sin embargo, en dicha explicación se parte del hecho de que el audio está en formato .ac3 (por lo que lo mejor sería dejarlo como está y no encodearlo), pero... ¿y si está en thd? ¿Lo pasamos primero a FLAC con eac3to y después le quitamos el delay? ¿O primero el delay y luego el encode? Y sobre todo, ¿hay una manera/programa mejor para quitar ese delay del audio?


7 - Usando el x264 CLI... ¿es aconsejable poner --open-gop? Es que en este manual (sí, ya sé que las guías de mundodivx no son las mejores del mundo, pero están en español y comentan muchísimas opciones/parámetros que en otros sitios ni mencionan) simplemente pone que es una técnica de codificación para aumentar la eficiencia, y que algunos decodificadores no son compatibles... ¿eso significa que no se podrá reproducir el vídeo resultante en algunos reproductores? Sí es así la verdad es que no me interesa demasiado: al tener un ordenador potente, las opciones de encodeo que busco son las que aumentan la calidad o permiten que el vídeo se abra en más reproductores, independientemente de que al estar activadas el proceso de encodeo tarde mucho más.


8 - Una pregunta compuesta: ¿qué tipos de entrelazado no puedo desentrelazar con AnimeIVTC, cómo los reconozco (los que se solucionan con AnimeIVTC se detectan con la información que te proporciona el DGIndex, ¿éstos también?) y qué programa puedo usar para desentrelazarlos (¿tengo que aprender Yatta? Y si es así... ¿sabéis de algún tutorial decente en español?)? Y una sub-pregunta muy relacionada... es los tutoriales donde ponen como reconocer el tipo de entrelazado según la información que te da el DGIndex, siempre te pone algo como "Si DGIndex te dice que es "100% film"... ¿dónde pone eso de "100% film"? Porque en la información que te sale al dar a "Preview" de un proyecto, no veo por ningún lado lo de "100% film".


9 - Y esta ya es la última (pero la más larga de responder XD): ¿Alguien me puede poner un tutorial/explicación fácil pero extensa de lo que es el SAR/DAR/PAR y cómo influye eso a la hora de encodear? Por ejemplo, imaginemos que yo tengo un vídeo 1920x1080p (que NO i) 16:9... ¿al encodear en x264 CLI tengo que poner --sar 1:1? ¿O no hace falta/me estoy liando y el SAR no tiene nada que ver? Y eso era el caso fácil... si resulta que tengo que recortar unas bandas negras arriba y abajo con el crop y al final me queda una resolución 1920x1050... ¿qué hago? Está claro que ya no guarda la proporción 16:9, y desde luego 1050 no es divisible entre 16 (por ahí me pareció leer que eso era importante)... ¿hago un resize y lo bajo a 1280x720 (me parece un poco bestia, la verdad)? ¿O hago resize y bajo simplemente bajo el 1050 a 1040 para que se pueda divdir entre 16? ¿Tendría que poner luego --sar en el x254 CLI? ¿Y qué valores pondría en ese sar? Como podéis imaginar, con este cacao mental que tengo ya ni hablemos de los casos con resoluciones tipo 720x480p y relación 4:3... ¡¿cómo puede ser 4:3 si 720/480 = 3:2?! ¡¿Qué hago con ese tipo de vídeos?! ¿Resize, sar en x264, ambos, nada...?

[Al_eXs]

No soy un experto en ésto pero te comentaré lo que se y como me manejo yo en este tema.

1.- Para DVD uso DGIndex, el cual me extrae el audio y el archivo de índice es un .d2v que en avisynth se carga con el MPEG2Source(). Para BD suelo descargar los BDMV y los .m2ts los indexo con DGAVCIndex que igual me extrae el audio y el archivo de índice es un .dga y se carga en avisynth con AVCSource(). Eso no me ha dado ningún problema, siempre funciona muy bien. Los audios luego los paso a Flac con el eac3to, según los canales y depth del original.

2.- Según se, el DGSource si es solo para el DGIndexNV, y yo como tengo AMD pues no lo he usado nunca. Los otros 2 si es como dices.

3.-Nunca he usado el eac3to para demultiplexar el video o audio directo de un .m2ts, siempre lo hago con el DG/DGAVCIndex para los audios y los videos nunca los demultiplexo de los .m2ts, no se que ventajas tendrá pues cuando empezaba con los BD lo que hacía era un remux del m2ts a mkv para cargarlo con FFVideoSource() pero luego que encontré la dll del DGAVCIndex ya no tuve que hacer eso.

4.- Para extraer los subs de un MKV hay 2 formas, una es con el MKVExtract y otra es cargando el video y los subs en Aegisub y luego guardarlos. Para los MP4 con softsubs no se, nunca he tenido alguno con softsubs.

5.- Por lo general los audios de BD no llevan delay, aunque dependiendo de donde se haga el corte se mueven un par de frames(al menos a mi se me han movido algunos), pero eso al final lo arreglo al hacer el MKV, no tiene mucho problema. Normalmente lo hago en el capi para QC, así al hacer el capi final ya no hay que tocar nada y va bien sincronizado.

6.- El delay del audio como digo arriba con el MKVMerge se puede arreglar sin líos con otros programas, para revisarlo solo hay que cargar el MKV en Aegisub e ir frame a frame revisando que el sonido vaya conforme al video, si va mal solo hay que contar cuantos frames va mal y hacer remux corrigiendo ese delay.

7.- Nunca he usado esa opción, y no he entendido la explicación que hay en Doom9 sobre esa opción.

8.- Yo para desentrelazar uso TFM() con Tdint() y Tdecimate(), es lo que mejor resultado me ha dado y si acaso algo se ve poco mal aplico yadiff y queda bien pero tarda una eternidad. Yo trabajo mas cosas de BD que no llevan entrelazado y hace mucho que no hago eso y ya no recuerdo como cambiar los parámetros según el tipo de entrelazado que lleve :__D

9.- Cuando la fuente es DVD NTSC la máxima resolución que puede llevar es 720x480 que es 3:2 pero el contenido puede estar diseñado para que se vea a 16:9, por lo que hay 2 alternativas: hacer un resize desde avisynth para forzar a que se vea bien el video o cambiar el DAR al hacer el mux en el archivo final(la mejor opción para muchos), todo depende de gustos. Sobre lo otro, también es según gustos, algunos prefieren dejar a resoluciones estándar los videos, otros prefieren cortar las bandas negras sin importar la resolución que quede al final.


Se que es poco y no explicado extensamente pero creo que se entiende la idea.

[Kumicho]

Me parece que Al_eXs ya te ha respondido casi todo, pero
1) Al igual que Al_eXs uso DGIndex o DGAVCIndex con eac3to para convertir el audio.
2) Según sé, .d2v se carga con MPEG2Source y .dga con AVCSource. También tengo una gráfica de AMD, así que no he usado nunca DGIndexNV. Cada formato solo funciona con una función así que es fácil
3) Sí, estas demuxeando. Sí, FFMPEGSource funciona mejor con contenedores - aunque pensandolo bien, no estoy seguro de si he intentado alguna vez de abrir un formato RAW (= sin contenedor).
4) MKVExtract es para extraer subtítulos de .mkv y MP4Box de .mp4 - desconozco si eac3to puede hacerlo
5) con DGIndex seguro que te pone el delay, con eac3to nunca he demuxeado un VOB
Cuando no tiene delay, si cortes el audio y el video de forma independiente después de demuxear no puede tener el problema que describe Al_eXs (que nunca me ha pasado).
6) Personalmente creo que es mejor corregir el delay durante el muxeo (ya sea a MKV o a MP4), pero no afecta a la calidad si lo haces antes o después del encode o durante el muxeo.
Si tienes buen oído, puedes obtener el delay correcto usando MPC. Las teclas + y - modifican el delay y en "información" te sale el delay que has añadido (si el archivo aún no tiene delay, este delay es igual al delay que debes usar para muxear).
7) No. Me parece mejor especificar el GOP máximo manualmente. Así puedes garantizar que no sobrepasa cierto tamaño y evitar que tarda mucho en saltar a otro fotograma (hacer seek). No es cierto que mejora la eficacia de la compresión. El resultado es idéntico especificando el GOP máximo, suponiendo que el GOP optimo es igual o menor al que has especificado. Un GOP mayor permite mejorar la compresión, pero no poner un tope no tiene ventajas practicas.
8) Nunca he encontrado un entrelazado de origen digital que AnimeIVTC no podia desentrelazar. El porcentaje "film" sale en el archivo .d2v que DGIndex genera.
9) SAR = Sample Aspect Rate (proporción de la muestra / del video guardado), DAR = Display Aspect Rate (proporción usado para mostrar el video en pantalla), PAR = Pixel Aspect Rate (proporción de los pixeles)
El SAR por defecto es 1:1, así que no hace especificarlo a no ser que el SAR de tu video es distinto.
Si recortas bandas negras el SAR (y PAR) sigue siendo el mismo. Un video 1080p con bandas negras en realidad no está en 16:9 (1,78:1) si no en 1,85:1 o 2,35:1 o 2,40:1 (existen más formatos, pero son poco comunes)
No hace falta que la resolución de un video sea un multiple de 16, solo mejora la eficacia del compresor. Cualquier proceso que puedes hacer para evitar esto será igual o peor de lo que hace el compresor (que hace un padding con pixeles idénticos). Redimensionar empeora la calidad y la compresibilidad (eficacia). La resolución tiene que ser un número par, así que como mucho tienes que cortar 1 píxel más.
720x480 puede ser 4:3 porque el PAR es 10:11 - aunque en realidad no es 4:3 (1,33:1) si no 1,36:1 (480 / 10 x 11 = 528 y 720 / 528 = 1,36)

[Tokugawa]

Muchas gracias a los dos por las respuestas, ahora me queda todo bastante más claro Sólo hay un par de puntos que todavía no logro pillar del todo (soy un poco lento, lo sé...). Os comento:

8 - ¿En qué se diferencian AnimeIVTC y TIVTC? Por lo que sé ambas son funciones del AVISynth ¿no? (bueno, TIVTC creo que es más bien un pack de funciones, incluyendo TFM, Tdecimate...).

9 - a) Entonces, si después de hacer un crop a un vídeo de 1920x1080 (16:9) para quitarle las bandas negras me queda un vídeo de 1920x1040 (que supongo que es esa proporción de 1,85:1 que menciona Kumicho), ¿qué tengo que poner en AVIsynth y x264 CLI? Es decir, si no me equivoco antes tenía una proporción 1,78:1 (16:9) y ahora 1,85:1... ¿hay que hacer resize de alguna manera para que vuelva a tener una proporción 1,78:1? ¿O se pone --sar 1,78:1 en x264 para indicarle que es su nueva proporción? ¿O hay que hacer algo distinto/no hacer nada?

9 - b) Y un caso similar pero más complicado: En el 720x480 con PAR 10:11 y proporción 1,36:1 (casi 4:3), si recorto de nuevo unas bandas y queda en 720x440 ¿qué hago en el AVISynth/x264?

9 - c) Aparte de eso, si un vídeo tiene un PAR distinto a 1:1, significa que sus píxeles no son del todo cuadrados ¿no? ¿Se puede dejar así, o es recomendable cambiarlo a PAR 1:1 al encodear para que sus píxeles queden completamente cuadrados?

9 - d) Algo parecido, pero con DAR: si un vídeo tiene un DAR ditinto de 1:1, ¿es recomendable cambiarlo?

9 - e) Y ya la última: si yo tengo un vídeo 1920x1080p al que no le recorto nada ni le hago ningún cambio (y por tanto su SAR es 16:9 = 1,78:1)... ¿luego al encodearlo en x264 tengo que poner --sar 16:9 (pues es distinto a SAR 1:1 que dices que es por defecto)? ¿o eso estropearía/deformaría el vídeo? Es para saber exactamente para que sirve poner --sar en el x264


Siento hacer tantas preguntas, es que el tema de las resoluciones/proporciones es algo que no se suele detallar mucho en las guías de encodeo, y las pocas veces que se hace no me entero de nada...

[Kumicho]

AnimeIVTC es un script y TIVTC un plugin.
9 a) No tienes que hacer ningún resize. Tienes que dejar la resolución como está. No hace falta especificarla en la linea de comandos de x264.
9 b) El SAR no ha cambiado así que lo tienes que convertir con el mismo sar como si no hubieras cortado las bandas.
9 c) Correcto. No hay que redimensionarlo porque piedes calidad y ocupará más. Tener un PAR de 1:1 no aporta ningún beneficio.
9 d) Dudo que has visto algo con un DAR de 1:1, porque sería un vídeo cuadrado. Me parece que te has confundido con el SAR/PAR.
9 e) el DAR es 16:9. El SAR/PAR es 1:1. Si comprimes un blu-ray nunca hace falta especificar el SAR.

La formula para redimensionar correctamente el vídeo almacenado de tal forma que se ve / reproduce sin distorsión es el SAR/PAR. El AR que obtienes después de aplicar la formula es el DAR.

[aanimeX]

Quizá un poquito tarde, pero este tema sigue costando a muchos. Espero te sirva y que no te aburras con tan largo post.

1.- Para usar cualquiera de estos programas es simplemente necesario que sepas el formato de vídeo con el cual están hechos tus vídeos. Por ejemplo, siempre (o el 99% de las veces) que tengas un DVD, éste vendrá con el formato MPEG2, por tanto deberás usar DGIndex para hacer el demux, que es especial para esos casos. Si tienes un vídeo cuyo formato es AVC, entonces deberás usar DGAVCIndex para hacer el demux, que también es especial para estos casos. Recuerda que estos software separan las cadenas de audio y video, por lo que el video lo podrás trabajar casi forzosamente con avisynth y el audio con el software de tu preferencia.

Hacer uso de FFMPEG() servirá siempre que tus vídeos tengan un formato *.h264. Ahora bien, eac3to es simplemente un software que te permitirá cortar el audio en AC3 sin tener una pérdida de calidad, es decir, no hará más que un simple remuestreo con las mismas cadenas de audio pero quitando las que no quieres.

2.- Así es. Cuando uses cualquiera de esos software harás uso de avisynth. Reitero, siendo el caso de que tu DVD sea MPEG2, usarás DGIndex, por lo que en tu script de avisynth usarás MPEG2Source(). Cuando tu video tenga un formato AVC, usarás DGAVCIndex, por lo que en tu script de avisynth usarás AVCSource().

3.- Realmente no conozco muy a fondo ese software, pero si únicamente utilizas la instrucción que planteas mediante línea de comandos, no estás haciendo un encodeo, simplemente estarías cambiando la extensión de tu archivo de video. Casi como si lo hicieras manualmente.

4.- Para extraer subs utilizas otros programas. Con la paquetería de MKVToolnix puedes descargar MKVExtract o en su defecto MKVClever (o algo así). El primero te servirá para extraer pistas separadas (una por una). Mediante el segundo podrías agregar múltiples archivos y extraer tantas pistas como archivos hayas cargado; si cargaste 12 archivos de vídeo podrás extraer sus 12 pistas de subtítulos a la vez.

5.- Sí y no. Realizar el demux con DGIndex te generará un archivo de audio con el nombre: “PIDXXX_audio_delayXXXms.ac3” (las ‘X’ representan números imaginarios) siempre y cuando el audio traiga un Delay (retraso). Cuando no lo traiga no te mostrará el delay en el nombre. Pero recuerda, la ventaja de todo esto es que agregando el delay a la hora de hacer el remux, el retraso desaparece. Y hasta donde tengo entendido, eac3to también te debería de mostrar el retraso que tiene el audio, no sé si en el nombre, pero en la interfaz el programa te indica cuántos milisegundos de retraso hay.

6.-Si tu audio está en THD, deberías usar software especializado (no podría recomendarte alguno). Aun así, si tu audio no es de DVD/BD, aunque marques el delay en mkvmerge, tendrás problemas en la parte de los comerciales por obvias razones. Aquí puedes usar distintas técnicas que te funcionen. A mí cuando me sucede eso, sólo intento cortar el audio “a mano”, es decir, lo corto una y otra vez hasta que me queda sincronizado.

7.- NO. Es mejor que uses P/B frames. Si sabes un poquito más de cómo funcionan, usa IDR (lee la documentación de x264) y no tiene nada que ver con la reproducción del vídeo en el sentido en el que te lo plantean allí.

8.- Se supone que solamente hay 2 “tipos” de entrelazado, el BFF (Bottom Field First) y el TFF (Top Field First), como bien mencionas esta información te la provee DGIndex. No es necesario que uses Yatta (a menos que sean de esos casos difíciles), el 95% de las veces puedes desentrelazar con TIVTC (que es más rápido de AnimeIVTC), que para eso está diseñado. De hecho, aparte de Yatta, hay muchos otros plugins para avisynth que hacen una función similar y son menos complicados.

Recuerda el desentrelazado se realiza sólo con TFM(), el Tdecimate() es para realizar el decimado de 30 a 24fps. Si usas TFM junto con Tdeint solamente estarás cargando un doble proceso que resulta inútil.

Esa parte de 100%film era una antigua característica que traía DGIndex para indicar cuál era el sistema para el cual fue diseñado el vídeo, si para NTSC/PAL/SECAM. Cuando DGIndex marcaba el pulldown y el 100% film, significaba que tenías un archivo con sistema NTSC, cuando no lo marcana significaba que tenías un PAL.

9.- No te compliques. EL PAR/SAR/DAR son cosas que para estas épocas ya casi no se usan para realizar los encodes. Si tú tienes un vídeo con resolución 1920x1080p es completamente innecesario que marques el SAR. Te explico:

PAR: Pixel Aspect Ratio

Este marca el tamaño del pixel que se usa dentro del video en una medida de Aspect Ratio, es decir, si tú tienes un vídeo el cual su AR es 4:3, el PAR siempre será 4:3 a menos de que hagas un resize. Para no hacer un resize simplemente deberás marcar el tamaño de la muestra, es decir el SAR, para que el video se proyecte en su resolución original, es decir, que tenga el DAR correcto.

SAR: Sample Aspect Ratio

Como lo menciono arriba, esto es el tamaño de la muestra. Bajo este comando es que el reproductor reconocerá el tamaño en el que se deberá proyectar el video, es decir, lo proyectará con el DAR correcto.

Para los casos:

NTSC AR 16:9 = SAR 32:27 (DAR 1.185)
NTSC AR 16:9 = SAR 11:9 (DAR 1.778 )
NTSC AR 4:3 = 10:11
PAL AR 4:3 = 5:4

Esto es más complicado de lo que yo te planteo aquí, para que no te metas en problemas te recomiendo usar un programa que calcule el SAR y así te evitas muchos dolores de cabeza. Aquí simplemente te planteo los escenarios más comunes.


DAR: Display Aspect Ratio

Marca el “tamaño” en el que se proyectará el vídeo en la pantalla.

Cambiando de tema, es mejor que si haces crop, dejes como está el vídeo, porque al hacer un resize estás modificando el PAR, lo que afecta en el bitstream de los pixeles. Sólo es una recomendación, tú tomarás la mejor decisión.


8.1.- AnimeIVTC y TIVTC se diferencian en los filtros y funciones que usa cada uno para su proceso, si bien ambos son bastante similares, TIVTC es más rápido. Según mi experiencia, está mejor adaptado a las circunstancias.

9.1.- No es necesario usar el SAR. Si así lo deseas haz un resize para que quede a la resolución que quieres o déjalo como tal. Recuerda que el resize afecta el PAR y que la proporción no cambia.

9.2.- Lo dicho en la anterior: no se usa SAR. La relación aspecto no cambia. Reitero que si así lo deseas sólo haz un resize con avisynth.

9.3.- No es recomendable cambiar el PAR a 1:1, pero puedes intentar y si te gusta el resultado, pues bien.

9.4.- EL SAR sirve para indicar cuándo un video es anamórfico. Para dicho caso, no es necesario aplicar el SAR en el CLI. El SAR únicamente lo aplicarás cuando tengas un DVD anamórfico. Para el caso de los BD/TS/otras, no es necesario.

Saludos.

[Tokugawa]

Muchas gracias por seguir respondiendo: es justo repitiendo una y otra vez lo mismo como mejor se aprende sobre ello (o al menos yo suelo necesitar leer varios puntos de vista para que me quede completamente claro). Bueno, yo creo que ya casi he entendido lo de la relación de aspecto XD


Por lo que habéis ido diciendo, entiendo que los DAR más usados suelen ser 4:3 ó 16:9 (y que varía según si el vídeo está preparado para reproducirse en un tipo de pantalla o en otra -> los televisores y monitores de ordenador más modernos creo que tienen todos ya una proporción 16:9 o parecida). El SAR entiendo que es simplemente el tamaño (en píxeles) del ancho x alto de cada frame (fotograma) del vídeo, y que el PAR es el alto x ancho de cada píxel... y que siempre se ha de cumplir SAR x PAR = DAR.

Espero ir bien hasta aquí Imaginemos entonces que tenemos un vídeo con un DAR = 16:9 = 1,778, con una resolución de 1920x1080 (es decir, un SAR = 1920/1080 = 1,778.). Dado que tanto el DAR como el SAR son 1,778, deducimos que el PAR es 1:1 y que por tanto los píxeles son completamente cuadrados. Ahora bien, imaginemos que el vídeo...

a) TIENE bandas negras arriba y abajo. Al recortarlas la resolución vertical disminuiría y lo lógico sería pensar que como el SAR resulta modificado (es decir, si de 1920x1080 pasa -por ejemplo- a 1920x1040 el SAR = 1920 / 1040 = 1,85) habría que modificar algo para que se siga cumpliendo lo de SAR x PAR = DAR... sin embargo, por lo que comentó Kumicho, los vídeos con bandas negras no tienen un DAR de 1,78, si no de 1,85 (u otro valor, dijiste que había varios posibles), por lo que después de recortar las bandas negras se sigue cumpliendo SAR x PAR = DAR (tanto SAR como DAR serían 1,85, así que el PAR seguiría siendo 1:1) y (como todos me habéis dicho) no hay que tocar nada más... ¿el razonamiento es bueno?

b) NO TIENE bandas negras, pero me da el capricho de recortarlo porque sí. Si al 1920x1080 le quiero recortar una parte del video hasta dejarlo en 1920x1024 (por ejemplo), sé que tengo que poner una función crop en el script de AVISynth, pero... ¿tendría que poner algo más en el script de AVISynth y/o el de x264? Tengamos en cuenta que es solo recortar (crop), no hago ningún resize. Considero que como el SAR cambia, habría que cambiar también el DAR o el PAR para que se siga cumpliendo la fórmula/condición, ¿no?

c) NO TIENE bandas negras, pero me apetece hacerle un resize hasta dejarlo en 840x640 (esta vez no hago ningún crop, sólo resize). Nuevamente, sé que tengo que poner el resize en el script de AVISynth, pero ¿tengo que hacer algo más en el AVISynth o x264? Parece evidente que el SAR ha cambiado (del 1,78 de antes a SAR = 840/640 = 1,31...), y que por tanto habría que hacer algo para que se siga cumpliendo la fórmula... pero por las palabras de aanimeX me ha parecido entender que la función resize también afecta al PAR, de manera que el AVISynth al modificar el SAR (por cambiar la resolución del vídeo de 1920x1080 a 840x640) también modifica automáticamente el PAR para que se siga cumpliendo la regla... ¿es eso cierto? Si es así supongo que no haría falta tocar nada más, ¿verdad? (es decir, poner sólo el resize en el script de AVISynth y ya, ¿no?).



Bueno, y esas ya son las últimas dudas que me faltan por aclarar en relación a ese tema Sin embargo, mientras estudiaba el asunto me han surgido dos interrogantes más:

10) Antes he comentado que me parece que todos los televisores/monitores modernos tienen ya una proporción de 16:9 o parecida... si tengo un vídeo con un DAR 4:3, ¿es recomendable cambiarlo a DAR 16:9 para que se vea mejor? ¿O así sólo conseguiré que se vea peor?

11) Si al muxear un vídeo le pongo dos pistas de audio (una en japonés y otra en español, por ejemplo), ¿cómo pongo que al abrir el vídeo se abra siempre con el audio en japonés por defecto? (aunque luego el espectador pueda ya cambiarlo a audio en español si quiere).

[aanimeX]

Veamos como ejemplo resoluciones:

Si tú tienes un vídeo con una resolución 640x480, significa que el SAR es 640x480 ó 4:3 y que el PAR es 1:1. Aquí sí aplica el PAR 1:1 debido a que los pixeles son totalmente cuadrados, pero es muy poco probable que encuentres algo similar a esto. Regularmente los pixeles más cercanos a pixeles cuadrados son los que encuentras en un video con una resolución de NTSC 720x480 y con un AR 4:3 ó de un PAL con AR 4:3 y resolución de 720x576.

Recuerda que el SAR es el tamaño de la muestra, este solamente definirá el AR y la resolución en la que se proyecta el vídeo en pantalla. Es un poco más que complicado y para las dudas que planteas es completamente innecesario que uses esto para hacer compresiones.

Y respondiendo a tus incisos:

a) Tu razonamiento es bueno en cuanto a que no deberías de tocar nada más. Al cambiar la resolución del video haciendo un crop recortando las rayas negras que mencionas, lo único que cambia es eso, la resolución, bajo ninguna circunstancia se modifica el PAR/DAR/SAR, por eso te hice la recomendación de dejar la resolución como saliera sin modificar nada más.

b) Aquí te reitero que al hacer crop lo único que cambia es la resolución. Cuando recortas las bandas negras de un vídeo en tu script de avisynth usas crop, por ejemplo: si tu video tiene una resolución de 1920x1080 y después de hacer crop te da como resultado 1920x1040, el PAR/SAR/DAR no cambia, lo único que ha cambiado es la resolución. Yo te recomendaría que no lo cambies pero tú tomarás la mejor decisión. Puedes hacer un resize para volver a dejarlo a 1920x1080, pero en este caso ya cambia el PAR/SAR/DAR, pero aún así no deberás agregar nada más cuando uses x264.

c) Sí, sólo tendrás que hacer un resize. La regla quizá ya no se cumpla porque estás modificando el PAR/SAR/DAR, pero no es necesario que agregues nada más ni en avisynth ni en x264.

10.- No es recomendable. Imagina que tienes una fotografía algo cuadrada (4:3) y que la estiras por ambos lados hasta que te quede muy alargada (16:9).

11.- Si lo haces mediante MKVMerge, sólo coloca las pistas en el orden en el que quieres que se reproduzca.

-Video
-Audio japonés
-Audio otro

Si esto no te funciona, márcala como “Default track flag: yes”

Para finalizar, recuerda que al recortar un video sólo modificas la resolución. Al hacer un resize sí modificas el tamaño de la muestra, del pixel y de la proyección.

Saludos.

[Al_eXs]

10.- Siempre es mejor dejar el original, así no se deforma la imagen, ya que si lo cambias a que se vea con un DAR diferente al que fue diseñado se va a ver mal.

11.- En el MKVMerge al añadir las pistas puedes seleccionar las opciones de cada una, por ejemplo el Idioma, Flag de pista predefinida(Sí para la que quieres por defecto, no para todas las demás), Flag de pista forzada(mas usada para los subs).

[Kumicho]

a) correcto. Una de los AR más comunes es 2,35:1 (formato de cine)
b) para Avisynth TODOS los vídeos tienen un PAR 1:1 - o sea que no hay forma de especificarlo
c) como Avisynth no trabaja con un PAR distinto a 1:1, tienes que calcular y especificar el SAR. Si usas Matroska sería más fácil especificar el DAR

10) no, porque es poco probable que lo harás igual o mejor que una solución por hardware - ademas de que muchos usuarios prefieren ver el vídeo sin distorsionar.
11) te recomiendo no poner ninguno por defecto, porque así la configuración del reproductor manda, pero puedes especificar la pista por defecto en la linea de comandos (tanto en mp4box como mkvmerge)