Iniciación al ripeo
-
- [FrOnkY]
- Mensajes: 1962
- Registrado: Jue 10 Dic, 2009 16:47
- Ubicación: EntreCorchetes
Re: Iniciación al ripeo
... &, a ser posible, enchúfale un SAR menos awevao
(pozíp k zuavisa er montluito, zíp)
(pozíp k zuavisa er montluito, zíp)
![Imagen](http://i.imgur.com/i6ArvV3.png)
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
Bastante efectivo ese filtrado. Es cierto que se pierde algo de detalle (por ejemplo difumina la textura de la ropa), pero es bastante poco teniendo en cuenta que elimina por completo ese ruido/artefactos tan feo que tiene la fuente.
Aunque... ¿tus capturas son solamente filtrado o filtrado y ripeo? Eso cambiaría mi apreciación de asunto, porque si son tras el ripeo las texturas podrían estar perdiéndose por falta de bitrate en la versión filtrada. Tiene mucho sentido que quitar artefactos deba ir acompañado de una bajada de CRF para no perder detalle. Pero si son sólo filtrado, se podría probar reducir la intensidad del filtro.
Aunque... ¿tus capturas son solamente filtrado o filtrado y ripeo? Eso cambiaría mi apreciación de asunto, porque si son tras el ripeo las texturas podrían estar perdiéndose por falta de bitrate en la versión filtrada. Tiene mucho sentido que quitar artefactos deba ir acompañado de una bajada de CRF para no perder detalle. Pero si son sólo filtrado, se podría probar reducir la intensidad del filtro.
-
- Mensajes: 256
- Registrado: Mié 12 Nov, 2003 01:00
- Ubicación: En una galaxia lejana, muy lejana....
Re: Iniciación al ripeo
Hola Dardo... Ayer por la noche le metí por fin lo que es el proceso de ripeo bajo este mandato arx264 que te pongo:Dardo escribió:![]()
![]()
Como penúltima recomendación, ya que siempre aparecerá algo, utiliza un CRF más bajo a 21, ya que una vez quitados artefactos tienes una fuente que ya te permite ripear a CRF que te aseguran más calidad y sin irte a un tamaño excesivo. Prueba con CRF=19, el bitrate te subirá en torno a un 16-18% y quedará más redondo, I think![]()
Código: Seleccionar todo
"C:\x264\x264.exe" --preset slow --tune film --crf 18.50 --level 4.1 --output "g:\MiPeli.mkv" "D:\Ripeos\02 MKVs\Mi_Script.avs" --no-fast-pskip --psy-rd 1.0:0.15 --sar 12:11
Bueno... me estaba planteando ponerle una especie de Intro de Video al estilo Twenty Century Fox, pero que ponga Producciones Alekhine... ¿quien sabe?, lo mismo doy el petardazo.Dardo escribió: P : Una vez hecho , lo grabas en un DVD y lo dejas en el buzón de alguna editora española, el viernes lo tenemos a la venta como Remastered Edition a 25€.
![Riendo :lol:](./images/smilies/icon_lol.gif)
lo dices por usar el 12/11 ¿¿...y que otra alternativa de SAR tengo...?? ¿....el aPePinao 16/15??fronky escribió:... &, a ser posible, enchúfale un SAR menos awevao
(pozíp k zuavisa er montluito, zíp)
![Riendo (:-)](./images/smilies/icono_meparto.gif)
Sinceramente, a mí me parece que 16/15 estrechaba aun mas las cabezas.
Gomorrite escribió:Bastante efectivo ese filtrado. Es cierto que se pierde algo de detalle (por ejemplo difumina la textura de la ropa), pero es bastante poco teniendo en cuenta que elimina por completo ese ruido/artefactos tan feo que tiene la fuente.
Yo lo veo un script cojonudo...en verdad la fuente era muy mala (¡¡y anda que me cobraron "poco" por el DVd por el que encima tuve que abonar los gastos de envío desde la Germany de la Merkel!!), pero si lo dices por el fondo ese difuminado donde está la niña o la madre, es que es así... no se puede hacer más ahí. No obstante, los rostros en la fuente original tiene en verdad mogollon de pigmentitos y que supongo será lo que vosotros denomináis "ruido" o "artefactos"... ruido que desaparece de fábula con TheMonster como puede verse.
Sí en efecto, las capturas son SOLO filtrado; es decir, sacadas con VDM tras cargar éste con el script AVS preparado para el ripeo y en el que obviamente se encuentra TheMonster. En cuanto a la bajada de CRF, observé que en la prueba previa dodne solo ripeaba 7409 frames, el bitrate y el tamaño final bajaba considerablemnte... así que aposté por una Rebaja de Primavera en CRF.Gomorrite escribió: Aunque... ¿tus capturas son solamente filtrado o filtrado y ripeo? Eso cambiaría mi apreciación de asunto, porque si son tras el ripeo las texturas podrían estar perdiéndose por falta de bitrate en la versión filtrada. Tiene mucho sentido que quitar artefactos deba ir acompañado de una bajada de CRF para no perder detalle. Pero si son sólo filtrado, se podría probar reducir la intensidad del filtro.
¿No obstante cuánto y como habría que cambiar?
En cuantito lo tenga acabado, os diré algo y os pondré unas capturillas; aunque como ya dije, repetire probando con --preset veryslow.
Gracias a todos....
En Ajedrez gana el que comete el penultimo error.
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
No me refiero a los fondos, sino a las texturas de la ropa que se difuminan muy ligeramente. Pero bueno, será que tengo el ojo demasiado adiestrado, realmente es poquísima la pérdida. Está bien como está, atina el CRF y creo ya lo tienes hecho.
"--preset veryslow" no creo que tarde mucho más (proporcionalmente a lo que ya tarda), ten en cuenta que probablemente es todo ese filtrado lo que se hace que tarde tanto, no la codificación en sí. No esperes una gran reducción en el tamaño, pero igual un 5% o así sí.
"--preset veryslow" no creo que tarde mucho más (proporcionalmente a lo que ya tarda), ten en cuenta que probablemente es todo ese filtrado lo que se hace que tarde tanto, no la codificación en sí. No esperes una gran reducción en el tamaño, pero igual un 5% o así sí.
-
- Mensajes: 1960
- Registrado: Lun 27 Feb, 2012 14:16
Re: Iniciación al ripeo
Pues si ha quedado limpita la cosa, estos Denoisers hacen milagros
, teniendo en cuanta el desastre de ruido en chroma y luma que presenta la imagen con el veryslow y la bajada del CRF debería de quedar mas que aceptable.
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
-
- [FrOnkY]
- Mensajes: 1962
- Registrado: Jue 10 Dic, 2009 16:47
- Ubicación: EntreCorchetes
Re: Iniciación al ripeo
Nop, por esto...Alekhine escribió:lo dices por usar el 12/11 ¿¿...y que otra alternativa de SAR tengo...?? ¿....el aPePinao 16/15??fronky escribió:... &, a ser posible, enchúfale un SAR menos awevao
(pozíp k zuavisa er montluito, zíp)![]()
![Imagen](http://img42.imageshack.us/img42/2047/akxv.png)
... y tu última prueba...
![Imagen](http://img62.imageshack.us/img62/6637/vix5.png)
Algo no cuadra (el soft capturerop?)
![Imagen](http://i.imgur.com/i6ArvV3.png)
-
- Polemista nato
- Mensajes: 5679
- Registrado: Dom 17 Jul, 2005 02:00
- Ubicación: Al final del río
Re: Iniciación al ripeo
Como bien indica Gomorrite, cuando el filtrado requiere tantos recursos, el preset no suele ser el factor más limitante (en el tiempo empleado) al hacer el ripeo, sino que es el script el "cuello de botella" del proceso.
En todo caso, tampoco quiero ponerme especialmente talibán con el preset veryslow. Slower está bastante bien y slow no está mal. Si ripeas con crf, básicamente vas a obtener más o menos la misma calidad con algo más de bitrate al hacer un ripeo "más rápido".
Con respecto al crf, cada unidad de diferencia en el crf hace variar ~ un 20% el tamaño respecto a la referencia. Así, si a crf 21.0 te vas a los 1000 kbps, a crf 19.0 deberías irte en torno a 1350-1400, aproximadamente (y aún así el QF en este caso sería bajo). Puedes irte hasta 18.5 o 18.0 casi con los ojos cerrados en casos donde empleas tan poco bitrate sin demasiado temor de estar "sobrerripeando" (en todo caso, estarías por debajo de 1600 kbps y en torno a un QF de 0.160).
Por lo demás, con este filtrado está claro que pierdes detalle, "fidelidad" al original (en este caso el original era una mierda pinchada en un palo, más o menos
), aunque en este caso para mejorarlo. En todo caso, deberías intentar asegurarte, en mi opinión, que el "detalle" que pierdes es por "culpa" del filtrado (que te ayuda en otras cosas) y no por el bitrate/CRF elegido. Más aún a favor de bajar el crf, incluso podrías probar hasta llegar a 17.
Yo con este tipo de fuentes no me peleo siquiera
, todo sea dicho.
Por lo que respecta a las capturas, al aplicar --sar, deberías hacerlas con el VirtualDubMOD con el siguiente script:
Ya puestos, indicar que --psy-rd 1.0:0.15 es redundante con --tune film, ya que el uso de --tune film ya implica --psy-rd 1.0:0.15. En todo caso, no te afecta negativamente al ripeo en modo alguno.
Por el contrario, si empleases --tune grain, lo de --psy-rd 1.0:0.15 sí te alteraría la codificación, pues en --tune grain tenemos --psy-rd 1.00:0.25 ( http://superuser.com/questions/564402/e ... -x264-tune ).
De todas formas, en el caso que nos ocupa --tune grain entiendo que no tendría ningún sentido, pues la fuente no se caracteriza precisamente por su grano.
En todo caso, tampoco quiero ponerme especialmente talibán con el preset veryslow. Slower está bastante bien y slow no está mal. Si ripeas con crf, básicamente vas a obtener más o menos la misma calidad con algo más de bitrate al hacer un ripeo "más rápido".
Con respecto al crf, cada unidad de diferencia en el crf hace variar ~ un 20% el tamaño respecto a la referencia. Así, si a crf 21.0 te vas a los 1000 kbps, a crf 19.0 deberías irte en torno a 1350-1400, aproximadamente (y aún así el QF en este caso sería bajo). Puedes irte hasta 18.5 o 18.0 casi con los ojos cerrados en casos donde empleas tan poco bitrate sin demasiado temor de estar "sobrerripeando" (en todo caso, estarías por debajo de 1600 kbps y en torno a un QF de 0.160).
Por lo demás, con este filtrado está claro que pierdes detalle, "fidelidad" al original (en este caso el original era una mierda pinchada en un palo, más o menos
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Yo con este tipo de fuentes no me peleo siquiera
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Por lo que respecta a las capturas, al aplicar --sar, deberías hacerlas con el VirtualDubMOD con el siguiente script:
que en su día recomendó elguaxo, pues según MediaInfo estás aplicando el --sar correctamente, pero no se aprecia en la captura.FFVideoSource("C:\ruta\mi_ripeo.mkv")
Spline36Resize(converttorgb,ffsar>1?round(width*ffsar):width,ffsar<1?round(height/ffsar):height)
Ya puestos, indicar que --psy-rd 1.0:0.15 es redundante con --tune film, ya que el uso de --tune film ya implica --psy-rd 1.0:0.15. En todo caso, no te afecta negativamente al ripeo en modo alguno.
Por el contrario, si empleases --tune grain, lo de --psy-rd 1.0:0.15 sí te alteraría la codificación, pues en --tune grain tenemos --psy-rd 1.00:0.25 ( http://superuser.com/questions/564402/e ... -x264-tune ).
De todas formas, en el caso que nos ocupa --tune grain entiendo que no tendría ningún sentido, pues la fuente no se caracteriza precisamente por su grano.
Florentino, fíchame.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
De acuerdo con todo lo que ha dicho Roisiano.
Para ahorrar tiempo de codificación, recomiendo "--preset veryslow --subme 9 --ref 10", que sería algo intermedio entre "slower" y "veryslow". Más que eso ya reporta muy pocos beneficios a costa de demasiado tiempo.
Para ahorrar tiempo de codificación, recomiendo "--preset veryslow --subme 9 --ref 10", que sería algo intermedio entre "slower" y "veryslow". Más que eso ya reporta muy pocos beneficios a costa de demasiado tiempo.
-
- Arrow Thrower Clown
- Mensajes: 18112
- Registrado: Dom 19 Oct, 2003 02:00
- Ubicación: Entre Encinas y Dolomías
Re: Iniciación al ripeo
En general estoy más o menos de acuerdo con los comentarios que van saliendo aunque discrepo en cierta forma con lo de "reportar pocos beneficios" a "costa de demasiado tiempo". Hablando de veryslow no puedo estar de acuerdo. Es un filo peligroso ya que esto es aplicable a muchas opciones de codificación del codec y al final el resultado es lo que vemos por la red en líneas generales, ripeos que sí se ven bien pero ni están optimizados y ya que te pones a ripear y se puede hacer bien o mejor no entiendo el limitar a un tipo como el "x264" que es tan listo y eficiente.Gomorrite escribió:De acuerdo con todo lo que ha dicho Roisiano.
Para ahorrar tiempo de codificación, recomiendo "--preset veryslow --subme 9 --ref 10", que sería algo intermedio entre "slower" y "veryslow". Más que eso ya reporta muy pocos beneficios a costa de demasiado tiempo.
Este tema lo hemos analizado hasta la saciedad y preguntado a elguaxo en diferentes ocasiones y las conclusiones eran claras. Si hablamos de placebo pues bien, pero coñe que yo ripeo desde el principio en veryslow y lo hago desde el ordendador más castaña que tengo (tiene 8 años o más y sin añadidos de ram ni historias) y es cierto que me lleva horas la codificación pero sé que después ofrezco un archivo que de tamaño está optimizado y de calidad también. Prefiero como digo con el CRF que sea el codec el que piense y trabaje con lo que necesita a ponerle yo limitaciones que no siempre son tan poco beneficiosas.
Bueno gente en un rato me voy de viaje asi que estaré desaparecido y con la mula apagada.
Ser buenos y pasarlo bien.
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
Creo que veryslow frente a slower es beneficioso gracias sobre todo a esos bframes extra o el merange. La superioridad de subme 10 u 11 ni siquiera es consistente y en ocasiones incluso aumenta el tamaño del ripeo. A mí tardar un 50% más ahorrar un 1% de espacio no me parece razonable, ¿para qué?, ¿para ahorrar 10 MB de espacio en el disco duro en las 10 personas que se descargan tu ripeo? La optimización de verdad se hace olvidándose de los tune film y tune grain y probando distintos valores de qcomp, psy-rd, aq-strength, etc. Ahí es donde se puede ahorrar un bitrate razonable y eso es lo que merece la pena hacer. Más tiempo de codificación es más energía gastada, factura de electricidad más alta, más emisiones de CO2, efecto invernadero... preset placebo es incluso inmoral.
-
- Mensajes: 1947
- Registrado: Jue 27 Ene, 2005 01:00
- Ubicación: Buenos Aires
Re: Iniciación al ripeo
Gomorrite escribió:preset placebo es incluso inmoral.
![Feliz :P](./images/smilies/icon_razz.gif)
-
- Polemista nato
- Mensajes: 5679
- Registrado: Dom 17 Jul, 2005 02:00
- Ubicación: Al final del río
Re: Iniciación al ripeo
Comentar que yo soy partidario de utilizar el mejor preset posible (esto es, el más lento
sin llegar a placebo) y, de hecho, así lo hago siempre (veryslow).
Lo que quería decir en mi anterior post es que tampoco creo que sea "exigible" (las comillas están ahí por algo, blablabla) al ripeador el que lo haga así, sobre todo si ripea a crf ab.cd, ya que, en último término, aquí el no usar el preset más lento te va a penalizar básicamente en el tamaño del archivo, no en la calidad del vídeo.
Si ripeas a bitrate fijo (pongamos que 5000 kbps), ahí yo entiendo que es más "exigible" un preset más lento, ya que, a igual bitrate, lo que vas a penalizar va a ser la calidad, no el tamaño.
En todo caso, de slow hacia abajo (hacia veryslow) tampoco me rasgaría las vestiduras implorando al ripeador que fuese "obligatoriamente" hacia un preset más lento, sobre todo si ripea con crf, repito.
Yo entiendo que es más "exigible" (las comillas siguen ahí por algo) pedirle (al ripeador) que "no la cague" en el script en primer lugar y en los (otros) parámetros de codificación del codec en segundo lugar.
Una vez que el script es bueno y las otras opciones de codificación son adecuadas, ya podemos "insistirle" (que no "exigirle") en lo de un preset más lento, creo yo.
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Lo que quería decir en mi anterior post es que tampoco creo que sea "exigible" (las comillas están ahí por algo, blablabla) al ripeador el que lo haga así, sobre todo si ripea a crf ab.cd, ya que, en último término, aquí el no usar el preset más lento te va a penalizar básicamente en el tamaño del archivo, no en la calidad del vídeo.
Si ripeas a bitrate fijo (pongamos que 5000 kbps), ahí yo entiendo que es más "exigible" un preset más lento, ya que, a igual bitrate, lo que vas a penalizar va a ser la calidad, no el tamaño.
En todo caso, de slow hacia abajo (hacia veryslow) tampoco me rasgaría las vestiduras implorando al ripeador que fuese "obligatoriamente" hacia un preset más lento, sobre todo si ripea con crf, repito.
Yo entiendo que es más "exigible" (las comillas siguen ahí por algo) pedirle (al ripeador) que "no la cague" en el script en primer lugar y en los (otros) parámetros de codificación del codec en segundo lugar.
Una vez que el script es bueno y las otras opciones de codificación son adecuadas, ya podemos "insistirle" (que no "exigirle") en lo de un preset más lento, creo yo.
Florentino, fíchame.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
Por cierto, más reference frames también es más energía gastada en la decodificación. Si os da igual el efecto invernadero, pensad que la batería del portátil os durará más viendo pelis con menos reference frames.
Prefiero mil veces antes un ripeador que usa preset slow pero se preocupa por tener qcomp / aq-strength bien optimizados, que uno que usa preset placebo y pone tune grain porque ve que la fuente tiene grano (un psy-rd tan alto como 1.0:0.25 a menudo no hace más que estropear el ripeo) y su única prueba es compararlo con tune film.
![Feliz :P](./images/smilies/icon_razz.gif)
Prefiero mil veces antes un ripeador que usa preset slow pero se preocupa por tener qcomp / aq-strength bien optimizados, que uno que usa preset placebo y pone tune grain porque ve que la fuente tiene grano (un psy-rd tan alto como 1.0:0.25 a menudo no hace más que estropear el ripeo) y su única prueba es compararlo con tune film.
-
- Polemista nato
- Mensajes: 5679
- Registrado: Dom 17 Jul, 2005 02:00
- Ubicación: Al final del río
Re: Iniciación al ripeo
En este sentido, hice algunas pruebas con algo intermedio entre film y grain pero más cercano a film que me han gustado. Probablemente use esos settings en algún ripeo "granuloso" en un futuro próximo... o no.Gomorrite escribió:Prefiero mil veces antes un ripeador que usa preset slow pero se preocupa por tener qcomp / aq-strength bien optimizados, que uno que usa preset placebo y pone tune grain porque ve que la fuente tiene grano (un psy-rd tan alto como 1.0:0.25 a menudo no hace más que estropear el ripeo) y su única prueba es compararlo con tune film.
Florentino, fíchame.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
Por 6.000 € netos mensuales te convierto en el mejor presidente de la historia.
-
- Mensajes: 256
- Registrado: Mié 12 Nov, 2003 01:00
- Ubicación: En una galaxia lejana, muy lejana....
Re: Iniciación al ripeo
Descuida Gomorrite, estoy seguro que tu si tienes el ojo mejor adiestrado para estas lides que yo; de hecho ya dije que mi vista lejos de ser la de un lince, empieza a ser la de un gato menopáusico, y de esto no me he dado cuenta ahora, sino cuando pude comprobar que no dando ya mas de sí la extensión de mis brazos (a la hora de querer ver de cerca), lo que tenía ya es un claro ejemplo de presbicia... jejejeGomorrite escribió:No me refiero a los fondos, sino a las texturas de la ropa que se difuminan muy ligeramente. Pero bueno, será que tengo el ojo demasiado adiestrado, realmente es poquísima la pérdida. Está bien como está, atina el CRF y creo ya lo tienes hecho.
Estoy contigo, creo que esa lentitud de 1.97 fps viene mas que nada por el propio scrit de filtrado; así que esa lentitud en la que de por sí trabaja "--preset veryslow" irá acorde al ritmo que tiene tal filtro.Gomorrite escribió: "--preset veryslow" no creo que tarde mucho más (proporcionalmente a lo que ya tarda), ten en cuenta que probablemente es todo ese filtrado lo que se hace que tarde tanto, no la codificación en sí. No esperes una gran reducción en el tamaño, pero igual un 5% o así sí.
Estás en lo cierto en que no cuadra Fronkyfronky escribió:Nop, por esto...Alekhine escribió:lo dices por usar el 12/11 ¿¿...y que otra alternativa de SAR tengo...?? ¿....el aPePinao 16/15??fronky escribió:... &, a ser posible, enchúfale un SAR menos awevao
(pozíp k zuavisa er montluito, zíp)![]()
... y tu última prueba...
Algo no cuadra (el soft capturerop?)
... la razón es que mientras esa primera captura la realicé cargando en VDM este script que te indico:
Código: Seleccionar todo
##########################################
# #
# Muestra los posibles SARs del video #
# que habrá que elegir visualmente #
# #
##########################################
avsfile = "VerCropDVD.avs" # Encoding script
format = 0 # 1=NTSC, 0=PAL
wide = 0 # 1=Widescreen 16:9, 0=Full screen 4:3
#############################
ITU = (format==1?10:12)/11.0*(wide==1?4.0/3:1)
SARs = """"12:11","16:11","10:11","40:33","16:15","64:45","8:9","32:27""""
ITUprof = "SDB "+(wide==1?"ANAMORPHIC ":"")+(format==1?"NTSC":"PAL")
i=import(avsfile).converttorgb
i
ab = round(height*(sqrt(45.0/44)-1))
a = spline36resize(round(width*ITU),height)
a = a.addborders(0,floor(ab/2.0),0,ceil(ab/2.0))
bb = width(a)-round(width*ITU/sqrt(45.0/44))
b = spline36resize(round(width*ITU/sqrt(45.0/44)),height+ab)
b = b.addborders(floor(bb/2.0),0,ceil(bb/2.0),0)
interleave(a,b)
scriptclip("""subtitle("Playback Resolution: "+\
string(round(width(i)*ITU*pow(44.0/45,current_frame%2)))+"x"+string(height(i))+\
"\nMeGUI Profile: "+ITUprof+(current_frame%2==1?" NON-ITU":"")+\
"\nx264 --sar "+eval("select(2*format+wide+current_frame%2*4,"+SARs+")"),lsp=6)""")
Código: Seleccionar todo
DGDecode_mpeg2source("D:\Ripeos\02 MKVs\video.d2v")
Import("C:\Archivos de programa\Edicion de Video\FrameServing\AviSynth 2.5\plugins\QTGMC-3.32.avs")
QTGMC(Preset="Slow")
SelectEven()
crop(16, 6, -16, -6)
##############################################################################################################
# Filtro TheMonster.- #
# ================= #
# Ataca los artefactos de compresión del DVD (macrobloques y ruido en croma y luma) #
# Dejan intactos los detalles #
# (Véase http://www.divxclasico.com/foro/viewtopic.php?p=667315#p667315) #
##############################################################################################################
source = last
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1, truemotion=true)
mask = mvmask(kind=1, vectors=forward_vec1).UtoY().LanczosResize(688,564)
smooth = source.degrainmedian(mode=3).fft3dfilter(bw=16, bh=16, bt=3, sigma=3, plane=0)
source2 = maskedmerge(source, smooth, mask)
source3 = source2.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
source3.gradfun2db(1.5)
##############################################################################################################
# SelectRangeEvery(5000, 239) # Cada 5000 frames pillamos 239
# trim(0, 7409) # Ripea desde el frame 0 hasta el 7409
Más adelante pondré las capturas finales, sacadas desde la película MKV, pero las he hecho con VLC, en las que he pretendido situarme en cada frame correspondiente... ¿Alguien sabe como decirle a VLC que vaya a un frame concreto? Ni hablar, por supuesto, del boton "frame a frame" del que dispone, porque en ningun momento se visualiza el numero del frame en que se encuentra.
Aunque yo soy todo un "pardillo" en esto, soy de la misma opinión... y es que más lento de 1.97 fps, casi como que no va a poder ser.roisiano escribió:Como bien indica Gomorrite, cuando el filtrado requiere tantos recursos, el preset no suele ser el factor más limitante (en el tiempo empleado) al hacer el ripeo, sino que es el script el "cuello de botella" del proceso.
Estás en lo cierto, a continuación pongo el info que me dá MediaInfo:roisiano escribió: Con respecto al crf, cada unidad de diferencia en el crf hace variar ~ un 20% el tamaño respecto a la referencia. Así, si a crf 21.0 te vas a los 1000 kbps, a crf 19.0 deberías irte en torno a 1350-1400, aproximadamente (y aún así el QF en este caso sería bajo). Puedes irte hasta 18.5 o 18.0 casi con los ojos cerrados en casos donde empleas tan poco bitrate sin demasiado temor de estar "sobrerripeando" (en todo caso, estarías por debajo de 1600 kbps y en torno a un QF de 0.160).
Código: Seleccionar todo
General
Nombre completo : D:\Ripeos\02 MKVs\MiPelicula 1850 (5) film Monster.mkv
Formato : Matroska
Tamaño del archivo : 1,25GIB
Duración : 1h 43min.
Tasa de bits total : 1 731Kbps
Aplicación de codifición : x264 r2345 f0c1c53
Librería de codificación : Haali Matroska Writer b0
Video
ID : 1
Formato : AVC
Formato/Info : Advanced Video Codec
Formato del perfil : High@L4.1
Ajustes del formato, CABAC : Si
Ajustes del formato, RefFrames : 5marcos
Modo Muxing : Container profile=Unknown@4.1
ID Códec : V_MPEG4/ISO/AVC
Duración : 1h 43min.
Tasa de bits : 1 697Kbps
Ancho : 688pixeles
Alto : 564pixeles
Relación de aspecto : 4:3
DisplayAspectRatio_Original/Stri : 4:3
Velocidad de cuadro : 25,000fps
Resolución : 8bits
Espacio de color : 4:2:0
Tipo de exploración : Progresivo
Bits/(Pixel*cuadro) : 0.175
Tamaño de pista : 1,22GIB (98%)
Librería de codificación : x264 core 135 r2345 f0c1c53
Opciones de codificación : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Ello me anima a bajarle media decima al CRF que estuvo en 18.50 para repetir de nuevo el proceso a ---preset veryslow y con ---CRF 18.00 .
A tenor de lo que vais diciendo, creo que es lo que corresponde... ¿no?
Sí, la fuente es mala de solemnidad, pero a mí me gusta el Ajedrez, ésta es una de las películas más brillantes que aborda el tema, y queriendo disponer de ella en mejores condiciones de las que hace años publique´(y que era una TVrip de algún internauta alemán), adquirí por fín este DVD... imagino que tras el currazo que me dé, a algún aficionado al Ajedrez como yo le gustará tenerla.roisiano escribió: Por lo demás, con este filtrado está claro que pierdes detalle, "fidelidad" al original (en este caso el original era una mierda pinchada en un palo, más o menos), aunque en este caso para mejorarlo. En todo caso, deberías intentar asegurarte, en mi opinión, que el "detalle" que pierdes es por "culpa" del filtrado (que te ayuda en otras cosas) y no por el bitrate/CRF elegido. Más aún a favor de bajar el crf, incluso podrías probar hasta llegar a 17.
Yo con este tipo de fuentes no me peleo siquiera, todo sea dicho.
¿Te refieres a aplicarlo una vez que ya tenga la pelí? OK...seguiré la recomendación: cargarlo en VDM y situarme en el frame correspondiente (aunque...para esta ocasión, ya había sacado las capturas con VLC situándome "a pelo" ... espero que estas os valgan).roisiano escribió: Por lo que respecta a las capturas, al aplicar --sar, deberías hacerlas con el VirtualDubMOD con el siguiente script:que en su día recomendó elguaxo, pues según MediaInfo estás aplicando el --sar correctamente, pero no se aprecia en la captura.Código: Seleccionar todo
FFVideoSource("C:\ruta\mi_ripeo.mkv") Spline36Resize(converttorgb,ffsar>1?round(width*ffsar):width,ffsar<1?round(height/ffsar):height)
Eso ya me ha quedado claro... --tune grain solo para peliculas de 16mm.roisiano escribió: De todas formas, en el caso que nos ocupa --tune grain entiendo que no tendría ningún sentido, pues la fuente no se caracteriza precisamente por su grano.
Hombre..ya que me he metido en el río, pues que más dá si el agua me llega al cuello...Dardo escribió:En general estoy más o menos de acuerdo con los comentarios que van saliendo aunque discrepo en cierta forma con lo de "reportar pocos beneficios" a "costa de demasiado tiempo". Hablando de veryslow no puedo estar de acuerdo. Es un filo peligroso ya que esto es aplicable a muchas opciones de codificación del codec y al final el resultado es lo que vemos por la red en líneas generales, ripeos que sí se ven bien pero ni están optimizados y ya que te pones a ripear y se puede hacer bien o mejor no entiendo el limitar a un tipo como el "x264" que es tan listo y eficiente.
Uffffffffff ..pero para eso hay que entender muy requetebien los manuales en ingles que indican el porqué de cada opción y su espíritu...para luego saber ir apretando las tuercas e ir ajustando la mááquina... no sé, pienso yo... y a falta de un buen manual en español...pues la cosa se pone torcida.Gomorrite escribió:Creo que veryslow frente a slower es beneficioso gracias sobre todo a esos bframes extra o el merange. La superioridad de subme 10 u 11 ni siquiera es consistente y en ocasiones incluso aumenta el tamaño del ripeo. A mí tardar un 50% más ahorrar un 1% de espacio no me parece razonable, ¿para qué?, ¿para ahorrar 10 MB de espacio en el disco duro en las 10 personas que se descargan tu ripeo? La optimización de verdad se hace olvidándose de los tune film y tune grain y probando distintos valores de qcomp, psy-rd, aq-strength, etc. Ahí es donde se puede ahorrar un bitrate razonable y eso es lo que merece la pena hacer. Más tiempo de codificación es más energía gastada, factura de electricidad más alta, más emisiones de CO2, efecto invernadero... preset placebo es incluso inmoral.
Y ahora os pongo las capturas sacadas como digo "a pelo" tras cargar la pelicula MKV en VLC:
![Imagen](http://img809.imageshack.us/img809/4868/fwa4.png)
![Imagen](http://img17.imageshack.us/img17/4197/f07i.png)
![Imagen](http://img607.imageshack.us/img607/8407/4n9x.png)
![Imagen](http://img22.imageshack.us/img22/4939/b8eq.png)
Gracias por vuestras opiniones y recomendaciones.
En Ajedrez gana el que comete el penultimo error.
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
La comparación con las capturas de la página anterior no es la ideal debido a su diferente tamaño, pero aún así se ve clarísimo: estás perdiendo bastante más detalle en la codificación que en el filtrado. Yo creo que eso necesita, no CRF 18, sino 17.5 o mejor 17.
-
- Mensajes: 256
- Registrado: Mié 12 Nov, 2003 01:00
- Ubicación: En una galaxia lejana, muy lejana....
Re: Iniciación al ripeo
¿¿Alguna opinión más antes de meterlo en el horno este finde, y tener el PC en estado ...que_NO_lo_toque_ni_Dios...??Gomorrite escribió:La comparación con las capturas de la página anterior no es la ideal debido a su diferente tamaño, pero aún así se ve clarísimo: estás perdiendo bastante más detalle en la codificación que en el filtrado. Yo creo que eso necesita, no CRF 18, sino 17.5 o mejor 17.
En Ajedrez gana el que comete el penultimo error.
-
- Arrow Thrower Clown
- Mensajes: 18112
- Registrado: Dom 19 Oct, 2003 02:00
- Ubicación: Entre Encinas y Dolomías
Re: Iniciación al ripeo
En realidad el CRF describe una curva logarítmica en la que a partir de cierto punto el descenso de su valor supone un consecuente aumento de bitrate y por tanto de tamaño pero donde la ganancia en la imagen es cuasi-incremental o ínfima por tanto lo suyo es que hagas dos capturas a través de un script con virtualdubmod del mismo frame para saber si ese descenso de CRF=18 a CRF=17 es efectivo.Alekhine escribió:¿¿Alguna opinión más antes de meterlo en el horno este finde, y tener el PC en estado ...que_NO_lo_toque_ni_Dios...??Gomorrite escribió:La comparación con las capturas de la página anterior no es la ideal debido a su diferente tamaño, pero aún así se ve clarísimo: estás perdiendo bastante más detalle en la codificación que en el filtrado. Yo creo que eso necesita, no CRF 18, sino 17.5 o mejor 17.
Para un Bluray de 100 minutos, el cambio de subme 10 a subme 9 supone un ahorro en el tiempo de codificación de un 20-22% pero con el lastre que el ripeo obtenido tiene un peso de un 5-7% mayor y con una calidad de vídeo inferior. Aquí podemos entrar en que te pueda parecer mínimas las diferencias, etc, pero la realidad es que el vídeo es peor, y lo que nos parece entra dentro del terreno de la subjetividad del ojo de cada uno. ¿Para qué ofrecer un ripeo de mayor tamaño aunque sea poquito que sé que encima es peor que codificando de otra forma?, es algo que de momento no entra dentro de mi baremo de prioridades, porque para eso me sirve un "tipo scene".Gomorrite escribió:Para ahorrar tiempo de codificación, recomiendo "--preset veryslow --subme 9 --ref 10", que sería algo intermedio entre "slower" y "veryslow". Más que eso ya reporta muy pocos beneficios a costa de demasiado tiempo.
Si rebajamos los ref de 12 a 10 mantiendo el subme 9 la velocidad de codificación apenas varía y el tamaño del ripeo aumenta levemente. Lo de tocar los ref me recuerda a cuando en el xvid no se subía de 2000 el bitrate para que los repros fuese fluídos, en fin con el tiempo hemos visto que no es buena técnica limitar calidad, porque con el tiempo tenemos ripeos que son para "delete". De hecho si el xvid ya se quedó atrás como para encima limitarlo a 2000 de bitrate...
Más cosas que me parecen interesantes:
En realidad esto no ocurre con subme 9 Gomorrite, para reducir en un 50% el tiempo de codificación has de darle la orden al codec de subme=7 y duplicarás o estarás muy cerca la velocidad de codificación con respecto a subme 10. Ahora bien si con subme 9 se produce un aumento del tamaño del ripeo y se resiente la calidad del vídeo con subme 7 las diferencias de calidad son más que notables, de hecho en Blurays con imagen poderosa la diferencia de una u otra configuración te determina el hacer un ripeo normalito a un muy buen ripeo.Gomorrite escribió:Creo que veryslow frente a slower es beneficioso gracias sobre todo a esos bframes extra o el merange. La superioridad de subme 10 u 11 ni siquiera es consistente y en ocasiones incluso aumenta el tamaño del ripeo. A mí tardar un 50% más ahorrar un 1% de espacio no me parece razonable, ¿para qué?, ¿para ahorrar 10 MB de espacio en el disco duro en las 10 personas que se descargan tu ripeo? La optimización de verdad se hace olvidándose de los tune film y tune grain y probando distintos valores de qcomp, psy-rd, aq-strength, etc. Ahí es donde se puede ahorrar un bitrate razonable y eso es lo que merece la pena hacer. Más tiempo de codificación es más energía gastada, factura de electricidad más alta, más emisiones de CO2, efecto invernadero... preset placebo es incluso inmoral.
Por supuesto que para fuentes malillas con tal de arreglar los desperfectos que trae la misma después la codificación será secundaria o al menos no tan importante como crear un buen script "arreglador de defectos".
Más cosas...
Puestos a preferir yo me quedo con un ripper que optimice todas las variables, y me lo haga al menor tamaño posible, parece algo de perogrulloGomorrite escribió:Por cierto, más reference frames también es más energía gastada en la decodificación. Si os da igual el efecto invernadero, pensad que la batería del portátil os durará más viendo pelis con menos reference frames.![]()
Prefiero mil veces antes un ripeador que usa preset slow pero se preocupa por tener qcomp / aq-strength bien optimizados, que uno que usa preset placebo y pone tune grain porque ve que la fuente tiene grano (un psy-rd tan alto como 1.0:0.25 a menudo no hace más que estropear el ripeo) y su única prueba es compararlo con tune film.
![Sonrisa :sonrisa:](./images/smilies/icon_sb_smile.gif)
Además el decir que tune grain puede estropear un ripeo es como decir que lavar a 60º la ropa la deteriora...pues habrá que ver qué vídeo y analizar cada caso. Es cierto que tune grain se usará en casos puntuales pero cuando hace falta y nos queremos aproximar al original pues no queda otra.
Se trata de hacer pruebas y entender los números y el codec, pero no podemos decir que tune grain estropeará un vídeo porque dependerá del mismo.
Volviendo a un tema anterior:
En realidad lo que tú ves como defecto para mí es una virtud del ripper y me explico. El ripper se ha gastado su dinero en corriente para que tú cuando te bajes el ripeo lo hagas con menor tamaño y en tu disco duro lo almacenes ocupándote menos. Entiendo lo que quieres decir es que tú prefieres algo menos de calidad y un mayor tamaño pero optimizar el tiempo que tienes al ordenador codificando y lo que gastas de recibo. Me parece estupendo pero como cada uno se paga su recibo, valoremos más los que optan por la opción de calidad acompañada de menor tamaño a costa de su "sacrificio"Gomorrite escribió:Creo que veryslow frente a slower es beneficioso gracias sobre todo a esos bframes extra o el merange. La superioridad de subme 10 u 11 ni siquiera es consistente y en ocasiones incluso aumenta el tamaño del ripeo. A mí tardar un 50% más ahorrar un 1% de espacio no me parece razonable, ¿para qué?, ¿para ahorrar 10 MB de espacio en el disco duro en las 10 personas que se descargan tu ripeo? La optimización de verdad se hace olvidándose de los tune film y tune grain y probando distintos valores de qcomp, psy-rd, aq-strength, etc. Ahí es donde se puede ahorrar un bitrate razonable y eso es lo que merece la pena hacer. Más tiempo de codificación es más energía gastada, factura de electricidad más alta, más emisiones de CO2, efecto invernadero... preset placebo es incluso inmoral.
![Guiño :wink:](./images/smilies/icon_wink.gif)
Es algo fácil de entender, si en un ripeo de tamaño medio como 4 Gb al que lo baja le ahorras 200 Mb (por poner una cifra más o menos moderada, en realidad puede ser mayor esa reducción) si a lo largo del año se baja 100 ripeos de ese tamaño medio (algo nada descabellado, 10 ripeos al mes 720p, 2-3 por semana), le estás ahorrando 20 Gb en su almacenaje y 20 Gb menos a bajarse por la mula. Por tanto el ripper se gasta su dinero en corriente para ofrecer un ripeo que tiene mayor calidad eso es objetivo y que le supone ahorrar espacio y bajarse menos megas. Yo a eso lo llamo optimizar porque el tiempo de más que me tarda el ripeo no lo tengo que guardar, y el resultado final sí, ya entraríamos en si es más caro lo que me gasto en discos duros o en ripear.
![Entornando los ojos :roll:](./images/smilies/icon_rolleyes.gif)
En fin diferentes puntos de vista.
![Guiño :wink:](./images/smilies/icon_wink.gif)
-
- Mensajes: 1947
- Registrado: Jue 27 Ene, 2005 01:00
- Ubicación: Buenos Aires
Re: Iniciación al ripeo
Suscribo lo que comenta Dardo, y vuelvo a ofrecer mi opinión de latinoamericano en esto, que me parece importante porque obviamente también formamos parte de la comunidad p2p que baja ripeos, y por lo tanto conformamos la red estadística de "conveniencias" que a veces necesitamos considerar: por razones cambiarias y de economías regionales, el acceso a la tecnología de hardware digital es muchísimo más oneroso aquí que en Europa. Un disco duro de 2 TB no es algo solamente "caro", es algo en lo que un docente, por ejemplo, tendría que invertir la cuarta parte de su sueldo... La optimización de los ripeos en términos de tamaño final es decisiva para alguien que invierte semejante cantidad de dinero en almacenamiento, y es importante para las redes p2p en general, porque de ese almacenamiento depende muchas veces la supervivencia del archivo en la red.Dardo escribió:Yo a eso lo llamo optimizar porque el tiempo de más que me tarda el ripeo no lo tengo que guardar, y el resultado final sí, ya entraríamos en si es más caro lo que me gasto en discos duros o en ripear.![]()
-
- Mensajes: 40
- Registrado: Vie 10 Oct, 2008 15:46
Re: Iniciación al ripeo
¿Un 5-7% mayor? Busca información por los foros de doom9 o similares, encontrarás mucha gente que ha hecho pruebas con fuentes variadas y los resultados suelen ser de un tamaño 1-2% mayor. Y eso es a igualdad de calidad, no a calidad inferior (estamos ripeando a CRF constante, ¿no?). Si realmente fuera 5-7%, sí me parecería muy recomendable, pero me temo que la ventaja no es tal. Aún no pareciéndome necesario en absoluto, he ripeado a menudo a subme 10 y es subme 11 el que realmente desaconsejo. ¡En algunas pruebas ha dado lugar a mayores tamaños que subme 10!Dardo escribió: Para un Bluray de 100 minutos, el cambio de subme 10 a subme 9 supone un ahorro en el tiempo de codificación de un 20-22% pero con el lastre que el ripeo obtenido tiene un peso de un tamaño 5-7% mayor y con una calidad de vídeo inferior. Aquí podemos entrar en que te pueda parecer mínimas las diferencias, etc, pero la realidad es que el vídeo es peor, y lo que nos parece entra dentro del terreno de la subjetividad del ojo de cada uno. ¿Para qué ofrecer un ripeo de mayor tamaño aunque sea poquito que sé que encima es peor que codificando de otra forma?, es algo que de momento no entra dentro de mi baremo de prioridades, porque para eso me sirve un "tipo scene".
Por supuesto que dependerá del mismo, si yo precisamente estoy abogando por adaptarse aún más a la fuente que simplemente probar "tune grain" y un "tune film" y comprobar cuál es mejor.Dardo escribió:Además el decir que tune grain puede estropear un ripeo es como decir que lavar a 60º la ropa la deteriora...pues habrá que ver qué vídeo y analizar cada caso. Es cierto que tune grain se usará en casos puntuales pero cuando hace falta y nos queremos aproximar al original pues no queda otra.
Se trata de hacer pruebas y entender los números y el codec, pero no podemos decir que tune grain estropeará un vídeo porque dependerá del mismo.
No, en absoluto, creo que no se me ha entendido. Yo no prefiero menor calidad (¡y muchísimo menos a mayor tamaño!), lo que digo es que puestos a optimizar, es mejor centrarse primero en lo que realmente optimiza el ripeo: valores adecuados de aq-strength / qcomp / etc. Por ejemplo "tune grain" sube qcomp notablemente, lo cual le puede sentar bien a una fuente con grano, pero al mismo tiempo sube psychovisual trellis, que le puede sentar mal a una fuente con cierto tipo de grano. Se use un tune o se use el otro, el ripeo jamás estará optimizado y no obtendrá el menor tamaño posible a igualdad de calidad. Optimizando los parámetros uno a uno sí que se pueden obtener beneficiones mucho mayores que un 1-2% (o 5-7%) y además no tiene demasiado efecto en el tiempo de ripeo. Por ello jamás diría que un ripeador es malo por el hecho de no usar subme 11 o 16 ref frames, porque eso produce beneficios mucho más marginales que la optimización de parámetros. Si el ripeador quiere usar "placebo" y aprovechar para poder freir huevos en su ordenador durante 24 horas, pues es un minúsculo extra para quien lo descargue, pero desde luego no lo covertirá en el mejor ripeador (y podría estar lejos de serlo) si no optimiza lo que realmente vale la pena.Dardo escribió:Entiendo lo que quieres decir es que tú prefieres algo menos de calidad y un mayor tamaño pero optimizar el tiempo que tienes al ordenador codificando y lo que gastas de recibo. Me parece estupendo pero como cada uno se paga su recibo, valoremos más los que optan por la opción de calidad acompañada de menor tamaño a costa de su "sacrificio"![]()
P.S. Por cierto, es cierto que cada uno se paga su recibo, pero los efectos medioambientales de un mayor consumo de energía eléctrica sí los pagamos todos.