Is there any good way to IVTC h.264 video in FFmpeg?

[Sharc]

Originally Posted by MaximRecoil

Thanks. I don't need to specify any parameters for the telecine filter?

Not for standard 2:3 telecine. The defaults should be fine.

Why not? DVDs are effectively the same resolution (the player resizes a DVD video from 720x480 to 640x480 due to the 4:3 DAR) and they are all telecined when they are film-source.

It's up to you of course. I thought the original resolution of your source was 1920x1080 (as stored) from a Blu-ray, and you might want to preserve as many details as possible, e.g. for playback with a future better TV with a bigger monitor. Whatever.

[MaximRecoil]

Originally Posted by Sharc

Not for standard 2:3 telecine. The defaults should be fine.

Okay. I tried it and looking at individual frames in VirtualDub, it looks like it was successful. I haven't watched it on my TV yet though. One thing that's weird is that MediaInfo identifies it as progressive, while it identifies the original video as interleaved fields, top field first:

It's up to you of course. I thought the original resolution of your source was 1920x1080 (as stored) from a Blu-ray, and you might want to preserve as many details as possible, e.g. for playback with a future better TV with a bigger monitor. Whatever.

No, this is exactly the type of TV that I want to watch old TV shows on, and it always will be. I watch movies on my HD projector on a 100" screen, because theatrical movies were intended to be seen projected onto a screen, but old TV shows were intended to be seen on a 15 kHz TV, which is how I and everyone else saw them when they originally aired. I have the Blu-rays themselves if I ever want to watch them in HD.

Edit: What exactly do you mean by a 15kHz TV?

Standard definition TVs, the kind that everyone had from the beginning of the TV era until about the 2000s, can only sync to a horizontal scan rate of ~15 kHz (it's about 15.7 kHz, but it's commonly stated as 15 kHz). An NTSC signal has 480 visible lines, interlaced, and has a ~60 Hz refresh rate, which works out to a ~15 kHz horizontal scan rate. A PAL signal has 576 visible lines, interlaced, and a 50 Hz refresh rate, which also works out to ~15 kHz. A signal from an old video game console, such as SNES, NES, Atari 2600, etc., has ~240 visible lines, progressive, and a ~60 Hz refresh rate, which also works out to ~15 kHz. So a standard resolution TV can sync to either a ~480i or ~240p signal at ~60 Hz.

For 480p at 60 Hz you need a ~31 kHz TV/monitor, which is commonly commonly called "VGA" (though that's not an entirely accurate usage of the term VGA). Prior to DVD, there was no mainstream home video format that could even generate a 480p signal, and TV broadcasts were all 480i (in NTSC territory), so there was no need for TVs to be anything higher than 15 kHz. However, with film-source DVDs that are soft-telecined, combined with a DVD player capable of "progressive scan," you can get a 31 kHz signal out of them, so starting in the late 1990s some ~31 kHz CRT TVs (all of which had component [YPbPr] inputs, because composite and S-video are ~15 kHz standards) started appearing in stores, and eventually there were even some 16:9 CRT TVs that could sync to 720p / 1080i.

There's an article about it here, though it's not very detailed:

https://en.wikipedia.org/wiki/Horizontal_scan_rate

[poisondeathray]

Originally Posted by MaximRecoil

Why not? DVDs are effectively the same resolution (the player resizes a DVD video from 720x480 to 640x480 due to the 4:3 DAR) and they are all telecined when they are film-source. Like I said in my previous post, DVDs and untouched DVD rips look great on my setup, hardly any noticeable interlacing artifacts.

But why would you want to add hard telecine after inversing the telecine ? You're adding 25% more field repeats for nothing. It's less efficient. You're encoding MBAFF instead of native progressive. Again less efficient. You risk playback problems on devices that cannont IVTC properly (get deinterlaced instead, reducing the effective resolution in 1/2) . It's all negatives, zero positives

One thing that's weird is that MediaInfo identifies it as progressive, while it identifies the original video as interleaved fields, top field first:

You didn't include the MBAFF encoding or field order . Try -x264opts tff=1 for top field first

Another more efficient option is soft telecine flags (analogous to mpeg2 DVD soft telecine, progressive encoding @23.976p , 25% fewer fields encoded, repeat field flags output 29.97i signal ), but not all players will handle AVC soft telecine correctly. I do not think it's implemented in ffmpeg libx264. For x264cli it's --pulldown 32 --fake-interlaced

[MaximRecoil]

Originally Posted by poisondeathray

But why would you want to add hard telecine after inversing the telecine ? You're adding 25% more field repeats for nothing. It's less efficient. You're encoding MBAFF instead of native progressive. Again less efficient. You risk playback problems on devices that cannont IVTC properly (get deinterlaced instead, reducing the effective resolution in 1/2) . It's all negatives, zero positives

I said why I want to do it in my post, i.e., film-source DVDs and untouched DVD rips look better (barely noticeable interlacing artifacts) on my setup than IVTC'd film-source AVC files do (prominent interlacing artifacts from the player interlacing it on the fly, which it has to do in order to generate a valid 480i video signal from 23.976 FPS progressive video). Here's the MediaInfo for one of many untouched film-source DVD rips that look great on my setup:



However, the test was a failure, because it resulted in blatant juddery motion when the camera was panning. So either FFmpeg's telecine filter doesn't work properly, at least not with the defaults, or my Blu-ray player doesn't handle telecined AVC content properly like it does telecined MPEG-2 content. Maybe the only way to get them to look as good as a DVD is to encode them as DVD compliant files, but that would make them quite a bit bigger than AVC for comparable quality, and I know virtually nothing about MPEG-2 encoding. From what little I do know, it seems that getting good results is a lot more cryptic than with more modern codecs.

You didn't include the MBAFF encoding or field order . Try -x264opts tff=1 for top field first

Another more efficient option is soft telecine flags (analogous to mpeg2 DVD soft telecine, progressive encoding @23.976p , 25% fewer fields encoded, repeat field flags output 29.97i signal ), but not all players will handle AVC soft telecine correctly. I do not think it's implemented in ffmpeg libx264. For x264cli it's --pulldown 32 --fake-interlaced

I could give that a try but I'd be surprised if my Blu-ray player would pay any attention to telecine flags in an AVC stream.

[Sharc]

Originally Posted by MaximRecoil

One thing that's weird is that MediaInfo identifies it as progressive, while it identifies the original video as interleaved fields, top field first

Yes, my bad. Here the modified commandline:

ffmpeg -i input.mkv -vf "fieldmatch,yadif=deint=interlaced,decimate,crop=1440:1080,scale=640x480:flags=lanczos,telecine" -c:v libx264 -x264opts crf=18:tff=1 -c:a copy output.mp4

[poisondeathray]

BD players should accept SD AVC soft telecine, if they are authored with a compliant tool. But the same player might fail if file is played back as a non authored in MP4 or MKV. 640x480 is not BD compliant either - you'd have to go strict 720x480 and use BD compliant settings

[MaximRecoil]

Originally Posted by Sharc

Yes, my bad. Here the modified commandline:

Thanks.

Originally Posted by poisondeathray

BD players should accept SD AVC soft telecine, if they are authored with a compliant tool. But the same player might fail if file is played back as a non authored in MP4 or MKV. 640x480 is not BD compliant either - you'd have to go strict 720x480 and use BD compliant settings

I just tried one of the original hard-telecined BDs in my player, and it has slightly juddery motion when panning; not nearly as juddery as the hard-telecined test file I just encoded, but not judder-free like my IVTC'd encodes. I guess my player just doesn't care much for hard-telecined AVC streams.

As for using x264cli to soft-telecine, is it even possible to IVTC with it? According to its --help readout, the only available filters are crop, resize, and select_every. If it can't IVTC, can it soft-telecine already-IVTC'd video without re-encoding?

[poisondeathray]

You can pipe ffmpeg to x264, or use avisynth to x264 , or vapoursynth to x264 . The x264 part is just for encoding and soft telecine

x264 does not have an ivtc filtering patch (at least I'm not aware of any, there might be some custom builds somewhere), and x264 cannot add soft telecine flags to an existing stream without re-encoding. There is DGAVCPulldown for an existing progressive stream (similar to DGPulldown for MPEG2) , but there some limitations

DGAVCPulldown adds 3:2 field pulldown to AVC elementary streams. Due to the insane
idea of negative POCs in AVC, a two-pass algorithm is used to avoid having to do
lookahead. On the first pass through the source elementary stream, analysis is
performed. On the second pass, the pulled-down output stream is written.

Source code is provided under GPL. It's quite messy but is provided as is in case it
may help others trying to parse AVC video. Portions of the code are derived from the
public domain JM reference software, and the JM licensing continues to apply to those
portions.

DGAVCPulldown currently works
with the output from the stock x264.exe encoder as well as the NAL-HRD patched version
of x264.exe. It will work with any AVC elementary stream with the following limitations:

1. The stream must have VUI timing info specifying 23.976 fps.

2. The stream must not already be specifying picture_structure.

3. If HRD info is present, picture timing SEIs (without picture_structure) must also
be present.

Limitations 2 and 3 can potentially be removed, but I will need stream samples to
implement those changes, so if you run into limitation 2 or 3, please contact me.
You can find my email address here:

[MaximRecoil]

Originally Posted by poisondeathray

You can pipe ffmpeg to x264

I'd like to try that but I don't know how it's done, i.e., I don't know how to tell FFmpeg to pipe to x264, nor how to tell it where to find the x264.exe file.

Can you give me an example script, assuming I have x264.exe in the same folder as FFmpeg.exe?

[poisondeathray]

Originally Posted by MaximRecoil

I'd like to try that but I don't know how it's done, i.e., I don't know how to tell FFmpeg to pipe to x264, nor how to tell it where to find the x264.exe file.

Can you give me an example script, assuming I have x264.exe in the same folder as FFmpeg.exe?

It would look like this

ffmpeg -i input.ext <options> -an -f yuv4mpegpipe - | x264 --demuxer y4m - <options> -o output.264

The only way AVC soft pulldown worked properly for my panasonic and sony BD players, was using BD compliant settings, and proper muxing/authoring in a transport stream. The exact same file in muxed to a MKV container did not play properly. The exact same file muxed with tsmuxer did not player properly. Some people have players that are robust and play everything properly. YMMV

https://sites.google.com/site/x264bluray/home/480p-ntsc

I just tried one of the original hard-telecined BDs in my player, and it has slightly juddery motion when panning; not nearly as juddery as the hard-telecined test file I just encoded, but not judder-free like my IVTC'd encodes. I guess my player just doesn't care much for hard-telecined AVC streams.

If you're watching on a 60Hz display, you're always going to get some judder, even your IVTC'ed encodes. It's impossible not to.

There can be other reasons for more than normal motion problems. Certain BD players can be finicky, and certain encoding settings can affect playback. If you encode with BD compliant settings, proper VBV buffer settings, you can at least eliminate those other reasons

[Sharc]

Originally Posted by MaximRecoil

I just tried one of the original hard-telecined BDs in my player, and it has slightly juddery motion when panning; not nearly as juddery as the hard-telecined test file I just encoded, but not judder-free like my IVTC'd encodes. I guess my player just doesn't care much for hard-telecined AVC streams.

I understand that your original hard-telecined BD was 1920x1080 in an .m2ts container, right?
How does your re-encoded and re-telecined file play in an .m2ts container? Same judder? Maybe your player just bobs the re-telecined .mkv.

[MaximRecoil]

Originally Posted by poisondeathray

It would look like this

Thanks.

The only way AVC soft pulldown worked properly for my panasonic and sony BD players, was using BD compliant settings, and proper muxing/authoring in a transport stream. The exact same file in muxed to a MKV container did not play properly. The exact same file muxed with tsmuxer did not player properly. Some people have players that are robust and play everything properly. YMMV

https://sites.google.com/site/x264bluray/home/480p-ntsc

If tsMuxer doesn't work, then I don't know what else to use.

And why does that site you linked to say to use SAR 10/11 for 4:3? 10/11 is for 704x480 picture content pillar-boxed to 720x480. It results in a 1.363:1 DAR, with the 704x480 picture content ending up as 1.33:1 (4:3). I was already doing that before, which you can see in the script I posted in post #7, because it compensates a little bit for overscan (I later decided to just do 640x480 because 720x480 gets automatically resized to that by the player anyway but it ends up being a bigger file size for no picture quality benefit), but if your picture content is the full 720x480 then you want SAR 8:9, because 720x480 = 1.5:1, and 1.5 × 8/9 = 1.33.

If I remember right, DVDs are commonly encoded both ways. Does BD only allow 10/11 for 4:3 720x480 video?

If you're watching on a 60Hz display, you're always going to get some judder, even your IVTC'ed encodes. It's impossible not to.

There's no judder with the IVTC'd files, nor with film-source DVDs, beyond what's inherent to telecined video on a normal TV (which everyone who grew up in NTSC land watching analog broadcast TV and VHS tapes is used to anyway). The judder I'm talking about goes way beyond that. On a scale of 1 to 10, with 1 being the normal inherent (and very minor) judder, the original hard-telecined BD was about a 3, and the test file that I telecined with FFmpeg's telecine filter was a 10.

[Sharc]

Originally Posted by MaximRecoil

....Does BD only allow 10/11 for 4:3 720x480 video?

Yes, as per BD specs.

[poisondeathray]

Yes, for SD BD, only those values are allowed according to the BD spec . Strict authoring tools will reject it otherwise , strict BD players will not play it

I used scenarist BD . The only free tool that worked was DVD Logic Easy BD Lite; not sure if it's available anymore. There should be some old versions archived on the videohelp site if it's not available anymore. I haven't done this for 5-6 years, it might be that newer BD players are less strict - they might accept tsmuxer muxed files (tsmuxer has been opensourced with some new development, so it might work now - it's worth a try)

[MaximRecoil]

Originally Posted by Sharc

I understand that your original hard-telecined BD was 1920x1080 in an .m2ts container, right?

I tried it in both an .m2ts container (I used tsMuxerGUI to do that) and the MKV container that MakeMKV originally put them in. It looked exactly the same both ways, including the same amount of judder. I can't try the actual discs in that BD player because its disc drive is screwed up, so I can only play files from a USB drive on it. The only working BD drive I have is the one in my PC.

How does your re-encoded and re-telecined file play in an .m2ts container? Same judder? Maybe your player just bobs the re-telecined .mkv.

For some reason, tsMuxerGUI won't open it. It just gives me this very informative error message:



So I used FFmpeg to put it into an .m2ts container, and there's no judder, which is very surprising because even the original 1080i hard-telecined file has some judder, though I haven't tried it with an FFmpeg-produced .m2ts container yet, just a tsMuxer-produced one.

I'm watching it now; I have to wait until some of the interlacing artifact scenes come along to see whether or not it's an improvement over my IVTC'd encodes. I'm already seeing the same prominent moire effect on one of the actors' pinstriped shirt collar, so there's no improvement in that area.

[Sharc]

Originally Posted by MaximRecoil

For some reason, tsMuxerGUI won't open it. It just gives me this very informative error message:



So I used FFmpeg to put it into an .m2ts container, and there's no judder, which is very surprising because even the original 1080i hard-telecined file has some judder, ....

Strange. I have no problem in opening re-telecined 640x480 .mkv or .mp4 test clips (produced with the ffmpeg commandline) in tsMuxerGUI.
Maybe you upload a few seconds of your re-encoded and re-telecined juddery clip so someone might take a look just to check if there is something suspicious with the file .....

Edit:
There is also the faint possibility that there is an issue with the ffmpeg source filter for your telecined source. Maybe you try the same process in avisynth using LWLibavVideoSource as source filter, and compare the results.

[MaximRecoil]

Originally Posted by Sharc

Strange. I have no problem in opening re-telecined 640x480 .mkv or .mp4 test clips (produced with the ffmpeg commandline) in tsMuxerGUI.
Maybe you upload a few seconds of your re-encoded and re-telecined juddery clip so someone might take a look just to check if there is something suspicious with the file .....

I just cut out a 10-second clip to upload, using Avidemux direct stream copy, into an MP4 container (the same as the original file is in), but the 10-second clip opens fine in tsMuxerGUI. Then I remuxed the entire original file into an MKV container using MKVToolNixGUI, and it opened fine in tsMuxerGUI too.

Then I tried the 10-second MP4 and the full MKV remux in my BD player, and the 10-second MP4 was juddery but the MKV was not. Then I tried the 10-second MP4 again, and no judder this time. I stopped and played it several more times; still no judder. So it seems that the container type doesn't actually matter, but rather, something is sometimes confusing the BD player; maybe it's because I didn't have "-x264opts crf=18:tff=1" in the script when I encoded it?

It doesn't really matter though because I'm not keeping it. I watched enough of it to see that it looks exactly the same as my plain IVTC'd encodes, including the prominent moire and slanted line interlacing artifacts in certain scenes, so hard telecining is pointless in this case, since it makes the file size bigger and doesn't improve anything.

I haven't tried soft-telecining yet, but I plan to.

[Sharc]

Originally Posted by MaximRecoil

I just cut out a 10-second clip to upload, using Avidemux direct stream copy, into an MP4 container (the same as the original file is in), but the 10-second clip opens fine in tsMuxerGUI. Then I remuxed the entire original file into an MKV container using MKVToolNixGUI, and it opened fine in tsMuxerGUI too.

Then I tried the 10-second MP4 and the full MKV remux in my BD player, and the 10-second MP4 was juddery but the MKV was not. Then I tried the 10-second MP4 again, and no judder this time. I stopped and played it several more times; still no judder. So it seems that the container type doesn't actually matter, but rather, something is sometimes confusing the BD player; maybe it's because I didn't have "-x264opts crf=18:tff=1" in the script when I encoded it?

That's the longer the more mysterious. Try this commandline:

ffmpeg -r 29.97 -i "your telecined.mkv" -vf "fieldmatch,yadif=deint=interlaced,decimate,crop=1440:1080,scale=640x480:flags=lanczos,telecine=pattern=23:first_field=top" -c:v libx264 -flags +ilme+ildct -x264opts crf=18:tff=1 -c:a copy output.mkv

You may also want to try the so called "advanced" 2:3:3:2 telecine pattern which gives 4 progressive and 1 combed frame. Maybe it irritates your player less, although it has a slightly higher judder than standard 2:3

ffmpeg -r 29.97 -i "your telecined.mkv" -vf "fieldmatch,yadif=deint=interlaced,decimate,crop=1440:1080,scale=640x480:flags=lanczos,telecine=pattern=2332:first_field=top" -c:v libx264 -flags +ilme+ildct -x264opts crf=18:tff=1 -c:a copy output.mkv

It doesn't really matter though because I'm not keeping it. I watched enough of it to see that it looks exactly the same as my plain IVTC'd encodes, including the prominent moire and slanted line interlacing artifacts in certain scenes, so hard telecining is pointless in this case, since it makes the file size bigger and doesn't improve anything.

But you can't watch your IVTCed variant with your legacy "15kHz NTSC TV".

[MaximRecoil]

Originally Posted by Sharc

But you can't watch your IVTCed variant with your legacy "15kHz NTSC TV".

There seems to be a misunderstanding here. I can watch them on my TV because my BD player can convert any video that it's capable of playing into an analog 15 kHz / 480i video signal, which it can output via its composite (CVSB), S-video, or component (YPbPr) jacks.

If a player is playing a progressive video like my plain IVTC'd encodes, then it has to add its own interlacing on the fly in order to generate a 480i signal, but if it's playing video that's already interlaced, it doesn't have to add its own interlacing.

I noticed that untouched DVD rips, which are inherently interlaced (either with hard or soft telecining in the case of film-source ones), look almost like progressive video on my setup. There are visible interlacing artifacts, but they aren't very noticeable unless you're looking for them.

On the other hand, my IVTC'd encodes have more prominent interlacing artifacts on my setup (but not to the point of being unwatchable). So my theory was that if I telecined them, maybe it would make them look like a DVD (less prominent interlacing artifacts). But it didn't work, i.e., once I got my re-telecined test encode to play without judder, it looked exactly the same as my plain IVTC'd encodes do, rather than looking like a DVD like I'd hoped. So I'm out of ideas. I guess my BD player is just better at dealing with DVDs than with AVC files when it comes to interlacing.

Out of curiosity I just tried one of my plain IVTC'd encodes in a different hardware player, a WD TV Live that I used before I got the BD player. It did a great job in terms of generating the on-the-fly interlacing; hardly any moire effect on that actor's pinstriped shirt collar (as opposed to tons of moire there with my BD player) and very little noticeable interlacing artifacts in general, like with a DVD on my BD player.

It has its own problems though, which is why I ditched it in favor of the BD player: dull colors, a few seconds of lag whenever you press a button on the remote control, and it loves to corrupt USB drives that are formatted NTFS (it doesn't corrupt FAT32 drives, but FAT32 has a 4 GB file size limit). It works fine with NTFS drives, but when I plug them into my PC afterwards, Windows always has to repair them.

On the other hand, my Sony BD player produces vibrant colors, instantly responds to the remote control, and never corrupts USB drives, regardless of the file system. Its problems include janky interlacing when it comes to AVC files, supports fewer file types than the WD TV Live, has too much overscan, and unlike the WD TV Live, it has no option to adjust the raster size and position.

Before the WD TV Live I had a Philips DVD player, one of the first DVD players that could play Divx/Xvid files. It had vibrant colors, no problems with interlacing, and no remote control lag, but I don't want to go back to Xvid and burning files to a CD/DVD (it didn't have a USB port).

[Sharc]

Well yes, the fundamental differences as I see it are:

- The 4:3 NTSC DVD film content is hard- or soft telecined mpeg2, 29.97fps. The frame size is 720x480, non-square pixel. A standard format.
- Your IVTC'd, re-sized, re-encoded and re-telecined files are AVC (x264 encoded), hard telecined, 29.97fps. The frame size is 640x480, 4:3, square pixel. A custom format.

I don't know where the culprit is and how your players handle custom formats.