VideoHelp Forum
+ Reply to Thread
Page 2 of 4
FirstFirst 1 2 3 4 LastLast
Results 31 to 60 of 109
Thread
  1. Originally Posted by opoman
    Groyal, I don't use AVISynth a lot so I ran your script. [...] As a source I used a short, uncompressed, interlaced AVI file. [...] I don't think your script does what you think it does. [...] The final result was a stream of the original frames, at the original frame rate, and still fully interlaced.
    I traced the script, and it does do what I think it does. If your results are different, the problem may be with the AVI clip you chose for testing. Use your MPEG-2 source files instead. You needn't covert them in whole, a short segment will do until things start to "click". I modified and annoted the script to make it easier to isolate any problem. Let's review:

    MPEG2Source("E:\Temp4\rugbyclip.d2v")
    Trim(0,7500)
    # AssumeFrameBased()
    # AssumeTFF()
    DoubleWeave()
    SelectEvery(2,0)
    LanczosResize(720,480)
    AssumeFPS(23.976,false)
    ConvertToRGB()

    1. Input file is interlaced PAL MPEG-2, nnn X 576 (25 fps), yes?
    2. OPTIONAL: encode only the first five minutes (for testing)
    3. AssumeFrameBased() is superfluous -- disable or delete
    4. AssumeTFF() is irrelevant -- disable or delete
    5. Line-double either field into full frames (50 fps)
    6. Discard every other frame (25 fps) [alternatively, SelectEvery(2,1)]
    7. Resize picture
    8. Set NTSC-FILM frame rate [No need to maintain sync if you're handling the audio separately]
    9. Force RGB colorspace.

    Load the script into VirtualDub. Verify you now have a progressive, 720 x 480, 23.976 fps picture stream. IF and ONLY IF the picture is perfectly deinterlaced, proceed to encode. If not, the problem lies in your source file, and that's an issue to consider separately.

    When you reach the encoding stage, don't use TMPGenc's DVD Wizard. Load the AVS file and adjust the encoder settings to match these values. Save as a project file for future reference:

    Video
    Stream Type: MPEG-2 Video
    Size: 720 x 480
    Aspect: 4:3 Display
    Frame rate: 23.976
    Rate control: Constant (for testing)
    Bitrate: 4000 (for testing)
    Profile: Main Profile at Main Level (MP@ML)
    Video format: NTSC
    Encode mode: Non-interlace
    YUV format: 4:2:0
    DC component precision: 8 bits
    Motion search precision: Normal

    Advanced
    Video source type: Non-interlace (progressive)
    Field order: Bottom field first (field B) [NOTE: field order is meaningless with respect to progressive frames. The default value, whatever it is, is fine.]
    Video arrange method: Full screen (keep aspect ratio)
    Filter settings: NONE. UNCHECK ALL BOXES.

    GOP Structure
    I pictures: 1
    P pictures: 3
    B pictures: 2
    Output interval of sequence header: 1
    Output bitstream for edit (closed GOP): Check
    Detect scene change: Check

    Quantize Matrix
    All values default, no special settings checked

    -------

    These settings should guarantee that the encoded MPEG matches what you saw in VirtualDub -- a progressive, 720 x 480, 23.976 fps picture stream. IF and ONLY IF this is what you end up with, proceed to use PULLDOWN (and its GUI if you like) to prepare the MPEG for authoring.

    On the plus side, the action was much smoother, without some of the curious break up effects I had seen before, altogether more watchable but, you know how it is, when things are good you want better. So I am strongly motivated to keep going.
    Believe me, you're on the right track.
    Quote Quote  
  2. Originally Posted by groyal
    MPEG2Source("E:\Temp4\rugbyclip.d2v")
    Trim(0,7500)
    # AssumeFrameBased()
    # AssumeTFF()
    DoubleWeave()
    SelectEvery(2,0)
    LanczosResize(720,480)
    AssumeFPS(23.976,false)
    ConvertToRGB()
    DoubleWeave() should in fact be SeparateFields(). My mistake.
    Quote Quote  
  3. Thanks, groyal.

    To answer your questions:

    Input file to DGIndex (formerly DVD2AVI) was a VOB, ripped from the PAL DVD recorded off digi satellite TV using my Pioneer 5100 HDD recorder. In case you haven't guessed, I'm in the UK - implications there for the above, perhaps.
    The outputs I see from DGIndex are a .d2v and an .ac3 pair. The clip is about 4 minutes long and illustrates a variety of kinds of picture from a rugby match - camera swinging, zooming, players hurling themselves about - all kinds of fast action, and a tough test, I guess, for compressed digital (I sometimes wonder if it was a good idea to go DVD in order to save postage across the pond to my son). It is 25FPS and I don't know how many rows and columns but assume its normal PAL, 720(625 visible) by 576 - DGIndex doesn't tell me.

    You suggest using the mpeg2 source files instead of avi (I presume DGIndex outputs my original ripped VOB as avi - I don't know this but I guess you are implying that this is so. I'm learning, but not *that* fast so please remain patient.). You also refer to the use of VirtualDub. That is just about the only frontline editing software that I haven't yet had to get my head round yet (I've been at this for about a week, almost fulltime, admittedly). Whatever, you suggest I use mpeg2 - so I rip to mpeg2 or convert my vob, and then name it as my MPEG2 source in the Avisynth script, right?

    Incidentally, is there an efficient way I can make my test file (about 170 meg but there is a section which is very high action which would be 100 meg or less) available to folks who might like to try their hand?

    OK, I'll do a re-test of your script with separate fields in place of double weave and the redundant lines (2,3 and 4) omitted.

    But first, I'd better get my head round VirtualDub as I really do need to shorten the process of testing out the effects of changing the script.

    Time I got showered,dressed and started another fascinating day!
    Quote Quote  
  4. Member NamPla's Avatar
    Join Date
    Jun 2004
    Location
    Whoop Whoop
    Search Comp PM
    My initial thought remains: CONVERT? WHY?
    Sometimes PAL-to-NTSC conversions are req'd for universal compatibilities... That is, so Americans & Japs can watch it too.

    As for the PAL world, well it's dual-format all the way. I'm not so sure if Japan & U.S. are universally dual-format too?

    I used Xesdeeni's old conversion script (for interlaced) and it worked just fine. No need to stretch/shrink audio. Now I believe he's enhanced his script using new & better bobbers etc?

    Now I don't know what NTSC-to-PAL looks like, but I know that PAL-to-NTSC looks just fine. No skipping/jerkiness/blurring/whatsoever. It looks (in my eyes) identical to the source avi.

    My 2c...
    Quote Quote  
  5. Member
    Join Date
    Apr 2004
    Location
    The bottom of the planet
    Search Comp PM
    I'm not so sure if Japan & U.S. are universally dual-format too?
    From speaking one-to-one with many US residents, I have found that America is where Australia was twenty-five years ago. Display units that can display PAL and NTSC signals are the exception, rather than the norm. On top of that, many Region 1 DVD players refuse to output a signal that is not NTSC (Toshibas apparently still persist in this).

    I don't know the situation in Japan, but since it is cheaper to import from any other country in the world than buy Japanese product in Japan, it may well be different.

    EDIT: Oh, and just because it looks the same to your eyes does not make it so. Don't take that personally, but by definition, conversion introduces artefacts. I've seen professional PAL to NTSC conversions (a Doctor Who serial being my favourite example) where the reduction in spatial resolution is very noticeable. Granted, the original master did not have that much resolution to begin with, but every little bit in the transfer counts.
    "It's getting to the point now when I'm with you, I no longer want to have something stuck in my eye..."
    Quote Quote  
  6. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    bugster, NO!

    When you CROP FOOTAGE, you knock off pixels. Let's say it's 720x480. The 20 pixels on all sides is bad, or for some other reason, you need to zoom in (VERY handy restoration method, in addition to matte widescreens or mattes in general).

    So now you have 680x440 material from a crop.
    This is no different that had you started with 680x440 source.
    THAT IS NOT DVD COMPLIANT!!!!!!!!!!!!!
    It is re-encoded (again!) back to 720x480.
    The source was interlaced.
    The new output is interlaced.

    The same thing applies to resizing x576 to x480.

    Interlace is maintained, REGARDLESS of the resize. Resize and crop are the VERY SAME PRINCIPLES. Just with a crop, you throw stuff away. You are STILL FORCED to encode to a predetermined frame size. It does not matter if you START WITH low res, or if you CROP DOWN to low res, in BOTH SCENARIOS, you have resize back up to the legal canvas size (in this example 720x480).

    Vertical, horizontal, there is no difference.

    The killer on PAL<->NTSC is TEMPORAL INTERFERENCE, the framerate conversion, NOT the frame size. That's the reason interlace wacks out the video. Hardware can overcome this. Software cannot. I have tried pretty much every guide I could find, and experimented for months to no avail. Nobody else has EVER been able to show me a successful interlace conversion, done by software.

    Software often requires deinterlace. Not because it is "impossible" to convert interlaced material, but simply because software conversion methods suck. For many of us, deinterlace artifacts are the worst thing you can possibly do to video. That is partially why homemade VCD (from interlaced sources) has always looked so terrible.

    ++++++++++++++

    I think part of your assumptions are based upon VIDEO MYTH.
    Interlace DOES NOT HAVE A SPECIFIC "SIZE". Interlace is a property of alternating video output signals. Do not confuse interlace with tv scanlines. Let the tv worry about its scan lines. You only need to worry about the video source, not the output device (at least for this exercise). Resizing the vertical DOES NOT disturb interlace. At most, it will diminish the sharpness, and possibly introduce ALIASING artifacts at worst. That is what resize does: alias. It may also get a bit "grainy" when you increase the size (this is where photo and video skill overlap).

    full-size source:


    cropped from full-size .. OR .. originally a smaller size


    final encode, upsized to fit the canvas




    I hope this clarifies things for you.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  7. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by NamPla
    My initial thought remains: CONVERT? WHY?
    Sometimes PAL-to-NTSC conversions are req'd for universal compatibilities... That is, so Americans & Japs can watch it too.

    As for the PAL world, well it's dual-format all the way. I'm not so sure if Japan & U.S. are universally dual-format too?
    It's becoming very common, harder to buy a player these days that is NTSC-only. Almost anything made in China these days does both, and LOTS of players are created for world-wide use. Later in the assembly process, in the factory, wires/etc and changed for that country's specifics. The mainboards, firmware and power supplies are often worldwide.

    Most people never even try. They just assume it does not work.

    And some of these players are as cheap as $25. And it looks MUCH BETTER to leave the signal native, especially over the mediocre quality software conversions.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  8. Member adam's Avatar
    Join Date
    Sep 2000
    Location
    United States
    Search Comp PM
    Lordsmurf, I have to confess I don't understand what any of that prior post is supposed to show. Resizing interlaced footage horizontally is fine. But resizing interlaced footage vertically simply should never be done unless you separate the fields first. If we took the actual video that you used in your example, going from size 1 to size 2 would be ok since you just cropped. But going from size 2 to size 3 would be messed up since you actually resized. You can't see this from a still picture.

    Sure the interlacing will be maintained, but it will be totally messed up. Fields will be moved to different fields reversing their order in time. This is a well documented occurrence. Look in any NLE's manual and it will warn you about it. Check out what After Effects has to say about it for example: Look at bottom of page 9.
    http://www.ledet.com/coolstuff/software/aftereffects/videoissues.pdf

    And bugster is right, if you crop down or up (technically adding letterboxing is considered cropping) its fine, because you remove or add scan lines but the remaining ones are not shifted, but if you resize down or up they get shifted in time and the results are terrible.

    You DO have to worry about the scan lines because they are in a temporal order and if you shift them then they can get reversed. "Scan line" has a dual meaning. You are talking about raster lines when you confine the term to tv playback, but I don't know what difference that would make. In the digital realm, a scan line is just a row of pixels and in an interlaced source, if you resize these vertically then it destroys the time order. Once this happens the digital source is now FUBAR and there is nothing the tv can do to correct this.

    Bottom line, if you resize vertically you have to separate the fields first. If you just crop vertically it doesn't matter.
    Quote Quote  
  9. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Well, I don't know if TMPGENC, Premiere/MC or Procoder separates the fields first, but resizing ANY DIRECTION has NO EFFECT on the "quality" of the interlace. (I think it's safe to assume TMPGENC, at very least, does NOT separate.)

    Resizing the frame DOES NOT AFFECT the temporal mechanics of the image/video. If that were true, PIP (picture in picture) would be impossible, both on tv sets, as well as on the news broadcasts (pick any local or cable channel that still does PIP).

    Again, you're getting wrapped up in some falsely perceived idea that "interlace has a defined size".

    I don't give two shits what manuals and document says is "not suggested". I'm not even going to waste time reading your link (sorry, I don't put much stock in documents with the name "cool stuff" in it!). Theory is worthless most of the time. The practice is if you resize interlace footage, using standard consumer software, you'll be just fine.

    I've been adjusting video sizes as a method of restoration for several years now. If it looked bad, I can assure you I'd never do it.

    I get the DISTINCT FEELING none of you have ever even tried to resize interlaced video. I think some interlace/resize boogeyman must have scared you away for no good reason long ago. Are you telling me you have NEVER EDITED a PIP on video in an NLE?

    And adding letterboxing is ABSOLUTELY NOT "cropping" (unless you crop AND augment to 16:9) .... THAT'S A MASK! There is a HUGE difference.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  10. Originally Posted by opoman
    You suggest using the mpeg2 source files instead of avi (I presume DGIndex outputs my original ripped VOB as avi - I don't know this but I guess you are implying that this is so.
    By "MPEG-2 source" I meant the output of DGIndex (d2v). Forget the AVI reference -- I got my wires crossed with junkmalle, who was using an AVI sample clip and pointed out the error with DoubleWeave() vs. SeparateFields(). That's been corrected, so everything else should be OK.

    And you don't need VirtualDub to check the result per se -- you can open the AVS in MediaPlayer or AVSEdit or what have you. So long as the picture is properly deinterlaced, the rest is gravy.
    Quote Quote  
  11. Member adam's Avatar
    Join Date
    Sep 2000
    Location
    United States
    Search Comp PM
    Originally Posted by lordsmurf
    I don't give two shits what manuals and document says is "not suggested". I'm not even going to waste time reading your link (sorry, I don't put much stock in documents with the name "cool stuff" in it!).
    That is a page taken straight out of Adobe's After Effects Manual. Refusing to read it simply because it disproves everything you have said is just stubborn. Getting angry over being proven incorrect on a matter of resizing is just silly.

    There are plenty of other credible sources that say the same thing. Its a shame to just ignore this.

    Originally Posted by lordsmurf
    Again, you're getting wrapped up in some falsely perceived idea that "interlace has a defined size".
    No one said interlace has a defined size. But fields DO have defined order, and when you move them around in each frame you can destroy that temporal order.

    Originally Posted by lordsmurf
    And adding letterboxing is ABSOLUTELY NOT "cropping" (unless you crop AND augment to 16:9) .... THAT'S A MASK! There is a HUGE difference.
    A mask is when you MASK the image. The resolution does not change. Adding letterboxing to increase the resolution, without masking any of your existing image, is technically considered a crop. I can provide sources explaining this if you'd like but I'm not going to bother finding them if you aren't going to bother reading them.

    EDIT: You bring up PIP. Great example. Try making your own PIP where the small image is interlaced. You will quickly see what myself and buster are talking about.

    Clearly a tv handles PIP completely differently.
    Quote Quote  
  12. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    But we are MERELY CHANGING THE SIZE OF THE FRAME ... there is NO TEMPORAL ADJUSTMENT going on.

    For PAL<->NTSC ... YES ....
    for non-conversion .... NO ...

    You say

    Originally Posted by adam
    If we took the actual video that you used in your example, going from size 1 to size 2 would be ok since you just cropped. But going from size 2 to size 3 would be messed up since you actually resized.
    What kind of silly non-sense is this?

    The numbers given for the crop/2nd image (680x440) is NOT GOING TO WORK. You have to encode it into a compliant DVD-spec size. It's not going to magically be authored at a goofball size.

    You encode RIGHT BACK UP TO the original 720x480 size now that you've zoomed in on the desired footage. You encode interlaced and IT IS FINE.

    And YOU ARE saying interlace has a defined size. Every single time you insist vertical resize is "not allowed" (in stern teacher voice) you draw this conclusion, whether you use those words or not.

    So ... what is it going to be?

    If I find time I can probably make several samples (burn-ready ISO's for download). Maybe a PIP sample too (time might not be that ample). Besides, you should be able to run these tests yourself, burn to RW and view on the tv.

    Why does everybody make interlace out to be so hard?

    And YES, I'm getting a bit angry. You're telling me not only that I'm wrong, but you're backing it up with silly nonsense. And while you may be happy merely reading some book somewhere, I'VE ACTUALLY DONE IT, and do it often. I mean, seriously, APPLE.COM suggests people "deinterlace" for tv MPEG2. How stupid is that? BJ_M shared that link with us some weeks back. Too many people simply have no idea how interlace works (and sadly, some of them are published).
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  13. Originally Posted by lordsmurf
    Well, I don't know if TMPGENC, Premiere/MC or Procoder separates the fields first
    Just because you don't know what your tools are doing 'under the hood' doesn't mean you can claim to fully understand their operation.

    Originally Posted by lordsmurf
    Again, you're getting wrapped up in some falsely perceived idea that "interlace has a defined size".
    Show me where I said that and I will take it back. The problem is, I never did.
    Originally Posted by lordsmurf
    I don't give two shits what manuals and document says is "not suggested".
    maybe you should, you never know, you might learn something
    There are 10 kinds of people in this world. Those that understand binary...
    Quote Quote  
  14. Originally Posted by groyal
    Originally Posted by groyal
    MPEG2Source("E:\Temp4\rugbyclip.d2v")
    Trim(0,7500)
    # AssumeFrameBased()
    # AssumeTFF()
    DoubleWeave()
    SelectEvery(2,0)
    LanczosResize(720,480)
    AssumeFPS(23.976,false)
    ConvertToRGB()
    DoubleWeave() should in fact be SeparateFields(). My mistake.
    Damn! I spent a few hours trying to get DoubleWeave() to work!
    Quote Quote  
  15. Member
    Join Date
    Mar 2003
    Location
    california
    Search Comp PM
    place your video files into DVDSanta, process with output set to PAL.

    burn.
    Quote Quote  
  16. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by bugster
    Originally Posted by lordsmurf
    Again, you're getting wrapped up in some falsely perceived idea that "interlace has a defined size".
    Show me where I said that and I will take it back. The problem is, I never did.
    Adam did. He concluded that, whether he knows it or not.

    You were a bit more vague about it.

    Consider this: Open an image in PHOTOSHOP. Make a new image, 200 DPI. Draw something full-size. Now, change the resolution to 220, and maintain the same print size. Does your image become skewed? No. That's in response to something you said about resolution being changed, and it being impossible or "losing" info. Still or video, same principles of digital imaging. The new image (video, interlaced or not) interpolates to the new resolution. Your interlace field change size as well, data does not jump from one field to the next. They stay in the same location. In fact SEPARATING THE FIELDS is what can truly muck up your interlace issues.

    Remember that every author learned from experience (at least the good ones). Not everybody "reads" for their knowledge. I don't need to read the dictionary to learn how to speak, and neither do I need a book to learn interlace. I already know about both just fine. I sometimes think this site is to link-happy and document-addicted. Good old-fashioned experience and knowledge somehow has been tossed aside.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  17. Originally Posted by junkmalle
    Damn! I spent a few hours trying to get DoubleWeave() to work!
    I'm sorry -- but I'm grateful you caught the mistake.
    Quote Quote  
  18. Member adam's Avatar
    Join Date
    Sep 2000
    Location
    United States
    Search Comp PM
    Adam did. He concluded that, whether he knows it or not.
    Bullshit. I've been nice enough to explain all this to, you just don't understand, or rather refuse to even try.

    You encode RIGHT BACK UP TO the original 720x480 size now that you've zoomed in on the desired footage. You encode interlaced and IT IS FINE.
    What do you think zooming in on an image does? How do you take a fixed number of scan lines and get them to represent another larger fixed number of scan lines? You use interpolation. What was once 1 pixel is now represented by several pixels. You now have multiple pixels, spread across multiple scan lines, representing what was once one pixel in a single scan line. You are taking field information and moving it to another field, but you are doing it at the frame level which is comprised of both fields. So you are swapping field data all over the place. Whether you will admit this or not, it does happen.

    I presume all the software you use does separate the fields before resizing interlaced sources, as it is necessary and well known to be the proper method of resizing. But avisynth will not do this unless you specifically invoke it, so all of your experience with X commercial software does not help you understand this matter.
    Quote Quote  
  19. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by adam
    Adam did. He concluded that, whether he knows it or not.
    Bullshit. I've been nice enough to explain all this to, you just don't understand, or rather refuse to even try.
    Then explain to me what your "not allowed to resize vertical" theory means. That is what it concludes (interlaced has a specific "size"). If you cannot resize vertically, and it has no size, then what is the reason?

    I'm afraid your theory may only hold true to a flaw of the often-overused AVISYNTH hobby methods. I'll venture a guess this is what you're using as the basis of your statements.


    So far this morning I've talk to two people that are broadcast editors, and two that work directly with studio editing work. I'm not wrong.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  20. Originally Posted by lordsmurf
    Consider this: Open an image in PHOTOSHOP. Make a new image, 200 DPI. Draw something full-size. Now, change the resolution to 220, and maintain the same print size. Does your image become skewed? No. That's in response to something you said about resolution being changed, and it being impossible or "losing" info. Still or video, same principles of digital imaging. The new image (video, interlaced or not) interpolates to the new resolution. Your interlace field change size as well, data does not jump from one field to the next. They stay in the same location. In fact SEPARATING THE FIELDS is what can truly muck up your interlace issues.
    Thats a still image. Thats different from video. That argument can be applied to an interlaced image from a progressive source where each field is from the same point in time. But if you have 'TV' type interlacing (for want of a better term), each of the 2 fields is from a different point in time. Applying ' still image' type resize techniques to these is where the problems lie, especuially during motion scenes where the difference between to interlace scan lines can be significant.
    There are 10 kinds of people in this world. Those that understand binary...
    Quote Quote  
  21. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Your resize resizes the interlace too. The interlace lines ALSO change size. Therefore, NO TEMPORAL ERRORS. What was on Field A in pre-cropped/resized video is STILL on Field A in post-cropped/resized video. It does not jump fields.

    Still image or not, that is a fact of digital imaging, period. Motion or still. Interlaced motion or progressive. All the same, it's a simple digital imaging issue. The image properties do not "change" but it merely occupies a differently sized space (canvas or resolution).

    TEMPORAL errors are time-based issues, like changing framerates. That's where you can make the video all wacky. Not by merely cropping/resizing. If your software alter the temporal mechanics of the video, while only doing simple resizing at the same framerate, I suggest you use better software. Again, AVISYNTH may be the problem for some of you. Resizing within an NLE or encoder itself should not cause ANY problems.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  22. Originally Posted by lordsmurf
    What was on Field A in pre-cropped/resized video is STILL on Field A in post-cropped/resized video. It does not jump fields.
    SO when going from 480 lines to 576 lines, anything that was visible on only field A in the source is only visible on field A of target? Is that what you are saying?
    There are 10 kinds of people in this world. Those that understand binary...
    Quote Quote  
  23. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    Yes, the field integrity remains. Resize cannot (should not) change this. Resize merely makes the material occupy a different sized space, nothing more, nothing less. This is because interlace does not adhere to some rigid "size" but rather is a simple weave property of the playback.

    Temporal properties are not affected. Although it should be noted some software can screw this up, and avisynth may be one of them.

    Thinking back, the PIP example may not have been then best one to give (you may run into contradicting video properties by joining two diverse video clips), so let's stick to a conversation solely based on single-clip augmentation.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  24. But when you resize a still image from 480 lines to 576 lines, a pixel from say line 50 in the source, could end up on line 55 in the destination. If this was a frame made up of two fields in an interlaced video, this has then changed fields (gone from even field to odd field) which contradicts what you are saying.
    If this does not happen, then the software must be seperating the fields, resizing each field independantly and then weaving them back together. Which is what adam and I are saying.
    There are 10 kinds of people in this world. Those that understand binary...
    Quote Quote  
  25. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    No, it did not move fields. The field moved.


    Now, there is another option,
    one I've not tried to investigate for quite a while....


    Some encoders are FIELD BASED encoders. Maybe all of them are, to some degree. The field data in a resize does not swap fields in software that does a resize correctly. It stays.

    The decoding part of the equation may be FIELD BASED before it is encoded into the FRAME BASED spec of DVD (which is the nature of DVD-Video MPEG as I have been informed by pros in the past). This is where interlace and software management can get a bit stuffy. Then again, "field based interlace" has always confused the hell out of me (never been able to confirm or deny it specifically). Was never important, semantics mostly.

    FIELD BASED would not be the same as "separating fields" but rather "reading the fields individually" before creating the final MPEG encode.

    Regardless of the method, this is (usually) an operation carried out by the software, and is of no concern to us. Just input your video, crop/resize/filter as needed, and then set to output. Rest assured your final file with look peachy-keen on the tv set.

    +++++++++++

    At any rate, data does not change fields. Again, the whole "line 50", "line 55" thing implies some sort of non-existant rigid "place" for the interlace to exist. I have seen different-sized fields MANY TIMES in the past. The first time I saw a larger-than-normal interlace fields I was confused. The first time I wanted to crop a video, I was warned "oh no, you'll screw it all up" (which was, of course, incorrect, the video came out flawless like I had hoped).

    +++++++++++

    And for mention's sake, adjusting frame rates is the issue with PAL-NTSC conversion looking so sloppy in software. Not the resize. Interlace occupies different moments in time (it's more complex than that, but simple explanation works for now), so moving the fields (reducing/repeating fields) is the problem. Software can never seem to 100% properly handle it.
    Want my help? Ask here! (not via PM!)
    FAQs: Best Blank DiscsBest TBCsBest VCRs for captureRestore VHS
    Quote Quote  
  26. Originally Posted by lordsmurf
    No, it did not move fields. The field moved.
    So it whent from being an even field in the source file to an odd field in the destination file. Same difference.
    But some fields in that resized frame would remain as the same type of field they started at and some would move. Others would have their info spread over two fields (or more). So in the end, some data moves from field A to Field B, and vice versa, depending on the exact algorithms used.

    Originally Posted by lordsmurf
    Some encoders are FIELD BASED encoders. Maybe all of them are, to some degree. The field data in a resize does not swap fields in software that does a resize correctly. It stays.
    Thats exactly what I am saying. The encoder doing the resize treats each field seperatley. So instead of seing a 720*480 frame it sees two fields of 720*240. Therefore when resizing 720*480 to 720*576 as part of a NTSC to PAL conversion, the encoder will resize two seperate 720*240 fields to two 720*288 fields for each frame. So when doing the resize operation seperate from the encoder, you need to seperate the fields.

    Originally Posted by lordsmurf
    FIELD BASED would not be the same as "separating fields" but rather "reading the fields individually" before creating the final MPEG encode.
    'Field Based' and 'seperating fields' are, to my mind, essentially the same. It means treating each field as a seperate entity and not as simply half a frame.

    Originally Posted by lordsmurf
    The first time I wanted to crop a video, I was warned "oh no, you'll screw it all up" (which was, of course, incorrect, the video came out flawless like I had hoped).
    So you cropped it, and then your encoder did a resize to bring it back to spec. Cropping isn't the problem, I keep saying this. When resizing though, each field must be treated seperatley. If you are happy for your encoder to resize for you, then there is nothing to worry about. But if using avisynth, you have to seperate the fields 1st, resize each field, then combine them back together.
    There are 10 kinds of people in this world. Those that understand binary...
    Quote Quote  
  27. I just wanted to point out that avisynth has a SeparateFields function so that, among other things, non-field-aware filters can work on interlaced data.
    Quote Quote  
  28. groyal - I'm sorry to have been so long - as you took so much trouble to give precise instructions, I've been following them to the letter and inspecting everything very closely at every stage.

    The de-interlaced picture was beautiful - I'm sure the source is OK.

    The final product is the best yet, by any method I've tried.

    However, there is a curious effect which distinguishes the NTSC playback from the original PAL - this is as played by my Pioneer 5100 recorder/player to my PAL TV.

    Its not easy to be adeqately clear and precise about visual effects - the best I can do is to say that if you imagined the picture being shaken, with very small amplitude, at a few tens of Hz, then you'd see what I see. I don't really notice it when action is slow but it becomes very marked at high rates of change of data. Its one of those things that when my wife watched (before any comment from me) she said, 'that's great' but when I pointed out the effect she saw it immediately. Its not trivial - it is slightly trying to watch for a while but we have come a huge way towards our goal.

    I have to congratulate you for being such a stalwart helper in the face of some pretty fierce fire.

    I obviously want to go further and would welcome suggestions as to how to pin down the unwanted effect that I have tried to describe. I tried the trick of viewing out of the corner of my eye to see if that effected the 'vibrational' effect -not so.

    I've made a frame by frame comparison of a few fast action frames between the non-interlaced and the final result from Pulldown. I can't see anything which gives a clue.

    Out of my depth again I'm afraid, but increasingly happy.

    Many, many thanks to all.


    Oh, I forgot, I guess the reason it went wrong the first time was the doubleweave thing?
    Quote Quote  
  29. Originally Posted by opoman
    the picture being shaken, with very small amplitude, at a few tens of Hz
    Remember you have traded temporal and spatial resolution to get smoother motion. You started with an fully interlaced PAL video where you saw 50 separate pictures per second. You threw away every other picture to get 25 pictures per second and then slowed the frame rate down to 23.976. But the remaining pictures weren't full pictures, they were every other scan line of the pictures. So you filled the in-between spaces with something interpolated from the nearby scanlines -- this isn't necessarily what was really there but that's pretty much the best you could do. Finally, you're playing this with 3:2 pulldown on an NTSC display. You're taking your 23.976 pictures per second and displaying one picture for 3 fields (~3/60ths of a second) and the next picture for 2 fields (~2/60ths of a second), and so on.

    Each step introduces it's own problems but this may be the best compromise.

    The drop from 50 pictures per second to 23.976 pictures per second is noticable on high motion material.

    The 3:2 pulldown also produces a fast jerkiness that is perceptable when you look for it. Especially in smooth, moderately paced, panning shots -- like you seen in sporting events.
    Quote Quote  
  30. lordsmurf, I usually respect what you have to say, but I honestly don't understand where you are coming from with respect to resizing an interlaced frame.

    How can you not understand that it will get fucked up if you resize it vertically? Have you ever paused on an interlaced source and watched your TV image? It shakes back and forth in two moments in time.

    I am sure you know that interlaced frames contain two fields. Each field represents a different moment in time. Pausing on one frame shows both moments in time and the TV is properly displaying it when it shows that shaking image. It is actually displaying two alternating fields over and over.

    Each field is on alternating lines. The TV displays each field one at a time. The fields cannot be shifted; they cannot be blended. Doing so would severely screw up your video.

    How can you say otherwise? Just saying that you do it all the time is not good enough. I've done it before too and it was completely fucked up (and rightfully so).


    Darryl
    Quote Quote  



Similar Threads

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