Lossless to MP4 Simple FFMPEG Commend.

[dellsam34]

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?

[dellsam34]

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.

[JVRaines]

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.

[dellsam34]

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

[sneaker]

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

[dellsam34]

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 ?

[sneaker]

If you care about compatibility: yes.

-pix_fmt yuv420p

[dellsam34]

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

[dellsam34]

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.

[JVRaines]

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.

[poisondeathray]

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.)

[dellsam34]

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.

[poisondeathray]

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

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

[dellsam34]

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.

[dellsam34]

Here is a sample of the commend you provided:

cartoon.mp4

[poisondeathray]

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

[dellsam34]

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).

[poisondeathray]

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

[dellsam34]

And what's the commend for converting from 4:2:2 to 4:2:0 if it were truly interlaced such as home videos?

[poisondeathray]

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 .

[dellsam34]

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.

[poisondeathray]

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

[dellsam34]

Thanks, What is the difference between SAR and DAR, I used 12:11 for NTSC and the picture is slightly stretched horizontally.

[SameSelf]

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.

[poisondeathray]

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

[dellsam34]

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?

[poisondeathray]

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)

[dellsam34]

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.

[poisondeathray]

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.