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 1st March 2003, 00:07   #101  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Quote:
Originally posted by trbarry
For 3.0 I'd like to propose one more flag attribute for each frame. This would say the frame contains unknown garbage.
Sort of like the infamous .AVI Drop Frame attribute we currently provide. NOT!

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:
But in a special filter it would be possible to turn all garbage frames black or (better) replace all garbage frames with the last known good frame.

- Tom
Or a Temporal Interpolated frame from the last known good frame and the next known good frame

IanB
IanB is offline   Reply With Quote
Old 1st March 2003, 00:20   #102  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Quote:
Originally posted by siwalters
@IanB
Your diagrams all seem to show your chroma sampling horizontally between two Y samples but all the stuff I can find on MPEG-2 4:2:0 (cause that's what the main use of the YV12 is for it seems) shows the samples as being horizontally co-sited with the 1st Y sample.

regards
Simon
Damn! So I have (to wrapped up in the vertical problems), I'll fix the posts.

[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.
IanB is offline   Reply With Quote
Old 1st March 2003, 09:01   #103  |  Link
Si
Simply me
 
Si's Avatar
 
Join Date: Aug 2002
Location: Lancashire, England
Posts: 610
Quote:
I dare you to ask for a PAL DV chroma resiteing filter
I'll just write a plugin myself

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
Si is offline   Reply With Quote
Old 1st March 2003, 10:40   #104  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
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.
sh0dan is offline   Reply With Quote
Old 1st March 2003, 10:47   #105  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Quote:
Originally posted by siwalters
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) ?
All DV filters I heard of converts to YUY2 - some with broken chroma upsampling, but even though they should be able to deliver an YV12 signal on PAL sources they don't. Guess they "go safe".
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 1st March 2003, 17:05   #106  |  Link
trbarry
Registered User
 
trbarry's Avatar
 
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.
trbarry is offline   Reply With Quote
Old 1st March 2003, 18:14   #107  |  Link
Si
Simply me
 
Si's Avatar
 
Join Date: Aug 2002
Location: Lancashire, England
Posts: 610
@trbarry
from avisynth.org
Quote:
Since frames are numbered starting from zero, SelectEven actually selects the first, third, fifth,... frames by human counting conventions
So I think that makes SelectOdd do the 2nd,4th,6th etc.

I think we need a syntax change to SelectEveryOtherFrameStartingFromThe2ndOne

regards
Simon
Si is offline   Reply With Quote
Old 2nd March 2003, 04:13   #108  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
@sh0dan
Quote:
the only thing changed is the way chroma is weighed when interpolating interlaced YV12 -> YUY2.
Shouldn't the weighting be applied in the YUY2 -> YV12 direction?

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
IanB is offline   Reply With Quote
Old 2nd March 2003, 05:38   #109  |  Link
trbarry
Registered User
 
trbarry's Avatar
 
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
Quote:
Since frames are numbered starting from zero, SelectEven actually selects the first, third, fifth,... frames by human counting conventions
Right, I knew that. (well, I should have RTFD)

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
trbarry is offline   Reply With Quote
Old 2nd March 2003, 17:26   #110  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Quote:
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]
It is not implemented in C - only assembler.

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
sh0dan is offline   Reply With Quote
Old 22nd March 2003, 14:25   #111  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,923
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.
Guest is offline   Reply With Quote
Old 22nd July 2003, 12:47   #112  |  Link
Bidoche
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.
Bidoche 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 11:31.


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