Re: Iniciación al ripeo
Publicado: Mié 30 Oct, 2013 00:02
... &, 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)
Para los amantes del Cine Clásico
http://www.divxclasico.com/foro/
http://www.divxclasico.com/foro/viewtopic.php?f=1018&t=40913
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€.
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)
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.
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.
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)
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)
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.
Gomorrite escribió:preset placebo es incluso inmoral.
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.
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?)
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
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
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.
¿¿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 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.
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.
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 perogrullo . No me parece que sea el caso que nos ocupa al menos en DXC.Gomorrite 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.
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.
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.
¿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"