Configuraciones de filtros y codecs

[fronky]

Cut+empalme, merge mediante.
Con algunos de mis últimos SDripios ya aproveché y arrasé con cortinillas, intermissions y demás (juer, el Zaragozano se iba a unos 12GB entre ambos discosh... la mare...).

Otra opción es, si se trabaja con trim, aplicar los delays correspondientes al audy, clarop

[Gomorrite]

Comparto con vosotros esta guía en inglés para conocer mejor los parámetros de x264. Para aquellos que no quieran quedarse estancados en los tunes predeterminados. Sí, puede que haya otras guías similares, pero está es la más didáctica e interesante que he leído.

x264 and You: An empiricist's insight into encoding theory, and settings. By mael of TC.

Disclaimer

Spoiler: mostrar

Before I start - I want to note that I am still a child exploring my way through x264. I have read quite a bit of literature, done a lot of testing, and talking to quite a few experienced encoders. My three primary teachers have been "Echohead", "Onkellars", "my own tests". My secondary teacher has been Doom9.

I decided to write this thing because most of the time - experienced encoders tend to not give very concrete opinions due to reasons like – a) every source is different and thumb-rules are bad; b) what the speaker intends to say is not always what the listener understands, and finally c) most of them share the belief that becoming a good encoder requires guidelines coupled with experimentation.

I am writing this somewhat opinionated monologue with the hope that it will help transfer my understanding to someone who is starting his journey. I welcome not only more information/insight; but also criticism on how wrong I am in certain areas. This explanation is more empirical than scientific - and might make a lot of generalisations that could be blatantly wrong.

But I am still confident that an absolute beginner will benefit from this guide.

Motion Picture, Frames and Frame-types

Spoiler: mostrar

A movie is a contraction for 'motion picture'. A movie consists of a certain number of pictures (frames) that are shown to you every second to create the perception of motion. Note that movie is not an arbitrary collection of images. Most of the images in a motion picture are dependent on the preceding and succeeding images, so for storage purposes, each image need not be stored in entirety.

So what we have are three types of frames/pictures:

I-frame or Intracoded frame -> Simply put - this frame is an independent frame, that does not use any information from frames that precede or succeed it. A rough analogy would mean this is our reference frame. They consume the most space.

P-frame or Predicted frame -> These types of frames use information from the previous frame. In other words p-frames basically encode how the current image is different from the preceding image. For this reason [presumably] they are also called as Delta-frames. Delta in calculus indicates change. They consume less space than I, but more than B.

B-frames or Bi-predictive frames -> These frames are the most interesting ones.They experience most compression and have the lowest space allocation.

I will do some illustrating here. Imagine a sequence of four images where Jerry appears in the screen from nowhere/another dimension over a course of four frames – and a possible compression strategy.

In the first image there is a static background alone;

In the second image there is a transparent jerry starts manifesting from nowhere, Jerry appears but with 99% transparency [almost see-through]. This could be a p-frame.

In the third image, Jerry is about 50% transparent, he is almost there but not yet. This frame borrows information from the next-frame as well as previous frame. Jerry is almost there but not yet.

In the final image, Jerry is 100% physically present. In a particular encoding strategy, this could be an I-frame.

Note that – this is a very rudimentary example only to illustrate things – what gets compressed as what frame, depends on compression and encoding strategy.

Source, Encode, Transparency, and Bloating

Spoiler: mostrar

A source can be defined as a set of images/frames – B, P, and I.

An encode can be defined as a set of images/frames – B, P, and I that are supposed to represent the source. Encodes are invariably smaller than the sources.

A transparent encode is defined as an encode that represents the source accurately enough – so that the differences between the encode and the source are indiscernible. That is, if I play the source and encode alongside you shouldn’t be able to tell which is which. So how do we test for transparency?

Well, if you take a particular I-frames of the encode and compare them with the corresponding source frames – you won’t learn a thing. That is because, I-frames are treated with great sanctity; and thus the encoder tries replicates these frames as faithfully w.r.t. the source as possible even when you use a relatively bad setting.

A B-frame, on the other hand, takes advantage of compression techniques the most – so B-frames are the best indicators.

When a frame that was P-frame in source [P-frames are space-heavier than B-frames]; but is encoded as a B-frame in encode – such a frame best indicates how much work [or damage] your encoder has done.

When a frame that was P in source and B in encode resemble each other – that means that your encoder has created an encode that is very faithful to the source. You have achieved transparency.

If you could have achieved transparency at a significantly lower bit-rate, your encode is termed bloated.

--bframes

Spoiler: mostrar

--bframes: This setting defines how many consecutive bframes can occur in sequence. To illustrate, visualise a sequence where two samurais are facing each other for the right moment to strike. They face off each other for 10 seconds and nothing changes! [Referencing a Kurosawa movie - Sanjuro]. While you are anxiously waiting for the change, even your encoder is waiting for some sort of change to document. So suppose you use --bframes 3, here is what happens.

Frame 1: Reference, the good guy and bad guy are facing off – starting and each other.

Frame 2: Nothing has changed, dammit. Nothing has changed, except for some grains and so shall call it a P-frame? or a B-frame?

Frame 3: Nothing has changed, this frame is the same as the I-frame. So let me call this a P-frame.

Now here is the trick, if I was encoding with -–bframes 2; my encoder tells itself

Frame 2: Frame 3 and Frame 1 are identical, except for some grain-movement, so let me encode Frame 3 as P-frame dependent on frame 1; and Frame 2 a B-frame that depends on frame 1 and frame 3.



But note that nothing is changing in this action sequence for 240 frames [about 10 seconds]

Thus in reality we have a sequence that goes as follows-

Frame 4: Nothing has changed.

Frame 5: Nothing has changed.

.

.

.

Frame 240: Finally the bad guy decides to make his move.

Now suppose, I told my encoder, I want only --bframes 2 – here is what could have happened frame by frame.

I -> B -> P -> B -> P -> etc.

But if I told my encoder that I am okay with bframes 10 – here is what happens :
I -> B -> B -> B -> 16 times then -> P then 10 more b frames.

So, to put it in one-line - if a --b-frames 10, means that after 10 consecutive b-frames - a frame that could have been encoded as a b-frame, will still end up as a p-frame - simple because the limit of consecutive b-frames considered is 10. It does not mean that b-frames are used when p-frames are explicitly determined as more benefitial.

So what are the pros and cons? A high b-frames would imply that your encoder keeps a lot more frames in mind while deciding if a frame must be b or a p. So it slows down your encoding process.

So what we do is – we determine what percentage of frames will benefit if we use a higher bframe strategy. Say we do a test-encode with –-bframes 16; the log will tell us how many frames actually benefit from looking at 16 frames ahead and behind. Echohead says that if a particular number is benefiting in less than 1% of the cases, you should choose that number.

Whereas, other encoders might say that you should always encode with –- bframes 16 because space saved in the final encode is space saved.

Verdict: Leave it at 16.

--b-adapt

Spoiler: mostrar

B-adapt is a minor setting that is always left at 2. Basically B-adapt is a setting that tells your encoder whether you want to place a P-frame or a B-frame in particular cases. B-adapt 1 will make this decision more quickly, leading to poorer judgements and lowered quality. B-adapt 0 will always pick B-frames – leading to worsened encode [but lowered encode size]. B-adapt 2; which is what encodes who aim for transparency use asks the encoder to take its time and make the best decision.

Verdict: Leave it at 2.

--b-bias

Spoiler: mostrar

B-bias is another minor setting that I leave unchanged at 0. B-bias positive till 100 will increase the likelihood of encoding a particular frame as B. And negative will increase the likelihood of encoding a particular frame as P.

Verdict: Leave it at 0

--b-pyramid

Spoiler: mostrar

B-pyramid is another minor setting that can be none, strict or normal. Bframes that are used as reference for other bframes get assigned more bits than your average bframe but less bits than a pframe. Choosing 'None'disallows a bframe from using another bframe as reference. 'Strict' basically allows only one b-frame to be used as reference frame in a set [referred to as minigop]. I leave this setting at normal to allow many b-frames to be used as reference b-frames.

Verdict: Leave it at normal.

Frames and Macroblocks

Spoiler: mostrar

Let us take a step back and understand how images are stored and rendered. When you deal with a 640X480 image - what does that mean? It means you are dealing with 3,07,200 pixels. So if you were storing that image by using a strategy of assigning a colour to each pixel, and say end up assigning 24 bits to store what colour a pixel is – you would end up using about 900 KB per picture. This would be a very inefficient strategy, because each pixel is not discrete/arbitrary; but will have a correlation with the adjacent pixels. Thus, as far as I understand, information in an image is not stored per pixel; but per macroblock. Look at macroblocks as an chunks/aggregation of pixels. Macroblocks themselves can depend on other macroblocks within the frame [or as we will see later in the next paras even other frames]

Going back to our original P vs B vs I discussion; an I-frame has independent and intradependent macroblocks. That is, a macroblock in that frame could depend on other macroblocks in the same frame or be totally independent.

But in a P-frame, a macroblock could depend on the macroblock from past-frame; and in a B-frame some macroblocks on macroblocks of a frame that can either be succeeding or previous.

mbtree and Qcomp; pb and ip ratios

Spoiler: mostrar

Disclaimer: Well, mbtree is where I am going to take a HUGE leap of faith and try to explain what I think is right. But please correct me if I am wrong. I think that my understanding does have great empirical validity and practical value – so I present it even with the risk of it being technically wrong. I encoded a small shot with four settings to explain myself better.

qcomp: 0; Mbtree: Off
x264 [info]: frame I:4 Avg QP:14.13 size: 69217
x264 [info]: frame P:34 Avg QP:17.18 size: 18025
x264 [info]: frame B:146 Avg QP:19.53 size: 4792

qcomp: 1; Mbtree: Off
x264 [info]: frame I:4 Avg QP:13.47 size: 73761
x264 [info]: frame P:34 Avg QP:14.00 size: 32968
x264 [info]: frame B:146 Avg QP:15.98 size: 12360

Exactly, what does this data mean?

As you can see, when Qcomp was increased to 1, P and B frames encoded more data and were more space-intensive; whereas when Qcomp was made to 0, P and B frames had less data.

Qcomp determines your encoding strategy. Given the fact that the default qcomp is 0.6, when I say "Qcomp = 0.8" I am telling my encoder this "Hey, just because a frame is P or B, doesn't mean that they are to be given too much of a step-motherly treatment". When I say "Qcomp = 0.4", P-frames and B-frames deteriorate much more than the I-frame.

Thus - in our example, when Qcomp was 0, the P and B frames were very information-light.

Let us take a break here and understand what does mbtree does. For that two more tests

Qcomp: 0; Mbtree: On (the strongest mbtree)
x264 [info]: frame I:4 Avg QP:10.51 size:113605
x264 [info]: frame P:34 Avg QP:18.05 size: 24044
x264 [info]: frame B:146 Avg QP:25.76 size: 1188

Qcomp: 1; Mbtree: On
x264 [info]: frame I:4 Avg QP:13.47 size: 73761
x264 [info]: frame P:34 Avg QP:14.00 size: 32968
x264 [info]: frame B:146 Avg QP:15.98 size: 12360

The most obvious thing you will probably notice is that at Qcomp 1; mbtree on or off doesn't make any difference. And also, when we use Mbtree, the I-frames consumed much more space, but the P-frames somewhat less space; and the B-frames a drastic drop in space consumed.

So what exactly happened here?

Mbtree is the answer to the following question - a lot of macroblocks evolve from a macroblock in the previous frame and evolve into macroblocks in the succceeding frame. So are we to look at macroblocks as stemming out from previous macroblocks and leading to succeeding macroblocks?

When I leave mbtree on – I make the reference frame highly detailed and I try to derive macroblocks in p and b frames as trees that emerge from the I-frame. So what are the implications of what we have discussed?

1) When a movie is very grainy and noisy [for instance, some of the 80s movies that are optimised for CRT viewing - we will benefit from high Qcomp]. Why? Because - the movie is very noisy! Thus, even though a b-frame is similar to p and b frames with respect to the actual movie - it is dissimilar with reference to noise. So if your encoder disrespect the b and p frames too much, your encode is going to look like shit. Similarly, a darker movie might not need a high qcomp, since quite a few macroblocks are non-luminated. A typical bluray movie will need qcomp from 0.65 to 0.75. A darker movie might have lower qcomp; and a brighter-grainier will need higher qcomp.

2) When you raise qcomp, your encode's size invariable increases

3) From (1) and (2) so ideally your qcomp should be high enough so that your p/b-frames get enough love; but low enough so that they don't document minor changes that are invisible to the eye. Example of a low Qcomp-scenario is a cartoon.

4) mbtree evaluates macroblocks as trees - when you have a very high qcomp, you are demanding that your b-frames and p-frames be treated respectfully. Thus, when you turn mbtree on at qcomps higher than 0.75, the mbtree is so weak that it will only look at extremely similar macroblocks as trees. Thus you will end up saving some bits, but not losing transparency.

5) The lower the Q-comp the stronger the impact of the mbtree. But read the next para carefully!

Warning: If you turn mbtree on for encodes which use qcomps less than 0.7, you must be very very sure that the source isn't grainy or complex or else you will end up destroying your encode. Turn it off with --no-mbtree; since mbtree is enabled by default.

Finally, IP ratio and PB ratio. As far as I understand, these are again controls that determine how much information must go inside P w.r.t I and P w.r.t B etc.

--aq-strength

Spoiler: mostrar

To me - this is another highly interesting variable. As we have discussed before, P and B frames have macroblocks that depend on macroblocks for other frames. Now the following questions arise – typically, all macroblocks aren’t same, so do you want them to treat them all similarly? Typically, the answer to this question is no. Say you are encoding a live action movie – in which a tanned, beautiful lady with extremely sharp features appears – here is what your AQ will determine for that shot:

The macroblocks that encode the eye, the nose, the lips etc. are highly detailed and are very dynamic – we will look at these as macroblocks that store sharp features. A low AQ preserves these edges and sharp features. Whereas, her clothing that has furls and waves and textures – what is stored there is gradients and contours. A high AQ preserves the texture/gradient. So if I had a low AQ, I will see her eyes as sharper and crisper, but look at her clothing - the finer details, waviness, folds in her altogether black dress will be compromised.

But, the above understanding grossly oversimplifies things. In reality - the quality of source, the graininess of the source, the noisiness of the source changes this game completely. Further, let us not forget the complexity introduced by qcomp and psy-rdo. Let us consider some examples. But before you read anything, bear in mind that these are empirical guidelines but not thumb rules. These should be used for coarse and not fine-tuning.

1) Consider a cartoony source that appears grain/noise-free and where you have chosen a q-comp that is low too, and maybe even enabled mbtree. There are some crisp features and some featureless macroblocks. In this scenario, you have chosen to invest more space/energy into I-frames. Thus, for a given bit-rate, a lower AQ encode (0.4 to 0.6) may look more transparent/better than a higher AQ encode (0.9 to 1.2) – since you have focussed your bits into encoding sharp features and edges.

2) Consider a grainy, high-quality source where you are, say, looking at qcomp of 0.65 or 0.7. An AQ between 0.7 to 0.9 could be helpful. Many high quality bluray sources may come under this category. A higher AQ will make your encode look smudged etc. A very low AQ could lead to loss of detail in clothing/hair etc.

Personally, I don’t know where I have benefitted from very high AQ like say beyond 1.1 or 1.2. They say that noise-free DVD films can use these settings. But I have worked only with shitty DVDs or DVDs optimised for CRTs and I have always found that the facial features and edges lose their detail if I use higher AQ [more than 1.1]. For noisy DVDs I have encoded thus far, I have had more luck with raising the qcomp and keeping the AQ low. For 70s and 80s movies that have shitty DVD transfers, qcomp of 0.75 to 0.85 is what worked for me; and for those I had to use lower AQs.

--psy-rdo

Spoiler: mostrar

Now this is a setting where theory and simulation won’t help you, but actual testing and experimentation is the way to go. Still - I will explain what little I have gathered from reading around and some experimentation.

Consider a set of source frames being encoded; here – in encodes, a lot of finer details and grains can be omitted to create a theoretically more faithful representation of the source [this is called structural similarity]. However, the resultant encode might not appear as sharp or as detailed as the source itself – because the encode is a simplified version of the source. Thus, even though the encode is similar to the source - it will look poor.

Here is where Psy-rdo comes handy. Psy-rdo, based on my rudimentary understanding, encodes to create macro-blocks that are less accurate representations of the source, but have similar complexity as the source. Thus – creating a perception of greater quality.

If you overuse psy-rdo, you will have too many artifacts and the encode will look bad. If you under-use or avoid psy-rdo, the encode will appear poor for the bit-rate. The right psy-rdo can only be determined through testing.

For relatively grain free sources, given the fact that the source is “simple”; you should try out lower psy-rdos [less than 0.6]. For more complex sources, you should try out all psys from 0.9 to 1.3; higher than 1.3 means you are abusing psy and are creating too many artifacts. Even if you manage to get a few transparent screenshots – I would call it a happy coincidence, and will say that your encode will definitely look bad overall. [Did I not tell you that I am an opinionated person?]

I don’t look at psy-rdo in isolation; rather I test it in tandem with AQ-strength. The reason why we do this must be self-explanatory – if you have understood the theory so far

psy-trellis

Spoiler: mostrar

Basically, in some movies some parts of a frame are grainier than other parts. In these cases Psy-trellis can be tweaked to gain transparency at a lowered-bit-rate. It is something that you have to test out after determining the psy – if you see a non-homogeneous grain-distribution.

--deblock

Spoiler: mostrar

Finally, one more setting that I want to discuss for now is deblock. Deblock basically determines what gets blocked. A deblock of -3:-3 is the trend. But if the source is very noisy and blocky – shitty DVD transfers; or VHS to DVD transfers [look up Turkish Rambo] – you will experience success with deblock -4:-4 to -6:-6.

Most important setting

Spoiler: mostrar

The most important setting to me and to many other users is this. --elitism 0. Basically, x264 developers have a right to be proud. The ones that have read their documentation and made information understandable for the rest of us also have reasons to be proud. The rest of us have either plagiarized information, or learned things by hit and trial.

Thank you for reading. Help refine my understanding if you can see that I am wrong somewhere.

This is work in progress.

[Alekhine]

Muchas gracias Gomorrite...

...sin duda todo un tesoro.

[professor keller]

Comparto con vosotros esta guía en inglés para conocer mejor los parámetros de x264.

Muchas gracias, Gomorrite, muy interesante. ¿Lo que tú has publicado es el texto completo? ¿No hay versión online completa? Creo que un texto plano y sin spoilers sería mucho más sencilla de leer y consultar.

[Gomorrite]

Era por no molestar demasiado con un texto demasiado largo, así se puede leer por capítulos. El original está en un tracker privado. TC creo que significa Tehconnection, tracker al que no tengo acceso.

[professor keller]

Era por no molestar demasiado con un texto demasiado largo, así se puede leer por capítulos. El original está en un tracker privado. TC creo que significa Tehconnection, tracker al que no tengo acceso.

OK, gracias, lo paso yo a texto y cuelgo un PDF

Edito: dejo la guía de mael compartida por gomorrite, em PDF: http://www.mediafire.com/?3e2dv53lb8udimq

[DMMD]

Muchas gracias Gomorrite y a keller por el PDF, cuando tenga un hueco le echo una ojeada con mas detenimiento.


Interesante en los --bframes

Verdict: Leave it at 16.


Con respecto a el apartado --psy-rd

"For more complex sources, you should try out all psys from 0.9 to 1.3; higher than 1.3 means you are abusing psy and are creating too many artifacts. ".


Entiendo que por defecto es psy_rd=1.0:0.0, ¿pero como nos aparecería ese 0.9 to 1.3, al que se hace alusión?

[professor keller]

Con respecto a el apartado --psy-rd

"For more complex sources, you should try out all psys from 0.9 to 1.3; higher than 1.3 means you are abusing psy and are creating too many artifacts. ".

Entiendo que por defecto es psy_rd=1.0:0.0, ¿pero como nos aparecería ese 0.9 to 1.3, al que se hace alusión?

Según entiendo el autor dice que en fuentes complejas podría lograrse una mayor similaridad estructural modificando el valor 1.0 que viene por defecto en --psy rdo, entre 0.9 y 1.3.

[roisiano]

Entiendo que por defecto es psy_rd=1.0:0.0, ¿pero como nos aparecería ese 0.9 to 1.3, al que se hace alusión?

La pregunta no está demasiado clara, en mi opinión.

Si te refieres a cómo habría que poner en la instrucción de ripeo un valor de psy-rdo entre 0.9 y 1.3, sería:
--psy-rd 0.90:<lo que sea>
o
--psy-rd 1.30:<lo que sea>

donde
<lo que sea> es el valor de psy-trellis.

Ambos (psy-rdo y psy-trellis) "se ordenan" en la expresión de --psy-rd:
--psy-rd <valor de psy-rdo>:<valor de psy-trellis>.

Aunque puede que esté respondiendo a una pregunta distinta a la que tú planteaste .

---------------

Del manual me sorprende que "pase bastante de puntillas" sobre ipratio y pbratio, que, básicamente, regulan la diferencia entre los quantizers I y P (--ipratio) y P y B (--pbratio), que son configuraciones, que, por ejemplo, tune grain cambia respecto al defecto (1.40 por defecto en ambos casos; 1.10 en tune grain).

Básicamente, tune grain lo que hace es "agrupar" los valores de los quantizers en relación al tune film, que los frames B se "parezcan" más a los P y los P más a los I, que es algo a lo que también conduce el valor más alto de --qcomp en tune grain.

Probablemente esta sea la razón principal por la que "tune grain" consume más bitrate a idéntico crf: porque hay muchos más B frames que P frames, y muchos más P frames que I frames, y si bajas el quantizer de muchos más frames (B), lo lógico es que suba el bitrate total.

A mí el tune grain, por cierto, no me entusiasma. En mi opinión, es capaz de producir excelentes resultados con bitrates muy altos en fuentes muy "granosas", resultados que, a ese bitrate, no podría conseguir tune film.
Desde mi punto de vista, el "nivel de excelencia" (parecido al original) en tune grain (con fuentes "granosas", digo) es mejor que el "nivel de excelencia" de tune film, pero para lograrlo necesitas mucho más bitrate (y habitualmente irte a bitrates y QFs "inasumibles").
Pongamos que a QF de 0.600 el resultado con tune grain es maravilloso y con tune film sólo muy bueno.

Con bitrates y QFs "asumibles", en mi opinión, tune film consigue mejores resultados.
Pongamos que a QF de 0.350 el resultado con tune grain es un "quería pero no he podido" y con tune film es bastante bueno.

Últimamente estoy haciendo algunas pruebas con configuraciones intermedias para fuentes "granosas", y me sigue pareciendo que, con bitrates "razonables" (pongamos que QFs por debajo de 0.450) los mejores resultados los consigo con configuraciones más cercanas a film que a grain... aunque, por supuesto, esto es opinable.

En resumidas cuentas: albergo el íntimo convencimiento de que tune grain "puro" para fuentes "granosas" sólo es realmente útil si estás dispuesto a "gastar" MBs "a mansalva" . Y no veo a casi nadie utilizando tune grain con bitrates escandalosos .

[DMMD]

Entiendo que por defecto es psy_rd=1.0:0.0, ¿pero como nos aparecería ese 0.9 to 1.3, al que se hace alusión?

La pregunta no está demasiado clara, en mi opinión.

Y que lo digas, no era exactamente lo que quería preguntar, me bailo el rdo y por eso la confusión , he releído el manual con mas tranquilidad y con las respuestas que me habéis dado tanto el profe como el citado, tema aclarado

Gracias.

[Gomorrite]

Roisiano, tengo entendido que cambiar pbratio no tiene ningún efecto si no desactivas mbtree, pues éste se encarga de calcular el pbratio óptimo en cada momento. En cuanto a ipratio, pues imagino que tendrá un efecto bastante menor que pbratio.

Creo que en general "tune grain" cambia los parámetros lo hay que cambiar, pero a menudo los cambia demasiado. Ese psychovisual trellis puede ser terrible...

[professor keller]

Ese psychovisual trellis puede ser terrible...

Disculpa, te he citado porque me causó gracia la expresión...

Creo que a veces, en la pasión de nuestro perfeccionismo técnico (que es muy buena) exageramos un poco. Yo no he visto ningún ripeo salido de aquí hecho por Dardo, Roisiano, DMMD, Fronky, etc. (o salido de Allzine de parte de elguaxo, Silien o un servidor) que pueda ser calificado como "terrible" Me parece que, en general, el estándar de calidad de los ripeos X264 de los foros de cine en español es uno de los mejores (si no el mejor) de toda la red, incluso cuando abusamos del tune grain...

[Dardo]

El propio elguaxo nos lo decía de forma clara:

Pero en el caso de películas donde hay un grano grueso, nervioso y furioso cubriendo todo el cuadro, no hay atajos que valgan ya que todo "pesa" lo mismo y los "atajos normales" pueden ser hasta contraproducentes. En estos casos el único camino para lograr un ripeo realmente transparente es --tune grain y ripear con el bitrate necesario.

De hecho si alguna vez dejamos el tune grain un poco de lado no es por calidad que en algunos Blurays cuando comparas capturas a diferentes configuraciones con el original te dejaba pocas dudas que como bien dice elguaxo es la configuración óptima en cuanto a fidelidad con el original, pero por desgracia no tiene sentido ripear un Bluray de 50 Gb para ofrecer un 1080p de 45 Gb por lo que ahí es dónde se toquetea algo más y ver si el resultado compensa o no. Debemos tener claro que cuando se busca fidelidad con el original no todo es ripeable. Nos ocurrió con ciertos DVDs que era absurdo ripearlos y también ocurre con ciertos Blurays. Ocurre que el 720p supone una reducción interesante ya por la propia resolución y que para muchos televisores es de sobra y supone un ahorro de tamaño.

Por otra parte hay ripeos publicados por compañeros con tune grain y que después los comparas con ripeos de la scene, que van más por la línea de toquetear variables y en fin la diferencia es notable no en tamaño en calidad.

Creo que está muy bien dominar y conocer todo lo que podamos, eso nos dará mayor agilidad para saber qué hacer con cada vídeo pero para mí la experiencia de uno mismo es muy importante y no hay nada más "educativo" que ir tomando un bluray y hacer varias pruebas, un dvd y lo mismo, el siguiente bluray igual, un HDTV y al final casi de forma intuitiva sabes lo que te está pidiendo cada uno de ellos.

Tengo la buena costumbre de mencionar a elguaxo, y es que para mí ha jugado un papel fundamental en muchos de nosotros ya que no he visto a nadie con su dominio, solución para todo y lo más importante una paciencia inmensa en explicar lo que muchas veces eran cosas triviales una y otra vez. Si nos está leyendo estoy seguro que dirá mira estos pipiolos que no tenían ni idea y ahora se atreven a dar consejos e incluso rajar de ripios de la scene , y tiene razón al menos lo pienso muchas veces pero por otro lado también creo que como bien dice keller nuestra trabajo ahí está, sin ocultar nada, y son muchos ya los ripeos que se llevan compartidos y cuando después se comparan con lo que hay por la red lo cierto es que no se puede decir que tengamos nada que envidiar a nadie todo lo contrario.
Son muchos los compañeros que han ido enriqueciendo este hilo de filtros y codecs, pero me parece justo y necesario el agradecer a elguaxo todo el trabajo que ha hecho mientras participaba en estos foros. A buen seguro que si estuviera por aquí ninguno de nosotros diría nada ya que él tendría la respuesta exacta con la solución precisa, pero nos pasa como al Barsa, no está Messi y entre todos tenemos que ir ayudándonos, mono de currantes y cada uno aportar lo que pueda.

[Jacob]

[video]http://www.youtube.com/watch?v=cTabjtDtJ7M[/video]

[professor keller]

De hecho si alguna vez dejamos el tune grain un poco de lado no es por calidad que en algunos Blurays cuando comparas capturas a diferentes configuraciones con el original te dejaba pocas dudas que como bien dice elguaxo es la configuración óptima en cuanto a fidelidad con el original, pero por desgracia no tiene sentido ripear un Bluray de 50 Gb para ofrecer un 1080p de 45 Gb por lo que ahí es dónde se toquetea algo más y ver si el resultado compensa o no.

Yo no tengo mucha experiencia ripeando Blurays (sólo he ripeado uno) porque justo cuando comenzaron a emerger en la red con más fuerza me mudé a una zona en la que apenas si puedo conectarme a internet para leer foros... Pero en toda mi experiencia ripeando DVDs, que fue mucha, casi siempre terminaba utilizando --tune grain después de las pruebas, porque, en general, era la configuración que mayor fidelidad con la fuente me ofrecía, sin incrementos de tamaño preocupantes (exceptuando, claro, el material "inripiable" al que hace referencia Dardo). Pero estoy también con Dardo en que el ripeo HD ha cambiado todas las fichas en ese sentido, porque es necesario encontrar un compromiso mucho mayor entre calidad y tamaño. Ripear un DVD en 2,5 GB no entrañaba mayor problema a la hora de distribuirlo, pero ripear un Bluray a 12 GB, por decir algo, sí lo entraña, porque aun pesando la mitad de lo que pesa la fuente sigue siendo mucha data para transmitir y almacenar.

[Gomorrite]

No sé a qué llamáis inripeable, incluso ripear un Bluray al 60% de su tamaño original siguen siendo un ripeo y no creo que haya muchos casos así de extremos.

Ese psychovisual trellis puede ser terrible...

Disculpa, te he citado porque me causó gracia la expresión...

Creo que a veces, en la pasión de nuestro perfeccionismo técnico (que es muy buena) exageramos un poco. Yo no he visto ningún ripeo salido de aquí hecho por Dardo, Roisiano, DMMD, Fronky, etc. (o salido de Allzine de parte de elguaxo, Silien o un servidor) que pueda ser calificado como "terrible"

Pues claro que no, yo no he dicho eso. Cualquier ripeo, incluso con los parámetros equivocados, tendrá una calidad alta si se utiliza el bitrate suficiente, y aquí todo el mundo parece estar ripeando con bitrates más que decentes. En realidad para ripeadores que buscan la máxima calidad, toquetear los parámetros (y hacerlo bien, no como los ripeos de la scene que parece que lo hagan al tuntún) tendrá el objetivo de reducir el tamaño del archivo a igualdad de calidad.

Es cierto es que un psychovisual trellis alto puede especialmente perjudicial precisamente para gente que intenta ripear con muy alta calidad. Como ya dije, creo que los "tune" están pensados para ser usados en combinación con CRFs más altos.

Me parece que, en general, el estándar de calidad de los ripeos X264 de los foros de cine en español es uno de los mejores (si no el mejor) de toda la red, incluso cuando abusamos del tune grain...

No, he visto grupos de ripeo en trackers privados con estándares increíble e incluso exageradamente altos, donde cada ripeo tiene que ser votado por el resto de miembros antes de ser subido y se rechazan por lo que llaman "grain shift". Eso significa que el grano oscila ligerísimamente entre la fuente y el ripeo, lo cual realmente es inapreciable cuando se reproduce el video.

[Dardo]

No sé a qué llamáis inripeable, incluso ripear un Bluray al 60% de su tamaño original siguen siendo un ripeo y no creo que haya muchos casos así de extremos.

Hay más de lo que te piensas, en DVDs muchas veces con ciertos filtros de compresibilidad el compromiso de pérdida con respecto a la fuente era eficiente y te permitía hacer un ripio, en otros casos no había forma de meterle mano, el ripeo no compensaba. Con ediciones en Bluray como digo la ventaja es que un 720p ya supone una reducción importante y es el tamaño que más manejamos varios, pero eso no quiere decir que hayamos visto ripeos que de hacerlos en 1080p nos íbamos a tamaños poco recomendables, aunque en eso opino como tú que cualquier reducción bienvenida sea.

Como ya dije, creo que los "tune" están pensados para ser usados en combinación con CRFs más altos.

Creo que no debemos confundir conceptos. Utilizar CRF alto implica bajar bitrate y eso no ha de compensarse con un tune agresivo. El compromiso de variables lo entiendo de otra forma y según está configurado el codec parece que los desarrolladores también.

En DVDs la horquilla de trabajo del CRF estaba más que analizada, y para Blurays la experiencia me dice que los tune prederteminados no funcionan nada bien para CRF altos, de hecho arrojan ripeos que en fuentes exigentes no quedan nada bien. Ahí es dónde veo interesante para la gente que busca ripeos denominado microhd (mal invento que nunca he entendido) toquetear varios parámetros para de alguna forma intentar mantener la esencia de la imagen sin penalizar mucho el tamaño del archivo. La fidelidad al original quedaría en un segundo plano.
Estamos volviendo un poco al principio de ciertos debates, pero estas cosas son muy fáciles de comprobar, se pilla uno un Bluray competente y empieza a hacer pruebas y se da solito cuenta de lo que digo.

Me parece que, en general, el estándar de calidad de los ripeos X264 de los foros de cine en español es uno de los mejores (si no el mejor) de toda la red, incluso cuando abusamos del tune grain...

No, he visto grupos de ripeo en trackers privados con estándares increíble e incluso exageradamente altos, donde cada ripeo tiene que ser votado por el resto de miembros antes de ser subido y se rechazan por lo que llaman "grain shift". Eso significa que el grano oscila ligerísimamente entre la fuente y el ripeo, lo cual realmente es inapreciable cuando se reproduce el video.

Está claro que hay gente por ahí fuera que ripea estupendamente, incluso son más frikis que nosotros, aunque entiendo que el grupo HANDJOB del que publicaste el ripeo The Other no es alguno de estos grupos que mencionas porque yo tengo algún DVDRip de ellos y me bajé el 720p para analizarlo y confirma lo que ya comprobé en el DVDRip que tenía de ellos y es que sus trabajos en fuente granulosas tienden al sobredimensionado, al igual que le pasa al Grupo DON sin duda alguna son ripeos buenos porque no arriesgan nada pero no son ripeos optimizados calidad-tamaño.
Por otro lado no soy dudoso yo de ser defensor de la Cofradía del Grano, pero el "grain shift" en fuentes HD como alguna vez hemos hablado Keller y servidor cuidadín, que después en pantalla lo que tenemos es grano revoltoso también llamdo ruido por ahí bailando. Además como bien dice elguaxo y yo me he topado con ello, hay ripeos que si queremos "clavar" la densidad granulométrica del Bluray el ripeo ocuparía lo mismo que la fuente, y es que no existe ninguna configuración ni filtro tan mágico que mantenga la calidad esa densidad con ganancia de tamaño, pero vamos esto es algo matemático no teórico. Existen filtros para reducir ruido y artefactos que también los hay en los HD y por lo tanto variar este aspecto con respecto al Bluray es algo no recomendable, obligado.
En fin que todo lo que sea buscar calidad y ser rigurosos con ella perfecto.

[Gomorrite]

No, HANDJOB es un grupo que pone unas condiciones básicas mínimas que aseguran una calidad aceptable, pero no exige optimización y por lo tanto no asegura que no le sobre o falte bitrate. Es un grupo enfocado a iniciar a gente al ripeo, pero también hay muchos miembros bastante experimentados. Y no creo que se tienda al sobredimensionado, realmente hay de todo. Especialmente las granulosas dudo mucho que estén sobredimensionadas, sino todo lo contrario. Un grupo de calidad hubiese rechazado mi ripeo de The Other por excesiva pérdida de grano (realmente tiene pérdidas sólo en algunas zonas concretas de la imagen) o grain shift y probablemente lo hubiesen aceptado a unos 9GB.

No he entendido lo que dices del grain shift. No me refiero a ningún filtro, me refiero a cuando a pesar de tener fuente y ripeo la misma densidad y apariencia de grano, el grano se mueve ligeramente de posición entre uno y el otro. Es algo imposible de apreciar reproduciendo el vídeo.

[professor keller]

Me parece que, en general, el estándar de calidad de los ripeos X264 de los foros de cine en español es uno de los mejores (si no el mejor) de toda la red, incluso cuando abusamos del tune grain...

No, he visto grupos de ripeo en trackers privados con estándares increíble e incluso exageradamente altos

Puede ser, claro. Al hablar de "red" me estaba refiriendo al p2p. Los trackers privados son otra cosa.

[Gomorrite]

no son ripeos optimizados calidad-tamaño.

Bueno, leyendo esto me da la impresión de que entendemos cosas distintas por optimización. No me refiero a optimizar un compromiso calidad-tamaño, pues eso al fin y al cabo es subjetivo y ni siquiera lo llamaría optimización. Me refiero a optimizar tamaño para una determinada calidad buscada (la que sea).