VideoHelp Forum

+ Reply to Thread
Results 1 to 29 of 29
Thread
  1. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    I have few SMPTE lossless AVI SD videos in 10bit and 8bit 4:2:2 720x486 NTSC that needed to be converted to MP4 and at the same time I need to remove 6 horizontal lines from the bottom of the frame to get 720x480 and assign a 4:3 aspect ratio flag or an appropriate APR flag for a 4/3 frame output.
    No de-interlacing or processing needed, Just what's stated above, Is there a cooked commend for ffmpeg that does all those in one pass?

    One more thing, The audio in the video files is 48Khz/24Bit, Will there be a compatibility issue with media players and TV's?
    Last edited by dellsam34; 23rd Feb 2019 at 22:16.
    Quote Quote  
  2. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    I know for video conversion I should use: ffmpeg -i input.avi output.mp4
    I did some online search and found out:
    For the crop: -filter:v "crop=720:480:0:0" I also found: -vf scale=720:480
    For aspect ratio I'm confused, Some talk about PAR some talk about SAR, Maybe -aspect 1.333 works?
    I just want to keep the same resolution 720x480 and just flag it to be displayed as 4:3.

    Anyway here is a sample of the videos I'm trying to work on.
    Last edited by dellsam34; 23rd Feb 2019 at 23:07.
    Quote Quote  
  3. Member
    Join Date
    Aug 2010
    Location
    San Francisco, California
    Search PM
    If you crop you shouldn't need the scale filter. You can use decimals or ratios for the aspect option, e.g. -aspect 4:3.
    Quote Quote  
  4. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Ok I used this commend: ffmpeg -i Ill_Be_Sample.avi -filter:v "crop=720:480:0:0" -aspect 1.333 Ill_Be_Sample.mp4
    It worked very well with one caveat, The audio bitrate is too low, 128kbps is really low, I would like to leave it as PCM but 16/48 instead of 24/48. Here is a sample I converted:

    Ill_Be_Sample.mp4
    Quote Quote  
  5. You can increase AAC audio bitrate via e.g. -b:a 192k . In mp4 lossless audio like PCM won't be supported by many media players, I guess. At least ffmpeg doesn't allow writing it (it does allow PCM and ALAC in mov, though. Also e.g. FLAC and PCM in mkv.)


    https://trac.ffmpeg.org/wiki/Encode/AAC
    Quote Quote  
  6. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    It must be way better than mp3 128Kbps then, Otherwise why would they settle on such low bitrate, Anyway let me give 192Kbps a shot, Now the whole commend is:
    ffmpeg -i Ill_Be_Sample.avi -filter:v "crop=720:480:0:0" -aspect 4:3 -b:a 192k Ill_Be_Sample.mp4
    And it worked!

    Should I be concerned about the chroma sub which is 4:2:2 and not the common 4:2:0 ?
    Quote Quote  
  7. If you care about compatibility: yes.

    -pix_fmt yuv420p
    Quote Quote  
  8. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Thanks Sneaker,
    Ok let me try the sample again with:
    ffmpeg -i Ill_Be_Sample.avi -filter:v "crop=720:480:0:0" -pix_fmt yuv420p -aspect 4:3 -b:a 192k Ill_Be_Sample.mp4

    Well I couldn't see a difference with the naked eye between 4:2:2 and 4:2:0
    Quote Quote  
  9. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    I'm not happy with the video bitrate that FFMPEG produces, 500Kbps to 1.6 Mbps, Is there a way to set better bitrate parameters? 15-20 Mbps will be ideal. I'm compressing from like 10GB to 100MB for the same file that's a lot of damage even though it is slightly visible but it's there.
    Quote Quote  
  10. Member
    Join Date
    Aug 2010
    Location
    San Francisco, California
    Search PM
    Try the crf option. It defaults to 23. Bump it down to 20 and see if you're happy. Around 17 should be visually lossless. I also recommend "slow" for the preset option if you're not in a hurry.
    Quote Quote  
  11. You should also IVTC progressive content , such as your sample, to return the original progressive frames . Then you can encode it progressively.

    Or if you're leaving it interlaced , then encode it interlaced (and flag it as such properly) instead of progressive.

    Otherwise there can be mixups and playback problems



    Also, you should be scaling in an interlaced fashion if keeping it interlaced (when converting 4:2:2 to 4:2:0 you're scaling the chroma channels), but scaling progressively if IVTCing (you probably won't notice here on such low chroma resolution, but it matters, because you will get chroma artifacts) . Right now you're scaling progressively, with interlaced fields, but encoding progressively...




    Well I couldn't see a difference with the naked eye between 4:2:2 and 4:2:0
    You won't see any difference with low chroma resolution. (Another way of saying this is 720x480 4:2:0 , which is 360x240 chroma resolution - already exceeds your chroma resolution of this content.)
    Quote Quote  
  12. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Ok I sorted out the quality problem by adding the CRF option, It goes from 51 to 0, 51 being the worst and 0 being the best.
    ffmpeg -i In.avi -filter:v "crop=720:480:0:0" -pix_fmt yuv420p -crf 0 -aspect 4:3 -b:a 192k Out.mp4

    Poisondeathray, Could you explain in simple words with commend examples what you mean? I tried -pix_fmt yuv420i it gave an error.
    Quote Quote  
  13. Originally Posted by dellsam34 View Post
    Ok I sorted out the quality problem by adding the CRF option, It goes from 51 to 0, 51 being the worst and 0 being the best.
    ffmpeg -i In.avi -filter:v "crop=720:480:0:0" -pix_fmt yuv420p -crf 0 -aspect 4:3 -b:a 192k Out.mp4

    Poisondeathray, Could you explain in simple words with commend examples what you mean? I tried -pix_fmt yuv420i it gave an error.


    Note crf 0 is lossless profile, and will not be compatible with most hardware decoders . Most people are happy with around 16-18 for good quality. A bit lower if you want higher quality . Otherwise, if you use too high bitrates (low crf values), you might need to set VBV restrictions to cap the bitrate for some hardware decoders, or you will get playback problems and stuttering


    For which case ? I'm assuming you want to keep it interlaced, telecined case ? ie. interlaced encoding, field order flagging, interlaced scaling ?

    (IVTC is unreliable in ffmpeg anyways, you'd have to use avisynth or vapoursynth to do it properly)

    for mbaff, BFF encoding with ffmpeg libx264
    -flags +ildct+ilme -x264opts bff=1

    The interlaced scaling flag is -vf scale interl=1 . All operations with -vf scale will be done in an interlaced aware fashion with the flag, that includes colorspace conversions with swscale. So that format=yuv420p means interlaced 422p=>420p because it was preceded by the interl=1 command

    You should explicitly specify the audio and video codecs. ffmpeg defaults to libx264 and aac at this point in time , but before this, it defaulted to mpeg4, and some future date it will not be libx264 anymore, and for audio it used to be mp3. It's just good practice.

    To be complete , you should also enter the colorimetry flags (smpte170m for NTSC)

    To be extra complete, analog capture should usually have a sar of 10:11 ,not 8:9 , because it's based on ITU ratio on the inner 702 width (rounded to 702) . -aspect 4:3 will give a sar of 8:9 based on the full frame . But if you look at the picture , there are pillarbars, that's another clue. So instead of -aspect 4:3, you should explictly set the sar as 10:11


    So it would look like this

    Code:
    ffmpeg -i "input.ext" -vf "crop=w=720:h=480:x=0:y=0,scale=w=-1:h=-1:interl=1,format=yuv420p,setsar=sar=10/11" -flags +ildct+ilme -c:v libx264 -crf 18 -x264opts bff=1:colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m:force-cfr -c:a aac -b:a 192k "output.mp4"




    Most people would IVTC it for better quality/compression. The content is actually progressive (music video), but it's broadcast in an interlaced format to make it compatible with NTSC equipment. For example, movies, film, most music videos are "24p" (23.976p), but they have repeat fields when broadcast to make it an interlaced 29.97 signal. This is telecine. Inverse telecine is "undoing" that process to get back the original progressive frames.

    Most people want the original native progressive frames . Progressive encoding is more efficient in general , motion vectors are better; and encoding interlaced requires you to encode 25% more frames for nothing. So the quality will be lower at a given bitrate with interlace. Also, native progressive will more compatible with things like portable devices. They don't know what to do with interlace. But TV's and BD players shouldn't have an issue with telecine
    Quote Quote  
  14. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Basically I capture in both NTSC and PAL, telecine and non telecine contents in lossless SD 8bit 4:2:2 480i and 576i, I want a generic commend for both (except I don't crop PAL, it comes out right, NTSC comes out 486i), I want a good quality audio and video mp4 yet it is compatible with most modern devices.

    I don't want to tackle progressive and telecine stuff because of my limited knowledge with script type programs. So I just leave the video interlaced and in the original frame rate and flagged for 4:3 aspect ratio I don't want square pixel because it will stretch the frame, I'm ok with the pillars.
    Last edited by dellsam34; 3rd Mar 2019 at 01:10.
    Quote Quote  
  15. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Here is a sample of the commend you provided:

    cartoon.mp4
    Quote Quote  
  16. Originally Posted by dellsam34 View Post
    Basically I capture in both NTSC and PAL, telecine and non telecine contents in lossless SD 8bit 4:2:2 480i and 576i, I want a generic commend for both (except I don't crop PAL, it comes out right, NTSC comes out 486i), I want a good quality audio and video mp4 yet it is compatible with most modern devices.

    I don't want to tackle progressive and telecine stuff because of my limited knowledge with script type programs. So I just leave the video interlaced and in the original frame rate and flagged for 4:3 aspect ratio I don't want square pixel because it will stretch the frame, I'm ok with the pillars.
    Maybe it's a good time to start tackling the progressive and telecine stuff? I would argue if you're going to the extent of capturing losslessly you might as do it correctly all the way through

    You would have to adjust it for PAL (different colorimetery flags, different SAR) . Analog 4:3 PAL would typically use a SAR of 12:11, and "bt470bg" instead of "smpte170m"

    using -aspect 4:3 will be slightly off for most analog captures (both PAL, NTSC) , but most people won't notice the tiny AR error



    Here is a sample of the commend you provided:
    The source wasn't telecined if that was your output. And there are 29.97p sections to that cartoon

    The reason I would try to get things correct, is that you don't want the player , or HW to indavertently mistreat it. For example, it might deinterlace instead of IVTCing film sources . That will destroy the picture quality on playback . When you have progressive content, and it's flagged correctly as progressive, you reduce the chances of things getting messed up , especially with modern portable devices, or if you upload to some website. Just like if you enter the proper flags, it reduces the chance of wrong colors, wrong processing etc... it's "best practices"

    I guess the "safest" would be to leave it interlaced like your doing, but it involves making trade offs
    Quote Quote  
  17. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    How to convert from 4:2:2 to 4:2:0 while staying in interlace mode, Is that what your commend doing? Also how do I know if the content is telecine or not and how to convert it to progressive if it is.

    If I have to do it right as you say then I will need at least four commends, NTSC 29.97i, NTSC 23.976p, PAL 25i and PAL 25p (this is the least needed).
    Last edited by dellsam34; 3rd Mar 2019 at 13:33.
    Quote Quote  
  18. Originally Posted by dellsam34 View Post
    How to convert from 4:2:2 to 4:2:0 while staying in interlace mode,
    Again, the command that deals with interlaced 422=>420 scaling is -vf scale=interl=1,format=yuv420p

    Is that what your commend doing?
    Nope. I would do it this way - only if it were truly interlaced content . Both your samples were progressive

    This is a problematic way of doing it. "1 size fits all" is going to be full of compromises.

    But if you had to choose only 1 way, and the target was TV only, not web or devices, this would have the fewer problems. (The "best" would be doing it properly, flagging it properly)

    Also how do I know if the content is telecine or not and how to convert it to progressive if it is.
    Unfortunately, you have to examine the fields or bobbed frames to look at the patterns . There is no "automatic" way that can do it with any accuracy
    Quote Quote  
  19. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    And what's the commend for converting from 4:2:2 to 4:2:0 if it were truly interlaced such as home videos?
    Quote Quote  
  20. Originally Posted by dellsam34 View Post
    And what's the commend for converting from 4:2:2 to 4:2:0 if it were truly interlaced such as home videos?
    That is the command for interlaced scaling .

    Telecine means you have progressive content, but in an interlaced format with repeat fields. You have to treat is as "interlaced" while it's still telecined, otherwise you will get bad things happen such as chroma errors like notching and ghosting

    But if you remove the pulldown (IVTC), then you have the original progressive frames, then you can do operations (such as scaling) in a progressive fashion

    Bad things can happen when you get the labels wrong. For example , the cartoon was actually progressive. It should have been encoded progressive. Some players, some websites will deinterlace it , thinking it's BFF . This will essentially reduce the resolution in half .
    Quote Quote  
  21. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    What should be modified in the NTSC commend for home videos to do PAL interlaced home videos?
    I will have to read about removing telecine later on and what commends used for that purpose.
    Quote Quote  
  22. Originally Posted by dellsam34 View Post
    What should be modified in the NTSC commend for home videos to do PAL interlaced home videos?
    See post 16. If you're cropping it would be 720x576 frame size, and analog PAL 4:3 SAR would be 12/11, and "bt470bg" instead of "smpte170m" for the colorimetry VUI flags
    Quote Quote  
  23. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Thanks, What is the difference between SAR and DAR, I used 12:11 for NTSC and the picture is slightly stretched horizontally.
    Quote Quote  
  24. I hate to be picky, but when pdr speaks of 10:11 or 12:11 sample-aspect-ratio (SAR), he really means pixel-aspect-ratio (PAR) and 720x486 is the SAR and the display-aspect-ratio (DAR) is the 4:3 image. Thus,

    SAR x PAR = DAR.

    I agree with pdr, I am not sure there is a one-shoe-fits all solution for PAL and NTSC because NTSC video has a 10:11 PAR versus PAL's 12:11. While pdr speaks of 702x480, I think he really means 704x480. Neither 720x486 SAR, 720x480 SAR, or 702x480 SAR are 4:3 DAR. 720 includes 16 pixels of "overscan", and the 4:3 DAR image is supposed to reside "somewhere" within 720. Depending on the capture device, the image could be centered, or not. If the captured image uses all 720 rows, then the image is not technically 4:3 DAR. If you do the math:

    704 / 480 x 10 / 11 = 4 / 3
    704 / 576 x 12 / 11 = 4 / 3

    There is no other way to make 720x480 or 576 4:3 unless you invent your own PAR.

    With all these funny pixel sizes, it is a whole lot easier to just deal with square PAR where the SAR is 640x480 for NTSC and 768x576 for PAL. Whenever, I drag out some legacy NTSC video my workflow typically looks like this:

    1. Crop the overscan to 704x480
    2. Change the PAR from 10:11 to 1:1 by rescaling to 640x480 or 768x576 (so, as you can see, depending on whether you have NTSC or PAL, you are going in two different directions)

    This preserves the 4:3 DAR which can be easily upscaled for display on modern HD/4K displays which are all square pixel devices. Yes, you will have pillarboxes, can't be avoided unless you manually crop the 4:3 image to a 16:9 image, but that require chopping 120 lines off the 480 lines in the image.

    I know you said you don't like scripting languages, but it really is a whole lot easier doing this in an Avisynth script then calling that with ffmpeg, than trying to cram all that into a single ffmpeg command line.
    Quote Quote  
  25. To clarify -

    Basically, the MPEG4 people changed all the names, but they mean the same thing

    In MPEG4 terminology, SAR is the sample aspect ratio , that's why "--sar" is used in the commandlines (and -vf setsar in ffmpeg ) to encode for modern formats. Formerly "SAR" was known as "PAR" or pixel aspect ratio . Both can be thought conceptually as the w:h of pixels .

    There are different names for these, but "FAR" is the best description for the dimensions - the actual width:height of the frame size (e.g. 704:480) - the "frame aspect ratio" (which was formerly know as SAR ... uuugggh I know...these acronyms and names were already taken... but these guys didn't care and just re-wrote everything. In production environments today, everyone tends to use MPEG4 terminology)

    DAR = FAR x SAR




    702 is accurate for NTSC equipment. It's 702 rounded to 704 (the typo said 702 rounded to 702)

    ITU-R BT.601: Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios (aka CCIR 601 aka Rec. 601)
    625/50 systems have a line length of 64 us, of which 52 us is the "active" part that contains actual image information. (The rest is reserved for horizontal blanking.)
    52 us x 13.5 MHz = 702 samples (pixels) per scanline

    Because of various transfer and generational issues - all this might be meaningless for you. The best way is to look at some circular object straight on to determine what your actual AR is
    Quote Quote  
  26. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    For NTSC I crop the extra 6 lines to get 720x480 and for PAL I leave it alone 720x576, But using 8:9 ratio for both gave me a perfect 4:3, I checked it with VLC when I switch from "default" to "4:3" the frame stays intact, I played it on several platforms, Android, iOS, TV, The frame is perfectly 4:3 with black bars on the sides. And yes I have a footage with volume knobs in a close up and they looked perfectly round when checked with a ruler on the screen.

    I really want to dive into the telecine thing, I noticed when playing back TV programs frame by frame I see 4 moving frames and the 5th is just a duplicate, How can the program detects and removes that frame?
    Last edited by dellsam34; 6th Mar 2019 at 21:21. Reason: added details
    Quote Quote  
  27. Originally Posted by dellsam34 View Post
    For NTSC I crop the extra 6 lines to get 720x480 and for PAL I leave it alone 720x576, But using 8:9 ratio for both gave me a perfect 4:3, I checked it with VLC when I switch from "default" to "4:3" the frame stays intact, I played it on several platforms, Android, iOS, TV, The frame is perfectly 4:3 with black bars on the sides. And yes I have a footage with volume knobs in a close up and they looked perfectly round when checked with a ruler on the screen.
    Great. Just goes to show, that all that geeky textbook stuff is meaningless. All that really counts is what you actually have

    I really want to dive into the telecine thing, I noticed when playing back TV programs frame by frame I see 4 moving frames and the 5th is just a duplicate, How can the program detects and removes that frame?
    It would be 1 in 5 decimation . e.g. TDecimate() in avisynth ..... It suggests a 23.976 content. How are you playing it back / which hardware/software ? It might be your playback setup is actually deinterlacing it . That's double bad, because you lose resolution, and you get jerky playback . You would want to field match, then decimate ( TFM() .TDecimate() ). As opposed to deinterlace, then decimate


    (And just FYI, I tried the ffmpeg IVTC on your 1st sample, and there was jerky playback at the beginning - because there were 2 extra frames. And that was an I frame format. ffmpeg can sometimes get mixed up with long gop and open gop issues, so there is no excuse here - that us just another example of how inconsistent and unusable ffmpeg IVTC is . And I'm saying this as a huge ffmpeg fan and almost daily user of ffmpeg)
    Quote Quote  
  28. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Originally Posted by poisondeathray View Post
    Great. Just goes to show, that all that geeky textbook stuff is meaningless. All that really counts is what you actually have

    It would be 1 in 5 decimation . e.g. TDecimate() in avisynth ..... It suggests a 23.976 content. How are you playing it back / which hardware/software ? It might be your playback setup is actually deinterlacing it . That's double bad, because you lose resolution, and you get jerky playback . You would want to field match, then decimate ( TFM() .TDecimate() ). As opposed to deinterlace, then decimate


    (And just FYI, I tried the ffmpeg IVTC on your 1st sample, and there was jerky playback at the beginning - because there were 2 extra frames. And that was an I frame format. ffmpeg can sometimes get mixed up with long gop and open gop issues, so there is no excuse here - that us just another example of how inconsistent and unusable ffmpeg IVTC is . And I'm saying this as a huge ffmpeg fan and almost daily user of ffmpeg)
    Sorry I was wrong, yes the formulas should be as follows as pointed out:
    704 / 480 x 10 / 11 = 4 / 3
    704 / 576 x 12 / 11 = 4 / 3


    As to FFMPEG, Are you suggesting using Avisynth instead? The program I used to playback frame by frame from lossless files is Vdub.
    Last edited by dellsam34; 23rd May 2020 at 04:35. Reason: correction
    Quote Quote  
  29. Originally Posted by dellsam34 View Post

    I've always known NTSC is 720x480 and PAL is 720x576 non square pixel, Never went to school for it though so never had a textbook. It's just a way to avoid cropping to 702 or 704 to keep the square pixel, It worked for all devices so may as well save a step.
    But there are slight variations on the non square AR interpretation . The one you ended up using would be incorrect for 99% of correctly processed (all the way through) sources .

    It would be a pain to check through every single source and measure what the actual AR is...




    As to FFMPEG, Are you suggesting using Avisynth instead? The program I used to playback frame by frame from lossless files is Vdub.
    I am suggesting avisynth for IVTC operations. Very reliable when done properly. You can use avisynth with ffmpeg for example . or avisynth with vdub. Or dozens of other programs

    avisynth doesn't encode. It's just a frameserver, and processing framework.
    Quote Quote  



Similar Threads