AVS Developers: AviSynth 2.5 alpha

[lighty]

Originally posted by WarpEnterprises
@lighty: where did you find truly interlaced movies? Are you sure they are not only telecined?

Hrm- well that is realy a question of taste- I like to preserve my encodes on as high resolutions as I can even if a have to do some blending or interpolation. Same goes for my vidcaps - I always grab at fulll or double resolution and then deinterlace. It maybe is odd but when I got it back to TV via TV out I got sharper image. :p

@Sh0dan

Eh- as I already explained I rather blend or interpolate then reduce size by 2. There are also films that are telecined and that I wish to treat- but I still wait for YV12 port of Decomb... :(
But I am a patient person so I can wait as long as possible--NOT!;)

lighty

[int 21h]

Decomb is GPL'd, maybe if some YV12 guru has time they can port it quick and save Donald some grief.

[trbarry]

Yes! Yes! Hurry, hurry!! I have three movies waiting to encode but alas- we still doesn't have any YV12 deinterlacer. I personally prefer Decomb because I got to know it's options but right now I would get satisfied with anything.

Yikes! I am getting beat up all over the place today about being tardy with TomsMoComp.

But maybe rightly so. ;)

I hereby vow not to get sidetracked with other interesting ideas (or anything else) until it's done. Expect a release tonight, or maybe tomorrow at the latest.

I can't help you with Decomb. But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?

- Tom

[MaTTeR]

Originally posted by trbarry
Expect a release tonight, or maybe tomorrow at the latest.

I can't help you with Decomb. But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?
Very cool to hear about the release of TMC, just got a concert Interlaced DVD today that I can use for testing:)

Yep, D2A/MPEG2DEC3 works fine using Force Film on Telecined movies and YV12 encoding. I've tested this with about 5-6 movies over the past few weeks.

[trbarry]

Maybe a cross post, but I just released a YV12 TomsMoComp test version. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=37915).

- Tom

[Guest]

Originally posted by int 21h
Decomb is GPL'd, maybe if some YV12 guru has time they can port it quick and save Donald some grief. No need. I am working on it.

Believe me, noone can do it quick. :)

[trbarry]

Believe me, noone can do it quick

I don't know about that. Marc FD and sh0dan are some pretty fast coders. ;) :devil: :devil: :devil: ...

- Tom

[Marc FD]

>No need. I am working on it.

great to hear don.

TomsMoComp is my favourite for DVD playback with BSplayer (becuause it's damn fast), but for encodes, decomb rules ^^

BTW, tom and don, i've some question about deinterlacing. i'll read a bit more the sources of TomsMoComp and decomb and then i may ask you some questions :)

[Krajensky]

Originally posted by trbarry
But, FWIW, DVD2AVI/MPEG2DECx Force Film should already work for properly telecined stuff in YV12. Anybody know?

ATSC isn't often properly done, it lacks the repeated field flags...

Though, as I think about it more (for anything over 480i), you could toss one field and simply use Decimate (should be simple to port just Decimate, I'll take a look later today).

Krajensky

[Didée]

There's one feature I am missing very often in AviSynth 2.0x, and since 2.5 is under development anyway ...

It's about "subtract". In its current form, it is very usable to see differences between frames.

But what if you want to work with these differences, e.g. make a mask out of it?

(Motivation: e.g.
- noise masking
- edge detection by gaussian blurring
- etc. )

In this case, the current "deviation image" with its "attractor" at Y=128 is not very usable.
I often need some kind of "absolut error" image, to use it proper as a mask. As for now, I'm taking the to halves [0,128] + [128,255] and re-build what is needed. But this is really Sissiphus' Work (and SLOW), since all calculations are done internally by "subtract" anyway, but simply get put out in the actual manner.

Would it be a big hassle to either

a) give "subtract" a new "mode" feature, or
b) introduce a new filter: "difference"

This would really be of great help, propably not only for me ...
Perhaps, while someone is working on implementing "Layer" in v2.5, he could do that by-the-way?

Thanks for listening

Didée

[Marc FD]

okay i'll add an abssubtract when i would add the subtract YV12 code.

[Guest]

Originally posted by Krajensky
...simply use Decimate (should be simple to port just Decimate, I'll take a look later today).
I said I'm working on it. :angry:

Are you trying to irritate me or just get me to close my sources?

[trbarry]

BTW, tom and don, i've some question about deinterlacing. i'll read a bit more the sources of TomsMoComp and decomb and then i may ask you some questions

Marc -

Of course.

ATSC isn't often properly done, it lacks the repeated field flags...

Krajensky -

I've noticed that here on some stations, especially WB.

But MPEG2DECx will still decimate somehow, just not as accurately. I haven't looked to see how it does it yet.

Instead of porting a YV12 GreedyHMA I'm thinking of trying to build one into MPEG2DEC2 so it could use the flag info when present. But it is not at the top of my list now that Marc's version is working for YV12. (except maybe for cropping)

- Tom

[sh0dan]

FYI, All XVID colorspace conversions have now been included in AviSynth. They all seem to require mod8, but fixing that should be quite easy. Perhaps I'll even have time for it today.

@developers:
no - this doesn't make AviSynth require NASM. I converted the assembly routines, so that VC6 will compile them just fine.

[trbarry]

sh0dan -

I'm porting SimpleResize today and I notice the chroma planes seem to have only mod 8 pitches. Is that what you finally decided on? I remember some discussion on this, somewhere.

I can work around it but SimpleResize has P4 sse2 code that would be disabled in that case since things would not be 16 byte aligned.

Can we get 16?

- Tom

[scmccarthy]

Tom,

The lines are modded (it that a word?) so you can work on 8 bytes at a time. Or is it eight pixels. Let me put it in a way I know is right.

The UV planes lines are half as long as the Y planes. The Y plane lines are mod 16 and each UV plane line is mod 8. So when you process all the Y samples you can at one time, you are supposed to only need to work on half that amount for each U and V sample.

A work around for this problem would be to convert the frame to NV12 internal to your filter. Never mine what I mean by that. What that does mean is you could try sticking the UV samples you are processing in the same array or in the same register or let them be pointed to by the same pointer. That way the number of samples in each array (substitute register of pointer if you will) is the same for luma and chroma. Combining two mod 8 chorma lines will give you a mod 16 line to work with that matches the luma line in length. It could either be interpolated uvuvuv... which is exactly like NV12, or or start the v samples at the halfway point.

Doing it this way lets you process Y, U, and V in the same loop too. Or process the Y plane separetely and the U anc V planes together. It sounds like you were planning to do each plane separetely. Otherwise this is no problem since then you do have to grab half as many U and V samples as Y samples as you go.

Stephen

[trbarry]

Okay, this is very strange. I see no reply button on posts now. I just clicked where it used to be to reply here. ???? :rolleyes:

Stephen -

Thanks, I think I understand all that. But for a small amount of memory usage P4's could run much faster just by increasing the pitch (not width) of the chroma planes to 16 bytes. Then they could have all lines start on 16 byte alignment. I thought we had already agreed to do that.

- Tom

[scmccarthy]

Tom -

I recently reread the whole avs 2.5 mpeg3dec (sic) thread and I remember the idea was the Y plane gets mod 16 line lengths and the UV planes get mod 8. There are so many ways that it can be done. You could even interleave each line using the same chroma samples for every two luma lines and use a luma mask again. Of course, then one comes to realize that planes are easier than interleaved files once you get used to them.

What I am saying is if you process the three planes concurently in the same loop, you will not need the UV planes to be mod 16 if the Y plane is only mod 16, because there are half as many samples in the UV plane per line. And lets say every time you stuff an mmx register with Y data, it you like you could stuff the next mmx register with interpolated UV data. That way you hit the end of each line at the same time. Or every time you fill an int64 with Y data fill half an int64 with U data and the other half with V data. Not nesessarily interpolation like uvuvuv.. but uuuuuuu then vvvvvvvv.

I am glancing at the SmartResize.cpp file, but I can't read mmx code yet.

Stephen

[trbarry]

Whatever.

I'm making a version of YV12 SimpleResize that just uses SSE2 instructions on every other line on the chroma planes. On the odd lines it will fall back to SSE. But it seems a shame.

- Tom

[-h]

FYI, All XVID colorspace conversions have now been included in AviSynth. They all seem to require mod8, but fixing that should be quite easy. Perhaps I'll even have time for it today.

I believe that Pete recently amended the colorspace code to support any mod2 resolutions, or mod4 in the case of field-based video.

Also, XviD's functions which work to or from RGB values are suboptimal, and even buggy in some cases.

-h

[sh0dan]

@-h:
I made them mod2 capable, by using a combination of the forced mod16 alignment, and using addborders/crop before and after resize, if the image wasn't mod8. Fairly hacky, but it works nicely.

YV12 -> YUY2 actually uses SeparateFields / Weave, when resizing Fieldbased material.

I've found that YV12 -> RGB24 has chroma noise on the leftmost pixel - I was going to ask if it was a known XVID problem, but I guess it is. RGB32 is fine though.

Anyway, replacing the routines with updated ones are trivial - I kept them completely separate, and haven't changed anything major.

@trbarry: Yes - chroma is only mod8, but there is a 50/50 chance it will be mod16 ;) You _could_ do a mod8 -> mod16 unpack - it's mainly a matter of a few BitBlt's - don't know if it's faster though.

[Koepi]

Shodan:

the YUV->RGB stuff is a known bug for nearly a year now :) Isibaar said the MMX routines are causing this, pure-C should work flawless.

Regards
Koepi

[scmccarthy]

@Koepi

MMX routines should work flawlessly too. I had the silly notion that MMX is so difficult to read that no one knows how these routines work. But that can't be right, Color Space conversions are pretty straight forward.:)

[sh0dan]

[wtf - it made a double post - I must have hit back - well anything to boost my post count :sly: ]

[sh0dan]

Well - as much as I'd like to rewrite them from scratch (I did do the ConvertRGB32toYUY2, and it was a real "pleasure"), I feel we get much further by using them. Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result.

(oh - oh - this will give me an excuse to use my newly mmx-optimized RGB32 -> RGB24 routine - done a night I was really bored ;)

[Guest]

Originally posted by neuron2
Are you trying to irritate me or just get me to close my sources? Oh, there I go being thin-skinned and rude again. Please accept my apologies, Krajensky.

[Wilbert]

Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result.

I think that TMPGEnc users would appreciate it if there will be a fast YV12 -> RGB24 conversion :) What about the conversions that Marc FD made (in his mpeg2dec3.dll) are they the same as yours?

[Marc FD]

>What about the conversions that Marc FD made (in his mpeg2dec3.dll) are
>they the same as yours?

no.

first, i didn't made them. it's jackei's code.

it works well and it's mmx optimised, i recommend it for YV12->RGB24 direct (specially interlaced) convertion.

[trbarry]

If anyone is interested I also have fast SSE2 color conversions routines as part of a package someone sent me for DVD2AVI. But that didn't seem to be the bottlenect so I never put them in and they are still (by me) untested.

- Tom

[sh0dan]

Originally posted by Wilbert
I think that TMPGEnc users would appreciate it if there will be a fast YV12 -> RGB24 conversion :) What about the conversions that Marc FD made (in his mpeg2dec3.dll) are they the same as yours?

That's why I optimized the RGB32 -> RGB24 code. Anyway, I'll look into it - the current code is _very_ fast - I don't think you'll notice the RGB32 -> RGB24 conversion actually.

@neuron: Nice to see, that we have a mature moderator, capable of admitting his own faults! Respect!

[Wilbert]

That's why I optimized the RGB32 -> RGB24 code. Anyway, I'll look into it - the current code is _very_ fast - I don't think you'll notice the RGB32 -> RGB24 conversion actually.
Ok. I guess ConvertToRGB24 on a YV12 source results in an error?

At the end we have to convince this Japanese guy to add an option "fast recompress like in Virtualdub" in TMPGEnc such that there are no conversions inside TMPGEnc :)

[sh0dan]

Originally posted by Wilbert
Ok. I guess ConvertToRGB24 on a YV12 source results in an error?

At the end we have to convince this Japanese guy to add an option "fast recompress like in Virtualdub" in TMPGEnc such that there are no conversions inside TMPGEnc :)

No, no - it performs the conversion internally, just use converttotgb24() - I'm pretty sure it wont affect you encoding speed at all.

[Wilbert]

Sorry for asking dumb questions. You said somewhere:

"I've found that YV12 -> RGB24 has chroma noise on the leftmost pixel - I was going to ask if it was a known XVID problem, but I guess it is. RGB32 is fine though."

Koepi responded "the YUV->RGB stuff is a known bug for nearly a year now".

You responded "Right now I don't care much about the RGB24 stuff - if people would like flawless operation I can map the conversion to do a YV12 -> RGB32 -> RGB24. It'll be slow, but it'll give the correct result."

What should people do: "YV12 --> RGB24" resulting in a small error most people won't notice, or "YV12 --> RGB32 --> RGB24" which would be correct. But if there is (almost) no difference in speed, why not advise the latter conversion.

[sh0dan]

Because this is what AviSynth does! :)

When you enter converttorgb24(), and AviSynth detects that the source is YV12, it will internally do what is the same as converttorgb32() / converttorgb24() - so whatever you enter you get the same speed and the same result :)

[Guest]

Originally posted by sh0dan
@neuron: Nice to see, that we have a mature moderator, capable of admitting his own faults! Respect! Who said I have faults?! :angry:


;)