OPV & Multipass Experiments

[dragongodz]

(but limiting to 4 or 5 the VBR encodings)
i imagine you will be able to get the test done in half the time or twice as many in the same time doing that. :)

I would repeat the whole test
so you want to have factors such as, dif matrix + bitrate + footage type + passes = result ? which will show not only the difference pass count makes to different types of footage but also how different matrices have an effect aswell. just a little bit of work. :)

Maybe an anime (Balto ?)
Balto ? umm i think we should be able to come up with something better than that when the time comes. :D

my experience in encoding anime movie is very very limited. I am almost sure it is better to change at least quality_prec from 16 to 24 or to 32, from the default of 16. Have you further suggestions on the matter ?
well i dont own CCE so not really, i have only used the trial version in regard to working on calling its plugin(by DVDx). that may raise the question then why am i even interested i know. well short answer is because i just find it interesting, besides which i may decide to buy CCE Basic in the future(i could never afford SP). i dont own a top of the line sports car either but still find it interesting to read about their capabilities and how they perform. :)

[akupenguin]

Originally posted by dragongodz
i imagine you will be able to get the test done in half the time or twice as many in the same time doing that. :)
Why would skipping 5 out of 20 passes save half the time?

@Didymus: You are just running a total of 10 vbr passes and 10 opv passes and reporting the results after each one, right?

[dragongodz]

Why would skipping 5 out of 20 passes save half the time?
i didnt mean literally. its just a saying meaning a great deal of time would be saved. geez.

[Sir Didymus]

Originally posted by akupenguin
Why would skipping 5 out of 20 passes save half the time?

@Didymus: You are just running a total of 10 vbr passes and 10 opv passes and reporting the results after each one, right?

Hi, akupenguin, :)

Well, no...

Actually the test, for each of the given Quanti Matrices, and for each of the given bitrates, is performing OPV and VBR encodings with passes from 1+1 to 1+9. So the total number of encoding passes is 56 for each "column" of the SSIM comparison tables... [except in the very specific situation of the Ultra Low Quanti Mat at 1250 Kbytes/s, where three OPV encodings instead of two were done...].

So limiting the test up to 1+5 VBR passes will save 34 encoding passes for each column, and the time saving would be 34/56 which is much more than 50% of the time...

Hope it is clear...

Cheers,
SD

Edit. If you need some further description/information about the procedure adopted for the test, you may find some ones in this thread, (it was closed due it went "a little bit" off track..., but it still contains some useful background info...):
http://forum.doom9.org/showthread.php?s=&threadid=85331&perpage=20&pagenumber=2

[Sir Didymus]

Originally posted by dragongodz
so you want to have factors such as, dif matrix + bitrate + footage type + passes = result ? which will show not only the difference pass count makes to different types of footage but also how different matrices have an effect aswell. just a little bit of work. :)

Exactely...
I really agree it may be not simple to draw some conclusions (if any is even possible, due to the known limitations of the "objectivation" tool, which is SSIM) from such big amount of data, but I really prefere being systematic and complete as much as possible...

After all, while carrying out these tests, I have the feeling (the hope ?) I am improving my experience with the CCE encoder much more than just doing some backups of my DVDs... So the time I am spending on the subject should be hopefully a good investment, from my very personal point of view...


Balto ? umm i think we should be able to come up with something better than that when the time comes. :D

Hey dragon, what do you have against the most lovely wolf in the world ? :p Please consider Christmas is approaching... And nothing can make your heart wormer than a movie of Balto... :cool: [glasses just to mask the eyes...]

It is very popular in this timeframe here in Italy...

Anyway I am open to discuss about VALID alternatives... :)

[dragongodz]

what do you have against the most lovely wolf in the world ?
nothing. i bought my son the first one years ago and he enjoys watching it. the fact is though that it is not anime but american animation(amblin).

I am open to discuss about VALID alternatives.
yes maybe we could even do a poll as to what anime would be a typical representation. if all else fails then Balto would be better than nothing. ;)

[akupenguin]

Originally posted by Sir Didymus
Actually the test, for each of the given Quanti Matrices, and for each of the given bitrates, is performing OPV and VBR encodings with passes from 1+1 to 1+9. So the total number of encoding passes is 56 for each "column" of the SSIM comparison tables...

So limiting the test up to 1+5 VBR passes will save 34 encoding passes for each column, and the time saving would be 34/56 which is much more than 50% of the time...

Disclaimer: I have never used CCE, and if I ever decide to encode something to MPEG2, I will be using ffmpeg. But my high-level discussion of ratecontrol should be independent of the codec.

Here's my proposed encoding process, assuming I don't grossly misunderstand the operation of CCE:
1st pass just performs compexity analysis, and doesn't output any video.
2nd pass (1+1) takes that analysis, performs bit/quantizer allocation based on it, and encodes. It also performs another round of complexity analysis. You keep this output video, and run your SSIM or whatever on it.
3rd pass (1+2) takes the analysis from 2nd pass to refine ratecontrol, encodes to another output video, and runs another round of analysis. You keep this output video, and run your SSIM or whatever on it.
...
10th pass (1+9) does the same.

Total: 10 passes, 9 video files. (plus the OPV encodes)


I'm assuming you don't have to tell CCE in advance how many passes you're going to give it. I could imagine a very smart codec might decide what options to evaluate based on how many passes it's going to run, and use all previous stats rather than just the last pass. But if CCE did that, then you wouldn't be seeing an oscillation in quality.

If I'm right, this will reduce your total time from 56 passes per setting to 21, while producing outputs what are bitwise identical to what you're getting now.

[Sir Didymus]

Originally posted by akupenguin
Disclaimer: I have never used CCE, and if I ever decide to encode something to MPEG2, I will be using ffmpeg. But my high-level discussion of ratecontrol should be independent of the codec.

...

Total: 10 passes, 9 video files. (plus the OPV encodes)

...

I'm assuming you don't have to tell CCE in advance how many passes you're going to give it.

...



I now understand what you mean...
I have to tell you assumption is wrong: actually you have to specify to CCE how many VBR encoding passes you want to perform in advance.

If you want to produce (and compare) two CCE encodings, for example based on 1+2 and 1+3 VBR passes, you should start two different CCE sessions, performing in total 7 encoding passes. And the second session should restart from the beginning. It would be very nice and useful to follow your idea, but it is simply not feasible...

Cheers,
SD

[akupenguin]

OK, now I'm wondering whether it actually makes use of the knowledge, or whether the restriction is just a misfeature. I mean, I could easily understand that that they might do it that way in the name of user-friendliness, without any technical justification.

And people wonder why I consider open source to be one of the most important features of a codec...

[robot1]

Originally posted by Sir Didymus
If you want to produce (and compare) two CCE encodings, for example based on 1+2 and 1+3 VBR passes, you should start two different CCE sessions, performing in total 7 encoding passes. And the second session should restart from the beginning. It would be very nice and useful to follow your idea, but it is simply not feasible...

Cheers,
SD Probably you could act as suggested, doing always one pass of VBR pass, using the last .vaf created.
If you've done 1+1, the result will be just like the output of 2+1.
(You could do a test to check with a binary compare).
With every added pass, you get a result for your test.

[Sir Didymus]

Hi robot1, :)

Could you please point me out where, in the CCE User Manual, the behaviour you suggest guarantees to obtain the result you mention ?

I heard the same other times (never personally verified, I have to say...), but in order to be totally sure the data reported in the test are actually the same as the ones generated by DVD-RB, I can not do anything else than exactely replicate what is doing DVD-RB in its encoding sessions.

I can not assume undocumented features (even though commonly accepted as valid) as facts. Even if the binary compare shows what you say for one single (or even for many) encoding(s), nothing guarantees this holds for all encoding passes...

Of course, ready to change my position in light of further news/info on the matter...

All the best,
SD

[akupenguin]

While I can't find any official info reguarding the workings of multipass, the user's guide does guarantee that you can use the same 1st pass VAF for all of the encodes. See http://www.cinemacraft.com/files/doc/ccs_270e.pdf page 35.

[Trahald]

doing a 1+3 (vaf+3) gives output that is is bitwise equivelant as doing 1+1 three times (using the same vaf file the 2nd and 3rd time.. it works for any number of passes. (did some quick testing to be sure)

[jdobbs]

Robot1 and Trahold are correct. I can assure you that running a single VBR pass four times is the same thing as running a four pass VBR encode. I wouldn't call it three (1+1) encodes, though, as each time you run it it will only do a single pass (because the VAF exists and is used from the previous pass. CCE will not do a .VAF pass if the .VAF already exists.

[Trahald]

yeah.. wasnt the best explanation. its more a 1+1 +1 +1

[Sir Didymus]

Hmmm, well, good to know...
Especially in light of the big time saving it implies...

I have to say that the User Manual is of no help: it clearly describes what to do for re using the VAF file, but it never states what you get...

I will do a simple further check (mostly for my own confidence), binary comparing the results, already available, of the Notch encoding...

If everything goes right, gonna changing the encoding procedure in order to perform the test with the Bach1 Quanti Mat (and the following...) using the described approach.

MANY THANKS for the fundamental contribution to akupenguin, robot1, Trahald and Jdobbs...

If everything is ok, in one of my next post I will report the number of encoding passes up to now spent unnecessarily... :scared:

Cheers,
SD

[Sir Didymus]

Well, as indicated, (many thanks guys!) the encoding following the scheme:

1+1 +1 +1 ...

works fine, and the results of the stepwise encodings are totally equivalent to perform the multipass as a whole. Tested on a couple of "columns" of the Notch Quanti Mat test... I have to admit my ignorance about this feature (let me just underlne again the CCE User Manual is not providing any enlightening on the subject...)...

Anyway, this will reduce the whole encoding time for the test at someting like the 20% of the previous...

Of course the way I am looking at this nice feature is not the thinking at the (huge :scared: ) amount of time wasted up to now... but considering that I am now working like having a PC running at 15 GHz !!! WOW!!!

Many thanks again to akupenguin and robot1 for the great suggestion...

Taking the opportunity for posting the SSIM results based on the KVCD Notch Quantimat Encodings:

http://img94.exs.cx/img94/9703/avgssimkvcdnotchmatr4oi.gif

http://img109.exs.cx/img109/7022/sdssimkvcdnotchmatr9ca.gif

http://img110.exs.cx/img110/1037/filesizekvcdnotchmatr5qk.gif

Cheers,
SD

[tylo]

Originally posted by jdobbs
Yes the VAF pass is nothing more than a first pass. In you want, you can even replace it with a OPV or CBR pass for creating the VAF.
Chapter 3.3.4 of the CCE manual:

Unless above parameters are changed, you don’t need to recreate
video information file. If the setting of the bitrate is a major change,
however, it is better to recreate the video information file because a
better encoding result can be obtained with less number of passes.
When an average bitrate is set to twice or more or half or less than
that previously specified, recreating the video information file is recommended.

This indicates that the .vaf file is somewhat different depending on avg. bitrate or Q (if OPV) chosen when creating it...

[jdobbs]

Absolutely.

If you do an OPV or CBR pass the .VAF is going to be based upon the Q or bitrate you selected. If you set it more than twice or half the target bitrate you've really over/underestimated...

BTW, haven't heard from you in a while, Tylo (the OPV master), how's it going?

[tylo]

I'm doing great, thank you! A little quite here yes, but I did make a small update on my little precious (d2sroba) a few days ago! :D

Btw: Interesting thread. Nice to see you people are keeping up the good work.

[Sir Didymus]

Just learning from the masters...
:)
By the way, your previous post and the one of Jdobbs helped me to understand better what was Boulder referring to, when he spoke, few pages above, about the possibility of performing one OPV pass for producing a VAF file, followed by a VBR pass, in order to have a very precise matching with a desired target avg bitrate.

Do you think (while I am doing 100 encodings, one more costs just quite little) it is worthwile to include this "mixed mode" encoding in the SSIM comparison tables ?

Cheers,
SD

[Boulder]

There is a slight difference when the vaf file is created by a OPV encode or a simple first pass of a multipass encode. If the Q value is predicted well enough, which it usually is, the average bitrate of the OPV encode is closer to the final target than the one that comes out with the first pass.

To me it looks like that the standard vaf file creation pass does almost CBR, and it often ends going much lower than the target. OPV is more like constant quantizer encoding. If there's anything to refer to, I'd like to point out that XviD does the first pass with a constant quantizer and DivX5 uses constant bitrate. Many people feel that DivX5 needs the third pass to come out with matching quality. Of course, these assumptions need to be taken with a grain of salt, but it's some food for thought anyway.

In short, it might be worth checking. However, it's your own time you're using so the decision is of course yours:)

[TheSeeker]

I guess im kind of lost as to what we are exploring here. Are you guys saying that using OPV to generate the vaf file might give a more accurate roadmap to the video stream than the first vaf pass of a multipass encode?

[jdobbs]

I really don't think so -- but I wouldn't be my life on it. The second pass is going to readjust upward (on high demand) and downward (on low demand) to approximately the same level either way. So performing a CBR first pass at the target average bitrate would pretty much do the same thing.

[J-Wo]

hey guys, I just stumbled upon this thread which was so timely because I was jsut doing my own informal comparisions b/t OPV vs multipass (1+1), and notch matrix vs standard. For years now I've been using the notch matrix and OPV with great success, but it is only now with Rb that I've tried others. Oh, and for those that say the disadvantage of OPV is poor file prediction, you should give Rb-Opt a try! It performs the prediction for you flawlessly and in a very short time too.

Based on the movies I've done, I find that notch and OPV makes natural film grain look more blocky, and very dark scenes lack detail and manifests itself as dancing dark grey/blue/purple squares where shadows should be. So for now I'm sticking with std matrix and 1+1 VBR. I'd love to go over a bit more of your results, sir didymus.

One question tho: for your notch encodes, did you also change DC precision to 8, Gop length to 15, and Quantizer characteristics to 25? These settings were recommended for DVD-Rb use in a thread over at kvcd.net and can be set using Rb-Opt.

[Sir Didymus]

Originally posted by J-Wo
One question tho: for your notch encodes, did you also change DC precision to 8, Gop length to 15, and Quantizer characteristics to 25? These settings were recommended for DVD-Rb use in a thread over at kvcd.net and can be set using Rb-Opt.

In short: no, no, no...

I mean, I know the recommended setting at kvcd.net is not just limited to the usage of the Notch Matrix in itself, but in the performed test, for obtaining results comparable with the other encodings (where just the usage of different matrices is a parameter) it has been necessary not to change any other parameter that may affect the compressibility.

In other words, thanks to the excellent application of robot1, it is very easy (and maybe convenient) to change a lot of CCE parameters. For example, it is very clear to me that extending the GOP length to 15 frames lead to an improvement of the compressibility.

But this equally holds for all of the matrices..., so since it is not a standard setting of DVD-RB, just preferred not to modify more than a single parameter (the matrix) for each test...

I think the focus of the test is just to perform a relative comparison among OPV and VBR multipass encodings, trying to understend if it is really useful to perform many VBR passes, how many, and why.

Even with such a "little" objective, possible answers will be necessarily subjective and limited. If you want to find the best possible CCE settings I think you will get no answers at all in this thread... ;)

Cheers,
SD

[Sir Didymus]

Originally posted by TheSeeker
I guess im kind of lost as to what we are exploring here. Are you guys saying that using OPV to generate the vaf file might give a more accurate roadmap to the video stream than the first vaf pass of a multipass encode?

Hi, friend, :)

That was my question !!!

Just to clarify: Due to my deep ignorance on the subject, (and to the dammit writers of the CCE User Manual :devil: ), I have been a little bit surprised from the understanding that the nth step of a VBR multipass encoding is just obtainable with a single VBR step, adopting the VAF file produced at the nth-1 step.

This means that the VAF file in itself is extremely important in the multipass encoding, since it basically contains all information about the previous n-1 steps.

As a consequence the way of producing this VAF file is fundamental...
...And it may be the case to add just another row in the tables...

My feeling is totally matching with what stated lastly by Jdobbs, and I am quite convinced that an extraordinary change in the SSIM values will be hardly obtainable, but you know, I am curious by nature, and this "discovery" :D about the VAF relevance is a nice stimulus to do some more encodings...

SD

[Sir Didymus]

Originally posted by Boulder
In short, it might be worth checking. However, it's your own time you're using so the decision is of course yours:)

Hey Boulder...

LOL...
That is exactely the deeply motivating and encouraging type of answer I was looking for... :D

[Boulder]

Could you feel the weight of the sudden additional responsibility?

:D

[pg55555]

Sir Didymus
That is exactely the deeply motivating and encouraging type of answer I was looking for... How about this:

Thanks to your testing I have reduced my standard encoding setting from 1+4 to 1+2, roughly reducing my encoding times from 5 hours to 3 hours, a 2 hours saving. This actually was not so important for myself, as I ussually do the encoding overnight (and I try to sleep more than 5 hours).

But it means two less hours for encoding in which my Pentium 4 will not be running at almost 100%, consuming 90W.

So, you have helped me (and possible many others) to "Save the Earth"!!! (and some pesos from my power bill)

Keep the good work

Pablo

[tylo]

I am not convinced that CCE manages to adjust the bitrate to be perfectly distributed in the second pass. In theory it should, but I then wonder what is going on in the subsequent passes...

However, I think it is possible to test whether an OPV created vaf is "better" than a CBR/VBR one by:
1. Create an OPV vaf with some chosen Q.
2. Add an extra VBR pass to it with exactly the bitrate that the OPV pass produced.
3. Create a new VBR + 1pass file with bitrate as above
4. Compare the two videos produced

[Sir Didymus]

Hi tylo,

Just to undestand what you mean:

a. Which way do you calculate the exact bitrate of your point 1. ?
b. due to some unavoidable rounding errors it seems to me it will be very difficult -- or better almost impossible -- to feed CCE with exactely this value... so is your argument, let me say, theoric or are you really suggesting an experiment to carry out ?
c. When you say "compare", in your point 4., do you mean binary compare, evaluate SSIM differences, or through subjective comparison ?

Cheers,
SD

[tylo]

Hi SD, I meant that you can carry out the test if you want.

a)
Select a realistic Q about 25 ~ 30, encode.
bitrate (kbps) = 8 * mpv_filesize_bytes / number_of_frames * framerate / 1000.

b) You can compute exactly the bitrate. Num of frames (shown in CCE), filesize in bytes (Properties menu in explorer), and framerate is 25 (PAL) or 29.976 (NTSC)...

c) I meant both evaluate SSIM differences and subjective comparison, although the latter will be difficult, I can assure you...

Cheers.

/Add: you may try a higher Q - it will likely give bigger differences (if any).

/Add 2: If you do the tests (I for one will be grateful), can you supply the SSIM values after the OPV pass too. Some have claimed that a following VBR pass, which not resize, may actually degrade the quality, or at least not improve it, because it is optimal already...

[Sir Didymus]

Ok. with the Bach1 matrix (see the enclosed results), the encodings and SSIM calculations for this cell of Kill Bill Vol.1 are complete...

At the usual results, I added the SSIM evaluations for including a single VBR step using the VAF file after a OPV encoding. Since the tables becomes even more extended, in a minimum attempt to reduce their visual size and to improve the general readability, the results are posted as thumbnail. I will edit the previously posted tables in the same way in the next days...

As you may see this matrix shows some interesting characteristics from the point of view of improving the encoding compression. I will do some subjective evaluations in the next days (of the next year, most probably... :D ) in order to check what are the drawbacks, if any...

Cheers,
SD

http://img65.exs.cx/img65/3913/avgssimddoggbach1matr6ag.th.gif (http://img65.exs.cx/my.php?loc=img65&image=avgssimddoggbach1matr6ag.gif)

http://img65.exs.cx/img65/4214/sdssimddoggbach1matr7vs.th.gif (http://img65.exs.cx/my.php?loc=img65&image=sdssimddoggbach1matr7vs.gif)

http://img76.exs.cx/img76/7172/filesizeddoggbach1matr6zs.th.gif (http://img76.exs.cx/my.php?loc=img76&image=filesizeddoggbach1matr6zs.gif)

[Sir Didymus]

Well, I carried out some test...
Hope it is useful in some way on this fascinating comparison subject...

First of all (just want to state it again, especially at the benefit of all occasional readers), I will never say enough that this SSIM index is a very nice and appropriate tool to numerically evaluate ïmage similarities, having many strong and good properties, but it shouldn't be taken as a metric for the quality assessment of your encodings. Quality is subjective, and, as already stated many times by people much more experienced ans skilled than myself, your eyes are the only valid instrument to use for measuring the quality...

Said this, please find attached another table... Well, that's right, it looks like recently I was not able to post anything else than tables... so I am a now quite seriously worried my way of communicating is becoming, a would say, a little bit too schematic :) ...

That's why, in order to balance the numbers, I'd like to give some explainations on how to read it (not to the masters, of course, but again, think occasional readers may find useful to have some hints on the subject).

The starting stream is composed by one cell (6797 frames) extracted from the movie Kill Bill Vol1 - R2 - PAL - Italian Edition; it is the famous scene where Vivica Fox is attacked in her house by Uma Thurman... The cell is composed by high dynamics parts (very high I would say)... together with some other static parts...

The stream has been encoded adopting tkeaked versions of an ecl file generated with DVD-RB...

In the table there are three blocks, since the test suggested by Tylo has been repeated three times, in order to check different Q values (Q28, Q34, Q42).

Initially the stream has been encoded using a single OPV pass, and the relative SSIM index has been calculated. The completion of this step allows to fill the first four columns of the table, i.e. filesize of the encoded m2v stream, bitrate, using the formula pointed out by Tylo himself, and SSIM values (average and std. deviation, calculated on the first 6795 frames of the stream).

As you may see the obtained bitrate, which have a precise value, but is not an integer, generates two bitrate values (ceil and floor rounding of the bitrate), so two 1 pass VBR encodings have been produced after this OPV step. For example, in the first row of the table the bitrate obtained after the OPV step is 4286.643 Kbit/s, and a VBR step was performed with the average bitrate values of 4286 and 4287 fed to CCE.

The completion of this step allows to fill the last columns of the table, including the filesize of the m2v stream at the end of this second step, its bitrate, and the relative SSIM values. As it is possible to observe, the obtained final bitrate is in some ways not optimal, so two more bitrate values (in the example 4291 and 4292 kbit/s) have been empirically identified in order to produce, if applied as avg bitrate of a single VBR pass after the OPV, a bitrate better matching the target. In the example, the given bitrates, fed to CCE, generate the two bitrate values of 4282.477 and 4292.003 for hitting the target of 4286.643.

The other rows in each test have been produced, using a normal 1+1 pass VBR encoding, for tabulate all of the meaningful bitrates involved in the experiment. In the example, all of the bitrate values between 4286 and 4292 have been tested.

The table contains three Q values, just for trying to replicate the test on some different bitrate "domains".

Conclusions:

- I am really embarassed this very simple test proposed by Tylo has assumed this huge dimension: the whole fileset for this "little experiment" alone is 3.53 GB... I was surprised on my own, while doing the test of its growing... And we'd better considering it is still improper to draw any general conclusion: just a single cell was used, of just a single movie, with just three Q values... Almost nothing from the statistical point of view...

- didn't even try to perform some subjective analysis: when average SSIM differences are (like in this experiment) in the order of few ppm, it's absolutely impossible to observe any relevant difference. This is my experience. So please do not to ask to my poor eyes to perform a meaningless effort...

- by looking at the SSIM values, I would say that there is some argument in favour of people claiming that a OPV pass, followed by VBR one, which is not resizing, may actually degrade the quality, or at least not improve it, because it is already optimal...

All the best,
SD

P.S. maybe I am a bit early, but let me take the opportunity for wishing all the friends and nice people of this beautiful forum a Merry Christmas and an happy new year...

http://img67.exs.cx/img67/2595/constqtest1kp.th.gif (http://img67.exs.cx/my.php?loc=img67&image=constqtest1kp.gif)

[bobwillis]

Re: VBR and OPV.

Similar discussions have occured in the past; here are my previous thoughts (bottom of page).

http://forum.doom9.org/showthread.php?s=&threadid=73959&highlight=vbr+bias

For me, it comes down to whether or not you prefer a constant quantization encode. The visual differences become more apparent as the Q level increases.

Regards,
Bob

[Sir Didymus]

@bobwillis.

Hey, thanks for the reference!!!

Just ended the reading of the thread, and...

Well, it seems incredible to me, I am reading almost daily the posts in this forum, since the beginning, but I have to admit I completely missed that very intersting and helpful discussion... :rolleyes:

All the best,
SD

Edit: Anyway, I know the topic has been widely discussed and investigated in a much more strong and complete manner elsewere. I just started to carry our some tests on my own, since I had the perception that too much discussions and opinions were proposed, while not so many documented results were posted to balance them...

[jdobbs]

Hey, Sir Didymus...

Go shopping, get some rest, drink some eggnog... Merry Christmas.

[Sir Didymus]

LOL, :D

Quoted, quoted...
Really need to do all you suggest...

SD