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. |
24th March 2003, 19:26 | #1 | Link | |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
Continued from this thread.
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. So the complete hierarchy could look like this: Code:
General --- IsInterLeaved() --------+--- IsYUV() -- YUY2 \ \ \ IsPlanar() -- IsRGB() -- RGB24 / RGB32 |-- IsRGB() |__ IsYUV() - IsYV12() - YV12 / I420
__________________
Regards, sh0dan // VoxPod Last edited by sh0dan; 25th March 2003 at 21:50. |
|
24th March 2003, 22:13 | #2 | Link | |||
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
Quote:
Quote:
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:
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. |
|||
24th March 2003, 23:30 | #3 | Link | |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
Quote:
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 |
|
24th March 2003, 23:38 | #4 | Link |
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. |
25th March 2003, 09:10 | #5 | Link |
Retired AviSynth Dev ;)
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 |
25th March 2003, 11:28 | #7 | Link |
Retired AviSynth Dev ;)
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 |
25th March 2003, 13:42 | #8 | Link | |
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:
Last edited by Bidoche; 25th March 2003 at 13:48. |
|
25th March 2003, 16:31 | #9 | Link |
Retired AviSynth Dev ;)
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); Code:
return AlignPlanar::Create(result); 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 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 |
25th March 2003, 17:04 | #10 | Link | ||
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
Quote:
Quote:
|
||
25th March 2003, 17:59 | #11 | Link |
Retired AviSynth Dev ;)
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 |
25th March 2003, 18:34 | #12 | Link |
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 !? |
25th March 2003, 19:07 | #13 | Link |
Retired AviSynth Dev ;)
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 |
25th March 2003, 22:17 | #16 | Link |
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 |
25th March 2003, 23:37 | #18 | Link |
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. |
26th March 2003, 14:46 | #20 | Link |
Retired AviSynth Dev ;)
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 |
Thread Tools | Search this Thread |
Display Modes | |
|
|