Simple process for interlaced H.264 encoding

[huykin]

I want to encode a bunch of old standard-definition NTSC DV home videos to H.264, to reduce the size and make them playable on hardware players and TVs that support H.264. I would like to have minimal perceived quality loss, and keep video interlaced. Also I am looking for a simple GUI-based process, with no (or minimal) Avisynth scripts or command-line parameters, and free software is preferred. Any suggestions would be greatly appreciated. Thank you

[_Al_]

download, install Cedocida DV codec ,

Avisynth you already have

it works on DRAG & DROP base, so NO script knowledge needed, you select DV files or just one DV file and dropping it on appropriate BAT file it will encode what you want

all is inside, batch join DV, encoding progressive 60p mp4, interlace 60i mp4, making DVD automatically (choosing method - CQ 1pass or 2pass VBR CQ and bitrates depending on length of that DVavi) or just getting m2v and AC3 for some more sophisticated DVD authoring software that allows menu

EDIT: I forgot to update my old HC.ini file, I updated new DV avi helper2.zip file, but for those who downloaded that DV avi helper.zip already and want to make DVD, you just put in HC.ini file (inside HcEncoder folder) this:

*MAXBITRATE       8500
*PROFILE          best
*AUTOGOP          15
*DC_PREC          10
*PREVIEW
*INTRAVLC         2
*MATRIX           mpeg
*PRIORITY         normal
*WAIT             0

[jagabo]

Handbrake doesn't support interlaced h.264 encoding directly but if you use the x264 encoder you can enter bff in the extra options box the encoder will run in interlaced mode.

[MaverickTse]

This issue came across when I was asked a similar question 2 weeks ago...
When someone want to take advantage of the higher fps of interlaced video to reduce judder when converting 60fps video to 30fps.

What I found is that x264 implements "fake interlacing", i.e. the video looks progressive anyway *IF the source is progressive*. (using the -tff/bff and -pulldown options)
To achieve "hard pull-down" out of progressive video, i.e. with those stripes in the absence of deinterlacer, either Avisynth is needed or used DGPulldown(for MPEG2)

Otherwise, -tff/bff will be sufficient to "keep" interlacing

[_Al_]

NTSC DV is 60i aka 30i or to be precise 29.970i. Not sure how fake interlace would help here. If op wants interlace, so he can simply encode video as interlace to get 29.970i again.

[hello_hello]

This issue came across when I was asked a similar question 2 weeks ago...
When someone want to take advantage of the higher fps of interlaced video to reduce judder when converting 60fps video to 30fps.

What I found is that x264 implements "fake interlacing", i.e. the video looks progressive anyway. (using the -tff/bff and -pulldown options)

The tff/bff options are for encoding video which is interlaced. There's nothing "fake" about it.
http://mewiki.project357.com/wiki/X264_Settings#tff

Pulldown applies soft telecine.
http://mewiki.project357.com/wiki/X264_Settings#pulldown

There is a fake interlaced setting, but it's not for encoding interlaced video.
http://mewiki.project357.com/wiki/X264_Settings#fake-interlaced

[MaverickTse]

This issue came across when I was asked a similar question 2 weeks ago...
When someone want to take advantage of the higher fps of interlaced video to reduce judder when converting 60fps video to 30fps.

What I found is that x264 implements "fake interlacing", i.e. the video looks progressive anyway. (using the -tff/bff and -pulldown options)

The tff/bff options are for encoding video which is interlaced. There's nothing "fake" about it.
http://mewiki.project357.com/wiki/X264_Settings#tff

Pulldown applies soft telecine.
http://mewiki.project357.com/wiki/X264_Settings#pulldown

There is a fake interlaced setting, but it's not for encoding interlaced video.
http://mewiki.project357.com/wiki/X264_Settings#fake-interlaced

I just want to remind readers that "If the source is progressive, x264 will not make a hard-pulldown out of it".
So, check the source format carefully.
If the source is already interlaced, using -tff/bff will be enough.

[huykin]

I want to send my very late thanks (I know it's been almost 3 years!) to _Al_ for providing a simple yet comprehensive solution above.

I also want to report that VidCoder (based on Handbrake / x264, and which I spotted based on popularity and high rating in the Software section) seems to do the trick, with "bff" typed into the "More Settings" box in VidCoder settings (Video Encoding tab, Encoder Settings set to Basic) - which doesn't seem to be explained in VidCoder or Handbrake help, but I figured out after some googling. I use Constant Quality (CRF) at 17 to minimize quality loss, with Preset (controlling speed / compression efficiency) at Medium, leaving the rest of VidCoder settings (including audio) at the default values. Anybody sees any flaws in using this simple approach with VidCoder instead of other software or multiple programs - for the original task discussed above of converting old DV videos to H.264 while keeping them interlaced?

Thank you

[jagabo]

"bff" isn't explained in the VidCoder docs because it's not a VidCoder setting, it's an x264 setting.

Be careful, Handbrake (used by VidCoder) may not handle the interlaced chroma channels correctly when encoding interlaced. So you may get blurred colors during high motion shots.

[huykin]

Thanks, jagabo. Any suggestions on how to avoid that issue with blurred colors in interlaced H.264? For example, I am happy to try another front end for x264, another H.264 encoder not based on x264, or add an Avisynth script, if that is likely to produce better quality interlaced H.264.

[jagabo]

If you're using AviSynth why not just use the x264 cli encoder? It's actually easier to use than any GUI once you're set up. You can just drag/drop the AVS script into the batch file.

start /b /low "C:\Program Files\x264\x264.exe" --preset=slow --crf=18 --bff --output %1.mkv %1
@pause >nul

Change the path to x264.exe if it's in a different place on your system. That will run x264 at low priority so you'll barely notice it's running. The Pause keeps the window open in case of an error -- so you'll be able to see the error message. Mux the audio later.

[ron spencer]

I thought x264 only used MBAFF for interlaced...

[huykin]

Thank you, jagabo. AviSynth is not really in my comfort zone, more like a last resort, so would prefer to stay with GUI and combined video/audio encoding, unless there would be a material quality improvement for interlaced H.264 from doing it the other way. Do you think other x264 GUI front-ends would also have the color blurring issue for interlaced H.264 that you mentioned for Handbrake?

An aside question, is changing from medium to slow preset going to produce practically the same perceived quality, but squeeze the file size / bitrate a bit more by spending more time to improve encoding efficiency?

ron spencer: I am certainly not an expert, but google told me that MBAFF is a way of encoding interlaced (used by x264 and many other encoders), and is actually more efficient than PAFF, with the only potential downsides of lower compatibility and slower encoding. I tested interlaced encodes done with VidCoder (x264) on a couple of devices including my Sony BDP-S5100 player, and they seem to play fine. And I didn't even notice any slowdown from interlaced encoding, plus that wouldn't be a big deal for me anyway. Do you have in mind a particular issue with MBAFF?

Thanks

[JVRaines]

Why not do a test and see if VidCoder actually blurs your colors? That's the best way to banish the spectres that get raised around here: do an experiment.

Running Avisynth through x264 with subsequent audio muxing is a PITA compared to the queuing facilities of VidCoder.

[_Al_]

Running Avisynth through x264 with subsequent audio muxing is a PITA compared to the queuing facilities of VidCoder.

as soon as you start to use command line and batch it really does not matter, you just create three command lines right after each other to get MP4 from 4:3 NTSC DVavi:

rem encoding   AAC
BePipe.exe --script "Import(^input.avs^)" 2>nul | neroAacEnc.exe -lc -cbr 256000 -if - -of "output.m4a"

rem encoding H.264
x264.exe --preset slow --crf 17 --bff --sar 8:9 --tune film --vbv-bufsize 15000 --vbv-maxrate 15000 --output "output.264" "input.avs"

rem muxing  MP4
MP4box.exe -add "output.264":fps=29.970  -add "output.m4a"#audio  -new "output.mp4"

then you just can go on to choose level of automation:
-first replacing input.avs for %1 so you can just drop avisyth script on batch and it will make MP4
-another advanced step is to create avisynth script within batch, so you drop DVavi onto batch script, not avisynth script, adding :

echo Avisource("%~1")  > "input.avs"
echo #whatever filter >> "input.avs"

-another step is to put it all in a loop so lots of DVavi's can be dropped onto batch script and creating batches of MP4's, of course names for MP4's has to be different, using same name as DVavi or something, if %1 is DVavi name then getting %~n1.MP4

:start
if "%~1"=="" goto :eof
rem your script here
shift
goto :start

[jagabo]

Why not do a test and see if VidCoder actually blurs your colors?

Yes, it doesn't happen with all sources. It depends on whether Handbrake has to make a colorspace conversion. For example, from YUY2 to YV12 for a DV source.

[sophisticles]

I thought x264 only used MBAFF for interlaced...

I was just about to post the same thing, you beat me to it. In fact, I have to double check to make sure, I think the AVC spec doesn't allow for interlaced content in the way that people are accustomed to, i.e. like mpeg-2 does, I think AVC only allows for MBAFF.

If i wasn't in between commercials of the AFC title game, I would look into it.

[jagabo]

Yes, x264 always encodes interlaced as MBAFF. So?

[ron spencer]

Yes, x264 always encodes interlaced as MBAFF. So?

So the OP doesn't need to worry about options. It will encode to MBAFF and be done with it.

[ron spencer]

Thank you, jagabo. AviSynth is not really in my comfort zone, more like a last resort, so would prefer to stay with GUI and combined video/audio encoding, unless there would be a material quality improvement for interlaced H.264 from doing it the other way. Do you think other x264 GUI front-ends would also have the color blurring issue for interlaced H.264 that you mentioned for Handbrake?

An aside question, is changing from medium to slow preset going to produce practically the same perceived quality, but squeeze the file size / bitrate a bit more by spending more time to improve encoding efficiency?

ron spencer: I am certainly not an expert, but google told me that MBAFF is a way of encoding interlaced (used by x264 and many other encoders), and is actually more efficient than PAFF, with the only potential downsides of lower compatibility and slower encoding. I tested interlaced encodes done with VidCoder (x264) on a couple of devices including my Sony BDP-S5100 player, and they seem to play fine. And I didn't even notice any slowdown from interlaced encoding, plus that wouldn't be a big deal for me anyway. Do you have in mind a particular issue with MBAFF?

Thanks

I have no issue...and used it before I had a 60p video camera. MBAFF works fine on every machine I have used.

[ron spencer]

Here is an interesting thread

http://forum.doom9.org/showthread.php?t=96598

there are four types of interlacing possible it seems:
1) interlaced (which means that all frames get interlaced)
2) paff: a mix of interlaced and progressive frames
3) mbaff: a mix of interlaced and progressive macroblocks in each frame
4) a mix of interlaced and mbaff frames

But X264 only permits MBAFF

[huykin]

Thanks, everyone. I'll stick with VidCoder for now, while trying to learn more about x264.

_Al_: Can you please briefly explain why you recommend using the following 4 setting "--sar 8:9 --tune film --vbv-bufsize 15000 --vbv-maxrate 15000" in your sample x264 command line for DV->MP4 conversion above?

jagabo: Why would Handbrake or VidCoder have to make a colorspace conversion and mess up colors for a DV source, while a direct use of x264 command line wouldn't have that issue? I thought those converters are basically just GUIs for x264, using it in the background, and we can even see the x264 parameters they use for a particular encode.

Thank you

[jagabo]

jagabo: Why would Handbrake or VidCoder have to make a colorspace conversion and mess up colors for a DV source, while a direct use of x264 command line wouldn't have that issue?

Because NTSC DV decoders typically output YUY2 or RGB and Handbrake has to convert that to YV12 before giving it to x264. It may perform that conversion assuming the frames are progressive rather than interlaced, blending the chroma of the two fields together. If you use AviSynth and the x264 CLI encoder you can control that conversion using ConvertToYV12(interlaced=true).

[_Al_]

Can you please briefly explain why you recommend using the following 4 setting "--sar 8:9 --tune film --vbv-bufsize 15000 --vbv-maxrate 15000" in your sample x264 command line for DV->MP4 conversion above?

--sar 8:9 DV avi is anamorphic video, 4:3 NTSC DVavi is stored within 720x480 but if you put it on computer screen medial player resizes it to 4/3 ratio, 640x480 , 640/480=4/3 , There is a flag within DV stream that media player follow to show proportionally 4:3 on screnn , any resolution but 4:3. So H.264 stream needs similar flag. x264 encoder can place that flag into h.264 stream and media players (hopefully) follow that flag. Outputting on screen 8/9 x 720 =640. 4:3 PAL DV avi has different SAR, NTSC widescreen as well etc, all values take from here
(Storage) aspect ratio x Pixel aspect Ratio = Display aspect ratio
SAR × PAR = DAR
8/9 x 720/480 = 640/480
But if you resize (note, you cannot resize interlace footage, but if having progressive) , if you resize to square pixel resolution, like 640x480, you do not put --sar xxxxx in x264 command line, no need
--tune film keeps noise in there, even better use --tune grain (files get larger), we do not want to smooth out gradients, because of SD resolution , banding is a big enemy and you want to avoid it, these kind of artefacts are very noticable, expecially if setting higer CRF (lower bitrates). It is just how you prefer to encode. You do not have to use it.
--vbv-bufsize 15000 --vbv-maxrate 15000 every x264 encoding should have set buffers, especially CRF, especially if encoding higher resolutions because bitrates (if selecting lower CRF) can really jump up. Cutting peaks is not an offence at all if if reasonable limit is set. For example for HD you'd have something like 35000, 40000 , UHD 100000 max. etc You gotta set limits where bitrates could go to and not above anymore. As I said before, banding is a problem, x264 selects lower bandwiths for those and it is not enough. So you just set CRF one or two step lower and restrain buffers as a precaution as well. Quality for those peaks is always ok anyway, that is not an issue. Heck some Blu-Rays are encoded like that , Martian for example, all bitrates are pushed up with limits set. Source is grainy, so perhaps good idea. If doing that with x264 you'd set CRF quite low and set limits --vbv-bufsize 35000 --vbv-maxrate 35000 or something, it would run up to 40000 but not much higher at all. So similar with SD resolution. Lower CRF values and limit peaks, because video with those peak bitrates look good enough anyway. 15000 is very generous bitrate for SD 4:2:0 video.

But as a precaution, in the future , developers would pay less and less attention to deinterlacing, myself I deinterlace to double frame rate using QTGMC and do not feel sorry at all. (still having DV archives) . Take for example most favorite media player application like Kodi, formerly known as XBMC and there is lots of other version of it now, deinterlacing is quite bad in there etc. Developers have their heads wrapped up in different things, they do not pay attention to deinterlace top notch.

[jagabo]

NTSC DV follows the ITU spec where the inner 704x480 frame holds the 4:3 image, making the SAR 10:11. The full 720x480 frame slightly wider than 4:3. But most computer based players will simply display the full frame as 4:3 DAR.

I don't see any reason to limit SD video bitrates with h.264 unless you have playback restrictions -- like with Blu-ray players that play AVCHD on DVD media.

[_Al_]

Generating internet stream, for example one has a limit 2500 as an example, talking about SD stream, or so, buffers can limit that setting them to about 2000 and with low CRF so banding is eliminated.
The same applies for regular video except peaks are very, very comfortable and it is a good idea to set them if CRF gets very low, SD, VHS, DVavi tends to have banding especially after clean up or even using QTGMC etc, CRF needs to be really low like 16 and lower. At the same time peaks 15000 are more than enough, just making sure bitrates are not wasted unnecessarily. Also it helps to keep 3.1level profile set by x264 (nobody seams to care about today really though), but understand within SD realm it is not that much issue. It will become an issue encoding UHD ad such , I can understand limiting buffers as a precaution more often and more important.