View Profile
View Forum Posts
Private Message
I have had instances in Vegas 6 (a or b) when working with DV where Vegas actually altered the field order order of clips of it's own accord while I was editing. When the results were rendered it would play fine, then suddenly a scene would be jerky and horrible, then it would come back to fine. Setting the field order back to the correct one (in my case BFF) solved the problem. The source had all been taken from the same DV master.
I have not experienced the same thing in later versions or Vegas 7.
+ Reply to Thread
Results 241 to 270 of 281
-
Read my blog here.
-
I did find that when I manually changed a stable DV clip's properties setting from BFF to TFF, the MPeg2 encoder assumed TFF and encoded a jittery TFF or BFF MPeg2. This was with Vegas 6d. G-Spot reported TFF or BFF based on the encoder generated flags not the actual video.
I'm not coming down on Vegas. It just shows again that garbage in produces garbage out. -
No, the encoder did not assume the video was TFF -- you told the encoder it was TFF. It did exactly what you told it to do.Originally Posted by edDV
-
We should remember that the problem was identical when I:
1.) Captured with Encode Interlaced to mpg, made DVD as usual to discover it is unstable.
2.) Captured avi then encoded mpg with either TFF or BFF. Therefore when I encoded with either TFF or BFF:
Yes edDV, I was told that "re-encoding with a different field order setting" would yield results, but it did not and it does not. Only after I changed the assumed order of the *source*, not the way the file was encoded, only then was the solution found.
Yes the solution could have been achieved by changing the properties of the flag, but I had no clue what that meant or how to do it and only a few posts up did I find out to
1. Use DGMPGDec to demux
2. Use ReStream to UNCHECK 'top field first'
That also fixes the problem.
Please:
How is AVISynth's BOB filter used? What do I do to check the flag so I can compare it to GSpot?
For my information, can you do the opposite of demux, what's that called? How do I quickly put the video & audio back together into .mpg after correcting the video file that has been demuxed? -
True I screwed with the DV file properties, then told the encoder to do a lower and upper with that input.Originally Posted by jagabo
The idea was to simulate a file with an upside down flag and see if Vegas could handle it. -
I confirmed that with my test at least for Vegas 4d. If the source flag is wrong, the subsequent MPeg2 encode with either TFF or BFF settings will be jerky.Originally Posted by c627627
All this points back to the MMC source as villain for setting the flag wrong, or worse changing field order during the clip.
ATI I assume will blame UK Channel Four and KQED as US distributor for an unstable PAL to ATSC transfer. Channel Four and KQED will blame PBS or Comcast for screwing with their show open. I think I see lawyers gathering in the lobby.
Since this is now an international incident with UK, Canada and USA in the fight maybe some Euro monarch could mediate?
Typo correction Vegas 6d. -
No. AVI does not support field order flags. AVI has no support for interlaced video at all. That doesn't mean you can't put interlaced video in an AVI file, just that there's no way for a program to know if an AVI file is interlaced or what field order is. It's possible for particular codecs to include interlace and field order flags but software must specifically written to handle those codecs. A program can also examine the frames of the video and try to determine if it's interlaced and what the field order is.Originally Posted by edDV
-
So you are saying my attempt to simulate c627627's MPeg2 problem by changing a DV clip's field order inside Vegas was flawed? Could well be.Originally Posted by jagabo
-
This is informative.Originally Posted by jagabo
I captured 3 test avi's this afternoon: pbs cartoon, comedy central movie, cnn headline news, opened them in Vegas and told you guys that Vegas opened them all as the source avi having properties of None (progressive scan).
Why did Vegas (both 6 & 7) open the problem avi as properties of Lower Field First.
Why do the SOURCE (not target) settings for the problem avi need to be manually adjusted on Encoders whereas other avi's work fine.
If there is no flag, what does that say about the broadcast vs. capture card blame?
and of course, please anyone want to tackle the important capturing questions:
How is AVISynth's BOB filter used? What do I do to check the flag so I can compare it to GSpot?
For my information, can you do the opposite of demux, what's that called? How do I quickly put the video & audio back together into .mpg after correcting the video file after demuxing it? -
Not at all. You lied to Vegas and told it your DV source was TFF. Vegas took your word for it and handled the video just as it would a real TFF video.Originally Posted by edDV
When you told Vegas to save as TFF MPEG it passed the frames unmodified to the MPEG encoder which compressed the frames and flagged the video as TFF. The final result was an MPEG file flagged as TFF, but it really contained BFF frames.
When you told Vegas to save as BFF MPEG Vegas "knew" that it had to swap the fields before compression. So it swaped the fields of each frame (probaly by shifting the video up or down by one scan line) and passed them to the MPEG encoder. Of course, now the frames are really TFF, but the MPEG encoder is told to compress them as BFF. The final result is a BFF flagged MPEG file which really contains TFF frames. -
Sorry Vegas, I lied.
So this does point back to MMC for setting the flag upside down vs the actual video. -
You'll have to ask Sony engineers. They decide what Vegas does when it opens AVI files. Maybe it analyzes the video (TMPGEnc does this) and attempts to figure out if it's interlaced and what the field order is. Then sometimes Vegas gets it right, sometimes wrong. That is not uncommon, TMPGEnc often gets it wrong. Maybe the program assumes TFF for some codecs, BFF for others. What codec(s) did you use? With some codecs it could look at the codec's private flags. I'm pretty sure it does this for DV compressed video in an AVI container. DV AVI is normally BFF or progressive.Originally Posted by c627627
Because in some cases the software guesses the source field order correctly, in some cases it guesses wrong.Originally Posted by c627627
There are no frames in standard definition broadcast video. There are no field order flags in broadcast video. Broadcast video is an alternating series of top and bottom fields. It's not 29.97 frames per second, it's 59.94 fields per second. You see one field at a time when you watch a standard definition TV. It's only when the video is captured by the computer that pairs of fields are woven together into frames and a field order flag becomes necessary.Originally Posted by c627627
You can blame Microsoft for the lack of field order flags in AVI. Microsoft made no provisions for interlaced video when it created the AVI spec. Microsoft abandoned AVI many years ago. AVI is now deprecated by Microsoft.
AVIsynth uses text based script files. Create a text file with notepad and add the following three commands:Originally Posted by c627627
change filename.ext to whatever the name of your video is. Save the file with the extension .AVS, for example "MyScript.AVS", in the same folder as your video file. Now open that AVS file with VirtualDub. If the video is TFF motion will be smooth as you step through frames. If the video is BFF motion will jerk back and forth.Code:DirectShowSource("filename.ext") AssumeTFF() BOB()
Yes, it's called multiplex, or mux. Demux is short for Demultiplex.Originally Posted by c627627
There are many MPEG multiplexing programs. TMPGEnc has multiplexing tools (File -> MPEG Tools...) but they are limited in their abilities (they can't multiplex AC3 audio, for example). Look through this listOriginally Posted by c627627
https://www.videohelp.com/tools?toolsearch=multiplex
for programs that support MPEG mux/demux.
You may not need to remultiplex -- many DVD authoring programs will accept separate video and audio streams. -
I don't know exactly what c627627 did. If he saved as DV AVI MCC should have captured (or converted to) BFF before compressing. If the video was saved as uncompressed YUY2 there is no way to flag the field order.Originally Posted by edDV
-
No, he's been using MMC to encode MPeg2. He seems to wander between interlace (MMC default field order), progressive without "inverse 3:2 pulldown" and progressive with "inverse 3:2 pulldown". He never is clear which mode he is using at the time he asks the question.Originally Posted by jagabo
-
What Vegas does when it opens (almost) all avi files I capture from TV is it sets the properties of them as "None (progressive scan)" as others can confirm. But why can it not be deduced that the problem avi source properties should also be manually set to "None (progressive scan)"?
And here is how the avi was captured with default MMC avi settings, except i did a registry hack to change the 704x480 to 720x480 since at that time I did not know that 704 should be used to capture TV anyway.
It was then loaded into Sony Vegas and I Encoded it to three mpg's to test all 3 settings (Encode Interlaced TFF and BFF, Progressive only). -
All 3 were then uploaded for you to see and test.
Then I discovered that I can get it stable if I change the source AVI Properties (not Target MPG) from bottom to top.
Then I did test avi captures to see they all open as and discovered that they all have source AVI Properties: "None (progressive scan)".
Then I asked why not also change the problem AVI settings to what Vegas usually opens AVI like, which is source AVI Properties "None (progressive scan)".
But I haven't tested that, I tested changing the Source AVI from bottom to TOP and that solved the problem. -
Thank you for teaching me how to use AVIsynth.
I tested the problem avi when I left the source properties unchanged than Encoded Interlaced TFF and BFF.
You said "If the video is TFF motion will be smooth as you step through frames. If the video is BFF motion will jerk back and forth."
Well both the Encoded Interlaced TFF and Encode Interlaced BFF exhibited behavior consistent with your description of what BFF behaves like.
However, only by changing the source avi properties, which were bottom do we solve the problem.
How is this consistent with your quote "If the video is TFF motion will be smooth as you step through frames. If the video is BFF motion will jerk back and forth." -
Why not set the problem avi to "None (progressive scan)" then? (Remember it set the problem avi to bottom, whereas it sets all other avi captures to "None (progressive scan)".Originally Posted by guns1inger
-
Uncompressed UYVY video in an AVI container has no field order flag. Any program that deals with it has to figure out the field order, guess, or assume. Who the **** knows why Vegas sometimes decides on one, sometimes another? And who CARES? Just figure it out for yourself, set the source field order in Vegas and encode. It's as simple as that. We've been telling you this for days now.
If the field order changes in the middle of a cap the hardware or software has problems, or the source is badly damaged. -
OK. I understand it should not be "None (progressive scan)", and what this means is that everyone who uses ATi capture cards and Sony Vegas needs to do this *every time* and set the SOURCE manually to TOP field first because Vegas by default will either set it as None or screw you up by setting it as "bottom".
I believe that does it for me, I thank you for your patience and for teaching me everything from how to use AVIsynth to the fact that this forum has no swear filter or it has but it can be bypassed.
Good luck. -
I've lost track of what you are trying to accomplish and what your current capture is.
You started insisting progressive with "inverse 3:2" telecine to MPeg2 in MMC was the way to go.
Then you changed to progressive without "inverse 3:2" to MPeg2 in MMC was the way to go.
Then you were doing default "interlace" to MPeg2 in MMC which we all assumed would be TFF default and you comfirmed that it was TFF in GSpot. You said everthing was working fine except that one clip. Focus was on the bad MPeg2 clip.
I was assuming you were importing to your MMC MPeg2 file into Vegas in an effort to change the field order flag. It wasn't clear what you were doing in Vegas.
You had one rogue file that was already encoded MPeg2 TFF interlace and played jerky when authored to DVD and played to a TV. Up until yesterday the focus was on changing the flag to BFF.
When did you shift to uncompressed capture in MMC? What are you capturing?
I have lost track of what you are doing. -
Well I believe I figured it out but I'd be glad to answer any questions. You should not be confused because I can answer any questions to clarify.
1. I usually capture with MMC directly to mpg with Encode Interlaced then convert to DVD.
2. Capturing this show to mpg with Encode Interlaced resulted in unstable capture.
3. Capturing this show to mpg with Progressive Source resulted in a seemingly stable capture (but at the expense of everything we talked about.) I was wrong to think that just because it seemed more stable than Encode Interlaced, that's why it should be captured like that.
I thought I only had Encode Interlaced, Deinterlace and Progressive options, period. I was unaware of other problems that can exist.
4. I then realized I needed to edit this show more so I captured it to avi and erased it from my DVR.
THEN:
5. AVI which has no flags was converted to MPG with the same results as when I captured the show to mpg. Encode Interlaced was unstable no matter what.
THEN FINALLY eureka:
6. The source AVI inside the program it is loaded into such as Sony Vegas has properties as a source that can be changed before encoding. That solves the problem.
THEN AGAIN eureka:
If I wanted to capture to mpg, I could have:
1. Used DGMPGDec to demux the mpg
2. Used ReStream to UNCHECK 'top field first'
That also fixes the problem of the unstable Encoded Interlaced mpg.
That should be clear as day - can further answer any questions you have. -
OK that can change the flag but I've never had that problem in the past with MMC MPeg2 or uncompressed YUY2 from MMC. I think there must be a lower/upper first field setting in MMC for MPeg2. I'll have a look when I reinstall MMC. Currently I'm running these cards from BeyondTV4.
-
-
OK
-
He actually did identify the AVI capture, before the threat incidentally, but in subsequent discussions it was sometimes unclear.
I thought it had been confirmed that at least one of these clips showed Field Order Reversal within the clip itself?
Important Questions for C6 -
1. Did the original MPG Encode Interlaced clip play jerky throughout the entire clip, just at the beginning, various spots, or what?
2. Can you confirm that the restream procedure did, in fact, correct the problem with the original clip mentioned in #1?
General question - is it possible for the broadcast clip to contain an actual Field Order Reversal?
Is it possible for an MPG file to contain a change in Field Order, and/or a change in the flag, and still play correctly? I had never before considered this possibility, believing field order to be continous throughout an individual file or source.
My concern is the apparent unreliability of the ATI card in terms of setting this flag for MPG files. I don't do AVI much. If this is a one-time problem, or if the original source was somehow flawed, then no worries. BUT, if it can be verified that ATI-encoded MPG files may contain improper flagging, then I need to add the "Restream flag set" to my standard procedures.
The original MPG Encode Interlaced clip SHOULD have played correctly. Outside of some Act of God, either the source was FUBAR or the flags were set wrong, and/or actually CHANGED during the clip. -
The PAL->NTSC transcoding process could have created a motion stream with backward fields. If we capture the next airing, that can be examined.
The ATI card could be loosing sync in difficult effects sequences or it could just be having trouble with this single clip. I don't have many files left that were encoded by MMC. I'm mostly using Beyond TV to capture from these cards. -
Glad to answer whatever helps anyone:
1. Instabilities were noticed in the beginning of both directly captured mpg as well as encoded mpg but were 2-3 minutes into the capture, not only a minute or less into the capture. I did not watch the rest to know.
Fully aware of the possibility that only the first part of the program may be unstable, I nevertheless selected the SOURCE AVI > changed the Field order to what I understood was ATI default: Top aka Upper Field First and then I Encoded as Interlaced TFF to mpg.
I also tested unstable mpg's and could also correct them without reencoding with ReStream.
I believe all ATi TV captures *source* AVI Properties should be TFF and then encoded from there.
2. I opened the problem avi, and without changing source AVI properties, I encoded interlaced to get unstable mpg. I then successfully corrected the unstable mpg with ReStream, 100% confirmed.
3. My future procedures are make sure ATi captured mpg files from TV are TFF, period.
My future procedures are to load captured from TV avi files into Encoders and then manually change SOURCE AVI properties to TFF, period. -
Nelson37, proof: This is AVI loaded into Sony Vegas and encoded to get unstable mpg's:
Encode Interlaced TFF: http://rapidshare.com/files/19603764/Test.mpg.html
Encode Interlaced BFF: http://rapidshare.com/files/19622715/TestBF.mpg.html
You can take these unstable mpg's:
1. DGMPGDec to demux the mpg
2. ReStream to UNCHECK 'top field first'
They can then become stable without reencoding.
OR of course, I could just set the Upper Field First of SOURCE avi properties (not just target mpg) when encoding to also end up with a stable mpg.
Quote
Similar Threads
-
Problem with Megui Maximum bitrate
By yaoyao0204 in forum Video ConversionReplies: 2Last Post: 17th Feb 2012, 10:57 -
Maximum Bitrate
By unity2 in forum Authoring (DVD)Replies: 17Last Post: 24th Jun 2011, 07:25 -
Nerovision maximum bitrate
By whenloverageswild in forum Authoring (DVD)Replies: 6Last Post: 11th Oct 2007, 08:40 -
CBR w/Maximum Bitrate = Dissapointing
By jcm0320 in forum Capturing and VCRReplies: 14Last Post: 27th Aug 2007, 21:16 -
Maximum Safe Bitrate
By SCDVD in forum Newbie / General discussionsReplies: 8Last Post: 21st Jun 2007, 22:37