resolved Image Stabilization under Windows 10 Problem

[Russ Croucher]

I have 5 master cut versions of videopad for my business and have discovered an error in the image stabilization process on Windows 10 versus Windows 7 of the latest version.  VLC works great with Windows 10 however the image stabilization under Windows 10 comes up with many false hours instead of the actual 2 hours or whatever it is with Windows 7.  Apparently the image stabilization must be looking at the header wrong or something but only under Windows 10.  I have taken the exact same project and run it under Windows 7 and Windows 10 and a problem only shows up with Windows 10.

Since I use handbrake as my last step (to change the encoder level) I can actually run videopad with Windows 10 and run it through handbrake and that corrects the problem.  However, the intermediate step from the video is very very large because of the wrong length of the file.  The length of the file should be approximately 2 GB per hour and since it has the wrong length it might be 2 GB per hour but it will be a huge file because it thinks is 10 hours long.  When you actually use the film and TV viewer that came with Windows 10 it cannot display anything after the file because is not there and just locks up.

So the workaround right now is to make sure handbrake is the last step and all the image stabilization is done with Windows 7.

Has anyone else seen this type of problem?  Since I have a good workaround I would just check periodically when it is fixed.

 

 

[borate]

Next stabilization, try this setting, under ADVANCED.

Submit an unstabilized test file that has the issue, and someone will take a look. 

Upload the file/s to a free server, such as Google Drive or MS OneDrive, get a shared (public) link, copy the link and paste it here or to me in a Private Message via the mail envelope in the top-right corner of this forum.  When using Google Drive, if necessary change "restricted" to "anyone with link can view."

[Russ Croucher]

I thought about it I did submit a bug report but I did check the box for uploading a file because the Windows 7 version is 2 gigs in the Windows 10 version is 11 gigs for the same file.  So I would have to zip it all up and send it as one file and that would be 13 GB.  So I opted to just not include the file update and see if anyone else's had the similar type of problem.

I've just discovered this and I think I went back several versions it was still there.  I normally use all Windows 7 but I have been slowly migrating to Windows 10 on my latest very fast workstations.  Actually I like Windows 7 better because it doesn't do updates and I don't want updates.  As long as it works I'm happy.

I will say I absolutely love this product.  But as all engineers like myself know you fix something and sometimes you breaks something without realizing it.

I do have 1 TB of Microsoft one drive with my Outlook 365 account.  Can I use that to create a link you could use here?  I would find that much easier than your FTP server.  That way I can actually include the link in with my bug submission.  I would leave the bug file there until I realized it is fixed in the later versions.

[borate]

A OneDrive link should work for forum visitors who want to look into the issue.  A bug report would go to the company, which is apart from a file linked here.  And this may not be a bug, but a setting for the deshaker plug in.  Test the suggestion above, with W10.

[Russ Croucher]

I understand it may not be a videopad bug.  It's an anomaly I have a notice between the same project file with Windows 7 versus Windows 10.  So to me it's a bug in Windows 10.  Maybe there's a configuration that I did not notice inside only use Windows 7 in the past.  So I'm going to go through the configuration of the D shaker plug-in very carefully.  I don't mean to give negative results about any product but as an engineer who worked on very large programs we create bugs not even realize it.

I love this program is awesome.  But every awesome program has some possibility of bugs

[Russ Croucher]

I did verify the image stabilization options above under the advances I always check them and there was no change.  The one interesting fact is some of the videos I have are interlaced and some are not so that's an option I had to change a lot.  Also on the version I have the NTSC standard is 0,.912.  However, I've knows that only affects how much skewing is going on with the stabilization.

I have uploaded to my Microsoft one drive 2 files that I'm going to submit official bug reports for this problem.  I have a workaround which I'm currently using.  That is to image stabilize with either Windows 7 or Windows 10 and then run the final output through handbrake which I always do anyway.  Handbrake does an excellent job of the de-interlacing old analog videos and setting the encoder level I wish to use.
 

[borate]

Post the link to an unstabilized file here and someone will check it out.

[Russ Croucher]

Here is the 2 files that are identical except for one is Windows 7 and the other is Windows 10.

win7   https://1drv.ms/v/s!AuSetTxgq7JxqMYWfcFJHuEyNZLtIQ?e=HG4Gn1
win10 https://1drv.ms/v/s!AuSetTxgq7JxqMYXUfvrRpQsOSx13Q?e=I1WbvE

I also have one workstation that is dual processor and the image stabilization will not start again after one file.  Is there any intention to ever change this so it will work with multiprocessor even if it doesn't use the other processor?  I even went into that particular processor and told video not to use the other processor but that doesn't seem to help.

[borate]

Both are listed as "stabilized."  What's needed is a single UNstabilized file, so it can be tested in the deshaker module.

[Russ Croucher]

Here is a link to the original file unstabilized.
https://1drv.ms/v/s!AuSetTxgq7JxqMYYtmc45CFLBb8jkw?e=bltSVb
 

[borate]

Checked with MediaInfo, Windows 10 deshaking here results in a 5h 16min file - sometimes only audio, at others A/V - yet file size isn't larger than the original. 

It tends to drift out of sync.  What equipment created the UNstabilized file?

[Russ Croucher]

Analog conversion is done with S-Video directly into a digital imaging Matrox VIO card card.  I do the following tapes:  VHS, SVHS, VHS–C, SVHS-C, Video8, and Hi8.  All analog conversion is done using S-Video at 640x480 through BNC connectors.  The loss of sync you're referring to is from the customer turning on and off the camcorder going through different video clips.

All VCRs are commercial SVHS VCRs Panasonic 1970 and even on eBay sell for $500 used today.

Some customers even switch between SP and LP mode between these video clips.

The original unstabilized video is one hour and 21 minutes in both unstabilized and Windows 7 stabilized.  However, under Windows 10 stabilized version is 5 hours and 16 minutes.
 

[borate]

Correct length and good overall result on this file when using the MPEG4 compressor.  Click deshaker OPTIONS to select it.

Click ADVANCED for other settings used in this test:  Standard (NTSC) pixel aspect, Progressive scan, Adaptive+fixed (no borders).

[Russ Croucher]

SUCCESS!

Apparently I was doing everything as H264 since I run my final product in H264.  Even though this intermediate step is done with very high output (high-quality).  So when I change it to MPEG4 everything was fine.  So now I'll change everything to that and use that as my intermediate step.

One last comment on the image stabilization is theater our older analog videos everything had to be done is interlaced.  We got away from interlaced about 20 years ago.  But older videos still use them.

[borate]

Looks as if the issue with H264 destabilization is fixed in version 10.48 (beta, as of this writing).

[Russ Croucher]

Thanks I have to give it a try.  I'm currently using 10.43 on everything.

[Russ Croucher]

I'm still having encoder problems with the latest versions of videopad.  Maybe this is a different problem but I have isolated it down to a small file that I have uploaded that I'm going to share with everybody to understand the problem.  I have verified this with 10.78 and 10.86.  I'm still currently using 10.78 because 10.86 as a problem with the ctrl-A(select all) keystroke and is very slow loading large files.So I have stayed with all my procedures with 10.78.  Since the image stabilization produces the exact same file.

Here is the Raw 12 minute MP4 file:  https://1drv.ms/u/s!AuSetTxgq7JxqN1gpKIv4cFD3ZAUzQ?e=Kbe9Al

Here is the project used to load the file above:  https://1drv.ms/u/s!AuSetTxgq7JxqN1gpKIv4cFD3ZAUzQ?e=219kR5

I started the image stabilization with "H264" in its largest file size.  Here is the output:  https://1drv.ms/u/s!AuSetTxgq7JxqN1gpKIv4cFD3ZAUzQ?e=IDu56Q

This is the file with the audio error.  The audio is delayed several seconds.  Here is the exact same file that works in "mpeg4" mode.  The only difference in the image stabilization is selecting this mode versus H264.  https://1drv.ms/v/s!AuSetTxgq7JxqN1iR0yrms4ZF8HnXQ?e=kXfK0Z

I also want to point out that this is only a Windows 10 problem and it does not pop up with Windows 7.  This may be a codec issue.  I just wanted to post here to get some input from you guys.  I made a pointed reduce the file size down to just 12 minutes so is it easier problem to understand.

[borate]

The issue of <ctrl-A> not selecting all bin files has been reported and should be remedied shortly.

For the load speed issue, go to OPTIONS | MEDIA tab and uncheck

Nothing in that stabilizer plug in has changed AFAIK.  Suggest sticking with MPEG4.

[Russ Croucher]

Thanks for heads up.  I am planning from now on to always stick with MPEG-4.  I thought I would try it and see what the deal is.  It seems like I have less issues with MPEG-4.  I will check the media tab options thanks.

[borate]

If you prefer H264 set the Mp3(Layer 3) audio encoder.  When finished, right-click on the stabilized file and flip it vertically.  Appears to be in sync.

[Russ Croucher]

No I'm perfectly happy with MPEG-4.  I just tried it to see what would happen.  Now I have a short 12 minute video I can verify one way or another.