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. |
14th August 2010, 03:37 | #242 | Link |
Registered User
Join Date: Jul 2010
Posts: 7
|
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! |
14th August 2010, 06:51 | #243 | Link |
Registered User
Join Date: Apr 2003
Location: Uppsala, Sweden
Posts: 157
|
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. |
15th August 2010, 17:18 | #244 | Link | |
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
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/41311023...scene.avi.html Results (H264): http://rapidshare.com/files/41311156..._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? |
|
15th August 2010, 20:36 | #245 | Link |
Registered User
Join Date: Apr 2003
Location: Uppsala, Sweden
Posts: 157
|
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. |
15th August 2010, 21:59 | #246 | Link | |||
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
Quote:
Quote:
True. Normally I use deshaker's fill-in-options and crop the video a little, which gives nice results. |
|||
15th August 2010, 22:56 | #247 | Link | |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
Quote:
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.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
|
16th August 2010, 02:31 | #248 | Link | ||
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
Quote:
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? |
||
16th August 2010, 07:33 | #249 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
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.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
16th August 2010, 13:42 | #250 | Link | ||
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
http://www.dma.ufg.ac.at/app/link/Gr...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. Quote:
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? |
||
16th August 2010, 17:44 | #251 | Link |
Registered User
Join Date: Apr 2003
Location: Uppsala, Sweden
Posts: 157
|
I'm not sure I understand exactly what you mean by this. Does the camera deliver video sized 640x480 or 720x480? And in what way is it distorted? And how do you want the final video to be? (Maybe I'm the only one who doesn't get it...)
|
16th August 2010, 20:01 | #252 | Link | |
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
So here's what I was thinking: Let's say the camera records an NTSC video with a pixel aspect ratio of 0.912. As I understand it, NTSC has 702x480px frames with a 4:3 aspect ratio plus a buffer of 9px on each side. In my case the whole buffer contains valid image information and should be preserved, so we actually have a 720x480px video with a 0.912 pixel aspect ratio and a 4.11:3 aspect ratio. If I wanted the video to have square pixels without distortion while maintaining its original height I would resize the video to 657x480px (4.11:3 aspect ratio). If I resized this video to 640x480px (4:3 aspect ratio) I would assume to end up with a horizontally condensed output. There is a website about the camera where they address this subject as well: http://chucklohr.com/808/#Resizing720x480. p.s.: I'm not sure if I'm still on-topic here and if this is of any value for other readers of this thread. If not, please let me know. Last edited by airborne_video; 16th August 2010 at 20:12. |
|
16th August 2010, 20:26 | #254 | Link |
Registered User
Join Date: Apr 2003
Location: Uppsala, Sweden
Posts: 157
|
Airborne, Your thinking is correct. But since the pixel aspect ratio is actually 4320/4739 (= 0,9115847...), although this has been debated for some time, the width should be 720 * 4320/4739 = 656.34... And since 656 is also a multiple of 16 (which is better for codecs), I'd use that.
Anyway, if you set the destination pixel aspect ratio to "square pixels" in Deshaker, they will become square no matter what destination size you use. |
22nd August 2010, 17:36 | #255 | Link | ||
Registered User
Join Date: Jul 2010
Posts: 7
|
Quote:
Quote:
Yesterday I found the time to record a suitable test video to determine whether the camera actually records in NTSC format with a 0.912 pixel aspect ratio or upscales a 640x480px video to 720x480px (as described on the website I have linked to). It turns out that the video is indeed just upscaled. So I'm now using a source pixel aspect ratio of 0.889 (not 0.88 as written before, bad rounding on my behalf) and 640x480px with square pixels for the output. Thank you for all the helpful feedback and comments! |
||
13th October 2010, 13:08 | #256 | Link |
Registered User
Join Date: Sep 2005
Location: Holland
Posts: 86
|
Is it possible to use the Deshaker plugin in an avisynth script? This way, I don't have to output an enormous video file first. Also, this way I have less intermediate conversions which is better for the picture quality I think. I tried some scripts, but it didn't work. This is the script I used:
Code:
LoadVirtualDubPlugin("C:\Deshaker.vdf","DeShaker",0) AVISource("C:\sample.avi") QTGMC(Preset="Slow").ConvertToRGB32() DeShaker("13|1|30|4|1.09402|1|1|0|640|480|0|1|1|1000|1000|1000|1000|4|1|0|2|5|40|300|4|C:\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|0|0|30|30|0|0|0|0|1|0|0|10|1|15|1000|1|88|1|1") DeShaker("13|2|30|4|1.09402|1|1|0|640|480|0|1|1|1000|1000|1000|1000|4|1|0|2|5|40|300|4|C:\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1.1|4|4|5|5|0|0|30|30|0|0|0|0|1|0|0|10|1|15|1000|1|88|1|1") Last edited by loekverhees; 13th October 2010 at 13:13. |
13th October 2010, 17:10 | #257 | Link |
Registered User
Join Date: Apr 2003
Location: Uppsala, Sweden
Posts: 157
|
In that script Deshaker pass 2 will be applied to the output video of Deshaker pass 1, and that won't work. Both passes should operate on the same original video. I think you'll need to use two separate scripts, one for each pass. That should work.
|
13th October 2010, 18:41 | #258 | Link |
Registered User
Join Date: Sep 2005
Location: Holland
Posts: 86
|
Ah, that's right of course . I modified the script:
Code:
loadvirtualdubplugin("C:\Deshaker.vdf","DeShaker",0) source = AVISource("C:\sample.avi") deinterlaced = source.QTGMC(Preset="Slow").ConvertToRGB32() firstpass = deinterlaced.DeShaker("13|1|30|4|1.09402|1|1|0|640|480|0|1|1|1000|1000|1000|1000|4|1|0|2|5|40|300|4|C:\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|0|0|30|30|0|0|0|0|1|0|0|10|1|15|1000|1|88|1|1") secondpass = deinterlaced.DeShaker("13|2|30|4|1.09402|1|1|0|640|480|0|1|1|1000|1000|1000|1000|4|1|0|2|5|40|300|4|C:\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1.1|4|4|5|5|0|0|30|30|0|0|0|0|1|0|0|10|1|15|1000|1|88|1|1") eval("secondpass") |
13th October 2010, 19:46 | #260 | Link |
Registered User
Join Date: Sep 2005
Location: Holland
Posts: 86
|
Yes, you're right. But I think the real problem is in the way avisynth processes the frames. Ideally, avisynth should first deinterlace the entire video before proceeding to the next step (the firstpass Deshaker part). And then it should do a full first pass and after that the full second pass. But I think avisynth kind of works on a frame-by-frame basis, so it does not deinterlace the entire video before the the firstpass Deshaker part is called. And that's the real problem I think. And about the skipping of the firstpass: I think that the avisynth interpreter first looks to the entire script, and then sees that in the output (eval statement) only "secondpass" is present. So it thinks that firstpass is not explicitly needed and therefore skips that part. In other words, avisynth does not run the script line after line. Could someone confirm this behavior of avisynth? Or is there still another way to accomplish my goals?
|
Thread Tools | Search this Thread |
Display Modes | |
|
|