VideoHelp Forum




+ Reply to Thread
Page 9 of 10
FirstFirst ... 7 8 9 10 LastLast
Results 241 to 270 of 281
  1. Always Watching guns1inger's Avatar
    Join Date
    Apr 2004
    Location
    Miskatonic U
    Search Comp PM
    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.
    Read my blog here.
    Quote Quote  
  2. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    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.
    Quote Quote  
  3. Originally Posted by edDV
    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.
    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.
    Quote Quote  
  4. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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?
    Quote Quote  
  5. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by jagabo
    Originally Posted by edDV
    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.
    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.
    True I screwed with the DV file properties, then told the encoder to do a lower and upper with that input.

    The idea was to simulate a file with an upside down flag and see if Vegas could handle it.
    Quote Quote  
  6. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by c627627
    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.
    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.

    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.
    Quote Quote  
  7. Originally Posted by edDV
    All this points back to the MMC source as villain for setting the flag wrong
    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.
    Quote Quote  
  8. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by jagabo
    Originally Posted by edDV
    All this points back to the MMC source as villain for setting the flag wrong
    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.
    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.
    Quote Quote  
  9. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    Originally Posted by jagabo
    AVI does not support field order flags.
    This is informative.

    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?
    Quote Quote  
  10. Originally Posted by edDV
    Originally Posted by jagabo
    Originally Posted by edDV
    All this points back to the MMC source as villain for setting the flag wrong
    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.
    So you are saying my attempt to simulate c627627's MPeg2 problem by changing a DV clip's field order inside Vegas was flawed?
    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.

    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.
    Quote Quote  
  11. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Sorry Vegas, I lied.

    So this does point back to MMC for setting the flag upside down vs the actual video.
    Quote Quote  
  12. Originally Posted by c627627
    Originally Posted by jagabo
    AVI does not support field order flags.
    This is informative.

    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.
    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
    Why do the SOURCE (not target) settings for the problem avi need to be manually adjusted on Encoders whereas other avi's work fine.
    Because in some cases the software guesses the source field order correctly, in some cases it guesses wrong.

    Originally Posted by c627627
    If there is no flag, what does that say about the broadcast vs. capture card blame?
    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.

    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.

    Originally Posted by c627627
    How is AVISynth's BOB filter used? What do I do to check the flag so I can compare it to GSpot?
    AVIsynth uses text based script files. Create a text file with notepad and add the following three commands:

    Code:
    DirectShowSource("filename.ext")
    AssumeTFF()
    BOB()
    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.

    Originally Posted by c627627
    For my information, can you do the opposite of demux, what's that called?
    Yes, it's called multiplex, or mux. Demux is short for Demultiplex.

    Originally Posted by c627627
    How do I quickly put the video & audio back together into .mpg after correcting the video file after demuxing it?
    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 list

    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.
    Quote Quote  
  13. Originally Posted by edDV
    Sorry Vegas, I lied.

    So this does point back to MMC for setting the flag upside down vs the actual video.
    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.
    Quote Quote  
  14. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by jagabo
    Originally Posted by edDV
    Sorry Vegas, I lied.

    So this does point back to MMC for setting the flag upside down vs the actual video.
    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.
    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.
    Quote Quote  
  15. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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).
    Quote Quote  
  16. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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.
    Quote Quote  
  17. Always Watching guns1inger's Avatar
    Join Date
    Apr 2004
    Location
    Miskatonic U
    Search Comp PM
    Vegas is opening it as progressive simply because there is no field order stored in the avi file for it use. If you cap interlaced using a codec that does not have an field order flag then you have to tell your editing software, Vegas or otherwise, what the true field order is.
    Read my blog here.
    Quote Quote  
  18. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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."
    Quote Quote  
  19. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    Originally Posted by guns1inger
    Vegas is opening it as progressive simply because there is no field order stored in the avi file for it use.
    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)".
    Quote Quote  
  20. 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.
    Quote Quote  
  21. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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.
    Quote Quote  
  22. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    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.
    Quote Quote  
  23. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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.
    Quote Quote  
  24. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    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.
    Quote Quote  
  25. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    Neither did I before now and no there isn't imo: MMC is always TFF.

    So just set the Upper Field First of SOURCE avi when encoding or fix the problem of mpg without encoding by

    1. DGMPGDec to demux the mpg
    2. ReStream to UNCHECK 'top field first'
    Quote Quote  
  26. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    OK
    Quote Quote  
  27. 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.
    Quote Quote  
  28. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    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.
    Quote Quote  
  29. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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.
    Quote Quote  
  30. Senior Member c627627's Avatar
    Join Date
    Oct 2004
    Location
    Kansas
    Search Comp PM
    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 Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!