convert 4x3 capture to 16X9

[Flibster]

Hi guys. *and guyettes..they may be some out there...;)*

Been using my Hauppauge USB2 PVR for a few weeks now with beyond tv on my Media PC..and have just found a slight error.

I've been recording a few things from sky and some of them are in widescreen. But I've been capturing in 4x3. Oops.

So now I've got something that approximates uselessness. :rolleyes:

Is there any quick and simple way to convert a 4x3 stream into a 16x9 stream as a I'm going to be dumping this onto a DVD so I can watch it on one of the other tv's in the flat. Sadly only the big tv is widescreen.

Any help would be appreciated on this.

Simon/~Flibster

[The Geek]

I've been recording a few things from sky and some of them are in widescreen. But I've been capturing in 4x3. Oops.

So now I've got something that approximates uselessness.

What exactly does that mean ? Do you have a 4:3 picture with the 16:9 image in the middle of it, and it looks normal ?
If so, you can't do anything about it.

Or, do you have a 4:3 image where the whole thing is full screen but looks squeezed ?
If so, setting the 16:9 flag is the only thing you gotta do I believe.

But another thing:

Been using my Hauppauge USB2 PVR
That is an analog capture box.
I've been recording a few things from sky
Isn't that digital ?

If so, the best would be to get a digital TV card. With your current setup, you receive the MPEG-2, convert it to analog, then back to MPEG-2. That means: Quality loss.
And with a digital TV card you don't need to worry about 4:3 or 16:9, the MPEG-2 stream that you receive will already be properly set.

The Geek

[jggimi]

For digital capture, see our HDTV / DVB / TiVo (http://forum.doom9.org/forumdisplay.php?s=&forumid=64) forum.

[Flibster]

It seems that I didn't make myself clear enough here.

I have the PVR2 USB because most of the stuff I'm doing is dumping all my old VHS tapes to DVD. Very occasionally I record stuff from sky or terrestrial when I'm on my way out or something. I have no need for a dedicated digital recorder.

All I need is to know how to change the video format once recorded from 4x3 to 16x9

If I play it back using Media Player Classic and manually stretch it to 16x9 it's fine - at 4x3 it's squished up.

It should be an easy matter to just switch the flag form 4x3 to 16x9 - no idea how it's done though.

Simon/~Flibster

[Flibster]

Forget it - found a tool that allows the editing of the stream header once it's been de-multiplexed

Seems to work.

Simon/~Flibster

[jggimi]

I'll move this to DVD Authoring, as your question is about setting the DAR flag.

[Trahald]

@Flibster - what you didnt mention in the first post is that the image appeared squished at 4:3 (which is what was needed to tell what will fix your issue.) That means (as you later found out) that you just need a tool that will allow you to change the bit. (Restream, etc. ) please share with the community the tool you used to correct this.

[mpucoder]

Actually for a DVD you don't need to fix the video stream DAR, the aspect ratio in the ifo overrides it.

[CirTap]

Hi y'all,

I'm new here (although reading "doom9" for month now to get a grasp of all this DV-stuff and this endless selection of "required" tools), so please PMFJI as I don't want want to hijack this thread ...

I'm about to "move" some ole VHS tapes to DVD, too -- for convenience and not necessarily for the "digital quality" (and this VCR of mine is bugging me anyways).

My captures are 4:3 (720x576/PAL), although some contain letterboxed movies I'd like to turn into "real" 16:9 for the very same reason as Flibster.

Is this possible at all and if so, how?
I don't really care [yet] about the quality loss any resizing may certainly introduce, as the sources aren't that brilliant either (some are LP recordings): a DVD is just easier to handle than a tape <g> and I'm just starting so this is more playing than doing "serious" stuff.

My idea is to crop the black areas with AviSynth MPEG2Source("Electric_Dreams.d2v").Crop(8,76,-8,-74) or even earlier during capture (Virtual[VCR||Dub]) which would give me some non-standard framesize (704x426).

From that: how would I proceed to get back to create a proper PAL-DVD 16:9 format?
Would I simple dumb-resize this back to 720x576 (creating egg-heads) and then set this mysterious 16:9 flag when I transcode/mux this to VOBs?
I'm still uncertain about these "virtual" and mysterious aspect ratio things (still thinking in square pixels, so please forgive me <g>)

Any ideas, hints, procedures?

tia and have fun,
CirTap

[violao]

Originally posted by CirTap
Would I simple dumb-resize this back to 720x576 (creating egg-heads) and then set this mysterious 16:9 flag when I transcode/mux this to VOBs?

If they are 16:9 after cropping then yes. If they are greater than 16:9 then resize to 720 x new_height where:

new_height = original_height * 1024 / original_width

and add borders to top and bottom to fill the heigth up to 576.

EDIT: Also be careful if you crop at capture. If you capture to YUV make sure you set width to multiple of 4.

[CirTap]

Hi violao,

thanx for reply. Let's see if I got this right :-)

After cropping off the black frame the size of the plain "picture" is 700 x 424, which is "close" to 16:9. Your intersting equation does not apply though :)
http://www.webmechanic.biz/pub/doom9/t89985/a_cropped.png
To fix the width wDiff = (720 - Width() ) / 2
AddBorders(wDiff, 0, wDiff, 0, $009900) (just to illustrate I used green here)
This makes it 720 x 424
http://www.webmechanic.biz/pub/doom9/t89985/b_borders-h.png
Should I then add top/bottom borders, too? That would bring me back to 720x576 which is 1.25:1 ??
hDiff = (576 - Height() ) / 2
AddBorders(0, hDiff, 0, hDiff, $990000) (the redish)
http://www.webmechanic.biz/pub/doom9/t89985/c_borders-v.png

I'm totally lost here %-/

CirTap

[mrslacker]

CirTap,

If you are starting with a 700 x 424 image, it is taller than 16:9 and you will need to add borders on the left and right, like you said. However, you should do this after you resize. This is slightly tricky.

The image is taller than 16:9, so you will resize to W x 576 (for PAL).
Then you add borders to get a frame that is 720 x 576.
This will be encoded anamorphic 16:9, so it will be displayed 16:9. There is no need to add borders on the top and bottom again. That's the letterboxing you are trying to get rid of.

So, go through the series of AR transformations to find the appropriate width:

You start with a 700/424 1:1 pixel image. You encode into a 720/576 frame. Then you stretch onto a 16:9 display.

W = 576 * image_AR / ( (16/9) / (720/576) )
(i.e. W = 576 * (700/424) / ( 1.7778 / 1.25 ) ~= 668.6)

So...

LanczosResize(668,576)
AddBorders(26,0,26,0)

When this is played back with proper 16:9 flags, it will look basically like the original, but you won't be saving the black bars on the top and bottom.

[violao]

The equation that would look more like my first one:

new_width = original_width * (576 / original_height) * (720 / 1024)

Don't think of 720x576 as 1:1.25. This is only because of the non-square pixels. Once it gets on a TV it will become 4:3, like if 720 is being resized to 768.

Another thing, you didn't mentioned if the source was interlaced. If yes then you have to separate fields, resize individual fields and then weave.

[mrslacker]

Originally posted by violao
new_width = original_width * (576 / original_height) * (720 / 1024)

Don't think of 720x576 as 1:1.25. This is only because of the non-square pixels. Once it gets on a TV it will become 4:3, like if 720 is being resized to 768.

Another thing, you didn't mentioned if the source was interlaced. If yes then you have to separate fields, resize individual fields and then weave.

That works too. It gives the same number I got.

You're right, it makes no sense to think about PAL as 1:1.25, as the video isn't played back with square pixels. But that's how the video is stored, so you need to take that into account. That 720/1024 term is just that, PAL_aspect/16:9. A more readable version of my equation is this:

stored_AR = original_AR * PAL / 16:9

You are trying to decide how to resize into encoded pixels, so expand the equation to:

W / H = (original_width / original_height) * PAL / 16:9

Choose max H, solve for W:

W = 576 * (original_width / original_height) * PAL / 16:9

Simple.

violao is right again about interlacing:

SeparateFields()
LanczosResize(668,576)
Weave()
AddBorders(26,0,26,0)

otherwise you will blend moments in time.

NOTE: I'm still assuming your 700x424 image.

[CirTap]

WOW!
Way too much math for me 8-)
But many, many thanks! Short story: it worx.

long story: I was playing with these values a bit and tried to get behind the magic.

@violao: This 1024 is extremely irritating: I hate such magic numbers that pop out of the void :)
For whatever reason your eqs. didn't work for me: they gave me numbers I was unable to reuse properly or to put in the right place. I'd blame it on a script error I successfully added though :) I need to debug this later.
I just want to understand what I'm doing that's all, and this implies knowing the source or reason of a "constant" so I'm still curious about the origin of this 1024.

@mrslacker: I was able to reproduce your (although more complicated looking) equation and it makes (more) sense to me once I deciphered it
stored_AR = original_AR * PAL / 16:9
Now I *think* I got it, but please let me try to rephrase this with my own words so we can find out if I'm on the right "stream"...

"PAL AR" = 1.25:1 for 720x576 picture aka frame
"NTSC AR" = 1.5 for 720x480 picture aka frame
thus apply to square PC-pixels only equal to the physical length of each side of the images stored in the video.

Then we have those mushy pixel "sizes":
PC 1:1 ~ straight for simply minds like mine: WYSIWYG so to speak
TV 4:3 ~ goofy
Wide 16:9 - bizzare

Now my functions based on mrslacker post: # -- aspect ratio constants
global AR_TV = (4. / 3) # 1.333333
global AR_WIDE = (16. / 9) # 1.777778
global AR_PAL = (720. / 576) # 1.25
global AR_NTSC = (720. / 480) # 1.5
function getClipAR(clip c) {
global AR_CLIP = (c.Width()*1. / c.Height()*1.)
return AR_CLIP
}
# currently PAL only
function getARWidth(clip c) {
ar = getClipAR(c)
w = Floor( 576. * ar / ( AR_WIDE / AR_PAL ) )
return w
function getARHeight(clip c) {
ar = getClipAR(c)
h = Floor( 720. * ar / ( AR_WIDE / AR_PAL ) )
return h
}
I added the cast to Float on purpose to see more details :)

Maybe this all seems so weired to me because I simply can't detect a *physical difference* in either size or alignment of the RGB spots of both my TV and PC screens which would proof the existance of any squashed and stretched pixels -- I find them pretty squared (or triangular) looking ;-)

So I accept pixels with an AR of 16:9 must virtually exist...
There's a lot of magic happening between all those connected devices I don't understand anyway <g>

I assume: the DVD player sees this 720x576 picture having a 16:9 (or 4:3) flag and rescales the height of its (actually distorted) 576px back to 424px.

On a 4:3 TV depending on the player setup
-- adds some "transparent" (or black) top/bottom borders itself for "letterbox"
-- or crop left/right if not (loosing content / "pan & scan" alike)
-- or use the ugly anamorphic squeeze-stretch-squeeze algo

On a real 16:9 TV set
-- ideally make 'em "square" again filling the edges of the screen

Right?

With a little mind juggling this is pretty similar to what happens with printers having a resolution of 300x150 dpi or such: they resize the initialy square pixel to match their resolution. As they use "dots" not "pixels" it's more easily to distinguish and to *accept* they are different in shape -- or aspect ration, to use this as a mnemonic device :)

However I really want to get into this aspect rations stuff, 'cos I'll run into it several more times with the bunch of captures I have (and plan to do) -- that much I already know. <shudder>
So please let me know if I was correct with this above, otherwise I still have bookmarks (somewhere) to some web-articles I "scanned" in the last few month, and I think I should then try to find them but this time *read* them as well. Too much input lately %-/

I'm going to play will all your nice equations a bit more with a couple of different captures to see what happens to them -- so I know what to do this weekend :)

@mrslacker: btw. is this Mrs. Lacker or Mr. Slacker :D?

Have fun,
CirTap

[mrslacker]

Originally posted by CirTap
I assume: the DVD player sees this 720x576 picture having a 16:9 (or 4:3) flag and rescales the height of its (actually distorted) 576px back to 424px.
...
@mrslacker: btw. is this Mrs. Lacker or Mr. Slacker :D?

It's an early bedtime today, unfortunately, so I just wanted to comment on this one statement...

The DVD player has no knowledge of the original horizontal resolution. As soon as you do that Resize(668,576).AddBorders(...), the source is history. A PAL stream with the 16:9 flag (or the 4:3 flag) is stuck with those 720x576 pixels, distorting them as the flag instructs. Neither the horizontal or vertical resel count are adjusted when the image is displayed. This is how I understand the playback process to work. Apparently, PAL and NTSC hardware are more complex than just 720x576/480, and I have some reading to do as well!


I'm mister slacker... Junior Slacker. ;)

[violao]

Originally posted by CirTap
[B]This 1024 is extremely irritating: I hate such magic numbers that pop out of the void :)
For whatever reason your eqs. didn't work for me: they gave me numbers I was unable to reuse properly or to put in the right place. I'd blame it on a script error I successfully added though :) I need to debug this later.
I just want to understand what I'm doing that's all, and this implies knowing the source or reason of a "constant" so I'm still curious about the origin of this 1024.
In fact they are the same as mrslacker's, just written differently.

As for 1024, imagine you have "digital 16:9 TV" equipped specially for playing DVDs, therefore having exactly 576 lines, or pixels of vertical resolution if you wish. Let's imagine it has square pixels. It needs to stretch 720 horizontal pixels, but to what horizontal resolution? Perhaps 576 * 16 / 9 = ..... Well, you guessed. It's 1024. That's your imaginary TV from your avisynth script. You're preparing image in the script that will appear right when resized to 1024/576. That's for example exactly what SW DVD player does on your computer.

[CirTap]

Hi,
Originally posted by violao
In fact they are the same as mrslacker's, just written differently.
...
Perhaps 576 * 16 / 9 = ..... Well, you guessed. It's 1024.
I made a new (simple) script and put your equations in and <surprise>: worx. As I thought, the error was in the other script.

Now as you both mention this hypothetical TV size and kind of "non existing" physical resolution: AFAIK we're acually dealing with "color and luminance frequencies in time", samplerates, in this whole MPEG/TV architecture.

This explains (to me) why all this rescaling (or better: resampling) does not affect the quality of a "pixel" as it would i.e. in Photoshop working with physical dots pre whatever: frequencies can just "played" slower or faster per line (576/480), adjusted in amplitude etc. and then by "accident" they'd hit the tiny RGB lights in the TV's matrix and illuminates them resulting in some "physical" picture at the postions according to any samerate adjustments made during the process, given by some 4:3/16:9 multiplier/dividor (full screen/letterbox/anamorphic).

At least this is how I can "picture" the process, and why there are such "odd" numbers like 576 -- this article above explains why.
Originally posted by mrslacker
Apparently, PAL and NTSC hardware are more complex than just 720x576/480, and I have some reading to do as well!
http://www.uwasa.fi/~f76998/video/conversion/#the_connectiion

Thanks a bunch for your help, time, and explanations - I think I'm getting to it :D

Have fun,
CirTap

[mrslacker]

Originally posted by CirTap
...and then by "accident" they'd hit the tiny RGB lights in the TV's matrix and illuminates them resulting in some "physical" picture...

http://www.uwasa.fi/~f76998/video/conversion/#the_connectiion
Makes sense, I suppose. I would guess the process would be less "accidental" on an LCD where there's no beam, but a well defined matrix of pixels.

That's the reading material allright! I think ITU-R BT.601 would ideally be considered in our equations, accounting for the fact that only 702 pixels of the width are utilized for the displayed PAL image. The actual frame is narrower than the sampled frame we're always talking about. And what about the source? Was the source sized according to ITU-R BT.601? I'd just consider letting a nice program called FitCD (http://shh.sysh.de/fitcd.html) manage the tedium for me.

Isn't this stuff fun?!?