VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker or buy a VSO converter software :)
+ Reply to Thread
Results 1 to 18 of 18
Thread
  1. I have a DVD in PAL format and want to offer it in NTSC as well but I'm concerned about quality loss. What might I expect the results to be like? And what would be the best way to do the conversion? (I used avisynth and HCEncoder to encode.)
    Last edited by kieranvyas; 7th Nov 2016 at 05:01.
    Quote Quote  
  2. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    The actual raw conversion quality can be almost transparent depending on the nature of the content and the methods used to convert.

    The biggest quality loss will be re-encoding from MPEG2 to MPEG2 again.

    If you can start with the raw sources in PAL format rather than converting the PAL DVD that would give the biggest quality boost.
    Quote Quote  
  3. Originally Posted by Skiller View Post
    The actual raw conversion quality can be almost transparent depending on the nature of the content and the methods used to convert.

    The biggest quality loss will be re-encoding from MPEG2 to MPEG2 again.

    If you can start with the raw sources in PAL format rather than converting the PAL DVD that would give the biggest quality boost.
    I have the entire project exported with the lagarith lossless codec. So my thoughts are if I run that through avisynth with the appropriate extra lines of script to do the convert, that should hopefully give me an NTSC version with little quality loss then??

    If that's the case, I'd be super grateful if you or anyone might assist me with what avisynth script I'd need to include to do the convert. Thank you very much for your help!

    My current script is:
    AviSource("file.avi")
    ConvertToYV12()
    Spline36Resize(720,576)
    Blur(0, 0.7, false).Sharpen(0, 0.3, false)
    ColorMatrix(mode="Rec.709->Rec.601",clamp=0)
    SelectEven()
    Quote Quote  
  4. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Good conversion settings/tools depend heavily on the nature of the content (interlaced, progressive, film, mixed, animation etc.).

    In other words, I cannot give you much of a sophisticated help without a sample.



    Originally Posted by kieranvyas View Post
    So my thoughts are if I run that through avisynth with the appropriate extra lines of script to do the convert, that should hopefully give me an NTSC version with little quality loss then??
    Yes.
    Last edited by Skiller; 7th Nov 2016 at 07:30.
    Quote Quote  
  5. Resize to 720x480 instead of 720x576. Encode as 25p. Us DgPulldown to add 3:2:3:2:2 pulldown flags for 30i.

    Or, resize to 720x480, convert 50p to 60p (ChangeFPS() for duplicate frames, or ConvertFPS() for blended frames) and hard pulldown to 30i.
    Quote Quote  
  6. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Originally Posted by jagabo View Post
    Resize to 720x480 instead of 720x576. Encode as 25p. Us DgPulldown to add 3:2:3:2:2 pulldown flags for 30i.
    That should be done only if the video is entirely 25p. How do you know it is? You should not give such advice until we know anything about the video.
    Quote Quote  
  7. He's happy making 25p with his current script. And I gave him the alternative for 50p to 30i.
    Quote Quote  
  8. Originally Posted by jagabo View Post
    He's happy making 25p with his current script. And I gave him the alternative for 50p to 30i.
    The lossless video (input) is 50p and I converted it to 25p in my script. Do I need to interlace it during conversion to NTSC then or can I stick with progressive? Thanks
    Quote Quote  
  9. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Originally Posted by kieranvyas View Post
    Do I need to interlace it during conversion to NTSC then or can I stick with progressive?
    You can stick with progressive, but in my opinion you certainly should not – not for the PAL version either (!) because you are losing half the motion by going from 50p to 25p instead of 25i which you can use for DVD.

    If you insist on progressive anyway, do it the way jagabo suggested.
    Quote Quote  
  10. If you prefer smooth motion you should use 25i and 30i. If you prefer the jerky flickery film look use 25p and 25p with pulldown for NTSC.
    Quote Quote  
  11. Originally Posted by Skiller View Post
    Originally Posted by kieranvyas View Post
    Do I need to interlace it during conversion to NTSC then or can I stick with progressive?
    You can stick with progressive, but in my opinion you certainly should not – not for the PAL version either (!) because you are losing half the motion by going from 50p to 25p instead of 25i which you can use for DVD.

    If you insist on progressive anyway, do it the way jagabo suggested.
    Thank you! The reason I stuck to 25p originally was because I had issues with the quality degredation from HD to SD and when I tested it in 25p and 25i and the 25p version produced much better results. I was not knowledgeable enough about avisynth and interlacing to be able to get it to work better than the 25p version. (I'm not a pro like a lot of you guys!) I'm sure there were issues in my workflow but ultimately, with what I'd done, the 25p just looked noticeably improved.

    This is why I'd be keen to stick with 25p because I know it works and I'm not knowledgeable enough to handle the problems I was facing with interlacing.
    Quote Quote  
  12. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Alright, all you would have to do is replace the last line of the script you posted, which is SelectEven(), with these two lines and then encode it interlaced with TFF (Top Field First) field dominance.

    Code:
    #interlaces for example 50p to 25i and 60p to 30i
    AssumeTFF()
    SeparateFields().SelectEvery(4,0,3).Weave()

    The NTSC version needs a frame rate conversion of 50p to 59.94p beforehand.

    This is the script for that, but I would actually recommend trying something more clever than ConvertFPS, I would recommend SVP.

    Code:
    AviSource("file.avi")
    ConvertToYV12()
    Spline36Resize(720,480)
    Blur(0, 0.7, false).Sharpen(0, 0.3, false)
    ColorMatrix(mode="Rec.709->Rec.601",clamp=0)
    ConvertFPS(60000, 1001)
    AssumeTFF()
    SeparateFields().SelectEvery(4,0,3).Weave()

    If you want to try frame rate conversion/interpolation using SVP, download it and replace the ConvertFPS line with this:

    Code:
    threads=4 #set this to the number of your physical CPU cores
    
    super=SVSuper("{gpu:0}")
    vectors=SVAnalyse(super, "{}")
    SVSmoothFps(super, vectors, "{ rate: {num:60000,den:1001,abs:true}, algo:13, mask:{cover:100,area:60} }",
    \ url="www.svp-team.com", mt=threads)
    Last edited by Skiller; 7th Nov 2016 at 11:58. Reason: added AssumeTFF()
    Quote Quote  
  13. Originally Posted by Skiller View Post
    Alright, all you would have to do is replace the last line of the script you posted, which is SelectEven(), with these two lines and then encode it interlaced with TFF (Top Field First) field dominance.

    Code:
    #interlaces for example 50p to 25i and 60p to 30i
    AssumeTFF()
    SeparateFields().SelectEvery(4,0,3).Weave()

    The NTSC version needs a frame rate conversion of 50p to 59.94p beforehand.

    This is the script for that, but I would actually recommend trying something more clever than ConvertFPS, I would recommend SVP.

    Code:
    AviSource("file.avi")
    ConvertToYV12()
    Spline36Resize(720,480)
    Blur(0, 0.7, false).Sharpen(0, 0.3, false)
    ColorMatrix(mode="Rec.709->Rec.601",clamp=0)
    ConvertFPS(60000, 1001)
    SeparateFields().SelectEvery(4,0,3).Weave()

    If you want to try frame rate conversion/interpolation using SVP, download it and replace the ConvertFPS line with this:

    Code:
    threads=4 #set this to the number of your physical CPU cores
    
    super=SVSuper("{gpu:0}")
    vectors=SVAnalyse(super, "{}")
    SVSmoothFps(super, vectors, "{ rate: {num:60000,den:1001,abs:true}, algo:13, mask:{cover:100,area:60} }",
    \ url="www.svp-team.com", mt=threads)
    Thanks a lot for this!!! I'll give it a go!!
    Quote Quote  
  14. Beware that SVP (and all the other motion interpolation filters) can generate severe artifacts. It works pretty well for panning shots but when motions get complex it fails badly. It's worth a try but don't be surprised if you get weird artifacts.
    Quote Quote  
  15. Member
    Join Date
    Oct 2013
    Location
    Germany
    Search Comp PM
    Yeah, have a good look at the output if you use SVP and see if you find artefacts.

    I do find however that it works quite well for conversions in the higher range of frame rates because there is not nearly as much difference between the original frames compared to interpolating from a low frame rate such as film or Super 8.
    Converting between 60p and 50p does seem to work pretty good in my experience, probably also because potential artefacts are shown for a very short time only with lots of original frames to insert inbetween.
    Quote Quote  
  16. Originally Posted by kieranvyas View Post
    I have a DVD in PAL format and want to offer it in NTSC as well but I'm concerned about quality loss. What might I expect the results to be like? And what would be the best way to do the conversion? (I used avisynth and HCEncoder to encode.)
    There's also this option: https://forum.videohelp.com/threads/166266-PAL-NTSC-DVD-Conversion-%28patch-method%29
    This is nøt å signåture.™
    Quote Quote  
  17. Far too goddamn old now EddyH's Avatar
    Join Date
    Jan 2003
    Location
    Soul sucking suburbia! But a different part since I last logged on.
    Search Comp PM
    My 2.7p-worth (equivalent to approx 2p worth, this time last year):

    Yes, you will lose quality converting from PAL to NTSC. The vertical resolution is only 5/6ths as much!
    (that's only *slightly* faecetious, as some people don't immediately realise it)

    And then there's the fun to be had with the different frame rates unless you do something very sneaky like slowing it down 4% from 25-frame (50-field) to 23.976-frame (er.... 47.9mumble fields) and tagging it as Film to force automatic Telecine padding within the player, or tagging as NTSC-Camera then chucking in a lot of repeat-field flags (like, 9.94 per second) to up it from 50 to 59.94 without actually changing any of the stored temporal data... both of which will at least preserve (83.3% of) the original video data somewhere within the stream, but might look pretty gopping when actually played back on an NTSC screen.

    Which means you could end up wishing you'd used a more advanced method, maybe even using a motion-detection (deinterlacer and) frame interpolator to up the rate from 25 frame / 50 field to 300 progressive frame/sec simulated, using a really high quality resizer (eg sinc-based or context aware) to do the vertical squash, decimating the rate back down to 30 / 60 (and re-interlacing if necessary) with some tool that can make a good fist of that as well, then slowing it to 29.97 / 59.94 and resampling the audio to 1000/1001ths of the original speed (IE decompress to 48000hz PCM, then either reduce the sample rate to 47952 and do a resampling conversion back up to 48000 with the necessary filters, or just give it a 100.1% time-stretch (which will preserve the pitch), then re-encode to the same or higher compressed bitrate with as good an encoder as you can find).

    Which will wield a double-edged sword of adding extra information to it by sticking in additional interpolated frames, whilst losing some thanks to only about one-third of the output frames (or fields) being identical (or a close match) to resized copies of the originals. Notionally, a net loss, as 66% of the original information has been swallowed into the algorithms, and only 20% more has been added amongst the padding. But if the software is any cop and you allow it sufficient CPU cycles, and compress the output with a good encoder in HQ mode and as much bandwidth as you can afford, the result *should* be inferior only to the original being played on a multiregion deck connected to a PAL compatible TV after being also posted across the sea.

    And in fact, given that your conversion method seems to be to take whatever the 50p input is (from HD I guess?), resize it to PAL then blindly decimate the frames down to 25p, then doing the above but starting out with the original source would arguably give better results not only compared to converting from the final PAL DVD version, but also that version itself. Maybe in fact if you skip the "interpolate to 300p" step (...with the resize staying the same as that's what you already do) and the audio reprocess but keep the re-interlace step (which might need a little bit of filtering? I'm not sure... there might be specific re-interlace plugins out there which do a better-looking job than simply picking each other line (or doing a 50%-height resample of some kind), starting from 0 on even frames, and from 1 on the odds. If being shown on a traditional TV, or a modern one (or PC) with a proper deinterlacing engine, and the original footage was actually high-motion rather than simply 25p redundantly encoded as 50p for some reason, it should look better that way (no guarantees!).

    If shown through a computer or HDTV that does a poor job of handling interlaced material, it might instead look completely gash, with combing all over the place and jerky motion additionally coloured with inter-frame blending due to the comb effects, so a straight decimate would actually look better, but that's more because of the poor quality of the playback engine rather than anything inherent to the video itself. Given that DVD can't store full 50p whilst remaining standards compliant, the choice has to be between jerkier but guaranteed-clarity 25p (which is used for film after all), or best-compromise 50i, which has 25p clarity for still or low-motion parts and 50p smoothness (but only half the spatial resolution) with fast motion.

    Given how cheap and easy and rapid it is to do so these days, I'd suggest a middle way of making a DVD copy as 50i (or 59.94i), but, if it is to be played on a PC or an HDTV, simply producing a 50p (...or, if you really must, 59.94p after motion-interpolating) version off the bat. Either at SD rez should that be a curious requirement (or maybe ED, e.g. 1024x576 for 16:9, and cropping off any additional letterboxing that's present for the entire length), or just taking the presumably huge and maybe weirdly-shaped original and re-encoding it with an offline, 2-pass encoder that can do a far better job than the realtime one in the camera in order to cut down the bitrate without losing any perceptible quality (...and it might also be possible to reduce, say, to 1440x810 if it's a 2/3rds full HD source, without losing a particular amount of quality with a touch of sharpening in the vertical direction, which might actually be the same ultimate rez if the camera deliberately smoothed between the lines to prevent spatial artefacting... and either crop from there, or just resize in the first place down to 1280x720?). There's a very real possibility that the HD, MPEG4 version, at original size or one of those square-pixel options, may occupy the same or less space than the MPEG2 SD one. And could even be dropped on a DVDR as a DVD-ROM file to be played back by an MPEG4 compatible, HD-ready device if the main requirement is "is delivered on an optical disc".

    Bear in mind in both the PAL > NTSC and 1440x1080 > 1440x810 cases (and indeed the 1440x810 > 1280x720 case if the vertical cropping is slightly asymmetrical so as to still start on a macroblock boundary) the only actual resizing, and hopefully, with an encoder set to the same CQ quantiser and using the same tables with no needlessly harsh limits on average or instantaneous bitrate, main "actual" re-encoding is in the vertical domain. Except for what smaller effects the interpolating has on 5 out of every 6 original / 4 out of every 5 final lines, the horizontal waveforms and thus DCTs should stay largely the same and so not suffer any signficant generational loss. There could be SOME loss of detail and/or bitrate bloat there, if the original was itself compressed fairly hard and quantised quite coarsely as a result, as any subtle changes will be flattened into non-events unless allocated additional bandwidth, and of course there won't be a 16.7% (or 33.3...) bandwidth saving vertically as there's almost as much waveform data there as before (only losing the (very) highest frequencies) and the actual encoding in that direction will turn out much different, only bearing some passing resemblance every few macroblock rows, but the patterning should still only suffer slight corruption unless, again, the bitrate is quite low and it gets forcibly quantised to match one of the more basic waveforms without having any refinement on top.

    MPEG's digital noise is fairly predictable so long as you have enough bits to throw at the encoder, and if your input data has already been at least partly moulded to fit its multi-pass cosine cancellation process, the delta left over after applying a carbon copy of the original components off each macroblock isn't that big (but admittedly does vary, sinusoidally, as you move from line to line)

    PS. There might also be some issues with colour encoding between the two standards, but I think that's just down to my head spinning a little from having read far too much about VHS and MPG and colour decimation standards and techniques and both analogue and digital video of late.
    Last edited by EddyH; 20th Mar 2017 at 12:17.
    -= She sez there's ants in the carpet, dirty little monsters! =-
    Back after a long time away, mainly because I now need to start making up vidcapped DVDRs for work and I haven't a clue where to start any more!
    Quote Quote  
  18. Member
    Join Date
    Aug 2002
    Location
    South Florida
    Search Comp PM
    Use ISO Buster.
    Quote Quote  



Similar Threads