hakko504
9th December 2002, 11:43
I was doing some tests with some captured files, and realized that the conversion from YUY2 to YV12 (AviSynth2.5a) isn't quite done in an optimal way. Right now, to use them in A2.5a I use something like the following scriptAviSource(capture.avi").convertToYV12()
TomsMoComp(1,5,1)# #Don't think TMC can use YUY2 in A2.5a yet?
BicubicResize(704,400,0,0.5) #from 352x576
Convolution3d(preset="movieLQ") #preset may varyThis means that the U&V planes are heavily filtered during the process. To enhance quality I would like to be able todo something like this:AviSource(capture.avi")
TomsMoComp(1,5,1) #processed in YUY2
ResizeYUY2toYV12("bicubic",704,400,0,0.5) #from 352x576, returning output in YV12
Convolution3d(preset="movieLQ") #preset may varyThis new ResizeYUY2toYV12 should first do one resize to 704x400 where it only returns the Y plane from the resulting YUY2 frame. Then it could do a new resize to same width 704 but only to half height, 400/2=200. If this also is done in YUY2 then it is only a matter of constructing the U&V planes in YV12 from the values returned from the later resize.
Part of the idea is that though ConvertToYV12 only averages chroma from nearby lines, this isn't necessarily the most optimal way of going from YUY2toYV12, especially if a resize is involved.
Does this sound like a good idea? The point is really to use as many input pixels as possible for the deinterlace and resize stages where they matter the most, but then get rid of excess data for final filtering to gain speed.
I might give it a try myself to code this, but I'm not a very good coder and even though I would like to take advantage of the existing routines, I'm not sure how to just processing U&V with YUY2 input.
Note: Yes it may sound strange to capture video in 352x576@25fps, but this has proven to be the most optimal solution, given my system speed/size. Also, the theory behind resizing states that as long as the final number of pixels is reduced, it may be redistributed with only the addition of errors from the resizing algo itself. And yes, the number of Y pixels are increased, but the number of U&V pixels are reduced.
TomsMoComp(1,5,1)# #Don't think TMC can use YUY2 in A2.5a yet?
BicubicResize(704,400,0,0.5) #from 352x576
Convolution3d(preset="movieLQ") #preset may varyThis means that the U&V planes are heavily filtered during the process. To enhance quality I would like to be able todo something like this:AviSource(capture.avi")
TomsMoComp(1,5,1) #processed in YUY2
ResizeYUY2toYV12("bicubic",704,400,0,0.5) #from 352x576, returning output in YV12
Convolution3d(preset="movieLQ") #preset may varyThis new ResizeYUY2toYV12 should first do one resize to 704x400 where it only returns the Y plane from the resulting YUY2 frame. Then it could do a new resize to same width 704 but only to half height, 400/2=200. If this also is done in YUY2 then it is only a matter of constructing the U&V planes in YV12 from the values returned from the later resize.
Part of the idea is that though ConvertToYV12 only averages chroma from nearby lines, this isn't necessarily the most optimal way of going from YUY2toYV12, especially if a resize is involved.
Does this sound like a good idea? The point is really to use as many input pixels as possible for the deinterlace and resize stages where they matter the most, but then get rid of excess data for final filtering to gain speed.
I might give it a try myself to code this, but I'm not a very good coder and even though I would like to take advantage of the existing routines, I'm not sure how to just processing U&V with YUY2 input.
Note: Yes it may sound strange to capture video in 352x576@25fps, but this has proven to be the most optimal solution, given my system speed/size. Also, the theory behind resizing states that as long as the final number of pixels is reduced, it may be redistributed with only the addition of errors from the resizing algo itself. And yes, the number of Y pixels are increased, but the number of U&V pixels are reduced.