Is that possible ?

[ookzDVD]

Dear XviD forum,

I really want to ask some questions here,
hope people here could suggest me what should I do,
but first let me tell you my situation.

The situation :
1. I mostly watch my XviD in my TV use TV/out,
as far as I know, TV is interlace display,
based on luke's guide ;)

2. All my DVD mostly in NTSC 29.97 fps format, with
interlace video.

3. I want to convert all DVD to the XviD and


My question is :

1. Should I perform de-interlaced to all my DVD when
converting them to the XviD ?

According to the luke's interlace guide,
if I want to see the XviD in the interlace display (TV)
so I don't have to perform de-interlace.

2. Is the XviD support interlace encoding mode ?

The one which we could find in the TMpgEnc settings when we
encoding Mpeg1 or Mpeg2 file with interlace source.

3. There are lots of XviD build released,
which one is suitable for me based on the situation I have.

Thank you.

[-h]

1. I mostly watch my XviD in my TV use TV/out,
as far as I know, TV is interlace display,
based on luke's guide ;)

This is true.

2. All my DVD mostly in NTSC 29.97 fps format, with
interlace video.

This is probably also true.

1. Should I perform de-interlaced to all my DVD when
converting them to the XviD ?

That is a matter or personal preference. If you're watching on a TV, I dare say true interlaced content would look better.

2. Is the XviD support interlace encoding mode ?

Yep, it's bug-free, and I'll add a checkbox for it to CVS tonight. Hopefully with the assembly speedups too. It's not feature-complete, but it should look far better than trying to compress interlaced content manually.

3. There are lots of XviD build released,
which one is suitable for me based on the situation I have.

Whichever's newest! :)

-h

[trbarry]

If you are going to be keeping interlace throughout and are willing to use Avisynth then you might want to also check out my InterlacedResize filter. Most of the other resizers will blend the two fields together somewhat when you resize.

This is part of SimpleResize, see www.trbarry.com/Readme_SimpleResize.txt

- Tom

[ookzDVD]

Dear Mr. "-h" ;)

Thank you for your reply and support ;)

So better I wait for the latest build which support interlace mode.

And I think I was not wrong, decide to use XviD instead of DivX ;)

PS.
Hope you could inform me if there is a build which support the interlace mode.

Thank you.

[ookzDVD]

Hi trbarry,

Thank you for the offer, I've downloaded your filter,
I'll try to play with it and watch the result.

Thank you.

[-h]

So better I wait for the latest build which support interlace mode.

Yep - you'll know which build is the right one, because the "Global" tab will have an "Interlacing" checkbox underneath the "Lumi masking" checkbox.

I had some odd side effects last time I tried to add the assembly optimisations however, but hopefully all will go well tonight. If I can't get it to link properly, I'll just enable the slow mode (it's still bug-free).

-h

[ookzDVD]

Hi "-h"

Thank you.

Btw, talking about the DivX Pro 5, (if you don't mind) ;)
I just found that there is an option from the "General Parameter"
Source Interlace.

Do you know if that those setting could make Divx 5 Pro possible to
perform interlaced encoding ?

Thank you.

[wing1]

@-h

I am drueling with aniticipation already :D

@trbarry

I like the simpleresize filter that you have; However, there is a DS filter that uses avisynth to do a bicubic resize (version 1.3b), which I currently use with Nic's DS filter. It's amazing and it automatically load if you have Huffyuv codec installed on your system. No need to create script in order to run. Can you make your filter to do the same thing?

[trbarry]

I like the simpleresize filter that you have; However, there is a DS filter that uses avisynth to do a bicubic resize (version 1.3b), which I currently use with Nic's DS filter. It's amazing and it automatically load if you have Huffyuv codec installed on your system. No need to create script in order to run. Can you make your filter to do the same thing?

SimpleResize/InterlacedResize is nowhere near as sophisticated as the BuCubicResize, just faster and unfiltered.

I've considered doing what you suggest but there is another possibility that I'm thinking of for dvd2avi and mpeg2dec that might also work here.

It would be much faster yet to do InterlacedResize in the decoder while the data is still in planar 4:2:0 format. And at this point it could do InterlacedResize on field pictures but SimpleResize on full frame pictures.

edit: And it would be done before deblocking/deringing so these could be applied to the result.

Any comments?

- Tom

[wing1]

@trbarry

Currently the DSSimpleResizer filter is applied before Nic's DSfilter in the filter chain according to WMP6.4. Yes that would be an excellent idea :D. I'd love to see that if you have time to code it.

[avih]

Originally posted by trbarry
edit: And it would be done before deblocking/deringing so these could be applied to the result.

Any comments?
- Tom

yes,
resizing before deblocking/deringing might harm these filters.

deblocking is definately expecting the original block bounderies.

deringing is implementation dependant.
usually is uses a 3x3 filter. so resizing before deringing might harm the quality of the dilter.

also, i've implemented a deringing algotithm that is working only on blocks with high contrast (to conserve cpu and tackle only the areas where ringing artefacts are most visible. usually high ringing happens inside block bounderies for blocks with high frequencies). so again, resizing will change the blocks bounderies, and the filter might get less effective.


another thing. since resizing is 'cheaper' than these filters, enlarging the image before the filters will make the filters consume much more cpu.

and last thing. i didn't see nic's source, but i have the feeling it uses the original image from the codec (core) as input, and not the image from the previous filter in the chain. (this might not be true, it's just an assumption). if indeed this is the case, the filter chain might get invalid/corrupted if nic's filter using a different size than the previous filter output image...
cheers
avi.

[trbarry]

avih -

Good points all. I guess I'll reconsider the ordering. But if Wing1's comments above are correct then resizing is already being applied before Nic's filter. If so, maybe that should be changed?

I wrote the deringing ssemmx implementation in Nic's filter but I confess I didn't study the rest of the code much. I was mostly just porting and optimizing existing C code.

That's an interesting idea about doing only high contrast blocks. I'll have to think some more about that one.

- Tom

[avih]

i think wmp6.4 shows the filters in alphabetic order.

i just tried, and the order is different than seen on graphedit (and the order in graphedit makes sense).

only using graphedit will give definite order of the filters, unless the player shows the filters in the correct order (from my tests neither wmp6.4 nor zoom player shows them in the correct order).

avi

ps.
u can check my last postproc build from www.geocities.com/avihpit/xvid/post.html

note that there's a stupid bug in that release that the filter selects any block that contain luma above some thresh, and not as it should in specific range (absolute contrast). but u can use the 'show selection' checkbos to see which blocks are selected. also, i don't remember now whether it uses 16x16 or 8x8 blocks. in my current code it uses 8x8 though.

[wing1]

Just did what avih suggested with graphedit and indeed Nic's filter came before the bicubicresize filter. However, WMP shows it as being first. It could be that WMP lists them alphabetically.

This would make more sense and it would be better in that order. Less CPU and better image.

[trbarry]

avih -

Just followed your link above to your site. I'd forgotten about that nifty vector drawing thingy you made. I'll have to learn to use that sometime.

I wanted to back up and add a comment to your prev post. Deringing is actually not more expensive than resize, though it's true that upsizing first would increase the total cost. But IIRC I got the deringing down to about 7 assembler instructions / pixel for (luma only) deringing. Even my SimpleResize filter takes more than that and BicubicResize takes a lot more.

- Tom

[Nic]

You have to remember, of course, it is physically impossible for the resize filter to come before my DShow filter. (as the resize filter needs image samples to resize, not MPEG-4 video blocks :D )

-Nic

[avih]

hehe, nic, that's a much better reply than my to-much-mummbling :)

yeh, of course, nic's filter is actually calling the decoder to decode the images :)

@tom: pretty cool with your optimizations :)

i really hope that after we merge u'll have some time to optimize my code as well ;)

;)
avi

ps
@tom:
>"I'll have to learn to use that sometime. "

it's not really newclear phisics :) just put the dll and an old dshow filter into windows\system, overriding your current ones, play an xvid clip normally with your standard player, and open the xvid conf dialog (i.e. in vdub) :)

[trbarry]

You have to remember, of course, it is physically impossible for the resize filter to come before my DShow filter. (as the resize filter needs image samples to resize, not MPEG-4 video blocks

Nic -

Actually, I was really talking about putting the resize IN your filter. A version of SimpleResize/InterlacedResize could work much faster if it operated on the smaller planar MPEG4 (decoded) video blocks in 4:2:0 format and it would allow the SimpleResize/InterlacedResize decision to be made on a frame by frame basis for folks that wanted to keep interlacing.

YUY2 Horizontal resize algorithms like in Avisynth and DVD2AVI are complicated and slowed by having to adjust for the interleaved chroma info. This is something I'll probably do for mpeg2dec anyway so when the topic came up I mentioned it here.

But I don't remember what your final output format is, so maybe that's not necessary.

- Tom

[trbarry]

i really hope that after we merge u'll have some time to optimize my code as well

avih -

Sure. I like turning small routines into fast assembler code. But it's obviously not a very good idea while you are still tinkering with them since they are then not so easy to modify. ;)

But I was thinking your high-contrast-only idea might already be compatible with the deringing in Nic's filter.

- Tom

[Nic]

I knew what you meant Tom :) I just thing other people were missing it thats all :)

The DShow filter gets the frame in 4:2:0 then just before the output does color conversion to what ever is necessary (XviD supports most conversions)

Cheers,
-Nic

[trbarry]

The DShow filter gets the frame in 4:2:0 then just before the output does color conversion to what ever is necessary (XviD supports most conversions)

That brings up another interesting possibility then. Does "supports most color conversions" also mean "support unchanged color conversion"?

If there were a dshow BiWhateverResize filter that could accept planar 4:2:0 input is that one of the options? Or for that matter a GreedyHM420 deinterlace filter?

Almost everything can run faster at that format if that is all the color depth available anyway. And each color conversion costs both time and quality.

- Tom

PS - Actually, wing1's comments had made me question whether the dsf was getting the data directly from Xvid even though I'd seen the code. ;)

[avih]

I knew what you meant Tom I just thing other people were missing it thats all
@nic: Ahmmmm ;)

@tom: can u send me the c+asm deringing code? i wanna learn optimizations from the pros.. :)

i still didn't find a descent method for yuv (y only) 3x3 adaptive lpf using mmx...

thx
avi

[trbarry]

@tom: can u send me the c+asm deringing code? i wanna learn optimizations from the pros..

Yes, of course. But I thought you guys were already merging code. If so it's in Nic's dsf and I thought Koepi had even put that into CVS.

And a pro is someone who get's paid for it. Since I'm currently unemployed I'm not sure that applies. ;)

- Tom

[wing1]

@Nic, Avih, Tom

Here is what i've observed from using the bicubicResize DS filter and Nic's filter.

If I registered bicubicResize DS filter and nic's DS filter without huffyuv codec, then WMP will attempt to locate some codec ( I guess huffyuv because bicubicResize DS filter only operates in YUV mode ) before opening the clip. If it can not find the codec, BicubicResize filter will not load and the clip will play using Nic's DS filter only. Once I registered huffyuv, then it will load both filters.

Another interesting thing that is happening to me lately is that without the DS bicubicResize DS filter, I can't play the clip at all??? my other systems play it fine. I am trying to find out what went wrong ( have to remove all codecs from system again and reinstall ).

[Nic]

Yup it could very easily (& might automatically support outputing 4:2:0 without any color conversion)

Sorry AviH! Ive forgot (Again!!!) Could you please PM me your email address & ill send it first thing 2morrow...(gotta dash home now :) )

Cheers,
-Nic

[avih]

@tom:
i will get the code sooner or later. i can live with that. but what i need is an example optimized asm code for 3x3 operations (convolution/adaptive) using mmx.

i could use a sample code with minimal stalls and cache misses.

all i could think of might have too many cache misses :(

i wanna see how u fetch data, order, registers usage etc. i have to remind i'm VERY new to assembler and mmx. i don't know even which registeres are better for loop control etc....

buttom line i wanna have a look on good optimized code from an experienced coder :) preferably one that has something to do with my interests atm (3x3) :)


avi.

@all (except spammers :) )
my email is
avihpit _at_@ yahoo _dot_ com

;)

[trbarry]

avih -

Don't know if it is THAT well tuned. I mostly concentrated on not confusing the branch prediction and minimizing instructions. There's an occasional rearranged instruction sequence to give the processor time to fetch. But it still could be tuned some.

anyway, see attached. (warning, ssemmx only)

- Tom

[trbarry]

I still don't see my attachment. If I edit the message it says it is there.

- Tom

[Koepi]

Oopsi, I didn't check for attachments for some time now, it's validated and should be accessable now.

Regards,
Koepi

[avih]

thx tom and koepi :). i'll get it now. i can see it.

[edit] so much code :) it basically a 3x3 adaptive lpf right??? i imagined it to be much smaller... :)

i'll go through it. thx again.

[trbarry]

avih -

so much code it basically a 3x3 adaptive lpf right???

Uhhhhh, I don't know what an adaptive lpf is. :( (It's not a Linear Predictive Filter) I was just trying to make it do what the existing C code did, but faster. I'd never seen a deringing algorithm when I started and didn't even know what the word meant. But I know what the code does.

i imagined it to be much smaller

You don't know how long I've waited to hear that. ;)

Actually there are about 4-500 lines of assembler code there. But it is straight through with no loops and by the time you are done you have done a block of 64 pixels.

So from the point of view of having to type it, or understand it, it's a pain. But from the point of view of running it then it's a different story. Mostly it's just the same thing repeated 8-10 times for the lines in the macro block. I got carried away a bit.

But don't hesitate to ask if there is some non-obvious part of the assembler code. I still feel like that about some parts of C++ and almost all Windows calls.

And if you gave me a short section of C (integer) code for a 3x3 adaptive lpf whazzit then I'll bet I could make a fast ssemmx one.

- Tom

[avih]

explanation:
3x3 convolution is very simple. u take a group of 9 pixels arranged like this:

<code>
[1][2][3]
[4][5][6]
[7][8][9]
</code>

multiply each one by a (possibly different) weight, sum the results, and devide the sum by another factor. u then replace the middle pixel ([5]) with this new value.

that's 3x3 convolution.

lo pass filter (also known as blur) is a convolution where the center pixel has the most weight and the final deviding factor is the sum of weights. this gives an average of the pixels values, with more stress on the center pixel. u then replace the center pixel by the result. u get blur.

the less weight u give to the center pixel, the less 'power' it has over the result, and u get more blur.

this is a lo pass filter, since it removes some high frequencies from the final image.

an adaptive lo pass filter means it doesn't consider all pixels 1-9 for the sum, but only those whose value is not further from [5] by X. this way, the average takes into account only pixels that are 'close' in value to the center pixel, hence, it's more coherentive, and doesn't blue edges. it's only averaging areas of similar color and removes noise without sacrifying sharpness.

X is a parameter of the filter, the higher X is, it takes more pixels into account while averaging and the filter smoothes more, but might harm the edges more.


deringing is some kind of adaptive lo pas filter.

nic's version is doing so to the whole frame if i understand correctly.

my version only applies it to 8x8 blocks with high contrast. the threshold for 'high contrast' is controllable. so if set to maximum, it's applied to the whole frame as well.

the weights that are applied to the pixels other than [5] may all be the same, or take into account the phisical distance from [5]. i.e.:

<code>
[1][2][1]
[2][P][2]
[1][2][1]
</code>

where P is the power of the center pixel.

3x3 convolution is a specific case of convolution. convolution in general may operate on any number of arguments, but with same principle: multiple by weights, sum, devide sum by factor.

different weights for 3x3 convolution can produce sharpenning effect/emboss/edge detection and more.

one factor to keep in mind while convoluting is that the pixel [5] changes, and other pixels' convoluted values depened on [5] (essentially, pixels 1-4, 6-9 depend on [5] for their convolutions) so some measures should be taken, such that [5] is not changed before the rest of the convolutions that uses [5] have been calculated.

one solution would be to output the new values to a new image, such that the original image stayes intact, and the the new image is the filtered one.
:)
easy right? :)

so, is your code basically doing 3x3 adaptive lpf? (unrolled for 8x8 pixels)?

[avih]

Originally posted by trbarry
Actually there are about 4-500 lines of assembler code there. But it is straight through with no loops and by the time you are done you have done a block of 64 pixels.

hell, u can use perl to produce a .asm file that is unrolled for the whole frame
lol

so your code is unrolled for 8x8 blocks? cool, might even be more usefull that i thought, and i now also understand how this 'contrast based selection' is compatible with your code.

and btw, when i started to work on it about a month ago, all i knew (from divx help file) was that ringings are artifacts that are produced due to compression of high frequencies. i wanted to write a deringing filter. since i had absolutely no idea how to start it, the 1st thought that came to my mind was blur only areas of high frequencies. but since i didn't know how to find these areas i had the idea that blocks with high contrast would correlate more or less to blocks with high frequencies. now i know that the smaller the block u're testing for contrast, the more accurate the corralation is. and if u select 3x3 blocks, it's basically an edge detection, which is the definition of high frequencies.

so i started with averaging 3x3 block of pixels, for all of the pixels inside 8x8 blocks with high contrast.

then i read sopme papers about image processing and learned about convolution, i also read some help on adaptive filters, and eventually produced my filter.

very easy :) logic and the web can make u very knoledgable :)

cheers
avi.

[trbarry]

so, is your code basically doing 3x3 adaptive lpf? (unrolled for 8x8 pixels)?

avih -

Yes, mostly, but Nic's adaptive criteria is different.

But first, a couple basic rules of mmx optimization:

1) It may not be that much faster doing one pixel, so find a way to do it to 8 pixels at a time.

2) You can optimize almost anything by giving up being general purpose and just cherry picking the way that's happens to be most convenient.

Rule one is pretty obvious. But to take advantage of rule 2 I notice that the (fixed) convolution weights in Nic's algorithm happened to be: (is this what's called a triangle filter?)

1 2 1
2 4 2 / 16
1 2 1

So I'll quote from the comments I left in the code at the time:


Note - As near as I can see, (a + 2*b + c)/4 = avg( avg(a,c), b) and likewise vertical. So since there is a nice pavgb MMX instruction that gives a rounded vector average we may as well use it.

Fill in b10x10 array completely with 2 dim center weighted average This section now also includes the clipping step.


Applying rule 1 I did it to 8 (64) pixels at a time.

The '2 dim center weighted average' was your 3x3 lpf. But my brain just couldn't get from your L.P.F. to 'low pass filter' for some reason. Strange. Anyway, the results are clipped to not vary too much from the original value, by a user specified parm.

A later (adaptive) decision decides whether to use the new value for each pixel or leave it the old value unchanged in the output. Since it's all done to a new block we don't have to worry about the changing values propagating.

I'll leave it to Nic to explain the adaptive part. I just recoded it to assembler for him it. (I'm hiding the fact that I don't understand it here. ;) )

- Tom

[avih]

thx for yoyr explanantion.

pls just confirm that the 64 pixels are arranged as 8x8 and not as line of 64 pixels.

thx

[trbarry]

avih -

The input variable stride is the offset from one group of 8 pixels (qword) to the next.

- Tom