johnmeyer

You have basically done what the preview window in Vegas does when set at different preview qualities. For example: Preview/Half will show the "ghost" video and Best/Half will show the "intended" video.

OldSmoke,

I think you are correct because I didn't realize that my Video_02 still shows some interleaving. However, you will still find that if you have preview scaling turned on, then the various Half/Full and Best/Good options will change what they do as you physically re-size the preview screen to be larger and smaller.

I'm still convinced that the problem lies in how the original video was captured, and how frame rates are changed or resampled during the editing process. I guess the buggy GPU structure could also be doing this.

If it were me, and I still had an earlier version of Vegas lying around, I'd try to get the project back to that earlier version, either using copy/paste between versions, or using an EDL file. I'd do it with just a small section of the project, to begin with, because the full project might take awhile to transfer. Then, I'd make sure I didn't use any GPU setting.

Having the problem come and go depending on which fX are applied can also be explained by how the video is structured because various fX re-sample and re-scale the video in different ways.

[edit]I just looked at both videos I posted (the one's that resulted from separating the video into fields) and I realized that this video has been telecined!! What this means is that there are repeating fields and/or frames in the original video. Therefore, the entire chain from the encoding done during capture all the way to the final render that created the example file must be looked at. Since this is PAL, I wasn't looking for telecine, but the duplicate fields are obvious in the two videos I posted (look at the dirt spots on adjacent frames/fields). If there is IVTC going on, or if there are explicit or implicit conversions being done between 29.97 interlaced, 24 fps film, 25 fps interlaced, and maybe even 25 fps progressive, there are lots of ways some of these effects might be created.

One thing I'd look for on the Vegas timeline is whether any of the events show that little diamond at the top edge of the event, signifying that the event has come to and end and is now repeating.
----

Put Video_01 on the timeline and match project properties. These frames (i.e., fields from the original video) are identical:

02,03
05,06
08,09
11,12
14,15
17,18
20,21
23,24

Thus, to get back to the original film, one out of every three fields must be decimated. If the original frame rate was 16 fps (a common 8mm and early 16mm frame rate) and this was then telecined to 24 fps (the usual film speed), then this is exactly the telecine pattern I'd expect. 24 fps is usually changed to 25 fps for PAL, simply by changing the file header (i.e., no repeating or decimation; the file is just played back a little faster). Since this looks like 16mm film to me (based on aspect ratio, not clarity), this makes sense.

John

The original film was shot in Standard 8mm cine film, mostly at the usual 16fps in 19890 and 1981. It was transferred to AVI with both GSpot and MediaInfo showing this as 25fps which is the PAL standard.

I'll look for the little diamonds when II get back to my PC tomorrow.

Richard

The best would be to have a look at one of the media/clips that is used for this project. What we see has already gone though the decoder again. We only see the result coming out of Vegas but we cant see what goes into Vegas.

"I'm still convinced that the problem lies in how the original video was captured, and how frame rates are changed or resampled during the editing process"..
+1 John. Hence the focus on the Canopus capture settings and or driver version.

I have to dash!
Paul.

Alarmingly enough I've seen something very much like this outside of Vegas and it has nothing to do with how the video is captured and everything to do with how video can be recorded.

What can happen is this:

1) You record content to a tape.
2) You're not happy with it so you do it again.

Between 1) and 2) one of the heads becomes badly clogged. Depending on the tape format alternating bands of the original recording are left intact and the other bands of the frame contain the new content which can be only slightly out of time with the original.

This is pretty blatantly obvious with DV as each head writes several lines in each pass. I wasn't around the technical stuff in the heyday of VHS so I'm not familiar with exactly how VHS is written to tape however I can confidently say from my above results that this problem has nothing to do with how the tape was captured or corrupted headers. Not only that but futzing around with how monitors are connected will reveal nothing new and is simply a waste of time. Changing monitoring may change how the problem is seen but not the problem itself.

I'd strongly suggest going back to the source material and checking it field by field at Best/Full with Stretch to Fit Off . To view each field change the project frame rate to double that of the media, in this case Double PAL (50fps), Set de-interlace method to None. This should work for V12....well it does with V9.

Bob.

I'd strongly suggest going back to the source material and checking it field by field at Best/Full with Stretch to Fit Off . To view each field change the project frame rate to double that of the media, in this case Double PAL (50fps), Set de-interlace method to None. This should work for V12....well it does with V9.+1

Very many thanks.

I've placed the original media in the Trimmer and played this as you suggested with no evidence of any ghosting coming through.. I've also played it in VLC, Windows Live Moviemaker and Windows Media Player and again with no ghosting to be seen.

I cannot see any of the diamonds that John referred to in his earlier post and my Rendering in this case is to PAL 4;3 mpeg2 at LFF (i.e. the normal) but I'm not sure how the rendering would impact on the problem as it is to be seen before we reach that stage.

I ought to say that I've had numerous films transferred by the same company in the same way to a hard drive and have always been able to edit this without any problem.

It seems that the problem occurs when a selection is transferred from the Trimmer to become an event but:-

1. I don't know why disabling one or perhaps either one of two of the FX applied to the event seems to remove the problem.
2. Nor can I understand why it does not appear when I select Progressive in Project Properties (which makes no sense with this sort of source material which both GSpot and MedfiaInfo have shown to be 25fps.

You have all gone to so much trouble and must have put yourselves out a lot to try to help me and I cannot say how grateful I am. It certainly says a great deal about this community of ours.

Richard

[I]"I've placed the original media in the Trimmer"[/I]

There's a problem to start with. It's very likely the trimmer doesn't show you every line in both fields. Looking at what you see in the trimmer is just useless.

I noticed the same thing looking at the thumbnails on the timeline, they look perfect, it's only at Best/Full in the preview window at Double PAL (50fps) as I previously explained that you really see everything that's in your source video.

Bob.

Richard: "1. I don't know why disabling one or perhaps either one of two of the FX applied to the event seems to remove the problem.

Which FX would that be?

Richard: "I ought to say that I've had numerous films transferred by the same company in the same way to a hard drive and have always been able to edit this without any problem.

Which FXs did you use with those?

Grazie

Richard, something you can consider more...
Do you have any updates on FXs or Windows or Video Drivers OR Sony Vegas itself between these projects?

Set

Bob

I've now tried dragging the source directly to a later spot at the end of the Timeline (but without applying any FX yet) and see no ghosting whether playing back normally or at double PAL etc. It might also be relevant that I've not seen any ghosting when playing back with the other programmes I mentioned. This seems to confirm that it's not the source that's at fault but something that happens on the Timeline itself

Grazie

It's not always the same one although Unsharp Mask seems to be the main culprit --- but in at least one instance by-passing FBmn Exposure did the trick.

I used the same range of FX on the other films and in the same sort of numbers and frequency.

Incidentally:-

1. I've now linked the PC to the external monitor via HDMI. I have to drag the Preview Window to the monitor to show it there (I assume that's the only way and that there's no pre-set I can use) and I see the same results occurring there as well which seems to suggest that it's not the Canopus/Firewire link that's the culprit.

2: In view of (2) of my previous post it's beginning to seem that this might be an interlacing issue that's affecting this project only (or an interlacing issue that might be brought into play when an FX is applied). The problem with this theory is that, although it's a recurring problem, it doesn't apply throughout the project. If I'm right I just don't understand how this can be as the Properties settings should remain constant throughout


Richard

OK, so following what Bob suggested you have proved that the footage is go to go. Yes? Excellent.

Richard: "or an interlacing issue that might be brought into play when an FX is applied

What version/update of your FXs are you using?

Richard: " The problem with this theory is that, although it's a recurring problem, it doesn't apply throughout the project."

Good, you now need to be precise at which point along the timeline you get the problem and with what FX?

Grazie

Grazie

The FX are the latest version of those in Vegas Pro 12 with the 'foreign' ones all being up to date as well --- and this has been so on the other projects as well.

I've tried to identify the specific points and it is not always the same FX that is being used although the Unsharp Mask seems to be a regular :(

Richard

Hi again, returned from my tasks..

Could you update or re-try those dropbox links for the Media Info information? Still can't read them as the links don't work.

Also, i have been led to believe that all your footage was captured by your Canopus unit, but reading more posts it seems someone else may have done the film transfer for you using other equipment. Did i read that right? If this is the case, then the Canopus is totally out of the equation.

Paul.

There is definitely something in all of this that still hasn't surfaced. I'd still like to get my hands on a few seconds of the original, unedited footage (i.e., cuts-only, smart rendered). If I had Vegas 12, I'd also like to see the VEG file, but I'll leave that to others.

The one thing that is so striking about this is how absolutely perfectly two portions of video have been interleaved into the odd and even fields in each frame. I have tried to remember all the various times I have seen similar behavior. I already mentioned one that had to do with not keeping frame rates consistent throughout the workflow. However, I have also seen other situations like this with various programs that have a tough time reading long-GOP file formats. In particular, I have seen almost exactly this sort of behavior with both H.264 and also MPEG-2 formats depending on the container in which they are encoded, and depending on what programs are used to read those format, I have seen exactly what you see in my deconstructed "Video_02" version I posted above.

Thus, it would still be useful to get those Dropbox links fixed up so we could see the actual codec being used in that AVI file. If it is something other than Cineform or DV, then we may be able to take the next step.

Just to be clear, I have seen exactly this sort of behavior when putting VOB files directly on the Vegas timeline (in older versions of Vegas, like Vegas 4 or 5) without first putting it into MPEG-2 format. I have also seen similar problems with some of the hacks to get various formats into programs which don't read those formats natively. Most of these hacks involve using DGIndex. As you scrub the timeline, the video initially looks fine as you go forward, but if you back up and then go forward, the video starts showing "flash frames" from places much earlier (or later) in the timeline.

So what I am saying is that these files might be encoded with a slightly "odd" codec, and that this may be causing Vegas problems, but only when the timeline is first scrubbed. If I am right, you might be able to get a decent render by opening the project and then immediately rendering without first doing anything on the timeline. I would, of course, turn off all GPU settings before doing this.

That really affirms what i was thinking too John. Basically an incorrect input source seems to be at work here. I was interested to read you have actually seen something like this before. That's a first in this thread other than Bobs dirty heads experience. And in your case, if i understand correctly, by an incorrect format being used as the source media causing Vegas to misinterpret the clip. Like your VOB source without going to MPEG or an unusual codec being used. Personally, i favor the bad codec idea. Now that it seems the capture was done outside of Richard's system (if i understood that correctly), there's no telling what the source material really is.
And just to again repeat what we are saying here, we need to see the Media Info links or a small sample of the source footage, without any codecs/rendering being applied. Just the bare footage.

Paul.

I'm sorry you've had trouble trying to read my earlier Dropbox links and have tried again with G Spot being at:-
https://www.dropbox.com/s/wc3jq8a2jnfzl4f/Capture%20GSpot.PNG
[and MedaInf at:-
https://www.dropbox.com/s/3866fovntrs850g/Capture%20MediaInfo.PNG

I hope this helps.

My source footage is some twenty minutes long and I should be happy to post some of this if I knew how to split out a section and put this on Dropbox as it is and in it's own format.

Richard

So its codec is DVSD, PAL, 4:3 aspect, 720x576, 25fps and 50 fields/sec, Interlaced, BFF (or lower field first).

This looks correct as far as i can tell.
Paul.

Thank you Paul but it doesn't seem to solve the problem or identify its source, I'm afraid (or explain why the hugely unorthodox idea of using Progressive instead of LFF in Properties seems to correct it.

Richard

indeed.
I only know that deinterlacing to progressive fixes the rendered output. Simply by disregarding the error frames being interlaced. And i only found this out by testing your sample file. Hopefully that's enough to finish your project. Would be interesting to see what happens if you put the same source file into a new project. Same error again? just curious.

Paul.

I've just loaded the one and half to two minute chapter containing the shots you have already seen and applied up to six FX (the same ones I used before), a Pan & Crop to one event and a two second dissolve between two events. The Properties were set at LFF and DVD PAL 4:3 and I've played it back rom the Timelein at Best Full, Good Full, Good Quarter and Draft Quarter and, guess what, it played back without any sign of ghosting. I haven't burnt this to a DVD but think we've already established that the problem shows in the Timeline rather than as a result of a burn.

So frustrating.

Richard