Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th March 2003, 19:26   #1  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Continued from this thread.

Quote:
@sh0dan

Please don't tell me 0 pitch is forbidden.
No - 0 pitch is no problem. Can't see any problems arising from it.

Regarding your hierarchy - problem is that it's not an easy distinction - is seems ok. But it should also be remembered, that both YV12 and YUY2 are YUV formats - however I still like your distinction better.

So the complete hierarchy could look like this:

Code:
General --- IsInterLeaved() --------+--- IsYUV() -- YUY2
         \                           \
          \ IsPlanar()                -- IsRGB() -- RGB24 / RGB32
           |-- IsRGB()
           |__ IsYUV() - IsYV12() - YV12 / I420
I still don't like that you using switch to choose an algorithm - IMO using the functions are both more readable, and safer. For instance, your filter will NOT process I420 material, because the enum is different, for internal purposes that filter writers shouldn't care about.
__________________
Regards, sh0dan // VoxPod

Last edited by sh0dan; 25th March 2003 at 21:50.
sh0dan is offline   Reply With Quote
Old 24th March 2003, 22:13   #2  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Quote:
No - 0 pitch is no problem. Can't see any problems arising from it
Cool, then BitBlit can be used to fill the squares, just have to create a row containing the good data.

Quote:
Regarding your hierarchy - problem is that it's not an easy distinction - is seems ok. But it should also be remembered, that both YV12 and YUY2 are YUV formats - however I still like your distinction better.
Generally in the processing, being interleaved makes YUY2 closer to RGB than to YV12.
But in some cases you would want to group YUY2 with YV12, for Crop for example, they have the same horizontal restrictions who can be shared...

Quote:
I still don't like that you using switch to choose an algorithm - IMO using the functions are both more readable, and safer. For instance, your filter will NOT process I420 material, because the enum is different, for internal purposes that filter writers shouldn't care about.
I don't see how a list of ifs can be more readable than a switch...

And for safety concern, of course if we are willing to add many colorspace clones, with enums we will be sorry.
At least If they are differencied, I mean YV12 and I420 are the same internally. So let's them be the same.

So there are no such thing as I_I420 in 3.0 and my switchs are safe.
Bidoche is offline   Reply With Quote
Old 24th March 2003, 23:30   #3  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Quote:
At least If they are differencied, I mean YV12 and I420 are the same internally. So let's them be the same.
Problem is, that for filters they are - for AviSynth it isn't. MPEG2DEC3 for instance decodes to I420, and it is marked as such in AviSynth.
AviSynth delivers the proper pointers to filters, so that the image appears as YV12 - even though it is arranged as I420 in memory. To filters I420 is fully transparent, as long as IsYV12() is used.

I420 is a good feature for input/output relying on being able to construct a correct I420 frame.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 24th March 2003, 23:38   #4  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
I don't get your point.
Filters who decode I420 could fill data as YV12 from the start, no ?

When you have I420 input you fill plane data accordingly.
If it's not the same way to fill as YV12 we don't care.
Bidoche is offline   Reply With Quote
Old 25th March 2003, 09:10   #5  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
It is to avoid BitBlits. MPEG2DEC and AviSource (and DirectShowSource IIRC) decodes directly to an AviSynth framebuffer, and the pointers are adjusted according to how the data is aligned.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 11:13   #6  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Decode directly to a framebuffer, that's evil

You mean for YV12/I420 it's fill all the data in one block, so plane order is an issue...
Bidoche is offline   Reply With Quote
Old 25th March 2003, 11:28   #7  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
You have to supply a buffer for AviSource for instance.
The pitch/pointers are adjusted to match what we can expect from VFW.

However, if pitch is not mod-16 (as required) on YV12 (actually quite rare) the data is blitted into a larger buffer, by the AlignPlanar filter.

This is the "legacy" (read: BenRG) way of doing this - and even though it isn't pretty it works - and it works fast. IIRC DirectShowSource() does the same thing.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 13:42   #8  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Hum, of course now that I think about it, vfw HAD to fill data in one block..

Guess I will have to make some VFW_YV12VideoFrame and VFW_I420VideoFrame who will initially allocate all planes into the first buffer and reallocate into others as needed....
But after that they will report being plain YV12.
Thanks to polymorphism it must be doable.

Quote:
The pitch/pointers are adjusted to match what we can expect from VFW.
And how is that ? If you can point me to the code, it would help

Last edited by Bidoche; 25th March 2003 at 13:48.
Bidoche is offline   Reply With Quote
Old 25th March 2003, 16:31   #9  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Sounds great!

In source.cpp (l:409) this frame is allocated:
Code:
PVideoFrame frame = env->NewVideoFrame(vi, -4);
This enforces a 4 byte alignment (which is always the same as VFW delivers). This is where the AlignPlanar filter is applied to all frames (source.cpp, l:88):
Code:
return AlignPlanar::Create(result);
AlignPlanar does nothing, if the pitch of a frame is at least mod16. Otherwise it realigns the image, by blitting it to a larger buffer.
In avisynth.cpp, line 754 it checks if V-plane should be placed first, using this line:
Code:
return ScriptEnvironment::NewPlanarVideoFrame(vi.width, vi.height, align, !vi.IsVPlaneFirst());  // If planar, maybe swap U&V
Around line 700 it then swaps the pointers, based on this test:
Code:
  if (U_first) {
    Uoffset = offset + pitch * height;
    Voffset = offset + pitch * height + UVpitch * (height>>1);
  } else {
    Voffset = offset + pitch * height;
    Uoffset = offset + pitch * height + UVpitch * (height>>1);
  }
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 17:04   #10  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Quote:
However, if pitch is not mod-16 (as required)
Quote:
This enforces a 4 byte alignment (which is always the same as VFW delivers).
How can we get mod-16 when we start specifying mod-4.... ?
Bidoche is offline   Reply With Quote
Old 25th March 2003, 17:59   #11  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
By applying the AlignPlanar filter. As long as a clip doesn't deliver non-mod16 clips, we're ok. Internally filters are allowed to create "forced size" frames, but they must _always_ apply the AlignPlanar before passing on the frame. This is why it is publicly available in avisynth.h
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 18:34   #12  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
In fact, it's the "(actually quite rare)" part I was wondering about.

About all this align stuff, if 4 and 16 are the only used values, maybe it should be made this way.
I mean, can anybosy find a reason where a filter would want a greater align than 16 !?
Bidoche is offline   Reply With Quote
Old 25th March 2003, 19:07   #13  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Yes - raising the limit to mod32 is actually something I have been planning to do for some time. This will ensure mod16 on luma, which is needed for SSE2 optimizations on P4 and the upcoming Athlon 64.

(Unless you want to change the way it is now, and just let chroma and luma pitch be independant).
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 19:28   #14  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
I provide same align on all planes, and YUY2 and RGB are aligned too (somehow the interleaved block in handled internally as a plane)

Last edited by Bidoche; 25th March 2003 at 19:30.
Bidoche is offline   Reply With Quote
Old 25th March 2003, 22:11   #15  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Sounds fair enough - let's keep planes separate, and do workarounds when video is delivered as a compact frame.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 22:17   #16  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Is there a reason for chroma align to be the half of luma ?
If not, I would simply make them the same.

Btw could you install STLPort and boost ? (www.stlport.or and www.boost.org respectively)
3.0 need them now, but 2.x can use the help.

boost::scoped_ptr, for example can simplify (make shorter) and safer lots of code.
I would like to introduce it someplaces, but if it's break your compile, you won't like it
Bidoche is offline   Reply With Quote
Old 25th March 2003, 22:40   #17  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Are there too many files for it to be included in the CVS tree?

What do they do?
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 25th March 2003, 23:37   #18  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
STLPort and boost are source libraries, there is no point in including them header by header in the cvs.

STLPort is a STL implementation to replace the one shipped with VC6 who is kinda old (I don't know for you, but I don't like seeing Copyright 95 in the headers).
Besides it adds some few things too (like hash_map which I need to do the FunctionTable)

And boost is a set of cool libraries for various needs, when things are already done in boost, I don't see the point doing them again (probably not as good).

Just take a look at boost::bll and boost::spirit.
Bidoche is offline   Reply With Quote
Old 26th March 2003, 13:22   #19  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
And for outputting frames, are they align conditions too ?
Or does it accomodate the actual frame pitch(s).
Bidoche is offline   Reply With Quote
Old 26th March 2003, 14:46   #20  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Regarding STL / Boost: Of course I'd have liked to hear that "STL-port makes it possible for us to design generic plugin interfaces that will allow plugins to remain through API changes" .. or .. "Boost will enable me to quickly create the best working cache implementation in 2.5 without breaking plugins".

Seriously - I have no problem adding these two to the "compilation dependencies", if there is a good point to this. I do trust you, when you say they could be good tools to have - I'd just like to know what the advantages are (explained for us more "casual" programmers).

I assume they will not be needed for plugin compilation!?!

Output:
For "AVI output" we are given a framebuffer by VFW, so we have to bitblit here anyway. I could however imagine that the image writer could use "specific pitch" images. Some way to create a new frame, where you can force pitch would be nice.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:14.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.