YUY2 Captured Resolution Not Divisible By 4, Won't Open In VDub...Help!!!

[Angelus]

I captured two shows in the past week and stupid me didn't realize that YUY2 needs to have a width divisible by 4. I think I captured at 726x480...cause there's always a black bar on the left of the show and i figured once I crop that out it would be standard 720x480 resolution. I made an avisynth script using crop(6,0,0,0) to get the 720 resolution but when I open it up in VDub the picture is greyed and slanted to the right. Does anyone know how to fix this or will I just have to delete the captures?

Thanks

Angelus

[vhelp]

@ Angelus,

This may or man not help at all, but I've made a few mistakes like
this too, or even when I tweaking resing and stuff like that, which
results in slanted b/w output in vdub.
.
.
But, try and use only crop() w/out any convertToyuv2() or other
color converters. Just just crop() only and see if that fixes your
issue. I'm suspecting that the convertXX is doing it's own error
checking and revolting back at'cha :)

In vdub, I would just use the NullTransform command, and
crop the 6 pixels off.
.
.
It it works in vdub, and you can't fix it via AVS script, than perhaps
you should perform this under vdub, and then frameserve it into AVS
script and continue as usual ??

Good luck,
-vhelp

[Angelus]

The avi won't open up in VDub...Well it will but as soon as I start to move the slider to go thru the show, it gives my a Vdub crash error, and it has to do with the huffyuv codec that I used to capture with. That is why I was trying to open it via avisynth in VDub. And if i just use AviSource("a.avi") and try opening that in VDub it states that YUY2 images for output must have widths divisible by 4...so this is where I got the idea for cropping...but when I try the cropping it comes out grey and slanted. And I never had a convertToyuy2 or anything after avisource...when it was captured it was in yuy2.

[vhelp]

ok, one more question..

Are you using the modified Huffy codec for CCE ??
or, the regular version ??

I had color issues when I used the Huffy mod version, and had to revert
back to the older one.
.
.
but, does it play fine in other apps ie, powerdvd, media etc ??

-vhelp

[Angelus]

I am using the modified huffyuv codec for cce, but I don't think that's the problem. I've had many captures with it and the only thing that was different with these captures was that the resolution was 726x480.

And I think it's because of the abnormal resolution that Media Player classic, and zoom player arent able to play the file.

So is there a way thay I could change the resolution of the file, back to standard 720x480 without using VDub?

[Wilbert]

Could you upload a few frames somewhere?

[Angelus]

Sure, here's the link for 3 pictures of what's happening:
http://home.comcast.net/~angeles6116/wsb/html/view.cgi-photos.html-.html

For some reason I think it has to be opened up in Microsoft Internet Explorer...don't ask me why :)

I got the capture to open up with the following script:

AviSource("D:\Tony\TV Capture\Angel Nov 12 (2003-11-12 at21-01-48).avi")
crop(6,0,0,0)
#LanczosResize(576,432)

I tried the example of LanczosResize too but it came with the same picture in VDub.

[Kika]

I guess it's the captured Video. It has to be devidable (?) by 16, not 4 or anything else.
You can use 704 or 720, also 672 or 688, but not 726. It's a limitation of the Codecs.

[Wilbert]

Sure, here's the link for 3 pictures of what's happening:

I meant the avi consisting of two/three frames :) But Kika could be correct, I don't know.

[Angelus]

Sorry about that, If you want I could email you the avi with 3 frames...I'm too busy right now to mess around with that stupid website. If you want me to do that, send me you're email address on a private message. Thanks

[vhelp]

Angleus,

wow. This is the EXACT same issue I had ben experiencing over the
weekend. In my case, I was toyin garound w/ resizing techniques and
whenever i would input a strange resize value, I'd get this same b/w
curviture :(
.
.
But for me, my resolution was to just change the resizing to something
else w/in the spec ie, 704, 720, 480, 352 etc. You could also just bump
down a few notches in values.

However, if your source is permanent in this way (which I believe it
truely is :( ) then you'll have to recapture it (if that's even at all
possible)

Here is a suggestion, cause I've toyed w/ this one and it did actually
work for me, and may work for you too (but only if the source is not
permanently in this way)
.
.
Inside vdub, use the Rotate - - there are two of them. In your
case, you would benefit it if you use the 2nd one, marked as rotate2,
because you want to notch it a few increments, till it levels off w/
the proper Horizontal. And, use the Preview.
.
.
Tip.. if you enter a number, and TAB to next field (during Preview)
you can wysiwyg each try (but remember to Shift-Tab back to first field. A bit tricky to do, but can be masterd. Otherwise, it'll drive
you crazy reseting up the filter every time because you pressed the
Enter key. Just a thought.

Again, I think it's too late, as it's my belief that this is recorded
(captured) in the source this way. It's like trying to take a Black &
White video, and bust some brain cells trying to make it color..
won't happen.

Do give the above some thought though,
-vhelp

[Angelus]

See the weird thing was that when I was capturing it in VirtualVCR in the preview pane the picture looked normal...that's why I thought it would be alright to do this. Obviously I should have realized about the parameters of the colorspace b4 I did this tho. I don't think I can do anything to get it to work but i will try what you suggested. Thanks

[trevlac]

@Angelus

What was your codec ?

Thanks

[Angelus]

it was huffyuv. I was just an idiot and didn't have a resolution that was divisible by 4.

[trevlac]

Originally posted by Angelus
it was huffyuv. I was just an idiot and didn't have a resolution that was divisible by 4.

I didn't know it needed to be a factor of 4. I thought it was 2 because there are 2 pixels in a 32 bit 4:2:2 macro pixel. I'll have to run some tests on different codecs I use.

Thanks

[Angelus]

I think it has to do with the colorspace...it's originally captured in RGB24 and huffyuv converts it to YUY2...and I think YUY2 requires a width divisible by 4.

[trevlac]

Analog is not natively RGB. I believe PAL is close to YUV and NTSC is like YUV but YQI. A BT878 will create pixels in packed YCrCb 4:2:2 format. From here it converts to many formats such as YUY2, YUV12, and RGB. I think YCrCb is basically the same as YUY2.

So basically, I guess one should ask a BT878 for YUY2 not RGB, if you use huffy.

For Packed 4:2:2 fromats like YUY2, each macropixel is 4 bytes (16 bits per pixel) and contains 2 pixels. The byte order is Y0 U0 Y1 V0 where U and V are shared by pixel 0 and 1.

So factors of 2 make sense because you have to read 4 bytes to get enough info for 1 pixel. By that time you have enough info for 2 pixels.

I am just learning about this. I wanted to test and thought your results would be a great start. I may be competly wrong on the stuff above. I'd be happy to be corrected.

Thanks

[Angelus]

I'm not sure about the techincal aspect of capturing video and the whole deal with colorspaces. The reason I initially set the colorspace to RGB24 is b/c if I set it to YUY2 or anything else other than RGB, I'm unable to preview the video in VirtualVCR.

[Wilbert]

@trevlac,

You are entirely correct (except I think it is YIQ instead of YQI). Some more info about YUY2: http://www.avisynth.org/index.php?page=DataStorageInAviSynth

[Angelus]

sorry I have a quick question. I just upgraded my drivers to the btwincap drivers (I got it to work finally!!! :D ) and now it seems I can capture with VirtualDub. Always before the Leadtek drivers would limit my colorspace to rgb. I read that link Wilbert posted too. So is there a distint advantage to capturing in YUY2 rather than rgb? Thanks

[ppera2]

Originally posted by Angelus
sorry I have a quick question. I just upgraded my drivers to the btwincap drivers (I got it to work finally!!! :D ) and now it seems I can capture with VirtualDub. Always before the Leadtek drivers would limit my colorspace to rgb. I read that link Wilbert posted too. So is there a distint advantage to capturing in YUY2 rather than rgb? Thanks

Of course that it's better - PCI bus load is much lower. YUY2 is best format for PAL analogue video, because it fits PAL color system.

[Arachnotron]

With RGB, one pixel takes 3x8=24 bytes
with yuy2, one pixel takes 8 + 2x4 = 16 bytes

So your bandwith requirements (and filesizes) are reduced by 33% even without compression!

Since, as Trevlac pointed out, with the BT878 RGB is generated from YUY2 anyway, there is no good reason to capture RGB and many reasons not to. (unless you want to capture with some exotic codec which only understands RGB24)

[Angelus]

Yea I came across a website too that explained it pretty well (google search). So now it makes me wonder if all those captures I did in RGB24 really suck! I'm unable to use VirtualVCR now but that shouldn't be a big deal because I can just use VirtualDubVCR instead. Thanks guys for your replies!

Angelus

[sprit]

Originally posted by Arachnotron
With RGB, one pixel takes 3x8=24 bytes
with yuy2, one pixel takes 8 + 2x4 = 16 bytes
<nitpick>That would be bits, not bytes.</nitpick> Also, RGB could be send using 4 bytes per pixel (even without alpha). This wouldn't affect compression, but would make RGB twice as demanding as YUY2 during capture (re PCI-b/w, cache space, etc).

[Arachnotron]

:o :o :o