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. |
|
|
Thread Tools | Search this Thread | Display Modes |
1st March 2003, 00:07 | #101 | Link | ||
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
And while we are into frame based attributes, it might be nice to pass Keyframe knowledge thru the pipe to the output .AVI synthisizer (pseudo-codec) so that keyframe seeking in applications like VirtualDub, et el is actually useful and fast. A simple flag probably would not cut it when filters with temporal dispersion are used. i.e. TemporalSoften(radius=1) seeking to a keyframe thru this filter accesses the keyframe (K), the frame after the keyframe (K+1) and the frame before the keyframe (K-1) opps maximum really long seek delay. But some fancy OO crawl-back (or is that claw-back ) method counting max cache hint width could certainly work extremely well, i.e seeking to K+1 and accessing K, K+1, K+2 would be really fast. Quote:
IanB |
||
1st March 2003, 00:20 | #102 | Link | |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
[EDIT]The art I grabbed is actually correct for MPEG-1 (which knows squat about interlaced) and I just embelished it without thinking. All this YV12 chroma subsampling and siteing is making my head spin, and sh0dan write MMX and SSE2 assembler to implement it as well. I don't know how he does it and stays sane. Simon, I dare you to ask for a PAL DV chroma resiteing filter[/EDIT] Thanks IanB Last edited by IanB; 1st March 2003 at 02:33. |
|
1st March 2003, 09:01 | #103 | Link | |
Simply me
Join Date: Aug 2002
Location: Lancashire, England
Posts: 610
|
Quote:
The only thing is, do any of the source filters actually provide YV12 from a DV source or do thay all already upsample to YUY2 (and do they get it right) ? regards Simon
__________________
http://www.geocities.com/siwalters_uk/fnews.html |
|
1st March 2003, 10:40 | #104 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
The converters stick to the MPEG2 scheme - the only thing changed is the way chroma is weighed when interpolating interlaced YV12 -> YUY2. The horizontal alignment of the chroma isn't touched, so it realigns perfectly according to the diagrams on the page you linked, and how your ASCII art now shows. I guess I must have missed your MPEG1 suggestion
(edit: spelling)
__________________
Regards, sh0dan // VoxPod Last edited by sh0dan; 1st March 2003 at 11:39. |
1st March 2003, 10:47 | #105 | Link | |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
Quote:
__________________
Regards, sh0dan // VoxPod |
|
1st March 2003, 17:05 | #106 | Link |
Registered User
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
|
I sometimes capture Buffy from UPN which has softly upconverted it to 1080i. Since there is not that much detail anyway I've been doing:
SeparateFields() SelectOdd() and then resizing the result. And even with Avisynth 2.5 this seems to work okay, fast, and I don't really notice any problems. But from rereading all the above posts (including my own) it occurs to me that I am probably introducing a fractional pixel vertical chroma delay here because of the interlaced YV12 format. With all the changes here is there currently a fast simple way to do this properly? In a couple hours I could probably create a fast mmx YV12TopFields() filter to use for now. Should I do this or isn't it needed? - Tom edit: I never thought or cared about it much before. Is the first field in Avisynth 0 or 1. That is, does SelectOdd take the first field? Last edited by trbarry; 1st March 2003 at 17:10. |
1st March 2003, 18:14 | #107 | Link | |
Simply me
Join Date: Aug 2002
Location: Lancashire, England
Posts: 610
|
@trbarry
from avisynth.org Quote:
I think we need a syntax change to SelectEveryOtherFrameStartingFromThe2ndOne regards Simon
__________________
http://www.geocities.com/siwalters_uk/fnews.html |
|
2nd March 2003, 04:13 | #108 | Link | |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
@sh0dan
Quote:
I did stumble across some bi-cubic interpolation algae for YV12 -> YUY2 in MSDN somewhere, it looked expensive but might be worth it in a ...yv12To...(HiQmode=true). It was somewhat of the form :- uv(x,2y)=-k1*UV(x,y-2)+k2*UV(x,y-1)+k3*UV(x,y)-k4*UV(x,y+1) uv(x,2y+1)=-k5*UV(x,y-1)+k6*UV(x,y)+k7*UV(x,y+1)-k8*UV(x,y+2) Perhaps poaching the code from BicubicResize or LanczosResize could be the go. And how are you doing the 75/25 top field - 25/75 bottom field flip,I guess it must be something to do with the for(..;..;i++) { switch (i) { case 2:_srcY-=src_pitch; but I can't quite find it or have I jumped the gun again [convert_yv12.cpp Rev 1.5 Fri Feb 28 10:09:33 2003 UTC] @trbarry I also can never rememberso I chuck in a ShowFrameNumber() whenever I need to know SeparateFields() ShowFrameNumber() SelectOdd() Returns Frames 1,3,5,7,... IanB |
|
2nd March 2003, 05:38 | #109 | Link | |
Registered User
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
|
Quote:
Anyway, I just went ahead and made the darn filter. See: http://www.trbarry.com/Readme_YV12In...dReduceBy2.txt and www.trbarry.com/YV12InterlacedReduceBy2.zip (source and dll) This can go in the filter pack if anyone thinks it would help for the moment. It does a horizontal and vertical "reduce by 2" by taking only the top fields, doing the needed chroma adjustment, and also horizontally reducing by 2 with no filtering. There are no parms. The same dll also contains a YV12InterlacedSelectTopFields() function. This does what the name suggests, also doing the chroma adjustment but leaving the width alone. This makes it sort of a fast (but hopefully proper) version of SeperateFields().SelectEven(). Since the source is there, and very small, I guess it can show how I think the chroma adjustment should be, though I was just going by the pictures in Video Essentials. - Tom |
|
2nd March 2003, 17:26 | #110 | Link | |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
Quote:
The switch stuff is for the top and bottom lines (8 lines total in interlaced mode, 4 in progressive). These lines are not interpolated, so chroma is simply copied here. The interpolation is done by "pavgb mmx,mmy// interpolate chroma U ". It actually translates to: chroma = (chroma1 + chroma2 + 1)/2 chroma = (chroma + choma1 +1 )/2 This is when chroma1 must be represented 75%. The reason we use two averages and not accumulate and divide by 4 is performancewise, since this operation can be done without unpacking bytes to words (which the slower MMX-routine has to). I personally think bicubic chroma scaling is highly overkill. But if someone implements it I will of course put it in. We already have much more precise conversion than most filters (XviD does no chroma interpolation at all), so if there are no obvoius bug, I will not use too much more time on this (of course we need an MMX version of the YUY2->YV12).
__________________
Regards, sh0dan // VoxPod |
|
22nd March 2003, 14:25 | #111 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Just adding this thread link:
http://forum.doom9.org/showthread.ph...094#post283094 ...because it demonstrates that cropping for YV12 must observe the interlaced/progressive chroma sampling frame flag to perform proper enforcement of crop values. |
22nd July 2003, 12:47 | #112 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
I finally got those video properties done in the 3.0 code.
Here are what I made : Clips are now marked (through VideoInfo) as either frames or fields clips. Filters are expected to enforce this distinction the way you can imagine. (essentially no mixing field/frame) Frames have self knowledge of ColorSpace, width, height and type. Type can be FIELD_TOP, FIELD_BOTTOM, PROGRESSIVE, INTERLACED_TTF, INTERLACED_BFF, UNKNOWN. The first two are for use in fields clips, the four others in frames clips. When creating a videoframe from a videoinfo, if the clip is a field one, frame type is defaulted to top. If it is a frame clip and colospace/dimension allow interlacing frame type becomes UNKNOWN, and otherwise PROGRESSIVE. UNKOWN type is not supposed to be kept, filters are expected to change it into one of the 3 others. As for frame properties, after some brainstorming, thinking about really complex things, finally remenbering the KISS rule... I came to this proposal : Distinguish 3 types of properties/flags : - state properties : their value depends only of the videoframe, and will always be the same whenever, wherever it is needed. Then it makes sense to allow their attachment to const VideoFrame as they a re not a modification but just an additional info. These properties are discarded when the frame is accessed for modification. An example of these could be decomb frame comb status. - forward porperties : properties we want passed through the filter chain for some reason. It suppose a method to make new videoframe inherit them correctly, and more importantly a (polymophic) method to deal with collisions (what to do when more than one ancestors with the property). They can be added normally to a PVideoFrame, but change a CPVideoFrame to a clone with the propery added (trick to keep state properties). Of course they are not discarded by frame modifications. The only example I could come up with is to time filters chain : a filter mark frames with a property with the processing time as value and an addition collision method, and an other make the difference between the processing time and the value passed through. - other properties : those who are none of the above, are discarded by modifications and are attached like forward ones. |
Thread Tools | Search this Thread |
Display Modes | |
|
|