VideoHelp Forum
+ Reply to Thread
Page 2 of 5
FirstFirst 1 2 3 4 ... LastLast
Results 31 to 60 of 141
Thread
  1. Analog video is simply a series of top and bottom fields:

    T B T B T B T B T B

    When you watch it on TV you never see an entire frame, you see one field at a time.

    When it is captured by a computer pairs of fields are joined together to make frames. If the capture device starts with a top field then adds the next bottom field you have top field first frames:

    TB TB TB TB

    It the capture device stats with a bottom field then adds the next top field you have bottom first frames:

    BT BT BT BT

    Now you feed these frames to the DV compressor. The compressor doesn't know or care about field order it simply compresses the data.

    Later the DV decoder decompresses the video. Again, the decoder doesn't know or care about field order. It just decompresses the frames and the result is exactly the same field order as the original source frames. You should now understand how it is possible to create TFF DV AVI files.

    Finally, you have a device or program that displays the video or converts it to some other format. Now it is important for that device or program to know the field order of the video.

    As far as I know, DV hardware encoders and camcorders always produce bottom field first frames. And most software assumes that DV AVI files are therefore BFF. But there is no reason a DV AVI file can't contain TFF frames (I doubt a camcorder would play them back properly though). Just be sure player or conversion software gets the field order right when it plays/converts it.
    Quote Quote  
  2. Capture using Lagarith . Best codec I've used for preserving video.
    Quote Quote  
  3. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Thanks! Never thought lossless capture is possible until this codec

    Thanks for clarifying. It now became clearer to me. There are still few questions that have been left unanswered:

    1) So different capture cards has different capture field orders. Does the codec has any way to know what field order that capture card is using?

    2) Definitely field order has to be precise if the video is to viewed on interlace displays or may end up with temporal mismatch if field sequences are reversed. However this field order problems should not be apparent with progressive monitors. right?

    3) After studying the video closely and analyzed it field by field I found out the field order problems mentioned here were different. I just found out that field from frame 1 is joined together with field from frame 2 and that should explain the blurry video even on progressive monitor. The puzzle is why it is like that if the only sin here is selecting the incorrect field order of the source in the encoder software???
    Quote Quote  
  4. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    Haven't bought it yet. What is the the color sampling of normal DV?
    Its hard to compare apple to oranges. I don't think the color resolution of VHS is measured the way it do with digital video. But if DVCPro is only 4:1:1 (180 chroma samples per line) wouldn't some parts of the image become loss during capture?
    DV format has more than enough chroma sample rate for VHS or for analog Betacam SP for that matter. DV format samples luminance at 13.5MHz (~6MHz analog equiv. bandwidth), Chroma UV are sampled at 3.375MHz (~1.7MHz analog equiv. bandwidth). Since VHS only has 3MHz luminance and around 500KHz UV bandwidth, DV sufficiently oversamples.

    Uncompressed capture (using a lossless codec) is another possibility. It depends on what your goals are for this file. Will it be edited and then encoded to MPeg2 for DVD? Or will it be saved to a MiniDV tape? Or will it be saved as data? If data, uncompressed 2hr. data will range from 50-140GB depending on "lossless" compression codec used. DV format would require a pair of DV tapes (27GB) and DVD would require one to two layers of DVD (4.3-8.4GB).

    You need to define the entire process and then test the process with representative sample files before you commit your capture.

    DV format is very convenient for editing in Premiere type editors since the data can be easily stored and retreived from to tape as intermediate and archive backup. Saving archive data on HDD is risky.

    There is no reason for you to be using DVCPro as the codec, unless you will be using DVCPro hardware for storage. Normal DV format is fine.
    Quote Quote  
  5. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    Thanks! Never thought lossless capture is possible until this codec

    Thanks for clarifying. It now became clearer to me. There are still few questions that have been left unanswered:

    1) So different capture cards has different capture field orders. Does the codec has any way to know what field order that capture card is using?
    Maybe.

    Normally, DV format would be encoded in a camcorder hardware DV codec (from analog inputs to the camcorder) and this wouldn't be an issue. It would be BFF and everything downstream would assume BFF.

    Since you are putting a generic capture card between the analog video and the DV codec, the capture process needs to be tested for correct field order. This is what you did above to ID the capture card as using TFF. The "reverse field order" check mark is used to set the software DV codec. Next you would test the process through the editor and back to analog from the resulting DV file (viewed on an interlaced TV). If you intend to make a DVD, you should encode a test DVD and view it on a TV.

    Originally Posted by enbidia
    2) Definitely field order has to be precise if the video is to viewed on interlace displays or may end up with temporal mismatch if field sequences are reversed. However this field order problems should not be apparent with progressive monitors. right?
    Right sort of. Fields are paired into frames for progressive display so if the fields are directly viewed (with line tear due to differenet field time samples) then field order isn't an issue. But if a deinterlacing viewer is being used, TFF vs. BFF may become an issue in how the video is displayed. I haven't tested this in detail. Include the viewer in your process test.

    Originally Posted by enbidia
    3) After studying the video closely and analyzed it field by field I found out the field order problems mentioned here were different. I just found out that field from frame 1 is joined together with field from frame 2 and that should explain the blurry video even on progressive monitor. The puzzle is why it is like that if the only sin here is selecting the incorrect field order of the source in the encoder software???
    I don't understand what you are saying exactly. Your pictures above illustrate the issues. The left picture has normal horizontal line tear (fields in different time sample) where the picture on the right also shows vertical motion from incorrect field order. This in some way upset the software player or still capture utility.

    I would expect that if you set the field order correctly during DV encode, everything downstream should work correctly but this needs to be tested.
    Quote Quote  
  6. Originally Posted by edDV
    Originally Posted by enbidia
    2) Definitely field order has to be precise if the video is to viewed on interlace displays or may end up with temporal mismatch if field sequences are reversed. However this field order problems should not be apparent with progressive monitors. right?
    Right sort of. Fields are paired into frames for progressive display so if the fields are directly viewed (with line tear due to differenet field time samples) then field order isn't an issue. But if a deinterlacing viewer is being used, TFF vs. BFF may become an issue in how the video is displayed. I haven't tested this in detail. Include the viewer in your process test.
    Just to clarify a bit... Computer players often use a BOB deinterlace. What this does is pull the two fields apart and then fill in the blank scanlines with pixels interpolated from the lines above and below. It then displays these at 60 frames per second. If the field order is misidentified the pairs of fields will play in the wrong order.

    Originally Posted by edDV
    Originally Posted by enbidia
    3) After studying the video closely and analyzed it field by field I found out the field order problems mentioned here were different. I just found out that field from frame 1 is joined together with field from frame 2 and that should explain the blurry video even on progressive monitor. The puzzle is why it is like that if the only sin here is selecting the incorrect field order of the source in the encoder software???
    I don't understand what you are saying exactly. Your pictures above illustrate the issues. The left picture has normal horizontal line tear (fields in different time sample) where the picture on the right also shows vertical motion from incorrect field order. This in some way upset the software player or still capture utility.
    I suspect you have a film source that has been through 3:2 (or similar) pulldown.

    http://www.dvdfile.com/news/special_report/production_a_z/3_2_pulldown.htm
    http://en.wikipedia.org/wiki/Telecine
    http://neuron2.net/LVG/telecining1.html

    The other possibility is that you have out-of-phase capture of a progressive PAL source. But since you are in the USA this probably isn't the case.

    Another way that software based players deinterlace is simply to blur the two fields together and then display at 30 fps. When motions (between fields) are small this looks a lot like motion blur. But when motions get big it looks like double exposures.
    Quote Quote  
  7. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Good point on possible film source. I was assuming camcorder or live source via VHS.

    It certainly helps us when poster discloses all the details up front as to source, software and intended use.
    Quote Quote  
  8. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    OK, will make this as simple as possible. My next sample is moving text captured live from NTSC SD TV. Firstly I want to rule out that the captured source is a TC film format nor is this IVTC when reencoded to MPEG. Everything here is as ease except for the TFF and BFF setting. I can safely say this because the fields are clearly distinct in each frame during motion nor do I set the encoder to IVTC during encoding to MPEG. Also during playback I also make sure the deinterlace filter is OFF to show both fields as distinctly as possible.

    Here is the screenshot. The motion of the text is from left to right and both fields show different temporal positions here and the same for every captured frame





    This was encoded using TMPG Express and played back with different MPEG decoders and surprisingly both cannot agree how the fields should be rendered.
    Quote Quote  
  9. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Originally Posted by edDV
    Originally Posted by enbidia
    Haven't bought it yet. What is the the color sampling of normal DV?
    Its hard to compare apple to oranges. I don't think the color resolution of VHS is measured the way it do with digital video. But if DVCPro is only 4:1:1 (180 chroma samples per line) wouldn't some parts of the image become loss during capture?
    DV format has more than enough chroma sample rate for VHS or for analog Betacam SP for that matter. DV format samples luminance at 13.5MHz (~6MHz analog equiv. bandwidth), Chroma UV are sampled at 3.375MHz (~1.7MHz analog equiv. bandwidth). Since VHS only has 3MHz luminance and around 500KHz UV bandwidth, DV sufficiently oversamples.

    Thats true. However for digital video that part of the image would probably be replaced by a single average colored block depending on the color algorithms of the encoder but for VHS the process could be very different. It may not be a single colored block but random colored noises instead. As much as possible don't want to further introduce more digital sampling artifacts to these color noises so this way its more like a VHS tape when played back.
    Quote Quote  
  10. Originally Posted by enbidia
    OK, will make this as simple as possible. My next sample is moving text captured live from NTSC SD TV. Firstly I want to rule out that the captured source is a TC film format nor is this IVTC when reencoded to MPEG.
    If every frame has interlace comb artifacts then you don't have telecined film. Telecined film has a distinctive pattern of three progressive frames followed by two interlaced frames, repeated over and over (other patterns are possible). Note that the crawling text that has been overlaid can be fully interlaced while the rest of the picture is telecined film.

    Originally Posted by enbidia
    Everything here is as ease except for the TFF and BFF setting. I can safely say this because the fields are clearly distinct in each frame during motion nor do I set the encoder to IVTC during encoding to MPEG. Also during playback I also make sure the deinterlace filter is OFF to show both fields as distinctly as possible.

    Here is the screenshot. The motion of the text is from left to right and both fields show different temporal positions here and the same for every captured frame
    You should post un-resized crops. Resizing has blended the scanlines in your images. I recommend you use VirtualDubMod to save frames. It saves images 1:1. A 720x480 capture will produce a 720x480 image file. This will make it much easier to see what is going on. It's also easy to save out exactly the same frame for comparison.
    Quote Quote  
  11. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Originally Posted by jagabo
    If every frame has interlace comb artifacts then you don't have telecined film.

    Each frame is exactly like that.

    You should post un-resized crops. Resizing has blended the scanlines in your images. I recommend you use VirtualDubMod to save frames. It saves images 1:1. A 720x480 capture will produce a 720x480 image file. This will make it much easier to see what is going on. It's also easy to save out exactly the same frame for comparison.
    Even though bicubic resampling may introduce some artifacts maybe some additional blur when pixels being enlarged are not exact multiple of its own both horizontally and vertically. What important here is the relative positions of the fields with each other could still be discernable or inferred whether it is up or down or left or right. For clarity here's the image again at its original size however JPEG compressed at maximum quality however cannot capture the same frame number because i'm not using a video editor and there is no reference to frame number. Be assured that no matter which part of the video the fields do not change. So no matter which frame number I captured it will still look exactly the same as below.






    I don't know about VirtualMOD but I don't think its useful. Because we are comparing different MPEG playback codecs here.
    Quote Quote  
  12. Originally Posted by enbidia
    Even though bicubic resampling may introduce some artifacts maybe some additional blur when pixels being enlarged are not exact multiple of its own both horizontally and vertically. What important here is the relative positions of the fields with each other could still be discernable or inferred whether it is up or down or left or right.
    I'll grant you it does appear the two MPEG decoders are playing the files differently. I'm not sure what your point is though. All that really matters is that the MPEG be encoded as interlaced and that the field order be flagged correctly. Then when you play it back on an interlaced device the fields will appear in the correct temporal order.

    When I play an interlaced MPEG file with Media Player Classic I have several choices (Play -> Filters -> MPEG-2 Video Decoder) of deinterlacing methods. I'm not sure if the MPEG2 decoder is built into MPC (in which case you will see the exact same settings) or if a directshow filter is being used (in which case you may not have the same settings). The different methods are: Auto, Weave, Blend, BOB, Field Shift. Switching between Weave and Field Shift shows the same difference as your samples.

    Weave simply takes the frame that was decoded (containing two fields) and displays it. Field Shift takes a field from one frame and combines it with a field from the next frame to convert the field order.

    Given a sequence of broadcast fields (T=Top, B=bottom, numbers=field numbers):

    T1 B2 T3 B4 T5 B6 T7 B8...

    Captured as TFF (pairs of fields merged into frames):

    T1B2 T3B4 T5B6 T7B8...

    Converted to BFF with Field Shift:

    B2T3 B4T5 B6T7...

    In both cases both fields are being shown at the same time on the monitor. This makes the feature useless as far as the monitor is concerned. Where it does make a difference is with TV output. When using DirectShow's overlay feature to output only a media player's picture to a TV (ATI calls this "Theater" mode, Matrox calls it "Dualhead DVDMax", I don't know what Nvidia calls it) different graphics cards assume different field orders. Having both Weave and Field Shift enables you to correct for this. I suspect one or the other of your players was doing it automatically.

    Originally Posted by enbidia
    For clarity here's the image again at its original size[/img]
    Even your original size post has been resized. I can tell because the two fields are blended together at points. Here's a 4x nearest neighbor enlargement (each pixel is simply duplicated 4 times, with and height) of a portion of your image and a 4x enlargement of a quick capture I made of similar crawling text (both with insets of the original size):



    In my sample the two fields are cleary separate. In yours they have been blurred and distorted.

    I don't think you resized the images. I think your playback software resized them (to correct the aspect ratio) before you did the screen capture. This is why I recommended you use VirtualDubMod to examine your MPEG files. It will show you exactly (except of course for the colorspace transformation which is necessary to display YV12 video on an RGB monitor) what's in your source files.
    Quote Quote  
  13. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    OK, will make this as simple as possible. My next sample is moving text captured live from NTSC SD TV. Firstly I want to rule out that the captured source is a TC film format nor is this IVTC when reencoded to MPEG. Everything here is as ease except for the TFF and BFF setting. I can safely say this because the fields are clearly distinct in each frame during motion nor do I set the encoder to IVTC during encoding to MPEG. Also during playback I also make sure the deinterlace filter is OFF to show both fields as distinctly as possible.

    Here is the screenshot. The motion of the text is from left to right and both fields show different temporal positions here and the same for every captured frame




    This was encoded using TMPG Express and played back with different MPEG decoders and surprisingly both cannot agree how the fields should be rendered.
    Hmm, OK so your intended use is to see how TFF vs. BFF affects various progressive players? The first three are the desired result for an interlaced display. What codec is being employed in Media Player Classic?

    The first step in the scientific method is to describe the problem to be solved.
    Quote Quote  
  14. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Originally Posted by jagabo
    Switching between Weave and Field Shift shows the same difference as your samples.
    THATS IT! My objective here is to able to predict the sequences of fields and frames with different settings. Jagabo you hit the cause of my problem and I didn't know the differences between weave, field shift, bob, blend etc. I thought all these are just different methods of combining upper and lower fields together in a frame. Never had I thought that it can go beyond the fields of its frame and I was wrong. Field shift skips a field to weave with a field of another frame and that should explain the fourth example there in the image above and changing it to weave will make it look like the three examples above. I will show some more test samples with different encoders and decoders to verify if the outcome can now be predictable.

    With the new findings I'm now going to state my understanding of how it should work and hope that it could be verified

    1) We have a T1B1 T2B2 T3B3 T4B4... analog interlaced display to begin with.

    2) Capture card is BFF. After capture to DV we now have B1T2 B2T3 B3T4 B4....

    3) Encode to MPEG

    a) Source setting is TFF: B1T2 B2T3 B3T4 B4....
    b) Source setting is BFF: T2B1 T3B2 T4B3....

    4) Playback

    a) for 3a

    1) weave: B1T2 B2T3 B3T4 B4....
    2) field shift: T2B2 T3B3 T4B4....

    b) for 3b

    1) weave: T2B1 T3B2 T4B3....
    2) field shift: B1T3 B2T4 B3...

    B1T3 B2T4 B3... probably have explained the big field gap betwwen letters in example 4 of the above image.

    Sorry that the above image is not the one that illustrate the big field gap in MPC. The encoder is Canopus Pro Express rather than TMPG Enc in that image and player is MPC which the filter is MPEG-2 Video Decoder with all these deinterlace options mentioned .
    Quote Quote  
  15. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    regarding automatic resize was it because MPEG2 pixel aspect ratio is 0.9091 while PC pixel aspect ratio is 1?
    Quote Quote  
  16. Originally Posted by enbidia
    regarding automatic resize was it because MPEG2 pixel aspect ratio is 0.9091 while PC pixel aspect ratio is 1?
    Yes. I believe the scaling is done by the MPEG2 decoder because changing MPEG2 codecs can effect how the image looks on the monitor with WMP. With 720x480 4:3 material some encoders squish the image horizontally to 640x480. Some stretch the image vertically to 720x540. Some just leave it at 720x480.
    Quote Quote  
  17. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    The hardware determines which field is first, not the signal. It's usually TFF for most hardware, but some (like DV) does BFF.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  18. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by edDV
    DV format has more than enough chroma sample rate for VHS or for analog Betacam SP for that matter. DV format samples luminance at 13.5MHz (~6MHz analog equiv. bandwidth), Chroma UV are sampled at 3.375MHz (~1.7MHz analog equiv. bandwidth). Since VHS only has 3MHz luminance and around 500KHz UV bandwidth, DV sufficiently oversamples.
    We've had this discussiuon before, but I think we've ended up meeting in the middle.

    There is theory that states the bandwidth should be able to cover it.

    There is also the common sense that a 4:1:1 compression from source that usually gets held in 4:2:0 and 4:2:2 is being compressed more than normal, and therefore loss.

    I think the bigger issue is DV-25 consumer NTSC codecs suck. Just honestly, frankly, suck. The 4:2:0 PAL is fine. DV-50 is fine.

    There is perceptual loss quite often with consumer DV (NTSC 4:1:1), when it concerns certain analog signals, especially VHS. Green and reds often end up shifted slightly, and then there are contrast issues (not to be confused with wrong IRE, which a lot of DV boxes are guilty of too).

    It was created with an intent for a shooting format. To date, I have found no information that ever suggests DV was intended for anything beyond shooting new video. Not conversion of analog. It's a shooters compression, not suited for conversion (raw is preferred) or final output (too big, use an MPEG version).

    Pretty much anybody who has used DV or seen the results of DV work will notice these things after a while.

    This may be considered nitpicking, because there are many other ways to ruin video, DV loss is minor in comparison, but DV conversion is surely not an optimal solution.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  19. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    The problem isn't DV format. The problem is VHS.

    I'm open to argument that VHS is a special case since it is so compromised with low luma bandwidth (3MHz max) very low chroma bandwidth (500-700 KHz) rampant crosscolor defects (luma bleeding into chroma and visa versa), timebase jitter and yes, unlocked subcarrier after the color under recording process.

    VHS was intended as a movie distribution format and as a cheap way to timeshift. It wasn't a serious archive format. S-VHS added more luma bandwidth (4 to 5MHz for more monochrome detail) but chroma and the other issues remained the same.

    Laserdisc used direct video recording including adequate bandwidth for subcarrier thus preserving the timing relationship between luminance and chroma. Laserdisc was essentialy an optical analog version of 1" type C broadcast tape used '76 to late 80's.

    VHS capture is more like a forensic restoration project than a normal dub/capture. You are dealing with an imperfect recording. Among the many competing techniques are:

    Uncompressed capture to YUV (e.g. YVYU, YUY2, etc.)
    Realtime MJPEG hardware encoding (e.g. Pinnacle-Miro DC series)
    Realtime MPeg2 hardware encoding (e.g. PVR-250, or standalone DVD Recorder)
    Realtime DV format hardware encoding (e.g. Canopus ADVC)
    Realtime MPeg4 hardware encoding (e.g. Plextor’s ConvertX)
    Realtime software encoding to MPeg 1,2,4, etc.

    , each with TBC or not.

    Many ways to proceed.
    Quote Quote  
  20. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    Originally Posted by jagabo
    Switching between Weave and Field Shift shows the same difference as your samples.
    THATS IT! My objective here is to able to predict the sequences of fields and frames with different settings. Jagabo you hit the cause of my problem and I didn't know the differences between weave, field shift, bob, blend etc. I thought all these are just different methods of combining upper and lower fields together in a frame. Never had I thought that it can go beyond the fields of its frame and I was wrong. Field shift skips a field to weave with a field of another frame and that should explain the fourth example there in the image above and changing it to weave will make it look like the three examples above. I will show some more test samples with different encoders and decoders to verify if the outcome can now be predictable.

    ...
    OK, we are now talking about deinterlace methods for progressive display or for graphics card overlay output to an interlace TV. A much more complicated subject.

    Just so the DV encoder field order switch was set correctly first so the resulting DVD will play interlace fileds in the correct order to an interlace TV. That path seems to be the needed reference.

    A DV hardware encoder should output BFF for NTSC or PAL. If a software DV encoder follows a TFF capture card, it seems to me that the field order reverse switch should be on to create BFF that downstream equipment will expect from DV format material.

    Once that path is assured then composite video from graphics card overlay output should be checked on an interlace TV for correct field order. Next the progressive player modes can be tested.
    Quote Quote  
  21. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    It would be very true. And what when the field order switch of the codec is set incorrectly for we may not be sure about the field ordering of the capture card? Example analog video is T1B1 T2B2 T3B3 and capture card is TFF so video is stored as T1B1 T2B2 T3B3 but since DV is BFF and therefore Ts are rendered as bottom and Bs as upper on TV. Would there be any noticeable deterioration of image quality?
    Quote Quote  
  22. Originally Posted by enbidia
    It would be very true. And what when the field order switch of the codec is set incorrectly for we may not be sure about the field ordering of the capture card? Example analog video is T1B1 T2B2 T3B3 and capture card is TFF so video is stored as T1B1 T2B2 T3B3 but since DV is BFF and therefore Ts are rendered as bottom and Bs as upper on TV. Would there be any noticeable deterioration of image quality?
    If your source file is TFF tell your MPEG encoder it is TFF. If your source file is BFF tell you encoder it's BFF. That's all there is to it.

    If you don't know if your source is TFF or BFF, use AVISynth and VirtaulDub. Use this AVISynth script:

    Code:
    DirectShowSource("FileName.avi")
    AssumeTFF()
    BOB()
    Change "FileName.avi" to the name of your video file, then open the AVISynth script with VirtualDub and step the the video frame by frame. If motion is smooth your file is TFF. If it jerks back and forth it's BFF.

    Or even easier, put this script into a file called "TFF Test.avst" in VirtaulDUbMod's template folder:

    Code:
    #ASYNTHER TFF Test
    [DirectShowSource("%f")]
    AssumeTFF()
    BOB()
    Then use VirtualDubMod's "Open Video file via AVISynth" feature, select the TFF Test template, and open a file.
    Quote Quote  
  23. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    I think I cause some confusion again here. Forget the one above. Lets use NTSC non-interlaced source for illustration. Suppose that my video capture card is TFF and the capture codec to use is DV which is BFF. Would not all the captured top fields become bottom fields and vice versa as well as when it is playback if we did not set the 'field order reverse switch' to 'reverse' during capture? If so wouldn't this affect image quality rather temporal?
    Quote Quote  
  24. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Jagabo, your explanation for using the 'bob' method to test for correct field order seems interesting. Instead of having to do this on interlace TV we can now split the fields into different frames and simulate its playback smoothness from progressive display. Right?
    Quote Quote  
  25. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    ...
    Example analog video is T1B1 T2B2 T3B3 and capture card is ...
    Analog video alternates fields. Any field grabbed at random has a 50-50 chance of being a field one or a field two. Analog equipment and TV sets sort out field order by differences in the RS-170A vertical sync pulse and subcarrier phase*.


    http://www.bkprecision.com/download/scope/TheNTSCCVS.pdf

    An A/D capture card strips the sync. Hence the need for the TFF, BFF field ordering ID.


    *Composite NTSC video actually has an eight field "color frame" (12 fields for PAL).
    Quote Quote  
  26. Originally Posted by enbidia
    I think I cause some confusion again here. Forget the one above. Lets use NTSC non-interlaced source for illustration. Suppose that my video capture card is TFF and the capture codec to use is DV which is BFF. Would not all the captured top fields become bottom fields and vice versa as well as when it is playback if we did not set the 'field order reverse switch' to 'reverse' during capture?
    No. Top fields remain top fields, and bottom fields remain bottom fields. They are just paired up differently when packaged into frames.

    Originally Posted by enbidia
    If so wouldn't this affect image quality rather temporal?
    They may look different on a computer monitor when you see both fields at the same time. But as long as you maintain the TFF/BFF flags properly the playback device will output the fields in the original order on an interlaced TV.

    Originally Posted by enbidia
    Jagabo, your explanation for using the 'bob' method to test for correct field order seems interesting. Instead of having to do this on interlace TV we can now split the fields into different frames and simulate its playback smoothness from progressive display. Right?
    Yes. But remember, this only tells you the field order of the file. The original analog signal didn't have frames, it was only a series of alternating top and bottom fields.
    Quote Quote  
  27. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Hi, I am confused by your statements here:

    edDV said A/D capture cards do not tell whether the fields it captured is top or bottom therefore I suppose no horinzontal or vertical sync info are encoded digitally but jagabo said top field remains top and bottom fields remains bottom. My question is how can the playback software know which is top and which is bottom unless the fields had been marked?
    Quote Quote  
  28. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by enbidia
    Hi, I am confused by your statements here:

    edDV said A/D capture cards do not tell whether the fields it captured is top or bottom therefore I suppose no horinzontal or vertical sync info are encoded digitally but jagabo said top field remains top and bottom fields remains bottom. My question is how can the playback software know which is top and which is bottom unless the fields had been marked?
    We keep talking past each other. Let's forget about computer playback. The pixels are properly ordered in the pixel addressing to play in correct spatial position on the computer. The TFF vs BFF flag becomes an issue when the digital video is turned back into interlace video and RS-170A sync pulses are restored. The TFF/BFF flags indicate whether the first field presented to the NTSC/PAL encoder is a field one or a field two. If the flag is in error, the fields are placed in the wrong sync order and the result is vertical jumping during motion scenes when watching on an interlaced TV.
    Quote Quote  
  29. Originally Posted by enbidia
    I am confused by your statements
    Here is a diagram



    Everything has been enlarged 3x for clarity.

    The first row is what the real world looked like at 6 consecutive points in time.

    The second row is how it looks during an interlaced broadcast. Fields 1,3,5 are a top fields and can be identified by the fact that the top-most scanline is contained in the field. Fields 2,4,6 are bottom fields and can be identified as such because the bottom-most scanline is included in the field. The black lines are the parts of the picture that aren't broadcast during the field. All standard definition TV is broadcast this way.

    The third line shows what happens when you capture top field first. Field #1 and #2 are packaged together to fill out a full frame. The same is done with fields 3+4 and 5+6. When this is broadcast as interlaced video again, the field order flag instructs the playback device to separate the two fields and output the top field first, the bottom field second. So the original order of the fields is preserved, 1-2-3-4-5-6...

    The fourth line is what happens when the video is captured bottom field first. The very first field (a top field) is skipped. Then fields 2 and 3 are packaged together into a frame. fields 4 and 5 are packaged togther. When the playback device outputs this to an interlaced display the bottom field is sent first, the top field second. Once again the original field order is maintained, 2-3-4-5-6...
    Quote Quote  
  30. Member
    Join Date
    Apr 2006
    Location
    America
    Search Comp PM
    Thanks again for the clarification. I was thinking that since the codec is DV it will always by convention begin with the bottom field and the playback software option is only to assign whether to use the stored top fields or bottom fields as its bottom field for the playback. Never had I thought DV can be played back with TFF literally perhaps not the case if it is from a DV camcorder?

    Ok, what about when transcoded to MPEG which is TFF and using the fourth case above? Wouldn't playback become 3-2-5-4-7-6...?
    Quote Quote  



Similar Threads

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