Deshaker by Gunnar Thalin

[Diamenz]

had to read that a couple of times get it, but i do now. thanks for the reply guth. great plugin.

[Dogway]

I have been struggling with the source pixel aspect ratio setting in the filter. I want to set it to 0.888 as a NTSC 4:3 PAR, will the filter let me choose this? or do I have to stick to 0.912? Another thing is: is it better to crop after the deshaking? that is leaving some black borders for Deshaker to estimate better.

btw. What does PAR have to be with deshaking? some better motion estimation?

[wonkey_monkey]

btw. What does PAR have to be with deshaking? some better motion estimation?

Far be it for me to speak for guth, but PAR affects how a rotation is performed.

0.912 is the closest AR for NTSC (I think it's actually 0.909), because of nominal analogue blanking (http://en.wikipedia.org/wiki/Nominal_analogue_blanking). What's your source, and how have you determined that the PAR is 0.888?

Another thing is: is it better to crop after the deshaking?

You can do, but Deshaker also has the "Ignore pixels" parameters. I'm not sure which will work better, or why...

David

[guth]

I have been struggling with the source pixel aspect ratio setting in the filter. I want to set it to 0.888 as a NTSC 4:3 PAR, will the filter let me choose this? or do I have to stick to 0.912?

When I looked into this a few years ago, I believe Adobe were the only ones I found who used 0.888, but they seem to have changed that lately too:
http://blogs.adobe.com/toddkopriva/2009/07/pixel-aspect-ratios-in-after-e.html

Anyway, the only way to be sure about what PAR your camcorder uses, is to measure it from the actual video (by filming a circle for example).

And you can enter any PAR value you want in Deshaker. (RTFM! ;))

And yes, the PAR is important for handling rotation and zoom correctly, and also if you use different PAR values for source and destination.

The reason Deshaker's preset is appr. 0.912 instead of appr. 0.909 is because I was convinced by that web page, but since most video applications out there seem to use 0.909 I may reconsider, even if it's not correct. :)

Another thing is: is it better to crop after the deshaking? that is leaving some black borders for Deshaker to estimate better.

Deshaker prefers not to see any borders during pass 1. They interfere with the motion estimation. You should remove them either by cropping or using 'ignore pixels'. If you use 'previous and future frames to fill in borders' for pass 2, you should definitely crop any borders before deshaking.

[Dogway]

This (http://forum.doom9.org/showthread.php?p=1390321#post1390321) is my source. I calculated PAR on the well known 8:9 value for 4:3 NTSC. I have also tried the 4320/4739 PAR on other similar sources (NTSC DVD with black bars on both sides) but they looked better in 8:9 (checking some circles of the footage and general appearance).

guth: Thank you, yes I tried to just input the value, and I got the same PAR I originally had in the .m2t (1.5 DAR), with 0.912 I was getting 1.4xx instead of the original 1.5, but I was unsure if it had some relation on the PAR value.

[wonkey_monkey]

The reason Deshaker's preset is appr. 0.912 instead of appr. 0.909 is because I was convinced by that web page, but since most video applications out there seem to use 0.909 I may reconsider, even if it's not correct.

AIUI, 702 (which would lead you to a PAR of 0.912 for NTSC video) is the "correct" width only for PAL video, whereas NTSC uses 704 pixels:

PAL: 576/(702*3/4)=1.09402
NTSC: 480/(704*3/4)=0.909091

Both the NTSC values we're discussing (0.909, 0.912) do account for NAB, but different amounts. If you don't account for NAB at all, you end up with 0.888, and only careful experimentation will tell you whether your camera is made up "correctly" (the difference is, at most, less than 3%).

David

[Dogway]

Well, I dont digitalize video, just old animation so normally the content I work with is NTSC DVD. My question is whether having the black bars do I have to actually take into account NAB in the 100% of the cases or if it depends on every telecined source.

[guth]

AIUI, 702 (which would lead you to a PAR of 0.912 for NTSC video) is the "correct" width only for PAL video, whereas NTSC uses 704 pixels:

PAL: 576/(702*3/4)=1.09402
NTSC: 480/(704*3/4)=0.909091

I don't use 702 for NTSC, I use 710.85. :)
According to this page (http://lipas.uwasa.fi/~f76998/video/conversion/), which I still believe is the truth, it should be calculated like this:

PAL: 576/(702*3/4)=1.09402...
NTSC: 486/(710.85*3/4)=0.91158...

[guth]

Well, I dont digitalize video, just old animation so normally the content I work with is NTSC DVD. My question is whether having the black bars do I have to actually take into account NAB in the 100% of the cases or if it depends on every telecined source.
I'm afraid I don't understand what you mean. I don't even know what NAB means...

But in case it solves anything for you, the aspect ratio of a pixel (ie the PAR) doesn't change just beacuse the video has borders or not, or if you crop, or not.

Finally, I didn't know you wanted to use Deshaker for stabilizing that kind of video. Deshaker was designed to stabilize unwanted camera motion, not really other kinds of shakes, even if it can do that sometimes too. In your case, it might actually be better to include the borders during pass 1, at least when the animation background isn't supposed to move.

[Dogway]

NAB (http://forum.doom9.org/showthread.php?p=1392010#post1392010)

Because if I have the black bars (NAB) I would have to assume 704 width, therefore indicating my source is PAR 0.909. So my question is whether this only applies for direct digitalization (analog->digital) or it stands as well for DVD's digital content previous digitalized. Otherwise I would just need to assume PAR 0.888. I mean, I would like to know what do I have to base on to know if the manufacturer assumed 0.888 or 0.909. Mainly because when I do play any DVD (NTSC) on my laptop the object geometry is the same as using 0.888, and in practice it feels more natural than 0.909. Manufacturers must be doing it wrong? Id like to see examples on this.

Sorry this talk derived to AR, its something Ive been carrying on long time.

I cant differentiate between camera shake or other shakes, other than floating cels in case of animations(?)

[guth]

Because if I have the black bars (NAB) I would have to assume 704 width, therefore indicating my source is PAR 0.909. So my question is whether this only applies for direct digitalization (analog->digital) or it stands as well for DVD's digital content previous digitalized. Otherwise I would just need to assume PAR 0.888. I mean, I would like to know what do I have to base on to know if the manufacturer assumed 0.888 or 0.909. Mainly because when I do play any DVD (NTSC) on my laptop the object geometry is the same as using 0.888, and in practice it feels more natural than 0.909. Manufacturers must be doing it wrong?
I'm no expert on this subject, but I don't think the black bars tell you anything about the PAR. The table on the page I referred to above says that the sampling matrices 720x486, 720x480, 711x486, 704x486 and 704x480 all share the same PAR, namely 4320/4739. The table also mentions DV, DVB and DVD for that PAR.

If you think 0.888 looks better, maybe you're fooling your brain to think so, because you want it to be that way, or maybe you're used to looking at video like that, or... maybe the manufacturers are wrong. But I really don't think 0.888 is ever the correct PAR to use (except for correcting other's mistakes).

[Dogway]

I have been doing some checks between different PAR screenshots and some original sketches from storyboards, and yes it seems to be 0.912 or 0.909, rather 0.909 I think. I think that what it was fooling me was the CGI circle, wrongly implemented into the animation (PAR wise), so anyway, who knows I will stick to 10:11 and see if that fully satisfies me, at least for the hand drawn parts.

I dont know where did I get the 8:9 thing, I cant find it, I guess it was in a thread here. Until now I was using this table I made for reference, now I guess is somewhat wrong:

SAR examples: (704x576) (704x480)

4:3 = 12:11 pal = 10:11 ntsc
16:9 = 16:11 pal = 40:33 ntsc

SAR For Digital Playback: (720x576) (720x480)

4:3 = 64:60 (16:15) pal = 64:72 (8:9) ntsc
16:9 = 64:45 pal = 64:54 (32:27) ntsc

*You can also see the 8:9 PAR in the reference section of the PAR wiki (http://en.wikipedia.org/wiki/Pixel_aspect_ratio)

[Boulder]

Gunnar,

some questions for you:

If I set the Deep analysis to kick in at for example <50%, it often doesn't show the "Deep analysis" text in the preview window even if the percentage of OK blocks is less than the limit. If I set it to 100% or so, it's used for every frame. Is this intentional or a bug?

Do you have any plans to improve the motion detection method, for example by introducing overlapping blocks (such as in MVTools2)?

[guth]

If I set the Deep analysis to kick in at for example <50%, it often doesn't show the "Deep analysis" text in the preview window even if the percentage of OK blocks is less than the limit. If I set it to 100% or so, it's used for every frame. Is this intentional or a bug?
The deep analysis percentage is a percentage of all found vectors, while the text gives you the percentage of all blocks. If matching fails for a block, it won't get a vector at all, so there are usually fewer vectors than blocks. That's why. A little confusing, I know. :)

Do you have any plans to improve the motion detection method, for example by introducing overlapping blocks (such as in MVTools2)?
Most people seem to think deshaker is too slow. What you propose wouldn't exactly make it faster. :)
We'll see, but I'm afraid it probably won't happen any time soon anyway...

[Boulder]

The deep analysis percentage is a percentage of all found vectors, while the text gives you the percentage of all blocks. If matching fails for a block, it won't get a vector at all, so there are usually fewer vectors than blocks. That's why. A little confusing, I know. :)OK, thanks for the info.


Most people seem to think deshaker is too slow. What you propose wouldn't exactly make it faster. :)
We'll see, but I'm afraid it probably won't happen any time soon anyway...The clips I use Deshaker on are very important so speed is not an issue.. The current 1st pass analysis is running at 0.9 - 1.2 fps at close to max settings so I don't know if it's that slow, though there's nothing in the AVS script but conversion to RGB24. Computers are getting faster all the time, my Core2Duo rig is from 2007 :)

[Boulder]

Another feature request: it would be nice to be able to use Lanczos or Spline for resampling. I assume that you use the selected resampling option for zooming in the edge compensation functionalities? Lanczos or Spline should provide sharper output than bicubic.

[guth]

Another feature request: it would be nice to be able to use Lanczos or Spline for resampling.
From what I've seen the difference is barely visible, except under extreme test scenarios. And not even then is it easy to see which is better, I think. So I don't think I'll bother. (And that's coming from a perfectionist :))

I assume that you use the selected resampling option for zooming in the edge compensation functionalities? Lanczos or Spline should provide sharper output than bicubic.
Deshaker needs resampling for lots of reasons, but everything is always combined into one single resampling (so no pixel is ever resampled twice between input and output). And that single resampling uses the selected algorithm.

[Undead Sega]

Hello guth, it has been awhile, hope all is well.

i probably mentioned this before a couple years ago but i cant find what ive type,plus im more experienced in this matter but im still having a problem. The problem im having is to stablize a shot, this contains a panning camera from right to left in an empty (static) room to only have a person sitting in the middle of the shot making large and fast movements. The camera itself is of course what i want to stabilize, however from what im gathering, the motion vections are picking the person's movement as camera shake, therefore the resulting video look would shake in accordance to the movement that the person is making. I was wondering how can i avoid this? and what parameters do i need to set accordingly?

i hope u understand what i mean, and i would really appreciate it if u can help me on this. thanks and look forward hearing back,

[guth]

The problem im having is to stablize a shot, this contains a panning camera from right to left in an empty (static) room to only have a person sitting in the middle of the shot making large and fast movements. The camera itself is of course what i want to stabilize, however from what im gathering, the motion vections are picking the person's movement as camera shake, therefore the resulting video look would shake in accordance to the movement that the person is making. I was wondering how can i avoid this? and what parameters do i need to set accordingly?
If the deshaked video is only slightly wavy, you should probably reduce the value for "discard motion of blocks that move > X pixels in wrong direction". Maybe to 1 or even lower. That's to avoid picking up even very slow motion from the person.

If it's very shaky after deshaking, then Deshaker probably lost track on where the stable background is and started matching partly or completely on the person. Remember, you shouldn't get any white vectors on parts of the person that are moving. The white vectors should only be on the background or on the person's still parts. This can sometimes be tricky to accomplish, especially if the person takes up a large portion of the frames. You can try decreasing block size and increasing differential search range and set "use pixels" to "all". If possible, you should definitely use "deep analysis". And if everything else fails, you can use "ignore pixels" to help Deshaker ignoring the person.
Next version of Deshaker will have more ways to help avoiding this problem. (Now that VirtualDub 1.9.9 is out and seems to include a bugfix I've been waiting for, I'll probably release it soon. Don't expect any major cool new features, though...)

[Boulder]

What sort of improvements are expected to be in the next version? I'll start working on the second passes of my projects and was wondering whether I should wait a while for the new release?

While I'm writing, here's another shameless feature request :) It would be nice to have limits for horizontal and vertical corrections in pixels so that I could enter a value that I know I can live with (for example I've measured that my TV has approximately 16 pixels of overscan).

[guth]

What sort of improvements are expected to be in the next version? I'll start working on the second passes of my projects and was wondering whether I should wait a while for the new release?
The changes for pass 1 will make it possible for that pass to become more robust.
For pass 2, you will be able to use future frames without having to delay audio, append clips etc. The actual output from pass 2 will be the same, however.

It would be nice to have limits for horizontal and vertical corrections in pixels so that I could enter a value that I know I can live with (for example I've measured that my TV has approximately 16 pixels of overscan).
The best way to control how big the borders will be (or to make them completely dissappear under overscan) is to select an "edge compensation" mode that gives no borders and then zoom out using an "extra zoom factor" below 1 ( ((width_or_height - 16) / width_or_height) to make borders dissappear under overscan in your case).
You can then use the smoothness settings and correction limits to find a good balance between motion smoothness and the amount of edge compensation zooming needed to get the amount of borders you wanted.

[Undead Sega]

Hello guth, thanks very much for the suggestion but during the past couple days, i have tried what you've said and ive tried everything else with no luck, therefore i was still wondering if you can help me with it:

http://www.megaupload.com/?d=G98LVF0E

was hoping if you could have a go with it and see if you get any good results. Hope its okay :)

[guth]

I'm afraid I can't really deshake that clip either. There's too little detail in the background, and the details that are there are mostly straight lines, which are "unmatchable". A feature based matching algorithm would probably do better in this case. Deshaker uses area based matching. Sorry...

[guth]

Boulder, in case you care, the formula I gave above should probably be ((width_or_height - 32) / width_or_height) instead, since I guess you meant 16 pixels on each side...?

[Undead Sega]

I'm afraid I can't really deshake that clip either. There's too little detail in the background, and the details that are there are mostly straight lines, which are "unmatchable". A feature based matching algorithm would probably do better in this case. Deshaker uses area based matching. Sorry...

Damn, and i thought i was doing something terribly wrong. Probably a feature based matching algorithm might be your next feature for Deshaker? :D

regarding this, what image stabilization software could probably deshake my footage?

[Boulder]

Boulder, in case you care, the formula I gave above should probably be ((width_or_height - 32) / width_or_height) instead, since I guess you meant 16 pixels on each side...?Yes, I meant ~16 pixels on each side. Thanks, I'll see how it works when I get to run the second passes some time this week :)

[guth]

regarding this, what image stabilization software could probably deshake my footage?
Don't know...

[Undead Sega]

fair enough, however I came across Mokey by imagineer systems which uses their 2.5D planes to track footage and etc. and if i am correct, you can also export that tracking data into After Effects. May i ask, could something rom that software be used in the logfile for Deshaker?

[guth]

The Deshaker logfile contains the change (in pannaing, rotation and zoom) between one frame and next frame. I don't know what that software can produce.

[Undead Sega]

This:

http://forum.doom9.org/attachment.php?attachmentid=11172&stc=1&d=1276733925

any of it looks familiar by any chance? :)

[Undead Sega]

take it what you saw doesnt look familiar or useful?

[poisondeathray]

planar trackers (like mocha and mokey) and point trackers (like AE) work differently than deshaker. They don't report the difference between subsequent frames (one frame and the next) like deshaker does. They track difference between a reference frame or x,y,z position and rotation/scale/sheer etc.., ie. where you set the point tracker or 2d plane . The reason is they are more geared for compositing work and they need precision against a specific reference point (e.g you want to replace an object in a movie, like a poster with another poster etc...)

You could translate them I suppose, if you made a program and converted the numbers to make them differences between consecutive frames

[guth]

take it what you saw doesnt look familiar or useful?
I've told you what Deshaker wants. Now it's up to you to see if you can get those values from somewhere else. (I'm definitely not saying it's impossible. I just don't want to do the work myself. :))

[dedfish]

Any recommendations specifically for vehicle, motorcycle in my case, mounted videos? Are there particular settings that would work better for high speed movement?

[guth]

I know a lot of people seem to be using Deshaker for those kind of videos, but it's not really designed to handle videos where the camera "moves around", at least not where it moves very fast. Deshaker can only handle panning, rotation and zoom. That said, I've seen some very good deshaked videos of that kind.

As always, make sure you're using a high enough shutter speed, if possible. There shouldn't be any motion blur in each frame.
Also, you would probably get *a lot* better results if the camera didn't have a rolling shutter. But I believe most helmet mounted cameras today have a rolling shutter. Deshaker can remove rolling shutter effects but only if the shaking isn't extreme.
I would also recommend trying to stabilize only on the most distant parts in the frames, since the "moving inwards"-effect is less there. You can do that by ignoring the other areas.
And turn off zoom smoothing by settings zoom smoothness to 0. You will also need to change the edge compensation type if you do that. Start with "None", maybe.
Finally, you should probably increase the value for "discard motion of blocks that move > X pixels in wrong direction". That's to allow the blocks to move "freely" a little, since Deshaker can't handle the "moving inwards"-effect.

But maybe you should ask someone who's actually stabilized these kind of videos. I haven't. :)

[dedfish]

Thanks, I appreciate you taking the time to answer my question.

If anyone else has any tips they've found to work well for this type of video I would love to hear them.

Cheers!

:thanks:

[Undead Sega]

Hello once again guth, it is I :D

I am actually still having problems trying to deshake my footage, I have created a new image sequence from the original, but this time it was deinterlaced using TGMC to 50p and I removed the noise using Neat Video resulting me with a (slightly sharp but) clean image, I dont know if that is going to make any differences?

...but I have been trying it with formentioned software, but it is not as effective as your filter, especially when it comes to border filling, wouldnt you happen to know of other software or filters that can literally do what your filter does interms of borderfilling effectively?

Also, you say your filter uses area based matching, is this something that is limited in ur filter or in Avisynth? Possibly there could be an avisynth filter that uses a more sosphisticated algorithm for the searching of the footage (and possibly be used in Deshaker)?

[guth]

I am actually still having problems trying to deshake my footage, I have created a new image sequence from the original, but this time it was deinterlaced using TGMC to 50p and I removed the noise using Neat Video resulting me with a (slightly sharp but) clean image, I dont know if that is going to make any differences?
Me neither. But removing noise can be very bad for Deshaker if the smoother uses some kind of temporal smoothing. That kind of smoothing often leaves traces of earlier frames that Deshaker can match on, incorrectly.

wouldnt you happen to know of other software or filters that can literally do what your filter does interms of borderfilling effectively?
No, I don't. But I haven't been looking much either.

Also, you say your filter uses area based matching, is this something that is limited in ur filter or in Avisynth? Possibly there could be an avisynth filter that uses a more sosphisticated algorithm for the searching of the footage (and possibly be used in Deshaker)?
I'm not sure I understand your question. The matching algorithm is inside Deshaker. You can't change it without me doing something.
Could there exist filters with a more sophisticated search algorithm? Sure, but Deshaker can't use it without me doing something. Unless it can produce logfiles for Deshaker pass 2.

[guth]

Deshaker 2.5 is now released.
(New versions don't seem to come very often lately, so I thought I should mention it.)

Get it here (http://www.guthspot.se/video/deshaker.htm).

[2Bdecided]

Deshaker 2.5 is now released.
(New versions don't seem to come very often lately, so I thought I should mention it.)

Get it here (http://www.guthspot.se/video/deshaker.htm).Thank you!

You should post this in the news section.

Cheers,
David.

[guth]

Nah... I just want true Deshaker fans to know :)

[airborne_video]

Hi Gunnar,

thanks for the great filter!

I have mounted a keychain-camera to a model airplane and use your filter to improve the resulting videos. Although (as you have mentioned before) the filter is not designed for this purpose the results are quite impressive. One issue I am facing though is the relatively high amount of dropped frames these kinds of cameras produce, which appear as duplicate frames in the video. Deshaker perceives these duplicate frames as proper individual frames and this leads to bad results. I was thinking that it might be a good thing if you only compared the first frame of a series of duplicate frames to the next real frame following the duplicate frames and then spread the resulting adjustments evenly over the series of duplicate frames. I am guessing that identifying duplicate frames should be feasible, since they show zero motion compared to preceding images.

Just an idea.

Thanks for all the time and effort you put into this!

[guth]

If duplicate frames appear, Deshaker should already behave exactly the way you describe. But since it only adjusts the whole frames, and not moving objects within frames, those moving objects will still appear to "jump" a bit. The background in the video should, however, become perfectly smooth even when duplicate frames appear.
If you want me to look at it, email me a short clip.

[airborne_video]

If duplicate frames appear, Deshaker should already behave exactly the way you describe.

Hi Gunnar,

I don't know what I have done wrong, but you are right - it does work in the way described. I am not sure why I didn't get the results I was looking for so far, but it was definitely some mistake on my behalf.

I have a small example clip with lots of dropped frames that shows that you're right:

Source (MJPEG): http://rapidshare.com/files/413110232/001_original_scene.avi.html
Results (H264): http://rapidshare.com/files/413111567/002_deshaker_results_H264.avi.html
Settings: http://rapidshare.com/files/413115102/settings.png.html

Frames 80 to 130 of the filtered video show results as expected.

Do you have any advise regarding the minor glitches between frame 171 and 172 and between frame 211 and 212 of the filtered video?

[guth]

The glitches occur because of basically three things:
1. The video there basically only contains fields without much detail, and with straight lines in-between. It's hard to match on.
2. Motion blur makes details fuzzy.
3. The date and time at the bottom of the video confuses the matching.

If you decrease the value for "Discard motion of blocks that have 2nd best match > best - X" all the way to 0, this will force deshaker to generate motion vectors even when they aren't very reliable. It will work fine for this video clip to fix the glitches.
Also, I would "Ignore pixels inside" the area of the date and time.
And since the video has size 720x480, the pixels probably have pixel aspect ratio = NTSC.
Finally I would probably do something about those black borders.

[airborne_video]

If you decrease the value for "Discard motion of blocks that have 2nd best match > best - X" all the way to 0, this will force deshaker to generate motion vectors even when they aren't very reliable. It will work fine for this video clip to fix the glitches.

Thanks a lot, I will try that.

Also, I would "Ignore pixels inside" the area of the date and time.

About that: if I have a video sized 720x480px and want to ignore a box sized 410x30px lying in the right bottom corner, do I enter L311 R720 T451 B480 or L310 R0 T450 B0 into the "ignore pixels inside" fields?

And since the video has size 720x480, the pixels probably have pixel aspect ratio = NTSC.

It's actually a distorted 640x480px sized video. The camera does the distortion. I usually resize the video before using deshaker.

Finally I would probably do something about those black borders.

True. Normally I use deshaker's fill-in-options and crop the video a little, which gives nice results.

[scharfis_brain]

It's actually a distorted 640x480px sized video. The camera does the distortion. I usually resize the video before using deshaker.
There is absolutely NO need to do so.
This way you'll end up with two chained scalings.

Just setup deshaker correctly.
In analyse pass set 4x3 NTSC Aspect Ratio.
In render pass set 1:1 aspect ratio and 640x480 pixel.

This saves processing time and offers better image quality.

[airborne_video]

About that: if I have a video sized 720x480px and want to ignore a box sized 410x30px lying in the right bottom corner, do I enter L311 R720 T451 B480 or L310 R0 T450 B0 into the "ignore pixels inside" fields?

Solved: it's the latter. :-) Stupid question...

In analyse pass set 4x3 NTSC Aspect Ratio. In render pass set 1:1 aspect ratio and 640x480 pixel.

This saves processing time and offers better image quality.

Thanks for the advice. Very much appreciated!

Since 640/720 is 0.88 and not exactly 0.912 (Standard NTSC) would it make sense and work to manually enter "0.88" in the dropbox?

[scharfis_brain]

Aspect Ratio Correction is far more 'complicated' than you might imagine.
640 pixels actually translate to 702 pixels.
This also means that 720x480 after aspect ratio correction are 657x480 pixels.
If there aren't any borders left and right (each about 9 pixels in width)
you're lucky to have some additional image information which widenes the image.
So just leave the numbers as they are. They are correct.

[airborne_video]

Aspect Ratio Correction is far more 'complicated' than you might imagine.
640 pixels actually translate to 702 pixels.
This also means that 720x480 after aspect ratio correction are 657x480 pixels.

Thanks, based on your posting I have searched for more information and stumbled upon this website (in German):

http://www.dma.ufg.ac.at/app/link/Grundlagen%3AVideo.Postproduction/module/9039?step=1#chapter

So here is what I learned:

NTSC has 480 horizontal lines. With square pixels and an aspect ratio of 4:3 a frame with a height of 480 pixels would be 640 pixels wide. A digitized 4:3 NTSC frame however is defined to be 702 pixels wide with non-square pixels (as a result of a 13,5 MHz scanning frequency).

Thus the pixel aspect ratio is 640/702 = 0,912

A 9px buffer is added on both sides to deal with horizontal deviation that might occur during the digitalization of an analog NTSC signal. In sum these borders to each side add up to 18px. So in the end we get a 720x480px frame.

The keychain camera produces an image where the complete buffer to the left and right contains valid image information.

This also means that 720x480 after aspect ratio correction are 657x480 pixels.
If there aren't any borders left and right (each about 9 pixels in width) you're lucky to have some additional image information which widenes the image.

Got it! Thanks!

So if I don't cut the buffer area, since it indeed contains valid image information, I should actually configure the output to be 657x480px in pass 2, if I chose a 1:1 pixel aspect ratio for the output, right?