Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Pequeños (y molestos) pixeles alrededor de karaoke hardsub
#1
Estaba encodeando anoche un karaoke con MeGUI cuando al ver los resultados veo esto:
[Imagen: screenshot001bpw.jpg]

Esos pequeños pixeles que están en torno a los kanji (se pueden ver mas claramente en el primer kanji) ¿cómo los evito? El perfil que usé no me dá esos problemas con otros karaokes. Infiero que debo usar un filtro en el AVS, ¿pero cuál?

Summon Encoders!
Responder
#2
Igual te estás quedando corto de bitrate. De todos modos, en la captura no veo bien qué es a lo que te refieres, pero vamos, la mejor forma de saber si necesitas aplicar algún filtro o es culpa de las opciones de encode es comparar ese resultado con un encode en lossless.
¿Pero yo curraba?
El Salón de mi Casa
Responder
#3
Deh escribió:Igual te estás quedando corto de bitrate. De todos modos, en la captura no veo bien qué es a lo que te refieres, pero vamos, la mejor forma de saber si necesitas aplicar algún filtro o es culpa de las opciones de encode es comparar ese resultado con un encode en lossless.

El bitrate es de 1051kbps x264.

Despues cuelgo una captura comparativa: Raw, encode lossy y encode lossless

EDIT:

Raw:
[Imagen: raw.png]

Lossy:
[Imagen: lossy.png]

Lossless:
[Imagen: lossless.png]

Fijate bien en los Kanji, en especial donde pone "少年"
Responder
#4
¿Que diferencia hay entre el lossy y el lossless? a parte de la calidad que parece mejor en lossless.
Responder
#5
Más que de bitrate, el codec x264 debe estar mal o nulamente configurado...

Te recomiendo que en la config del codec uses:
En la pestaña "Main" >>>

***AVC Profiles >>> Usa High Profile
***AVC Level >>> Usa Unrestricted

En la pestaña "RC and ME" >>>

En el apartado M.E. >>>
***M.E. Algorithm >>> Usa SATD Exhaustive o al menos Multi Hex
***Subpixel Refinement >>> Usa 9 - RD Refinement on all frames o al menos 7 - D on all frames

En la pestaña "Advanced" >>>

Habilita todas las opciones en Macroblock Options...

Eso debería ayudarte a evitar el pixelado en los bordes de los textos sin tener que recurrir al Lossless...^^
Pero aumentará el tiempo de encodeo, espero que eso no sea demasiado problema...XD

Ja na....
Responder
#6
(06-06-2009, 06:39 AM)Drago escribió: Más que de bitrate, el codec x264 debe estar mal o nulamente configurado...

Te recomiendo que en la config del codec uses:
En la pestaña "Main" >>>

***AVC Profiles >>> Usa High Profile
***AVC Level >>> Usa Unrestricted

En la pestaña "RC and ME" >>>

En el apartado M.E. >>>
***M.E. Algorithm >>> Usa SATD Exhaustive o al menos Multi Hex
***Subpixel Refinement >>> Usa 9 - RD Refinement on all frames o al menos 7 - D on all frames

En la pestaña "Advanced" >>>

Habilita todas las opciones en Macroblock Options...

Eso debería ayudarte a evitar el pixelado en los bordes de los textos sin tener que recurrir al Lossless...^^
Pero aumentará el tiempo de encodeo, espero que eso no sea demasiado problema...XD

Ja na....

Se me olvidaba: este tema es de la semana en que se borraron muchos mensajes. En ese entonces Deh, Chak y Gilgamesh ya me aconsejaron, pero gracias por la intensión (aumenté el bitrate, usé Multi Hex y 7 - RD)
Responder
#7
(06-06-2009, 06:39 AM)Drago escribió: ***M.E. Algorithm >>> Usa SATD Exhaustive o al menos Multi Hex

Completamente inútil. Desde me esa y tesa son de esas características que sólo aumentan la cantidad de tiempo que tarda, la mejora en compresión es completamente despreciable (junto a trellis 2) a menos que compares por PSNR, pero lo que importa es cómo se ve.

Me umh es suficiente.

Otra cosa que te recomiendo es no hacer upscaling, es mejor dejarlo a 640x480, eso te está provocando pérdida de bitrate sin necesidad. Also, no sé si ya te lo dije, pero puedes aumentar el número de b-frames a 5 o 6.
[Imagen: gilgameshba5.jpg]
Responder
#8
No se que guarradas estais haciendo xD

La denominacion SATD si no recuerdo mal, era un parche aparte experimental (en las versiones normales no esta). Y no, UMH a veces no es suficiente, ESA es un modo completamente util

Y en cuanto a b-frames, 5 o 6 sigue siendo poco si no se usa b-adapt 2. Si no hay limite por hardware (no creo que lo haya a esa resolucion), lo suyo seria poner 16 b-frames, o menos pero con b-adapt 2

EDIT: ah, y el PSNR no tiene utilidad si no se compara el video original (sin filtrar, resize, ni nada) con el resultado final, asi que desactivandolo se ahorran ciclos de CPU xD
Mayor fan de Artanis :3
Responder
#9
Si útil va a ser que la diferencia sea despreciable y tarde toda la vida a diferencia de UMH, pues a mí no me parece. Y como dices, puede que UMH a veces no sea suficiente, pero las veces que es suficiente son mayoría en comparación a las veces que ESA es necesario. Cosa que pruebe qué le queda mejor a esto, I guess, pero realmente dudo que vaya a mejorar algo.

En cuanto a los b-frames, 6 con b-adapt 2 es suficiente, todo lo demás es overkill IMO, aunque hasta ahora no he tenido ninguna fuente tan hambrienta de b-frames como para usar más...

Mencioné PSNR por decir que se pueden comparar varias compresiones con el mismo filtrado pero con diferentes opciones, sin embargo, la diferencia no pasa de ser números en el caso de esas opciones en particular. Activarla sólo le sirve a alguien que esté comparando por cálculos y no por cómo lo ve, lo mismo va para SSIM.
[Imagen: gilgameshba5.jpg]
Responder


Salto de foro:


Usuarios navegando en este tema: 2 invitado(s)