Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Hi10P / 10-bit animu
#31
(08-30-2011, 04:33 PM)Reaper45 escribió: P.D.: Me gusta el olor del flame por la tarde.

Esto Tongue. Ahora daré mi opinión de cada punto al respecto del tema.

- 5-15% más de requisitos mínimos para decodificar.
Si sacas una versión en 480p (altamente recomendable) o un XviD (opcional), este punto da lo mismo porque simplemente rediriges al leecher que no podía reproducir el 720p al 480p. En caso de no ser así y ser el 720p tu único release, es desaconsejable porque un 2-5% de personas que a penas podían reproducir tu releases ahora ya no podrán y los estas mandando al diablo. También esta contra se invalida si sacas un release 8bits aparte (cosa que varios guiris hacen, pero los hispanos son muy flojos para ello por lo general). De todas formas la diferencia de potencia es algo reducida ahora, y de hecho con el paso de los meses o un año la diferencia va a ser casi mínima.

- Aceleración por tarjeta gráfica.
Este punto únicamente lo voy a considerar para 1080p, dado que en 720p generalmente quien tiene un GPU compatible para esta aceleración también tiene un CPU que se puede cualquier 720p sin problemas. (Y siempre está CoreAVC para las cafeteras cuando salga el CoreAVC 3 en unos meses más). Pero en 1080p hay gente que no puede reproducirlo si no es por aceleración mediante tarjeta gráfica, y la verdad es un punto importante a considerar para estos releases.

- Bugs y alteración en el croma.
Es una realidad, hay un bug que causa una alteración en el croma en el perfil de Hi10p en x264, sin embargo un buen encoder guiri (que todavía no publica en Hi10p dado los inconvenientes que aún hay) me dijo que basta con modificar algunas opciones (hasta en el MEGuI se podía hasta donde recuerdo) en la codificación para resolver este bug, sin embargo no me acuerdo muy bien de los detalles dado que yo no realizo de manera usual compresión. =/. De todas formas los bugs en Hi10p son mínimos y de hecho también se andan arreglando ahora.

- Tiempo de compresión.
Yo con lo que he escuchado ya de parte de como 5 encoders, el tiempo agregado en la compresión va del 10 a 60% aproximadamente, parece que dependía sobretodo del filtrado y demás utilizado. De todas formas todo encoder es libre de decidir si quiere usar o no ese tiempo extra encodeando, no puedo decir que sea un real punto en contra aparte de atentar contra la flojera o prisa de algunos. De todas formas el tiempo se compensa un poco con la reducción del peso y por lo mismo una subida más rápida.

- Playback.
CCCP es una mugre, y de hecho a quien dijo que no podía reproducir por aceleración gráfica en CCCP, lo que tiene que hacer es desactivarlo e intentar reproducir de esa manera con los codecs internos del MPC-HC. El K-Lite ofrece algo un poco más decente, pero nada recomendable igual por el momento. Sin embargo los usuarios de smplayer y kplayer2 no tienen ningún problema. Pero no me parece del todo recomendable sacar al menos en este instante sin estar todavía disponible el CoreAVC 3 a lo menos (o al menos, una versión mejor de CCCP, que la última me causo unos desastres de lo lindo que tuve que limpiar a mano). El MadVR ya está y es ideal, pero lamentablemente el leecher promedio no entiende cómo instalarlo y demás.

- Reducción del peso entre 10% a 50%.
Una ventaja asombrosa que permite el Hi10p, actualmente el perfil tiene un desempeño bastante superior en el manejo del bitrate y también en el combate contra las imperfecciones producidas al comprimir, la diferencia de calidad es mínima con su contraparte en 8bits si mantenemos un bitrate muy alto, pero cuando reducimos el bitrate la diferencia es notable, haciendo que Hi10p tenga un manejo superior de la compresión y por lo mismo hacer posible la reducción entre 10% a 50% alterando minimamente la calidad.

- Hurr, Hurr, la fuente no es 10bits.
Eso da lo mismo, el perfil de Hi10p es de por sí más eficiente en el manejo de la compresión, claro que ante una fuente 10bits es mejor aun, que de hecho ya hay discusiones en USA y Japón para cambiar el estándar a este (dado que varios estudios han demostrado que el costo de trasmisión se reduce ampliamente). Pero por mientras igual se puede disfrutar del beneficio. En cuanto los monitores, las antiguas cafeteras CRT pueden reproducirlo (lol). Pero los LCD, recién el 10-25% aprox. de los nuevos en el mercado pueden reproducirlo, sin embargo ya de hace tiempo que varios monitores soportan un espectro más amplio que 8bits, pero eran unas combinaciones híbridas y blah, igual la diferencia se nota un poco. Pero quien tenga monitor o CRT compatible con 10bits, verá indiscutiblemente una mejora amplia si la codificación fue adecuada (inversión a futuro).

- Mi recomendación.
Personalmente me parece una terrible idea el solo sacar en Hi10p por el momento, ¿por qué? Por problemas de compatibilidad y porque los encoders son muy novatos todavía con este nuevo formato, y los estándares y decoders recién andan en versiones beta todavía. También me parece desaconsejable sacar cualquier tipo de 1080p Hi10p mientras no este adecuadamente adaptada la aceleración por tarjeta gráfica.

Lo más recomendable hoy en día es sacar un release Hi10p, y su contraparte directa 8bits, así también la gente tiene la oportunidad de comparar ellos mismos, ofreces el soporte completo y las opciones y preferencias para todos, pero sé que por flojera o problemas de distribución no es siempre posible. Tal vez recién el año siguente sea buena idea comenzar a sacar con exclusividad en Hi10p, pero por ahora es un "poco" bastante apresurado. (Pero a la vez, sacar un Hi10p aparte opcional es una inversión a futuro si se codifico adecuadamente, dado que de aquí a 1 año y tanto, tendrá un soporte completo).

Nota: Con el error ese del croma, y en general otros bugs menores, sino se codifica bien; te quedará una mugre en lo que respecta a un buen estándar de codificación. Solo puedes codificar en Hi10p por ahora si sabes lo que haces, pero por lo general: casi ningún encoder sabe lo que está haciendo, y por tanto la respuesta general será: No, mala idea.

Nota 2: A mí por lo personal me da lo mismo, aunque tengo una cafetera de PC, puedo reproducir 720p Hi10p igual, pero a la vez no me importa el peso extra de un archivo, así que me da un poco lo mismo. xDD

Nota 3: No soy una experta en todo caso, solo he averiguado estos meses al respecto xDU, cualquier dato o cosas así en las que me haya equivocado las investigaré más y corregiré ASAP, xD.
Se supone que tendré firma algún día.
Responder
#32
Bien entonces, como última palabra sólo decirte que estás equivocado y no te has enterado de nada.

Los decoders actuales funcionan mal y cuando los arreglen todo lo que se ha encodeado hasta de ahora tendrá los colores jodidos. Si ahora lo ves bien es porque tanto x264 como los decoders tienen el mismo bug (ambos tienen el swscale jodido) y se cancelan mutuamente. Te hago un croquis a ver qué tal:

x264 jodido + decoder jodido = Visualización correcta en encodes anteriores.
x264 arreglado + decoder jodido = Ni idea.
x264 jodido + decoder arreglado = Visualización incorrecta en encodes anteriores.

Buenas noches dulce princesa, yo también me retiro.
[Imagen: h0FIGlU.png]
Responder
#33
No, veo que tú a mí no me has entendido.

Unicamente estoy diciendo que actualmente dudo que las versiones de ffdshow actualizen hasta que el problema este subsanado, así que de momento no hay problema.

El único error que en mi caso he cometido, es no haber sacado dos versiones (la primera release de los 10bits no tiene ni dos días de diferencia tras empezar a aperecer el susodicho bug, por lo que lo tenía bastante complicado como para estar al tanto del problema). ¿Qué hacer de aquí a un futuro?, pues esperar a ver como avanza todo y ver que se hace, si se recomprimen los capítulos con las versiones nuevas a que vayan saliendo o que.

Nos hemos arriesgado, en este caso no ha salido del todo perfecto, bueno, es lo que tiene seguir fansubeando e intentar probar cosas nuevas, Wink
[Imagen: kyufail.png]
Responder
#34
[Imagen: dhalsi11.gif]

Si no lo ponía, reventaba (lo siento, la próxima vez a lo mejor tenéis suerte).
[Imagen: etf7ll.gif][Imagen: k4z9sw.jpg]
Responder
#35
(08-31-2011, 07:11 PM)Orestes escribió: http://screenshotcomparison.com/comparison/77428
http://screenshotcomparison.com/comparison/77441

LOL

Si crees que eso es debido al chroma desplazado por 1 o 2, apaga y vámonos.

Eso es que está usando un colormatrix equivocado. MadVR usa Rec.709 para HD MPEG-4, lo cual está bien, y tu CCCP usa Rec.601 por alguna razón que desconozco. FFDshow usa Rec.709 para ancho > 1024 y alto >= 600, y rec.601 para ancho <= 1024 y alto < 600, y lo verás así siempre que no le dejes al renderer hacer conversión de color al pasar a rgb o que lo especifiques tú mismo en las opciones. Que yo sepa solo el renderer de Haali no lo hace.
O quizá sea problema al crear la captura. El renderer de Haali las saca como le da la gana.

Carga la imagen del CCCP en avisynth con:
Código:
ffimagesource("CCCP.png",colorspace="yv12")
converttorgb32(matrix="rec709")
Y automágicamente obtienes la imagen del MadVR.

De la misma manera, carga la imagen del MadVR con:
Código:
ffimagesource("MadVR.png",colorspace="yv12")
colormatrix(mode="rec.601->rec.709")
Y automágicamente obtienes la imagen del CCCP.

Sí, hay un bug, pero de un puto valor de croma en una escala de 1024. Una gilipollez que incluso cuesta de ver en la comparación de EvilSefirot, que si bien lo van a arreglar, va a ser únicamente para cumplir las especificaciones del ITU-R BT.709 y seguir un estándar. ¿De verdad crees que si fuese un error tan gordo de colores como pensabas, no lo habrían arreglado en 1 mes desde que se comentó por primera vez?

Creo que alguien debería aprender más antes de dárselas de listillo y crearse pedestales.
http://forum.doom9.org/showthread.php?t=133982
http://avisynth.org/mediawiki/Color_conversions

¿Zas en toda la boca?

Por lo demás, paso de comentar en un hilo creado expresamente para flamear, manipulado por su creador y orientado como a él le da la gana.

EDIT: A mí me va igual de rápido encodeando 10 u 8 bits. Y si va algo más lento, es tan poca cosa que ni me he dado cuenta.
[Imagen: Necrontyr.png]
Responder
#36
http://forums.bakabt.me/index.php?topic=...msg4659283

Cita:All in all, this is mainly a concern from a technical accuracy standpoint. In most cases, it would be really hard to notice without direct comparison, unless your video is very dark. The resulting error results in RED, GREEN, and/or BLUE 8bit values +/- 1 across the entire luminance range. This basically means the problem becomes more significant the closer you get to black, but it somewhat balances out with our reduced visual sensitivity near-black and the limitations of lower-end LCD's ability to accurately reproduce the difference between say 13-10-16 (8bit source video) and 14-10-17 (madVR/mplayer2) or 13-11-16 (ffdshow/lav video).

254-254-254 = up to ~0.4% hue shift
127-127-127 = up to ~0.8% hue shift
64-64-64 = up to ~1.5% hue shift
32-32-32 = up to ~3.1% hue shift
16-16-16 = up to ~6.3% hue shift
8-8-8 = up to ~12.5% hue shift
4-4-4 = up to ~25% hue shift
2-2-2 = up to ~50% hue shift
1-1-1 = up to ~100% hue shift

If you are making lossless encodes (-qp 0) or Blu-ray rips with a bitrate meant to be transparent, this may be something you care about. When encoding TV sources at lower bitrates, you probably shouldn't care.

Di por sentado que mi CCCP tiene el espacio de color correcto porque con cualquier otra release lo presenta bien, culpa mía. Mañana volveré a hacer las capturas que probablemente y como dices estén mal. De todas formas no se me van a caer los anillos por reconocer que las he hecho mal. El impacto de todo este rollo ya se verá pero seguirá dejando mácula en los asombrosos encodes a 10-bit que están saliendo como churros.

A ver si es verdad y no haces como Sefi que dice tres o cuatro veces que se larga en cada hilo. No quiero decir que no vuelvas a postear, sólo que es un poco absurdo.
[Imagen: h0FIGlU.png]
Responder
#37
Una última cosa Orestes.
Cuando saques capturas comprueba que lo estas haciendo bien. Es decir, si las de madVR las estas pegando en el Photoshop CS5, asegurate en que rango de color estas creando el proyecto, no sea que te puede haber pasado (intencionadamente o no, ahí ya no me meto)
Si no estas haciendo esto, también asegurate de que el Output no es el Haali Renderer ya que saca unas capturas mas apagadas. Usa el EVR, (obviamente me refiero al sacar capturas con el MPC) Wink

Capturas del capítulo 01 de Dantalian no Shoka de inshuheki, usando el MPC y tomando capturas para los dos casos con Snagit (debido a la imposibilidad de sacar capturas de madVR con MPC)
http://screenshotcomparison.com/comparison/77466

Se sigue viendo el problema del chroma, pero claro, como es en verdad, no con la trolleada que te has marcado.

Hasta mañana, mi querido troll.

PD "Siempre tengo razón", va a ser que esta vez has fallado.
[Imagen: kyufail.png]
Responder
#38
https://github.com/DarkShikari/x264-deve...d4577bd556
[Imagen: Necrontyr.png]
Responder
#39
(08-31-2011, 11:37 PM)Evil Sefirot escribió: PD "Siempre tengo razón", va a ser que esta vez has fallado.

Me he equivocado con las capturas, ya lo he dicho antes pero si quieres te lo confirmo otra vez. El hilo lo he abierto yo y en el primer mensaje tienes mi opinión sobre el tema que obviamente después de que se actualicen encode y decode no tendrá demasiado sentido. En cualquier caso habrá sido un mes largo de risas gracias a los encodefags y sus locos seguidores. Sujétate fuerte al hilo de que haya sacado mal las capturas, con un poco de suerte igual sacas petróleo. De todas formas las diferencias entre las dos capturas que has puesto son más que obvias y no se puede negar que el fallo esté ahí y sea importante, sobre todo para esa gente que se dedica a hacer encodes "perfectos" de blurays y otras fuentes.

La crítica de este hilo iba para los encodefags que tienen razón en absolutamente todo lo que dicen y que las cosas son más o menos importantes según les apetezca y de una forma totalmente arbitraria. También iba para aquellos que se suben como descerebrados al carro de lo más nuevo y "más mejor" guiados por sus gurús de pacotilla.

Si no te importa una mierda cómo salgan tus encodes entonces ya no tengo nada que objetar aunque siguen resultándome curiosos los altibajos que tienen tus mensajes tratando del tema. Desde la más completa indignación hasta la más absoluta desidia que te hace saltar por el más mínimo comentario.

Ha sido divertido y tal.
[Imagen: h0FIGlU.png]
Responder
#40
Orestes escribió:[Imagen: flame_dragon.jpg]

Por lo demás estoy de acuerdo con él.
Se supone que tendré firma algún día.
Responder


Salto de foro:


Usuarios navegando en este tema: 2 invitado(s)