VideoHelp Forum
+ Reply to Thread
Results 1 to 20 of 20
Thread
  1. Member
    Join Date
    Feb 2003
    Location
    Norway
    Search Comp PM
    Hi. I wanted to convert from interlaced HD (HDV) to interlaced SD (DVD) with best possible quality, so I researched the net a lot and ended up with this AVISynth script, in case others want to do the same:

    ------------------------------------------------------------------------------------------------------------------
    #You need to download these three external filters
    #and place them in the same folder as the script:
    LoadPlugin ("MSharpen.dll")
    LoadPlugin ("SmoothDeinterlacer.dll")
    LoadPlugin ("ColorMatrix.dll")

    #Change XXXX with the filename of your HD-video:
    avisource ("XXXX.avi")

    #Change colorspace from ITU.709 (HD) to ITU.601 (SD):
    ColorMatrix ()

    #Change from 25/30 interlaced fps to 50/60 progressive fps preserving
    #full vertical resolution for non-moving objects in picture:
    SmoothDeinterlace(lacethresh=10, tff=true, doublerate=true)

    #Sharpen the image BEFORE scaling it down (for best quality).
    #I found MSharpen to do a good job. Maybe it's not the best.
    #See if you can find a better if you like:
    MSharpen ()

    #Resize to PAL:
    LanczosResize (720, 576)

    #Or resize to NTSC:
    #LanczosResize (720, 480)

    #Cut away the first field to get clean cuts (from one scene to another inside the video):
    Trim (1,0)

    #Interlace it back to 25/30 interlaced again:
    SeparateFields
    SelectEvery (4,0,3)
    Weave
    -----------------------------------------------------------------------------------------------

    These are the issues I had to solve:
    1. The camera "sees" in RGB (red, green blue) and your TV displays in RGB, but the video on tape in between is YUV (luminance Y, and two color channels U and V). And of course: conversion between the two does not involve just ONE standard, oh no. HD uses one standard called ITU.709 and SD uses another: ITU.601. There isn't a huge difference, but if you want perfect quality, you have to convert from 709 to 601. And this is what ColorMatrix does.

    2. Resizing interlaced video is not easy if you want perfect quality. Simply separate the fields, resize each, and then combine them together again is not ideal because if some objects in the picture doesn't move (for instance graphics or maybe you have used a tripod), these objects use both fields to build up their full resolution. In such cases you do not want to deinterlace before resizing to keep quality. But for objects that do move, you HAVE to deinterlace unless you want ugly horizontal lines. That's why I chose the SmoothDeinterlacer. It analyzes each frame to see what moves and what does not and then separates each field into two full size frames with full resolution for non-moving objects and half (interpolated) resolution for moving objects.

    3. Each time the video cuts from one scene to another, the first frame of each new scene contains the last field of the "old" scene and the first field of the new - for some reason... With the Trim-function I offset the whole video with one field to avoid this, before interlacing.

    4. If you convert to DV, you have to switch the field order, because DV is bottom field first while HD and DVD is top field first. If you don't change this, all moving objects will shake horribly. I haven't thought out how yet. Anyways: This script will work for conversion to DVD.

    Use VirtualDub to make a new AVI-file, or open the avs-script directly in your DVD-encoder software. The script works very slowly, so if you plan to use 2 pass VBR in your DVD encoder, I recommend making a (nearly) uncompressed avi first, or else the encoder will do the slow script process twice. If you use VirtualDub: Make sure you don't add any filters, because then VirtualDub will convert from YUV to RGB and you loose some quality, but the worst is: you don't know if your video will end up with the correct YUV color space (601 vs. 709). Set VirtualDub to "Direct Stream Copy" if you want uncompressed YUV output or "Fast recompress" if you want to set your own YUV codec (for instance DV). The point is: You want to be sure that you feed your DVD encoder or DV-tape with ITU.601 YUV signals.

    Good luck, and please do ask if something is unclear. Please also suggest an adjusted script if you find an even better downsizing method, or you find that I have done anything wrong.
    Quote Quote  
  2. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    http://forum.doom9.org/showthread.php?t=136109 has info on this topic !!

    Not sure your Selectevery is right ... there's instructions here http://forum.doom9.org/showthread.php?p=1110741#post1110741

    Originally Posted by jorbje
    4. If you convert to DV, you have to switch the field order, because DV is bottom field first while HD and DVD is top field first. If you don't change this, all moving objects will shake horribly. I haven't thought out how yet.
    Er, no, DVD can be BFF, use it all the time. Free to air HDTV is usually TFF. My Canon MV920 miniDV returns DV interlaced BFF 720x576 which I convert to DVD BFF just fine via the HC encoder. Are you talking about a HD clip from a DV camera per chance as your comment seems a bit confusing - DV vs HD vs HDTV vs DVD.

    When you downsize, why sharpen ? The act of downsizing increases perceived sharpening, doesn't it ?
    Quote Quote  
  3. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    There's also these links which show other methods...
    https://forum.videohelp.com/topic337231.html
    https://forum.videohelp.com/topic346088.html
    https://forum.videohelp.com/topic309286-30.html#1754722

    and this which talks about denoising and converting an SD DV camera capture to a DVD ...
    https://forum.videohelp.com/topic348133.html#1827995
    Quote Quote  
  4. Banned
    Join Date
    Oct 2004
    Location
    Freedonia
    Search Comp PM
    Originally Posted by halsboss
    Er, no, DVD can be BFF, use it all the time.
    This is 100% correct. While it is true that DVD is usually top field first (TFF), it can be BFF as long as the flag is set correctly in the video stream. Some DVD authoring applications may assume TFF for all input and set the flag incorrectly, but as long as the flag is set correctly, BFF is certainly valid for DVD. If the flag is not set correctly, then the shaking mentioned is exactly what happens. It is possible to modify this flag before the DVD is burned, but I only did this once and I don't remember the name of the program that can do it.
    Quote Quote  
  5. Member Alex_ander's Avatar
    Join Date
    Oct 2006
    Location
    Russian Federation
    Search Comp PM
    Originally Posted by halsboss
    Not sure your Selectevery is right ...
    Yeah, by default (without AssumeTFF/BFF before SeparateFields) the field separation order (= script output here) will be BFF (possible for DVD, but not what is expected).
    Also 'interlaced=true' is needed for ColorMatrix used with its position in script (or it could be used after bob-deinterlacer).
    Quote Quote  
  6. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    A good encoding engine should set the BFF flag for you eg, the HC encoder input to DVDlab, the VideoReDo TV Suite editor/encoder/author program. Even ffmpeg produces a video stream with the flag set properly, so I'd quiery the DVD authoring program if the result isn't going well.

    Re selectevery, the link supplied indicates
    Code:
    AssumeTFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> TFF
    AssumeBFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> BFF ***
    AssumeTFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> BFF
    AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> TFF
    So make sure in any of the examples in the links supplied that the AssumexFF() and SelectEvery(...) are set properly as well as the Order= parameters in other plugin calls...
    Quote Quote  
  7. Member Alex_ander's Avatar
    Join Date
    Oct 2006
    Location
    Russian Federation
    Search Comp PM
    ... and it's easier (for remembering) to always use (4,0,3) numbers because the field order you assume becomes the output field order in this case.
    Quote Quote  
  8. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    Too right. Seen a lot of examples in this place and on Doom9 where they're mixed and matched out of context and sometimes plain wrong.
    Quote Quote  
  9. Originally Posted by Alex_ander
    Originally Posted by halsboss
    Not sure your Selectevery is right ...
    Yeah, by default (without AssumeTFF/BFF before SeparateFields) the field separation order (= script output here) will be BFF (possible for DVD, but not what is expected).
    Also 'interlaced=true' is needed for ColorMatrix used with its position in script (or it could be used after bob-deinterlacer).
    Didn't he switch the field order when he knocked out the first field? He did it in order to not have scene changes be split between 2 fields in a single frame, but one (accidental?) side effect was to change the field order to TFF. I think.
    Quote Quote  
  10. Member Alex_ander's Avatar
    Join Date
    Oct 2006
    Location
    Russian Federation
    Search Comp PM
    Originally Posted by manono
    Didn't he switch the field order when he knocked out the first field?
    Hi, manono. I think by Trim(1,0) he removed a complete frame from progressive video sequence (already field-neutral). I recently tested for myself, what happens at field separation if field order is not chosen: as with some other operations, AviSynth assumed BFF by default.
    Quote Quote  
  11. Hello Alex_ander-

    I'm assuming he's used this script himself before with good results - no obvious jerkiness - so it must be good. Maybe the TFF setting in SmoothDeinterlacer plays a part in setting the field order (incorrectly, I think), so that when he removes that first bobbed field, combined with the SelectEvery (4,0,3) line, it becomes true TFF again.

    Maybe jorbje will come back again soon and elaborate. I'm counting on you, jorbje. Don't let me down.
    Quote Quote  
  12. Member
    Join Date
    Feb 2003
    Location
    Norway
    Search Comp PM
    Thanks a lot guys for your comments

    Originally Posted by halsboss
    DVD can be BFF, use it all the time
    Oh, it can? I didn't know that. Cool. But since DVD seems to be TFF as default, and since you CAN run in to problems with BFF (as mentioned in this thread) I feel it safer to make it TFF.

    Are you talking about a HD clip from a DV camera per chance as your comment seems a bit confusing - DV vs HD vs HDTV vs DVD
    Let me clear this up: HD clip from a DV camera is not possible since DV is SD and never anything else. An HDV camera on the other hand can give you HD. DVD is also SD only.

    When you downsize, why sharpen ? The act of downsizing increases perceived sharpening, doesn't it ?
    I sharpen because IMO it gives me better pictures. Sharpening SD sources is a no-no for me, because I think the build-in sharpening process that's part of the video standard gives me ugly thick outlines, and I don't want to make them even more ugly. But if I sharpen an HD source, that is make the outlines even "worse", gives me more room. So when I downsize it, the extra outlines almost disappears, and the result is just pure sharp. But this is a subjective thing.

    I'm not much into heavy coding yet, so I don't fully understand these codes, but what I see looks like just resizing the image pluss a lot about encoding to MPEG which is not my issue here. Is the quality loss when deinterlacing non-moving objects taken care of? What about 709 -> 601?

    Originally Posted by manono
    Didn't he switch the field order when he knocked out the first field? He did it in order to not have scene changes be split between 2 fields in a single frame, but one (accidental?) side effect was to change the field order to TFF. I think.
    No. Switching field order makes field 1 come before field 2 or vice versa. Let's say you have these fields:
    1-2-3-4-5-6-7-8
    You can then interlace them like this:
    (1-2)-(3-4)-(5-6)-(7-8) (is this TFF?)
    Or, if you switch field order, like this:
    (2-1)-(4-3)-(6-5)-(8-7) (is this BFF?)

    If the field order is TFF and the player assumes BFF (or vice versa), you will get very shaky movements.

    What I did was skipping the first field:
    2-3-4-5-6-7-8-9
    which interlaced would be like this:
    (2-3)-(4-5)-(6-7)-(8-9)

    Now, this is important: Fields is dependent on two factors. And you can switch both independently:

    1) Time: the second field is recorded 1/50 (PAL) second after the first, and therefore contains a different placement of a moving object. That means: If you put field 1 in the lines where field 2 should be and vice versa, moving objects will shake (two steps forward and one back, two forward and one back etc.).

    2) Placement: Each field represent each half of a full resolution video frame. That means: If you put field 1 in the lines where field 2 should be and vice versa, non-moving objects will get jagged and ugly.

    I guess there are AVISynth filters that will do this but I don't know AVISynth much yet. Anyways, this is the theory:

    1) How to switch the fields in just time and not placement: Move the whole frame up or down exactly one line. Well, of course the fields are moved, but the point is: They are NOT moved relatively to each other. The whole picture is the same, but each field has still switched places and will be played back in opposite order in TIME. This is how you can repair shaky movements and still keep full vertical resolution.

    2) How to switch the fields in just placement and not time: Switch field 1's lines with field 2's and then move the whole frame up or down exactly one line.

    Why am I explaining this heavy theory in this thread? Because skipping the first field before interlacing does exactly the same thing as 2). But you don't want jagged output. Well, it is not that jagged after all since I downscale from HD to SD, but I will still lose some quality. That is one reason it is so important to have as close to FULL vertical resolution as possible in each picture before downscaling and weaving them together again. And SmoothDeinterlacer makes sure you have that. Bob does not.
    Quote Quote  
  13. Member racer-x's Avatar
    Join Date
    Mar 2003
    Location
    3rd Rock from the Sun
    Search Comp PM
    I posted a guide for this about a year ago, I can't find it now.........

    Anyway, Yes a DVD can be BFF, TFF or Progressive. Mini-DV codec can support BFF, TFF and Progressive. All Mini-DV camcorders record as BFF for simplicity sake. Just as al HD cameras record TFF...............

    Your method works, but it is redundant and too slow for my tastes. I'd rather go with this:

    Code:
    LoadPlugin("MSharpen.dll")
    MPEG2Source("Test.d2v", cpu=0)
    assumetff().Bob(height=480)
    LanczosResize(720,480)
    assumetff().separateFields()
    SelectEvery(4,0,3) #TFF source - use (4,1,2) for BFF
    Weave()
    MSharpen(15,53,false,false,false)
    That gives as good or better quality than yours and is at least 5x faster. If you absolutely want to use a smart De-interlacer, I think Yadif would be a better choice.
    Got my retirement plans all set. Looks like I only have to work another 5 years after I die........
    Quote Quote  
  14. Member Alex_ander's Avatar
    Join Date
    Oct 2006
    Location
    Russian Federation
    Search Comp PM
    Originally Posted by manono
    Maybe the TFF setting in SmoothDeinterlacer plays a part in setting the field order (incorrectly, I think), so that when he removes that first bobbed field, combined with the SelectEvery (4,0,3) line, it becomes true TFF again.
    It could happen in case of BFF input video, then the double framerate video would have reversed (due to TFF setting in S.Deinterlacer) motion phases in each pair of frames. Then BBF assumed by AviSynth before separating fields would give correct TFF result in the end but only if you add 'AssumeTFF' in the end(!) or set TFF for import in the encoder. In case of correct bob-deinterlacing throwing away the first frame wouldn't matter at all, but when you do it on wrongly phased bob, looks like it would turn TFF back to BFF - catch 22!

    P.S. In the last case trim operation also mixes fields up in a strange way by the end of the script (my next post).
    Quote Quote  
  15. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    Originally Posted by jorbje
    DVD seems to be TFF as default, and since you CAN run in to problems with BFF (as mentioned in this thread) I feel it safer to make it TFF.
    Well... it's like saying 3000kbits/sec "is the default"... be interesting to hear about specific BFF problems as I've been doing it for years without any problems and without hearing of any....

    Originally Posted by jorbje
    Let me clear this up: HD clip from a DV camera is not possible since DV is SD and never anything else. An HDV camera on the other hand can give you HD. DVD is also SD only.
    OK, you're downsizing a HDV camera clip which is natively BFF ?

    Originally Posted by jorbje
    Sharpening SD sources is a no-no for me, because I think the build-in sharpening process that's part of the video standard gives me ugly thick outlines, and I don't want to make them even more ugly.
    You're coding something slighly "off-center" to end up with ugly stuff ? Have a poke around at the doom9 forums avisynth usage, they have literally hundreds of pages dedicated to this sort of thing including the inimitable Limitedsharpenfaster function and Soothe etc etc ... been using them for years with fantastic results. I have a view that sharpening before downsizing adds cpu cycles unnecessarily unless the clip has some poor characteristics... denoising HDV I can understand, and maybe the methods you use could introduce softening or something which makes sharpening necessary ?

    Originally Posted by jorbje
    Switching field order makes field 1 come before field 2 or vice versa. Let's say you have these fields
    be very careful with swapping with field orders willy nilly, suggest have a look at "ReverseFieldDominance" (eg there's a plugin) etc over at doom9 and the discussions pertaining to changing field orders... really odd stuff can happen that you wouldn't necessarily think of, if you do it. There's some real experts over at doom9 around this gear. **addendeum* oops that stuff is about playing with field orders without deinterlacing... here you are deinterlacing so we must be careful to re-interlace retaining information from the original fields, now resized, rather than from the interpolated fields generated during doubleframerate deinterlacing; one of the links about selectevery mentions it.

    Originally Posted by jorbje
    Switching field order ... This is how you can repair shaky movements and still keep full vertical resolution.
    Happy to be corrected, but I think they say otherwise over at doom9... feel free to look up those discussions, I recall they seemed comprehensive.

    Originally Posted by jorbje
    If the field order is TFF and the player assumes BFF (or vice versa), you will get very shaky movements.
    Why play with fire ? Better still, *don't* muck with the field order at all - ensure your video stream creation and authoring set the field order flag. The software I've played with does it fine, if your software doesn't do it then I suggest get rid of it and use something reliable (who knows what else it's not doing correctly). I'm 99.99% certain that no modern DVD players over-ride a DVD's field order flags setting with its assumptions, never come across it nor heard of it. Works fine for me for years with various players of my own and others (family DV footage). If absolutely you must "do it" for whatever reason, please have a read of the doom9 discussions before you do. Can anyone relate an experience of a hardware DVD player over-riding the BFF flag on a DVD ?

    Originally Posted by racer-x
    Anyway, Yes a DVD can be BFF, TFF or Progressive. Mini-DV codec can support BFF, TFF and Progressive. All Mini-DV camcorders record as BFF for simplicity sake. Just as al HD cameras record TFF...............
    OK... is the OP saying the clip's BFF from a HDV camera ?
    Quote Quote  
  16. Member
    Join Date
    Jan 2004
    Location
    Australia
    Search Comp PM
    Originally Posted by racer-x
    If you absolutely want to use a smart De-interlacer, I think Yadif would be a better choice.
    Yes. Or say YadifMod with NNEDI ... depends on the desired outcome (eg quality vs speed) The links I gave show TDEINT as it's still one of the best motion compensating deinterlacers going around, although Yadifmod/NNEDI are conjectured to possibly give a fine result for sports type footage if reinterlacing (be interesting to see what others think).

    If the OP is deinterlacing and then reinterlacing ... just a thought, leave it progressive ? Depends on the OP's clip features I guess. I have gear which is turned progressive and left that way - the clip features are such that it appears OK.
    Quote Quote  
  17. Member
    Join Date
    Feb 2003
    Location
    Norway
    Search Comp PM
    Originally Posted by halsboss
    OK, you're downsizing a HDV camera clip which is natively BFF ?
    No. My HDV camera is TFF, which is, I guess, the normal.

    Have a poke around at the doom9 forums avisynth usage, they have literally hundreds of pages dedicated to this sort of thing including the inimitable Limitedsharpenfaster function and Soothe etc etc ... been using them for years with fantastic results. I have a view that sharpening before downsizing adds cpu cycles unnecessarily unless the clip has some poor characteristics... denoising HDV I can understand, and maybe the methods you use could introduce softening or something which makes sharpening necessary ?
    Thanks for that advice. I'll take a look.

    be very careful with swapping with field orders willy nilly, suggest have a look at "ReverseFieldDominance" (eg there's a plugin) etc over at doom9 and the discussions pertaining to changing field orders... really odd stuff can happen that you wouldn't necessarily think of, if you do it.
    Correct. That's why I explained the problem. But I'll take a look at Doom9.

    Originally Posted by jorbje
    Switching field order ... This is how you can repair shaky movements and still keep full vertical resolution.
    Happy to be corrected, but I think they say otherwise over at doom9... feel free to look up those discussions, I recall they seemed comprehensive.
    I have tested it, and it works perfectly for me. But I'll have a look at doom9 to see what they write

    Thanks for the alternatives to SmoothDeinterlacer. I'll try them out.
    Quote Quote  
  18. Member Alex_ander's Avatar
    Join Date
    Oct 2006
    Location
    Russian Federation
    Search Comp PM
    Originally Posted by jorbje
    What I did was skipping the first field:
    2-3-4-5-6-7-8-9
    which interlaced would be like this:
    (2-3)-(4-5)-(6-7)-(8-9)
    Do you mean Trim (1,0) ???
    Then it's not a field, it's a frame skipped and this will not change field order at re-interlacing. What we have before SeparateFields() is a frame-based progressive video (its field-processing history is already lost):
    (2t+2b)-(3t+3b)-(4t+4b)-(5t+5b)....
    Since each pair of fields here belongs to its own moment (progressive frame) you can further separate fields in either order (you have double set of frames for this due to double framerate). If you don't set this order (=use AviSynth default) or (the same) use AssumeBFF() before separation, you'd get:
    2b-2t-3b-3t-4b-4t-5b-5t....
    After Select(4,0,3) you leave 2 of each 4 fields:
    2b-3t-4b-5t....
    Weave():
    (2b-3t)-(4b-5t)...
    since numbers 2,3,4... correspond to motion phases, it's BFF (if you want a different field order from the script, you can simply use AssumeTFF before SeparateFields).

    Now if you don't skip the first frame and still separate with BFF (or leave default field order):
    (1t+1b)-(2t+2b)-(3t+3b)-(4t+4b)-(5t+5b)....
    AssumeBFF().SeparateFields():
    1b-1t-2b-2t-3b-3t-4b-4t-5b-5t....
    1b-2t-3b-4t...
    (1b-2t)-(3b-4t)...
    - it is also BFF (same as with Trim)


    The only case Trim (1,0) changes things by the end of the script is in case the input for bob-deinterlacer is BFF but it has the wrongly set parameter TFF=true. Not 100% sure of SmoothDeinterlacer behaviour in this situation but LeakKernelBob (with order=1) would produce something like this:
    (2t+2b)-(1t+1b)-(4t+4b)-(3t+3b)...*
    without Trim(1,0):
    (separated as BFF)
    2b-2t-1b-1t-4b-4t-3b-3t....
    selected/weaved:
    (1t-2b)-(3t-4b)... - true TFF
    then trimming * to (1b+1t)-(4b+4t)-(3b+3t)...
    gives (separated as BFF):
    1b-1t-4b-4t-3b-3t-6b-6t-5b-5t....
    selected:
    1b-4t-3b-7t-5b...
    (1b-4t)-(3b-7t)... - BFF, but the fields are completely mixed up -> the Trim() line can be dangerous in some cases, while the script without it still works in case of field order mistake in the beginning (only field order changes).
    Quote Quote  
  19. Member
    Join Date
    Feb 2003
    Location
    Norway
    Search Comp PM
    Originally Posted by Alex_ander
    Originally Posted by jorbje
    What I did was skipping the first field:
    2-3-4-5-6-7-8-9
    which interlaced would be like this:
    (2-3)-(4-5)-(6-7)-(8-9)
    Do you mean Trim (1,0) ???
    Then it's not a field, it's a frame skipped...
    Yes, I meant Trim (1,0). I know they are technically speaking not fields anymore. I just like to still call them "fields" in hope of making it more understandable, but I see now that it was confusing not calling them what they actually are. Sorry 'bout that.

    ...and this will not change field order at re-interlacing
    Exactly my point, as an answer to manono who asked if I changed the field order by trimming. But since I wrote: "#Cut away the first field to get clean cuts" in the script, I can see the confusion now.

    Thanks for clearing up the Trim(1,0)-issue. I see there can be heavy field problems using it in the wrong place. But still: In my case I can't find any other way to get clean cuts. My source is TFF, I know that for sure, and I want my output also to be TFF. And even if I set AssumeTFF all over my script, my cuts will only get clean if I trim out the first deinterlaced frame (now, that was a better word for it?). I guess there is something faulty with SmoothDeinterlacer.... Anyways, it works perfectly fine.

    Originally Posted by racer-x
    Your method works, but it is redundant and too slow for my tastes. I'd rather go with this:

    Code:
    LoadPlugin("MSharpen.dll")
    MPEG2Source("Test.d2v", cpu=0)
    assumetff().Bob(height=480)
    LanczosResize(720,480)
    assumetff().separateFields()
    SelectEvery(4,0,3) #TFF source - use (4,1,2) for BFF
    Weave()
    MSharpen(15,53,false,false,false)


    That gives as good or better quality than yours and is at least 5x faster
    I have now compared your code (translated to avisource and 576 lines) with mine. Your is 3.6 times faster on my computer and a little less detailed, especially with graphics. Take a look at these tiff-files of the results:
    http://spokke.com/bob.tif -> your script
    http://spokke.com/smooth.tif -> my script
    (I have deleted the 709-601 conversion in these examples)

    Compare the superimposed text in the top right, the phone cord in the logo (down, left), the text on the food, and even the eyes of the boy. It is clear to me that simply "bobing" is way faster, yes, but with a cost of a little bit less quality.
    Quote Quote  
  20. Member racer-x's Avatar
    Join Date
    Mar 2003
    Location
    3rd Rock from the Sun
    Search Comp PM
    The differences could just be that you're using more sharpening. I don't like to sharpen interlaced video too much, it usually leads to flickering on the TV. If the differences are enough to convince you to keep using your script, then that's your choice and you should do what you feel is best for you. As for me, there's not enough difference to justify the extra processing time required. We are after all talking about video (moving pictures not still) and I doubt anyone can tell the difference watching it on TV.........

    It was good that you posted your method, as it gave me a reason to try new filters.
    Got my retirement plans all set. Looks like I only have to work another 5 years after I die........
    Quote Quote  



Similar Threads

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