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

[MaximRecoil]

Originally Posted by 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.

I get the same results (same prominent interlacing artifacts) when encoding at 720x480, SAR=10/11, like in the script I posted in post #7.
I changed to 640x480, SAR=1/1, because it doesn't make any difference in how it looks, and it results in smaller files at a given CRF value (38,400 less pixels to encode).

I still haven't tried doing a fully BD-compliant encode like poisondeathray talked about. I need to figure out what can be excised from the script in the link he posted,
while still resulting in a BD-compliant encode, because I don't want to do 2-pass, nor use "preset veryslow," and I don't think "tune film" is necessary either.

I tried this...

ffmpeg -i input.mkv -vf "fieldmatch,yadif=deint=interlaced,decimate,scale=704x360:flags=lanczos,pad=720:480:8:60" -an -f yuv4mpegpipe - | x264 --crf 18 --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --pulldown 32 --fake-interlaced --colorprim "smpte170m" --transfer "smpte170m" --colormatrix "smpte170m" --sar 10:11 -o output.264

... but it didn't work. I got this error:

av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument00:00:00.04 bitrate=99452.2kbits/s speed=0.655x
frame= 1 fps=0.0 q=-0.0 Lsize= 506kB time=00:00:00.04 bitrate=99452.2kbits/s speed=0.366x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 109750.421875%
Error closing file pipe:: Invalid argument
Conversion failed!

[poisondeathray]

See post #30

for the x264 arguments you are missing --demuxer y4m -

[MaximRecoil]

Originally Posted by poisondeathray

See post #30

for the x264 arguments you are missing --demuxer y4m -

Thanks, that seems to be working. I had your example from post #30 in front of me when I made the script but somehow that part got lost in the shuffle. I must have accidentally deleted it during the various copy and pasting I was doing from the script at the site you linked to, and from my own previous scripts.

[Sharc]

When using --fake-interlaced you should also include --pic-struct for BD compliance.
I am not sure whether --pic-struct gets inserted by default, but adding it explicitly doesn't do any harm.

In the past (years ago) tsMuxer did not support any of the --pulldown options, but this may have changed with newer releases.

Edit:
The current tsMuxer seems to support pulldown 32, as far as I can tell.

[MaximRecoil]

It was worth a try but it didn't work well. I encoded the video stream using the script that I posted in post #41 (after adding the missing arguments to make it work) and then I compiled it along with the original AC3 audio as a BD using DVDLogic EasyBD Lite 1.1. Then I copied the 00000.m2ts file from the BDMV\STREAM folder to a USB drive and tried it in my BD player. The interlacing artifacts were even worse than with my plain IVTC'd encodes.

There's a scene I've been using for reference where a car pulls into a driveway. There are prominent interlacing artifacts visible on the car's chrome trim. With my plain IVTC'd encodes, once the car and camera stop moving the interlacing artifacts mostly go away, but with this soft-telecined encode I just tried, the interlacing artifacts remain just as prominent when the car and camera are stationary as when they are moving.

Originally Posted by Sharc

When using --fake-interlaced you should also include --pic-struct for BD compliance.
I am not sure whether --pic-struct gets inserted by default, but adding it explicitly doesn't do any harm.

Do you think that would make a difference regarding the interlacing artifacts being worse?

[poisondeathray]

It shouldn't make a difference because --pic-struct is enabled by the --bluray-compat switch for pulldown , but it doesn't hurt as Sharc wrote

Originally Posted by shon3i

bluray compat will enable pic-struct for interlaced, fake-interalced, pulldown, and not for progressive. Because that required by BD specs.

[MaximRecoil]

Originally Posted by poisondeathray

It shouldn't make a difference because --pic-struct is enabled by the --bluray-compat switch for pulldown , but it doesn't hurt as Sharc wrote

Thanks. I guess there's nothing else to try other than making DVD-compliant encodes, but I don't want to do that, not even if I knew the ins and outs of MPEG-2 encoding. If it were just a few files I might look into it, but for over 100 total hours of video, with each file ending up ~three times as big for the same quality, that's too much.

[Sharc]

Originally Posted by MaximRecoil

Thanks. I guess there's nothing else to try other than making DVD-compliant encodes, but I don't want to do that, not even if I knew the ins and outs of MPEG-2 encoding. If it were just a few files I might look into it, but for over 100 total hours of video, with each file ending up ~three times as big for the same quality, that's too much.

You could try once more without --fake-interlaced in the x264 commandline. Does your player react differently then?

I seem not to be able to reproduce your reported judder and/or residual combing issues here, with any of the propsed re-telecining solutions. But of course I don't have your player. I tested on PC and streaming to (modern) TV only.

Are you familiar with Avisynth (or VirtualDub2)? Did you analyze your files (source, IVTC'd, re-telecined variants) by stepping through the fields? Does the fields sequence behave as expected?

[MaximRecoil]

Originally Posted by Sharc

You could try once more without --fake-interlaced in the x264 commandline. Does your player react differently then?

Remove --fake-interlaced and keep --pulldown 32 in there? What would that do? Hard-telecine it?

I seem not to be able to reproduce your reported judder and/or residual combing issues here, with any of the propsed re-telecining solutions. But of course I don't have your player. I tested on PC and streaming to (modern) TV only.

Well, like I mentioned in a previous post, the judder with my re-telecined file turned out to be my BD player sometimes playing it wrong, probably because the script I used to encode it resulted in it being identified as progressive video. Whenever the player randomly decided to play it correctly there was no judder, it looked exactly the same as my plain IVTC'd files.

The prominent interlacing artifacts that all of my encodes have had so far are player-dependent too, so I wouldn't expect anyone to be able to reproduce it unless they have the same BD player that I have (Sony BDP-S480) or one with the same hardware and firmware. As I mentioned, my WD TV Live hardware player doesn't produce the prominent interlacing artifacts when playing my encodes.

Furthermore, even if you had the same BD player that I do, you'd also need a 15 kHz CRT TV, because digital TVs operate completely differently. Even if you had a digital TV that can accept a 15 kHz analog video signal (i.e., one that has a composite input jack as many of them do), the results would still be totally different, because a digital TV has to buffer, process, scale a 480i signal into something it can not only display, but display full screen. On the other hand, an analog video signal directly drives the electron guns in a CRT in real-time, which is why they have no display lag, which is what makes them preferable for playing classic video games, particularly among "speed runners" who rely on a bunch of "frame perfect" tricks to get the fastest times.

Are you familiar with Avisynth (or VirtualDub2)? Did you analyze your files (source, IVTC'd, re-telecined variants) by stepping through the fields? Does the fields sequence behave as expected?

Yes to all three questions. The source and my re-telecined encodes have the same pattern: 3 progressive frames followed by 2 interlaced fields, followed by 3 progressive frames, followed by 2 interlaced fields, and so on. My IVTC'd encodes are all progressive frames, as you'd expect. As for my most recent encode, which I'll refer to as the "fake-interlaced" one, which is also the one that has the worst interlacing artifacts on my BD player / TV, I'm only seeing progressive frames in that one when stepping through it in VirtualDub.

By the way, you can also use the original VirtualDub for that (there's an FFmpeg-based plug-in that allows you to choose "FFmpeg Supported Files" in the "Files of type" drop-down menu in the "Open video file" dialog box). In my experience, it's very stable too, unlike VirtualDub2, which I've had crash on me several times, but VirtualDub2 still has the advantage of being able to encode with modern codecs and containers.

[Sharc]

Originally Posted by MaximRecoil

Remove --fake-interlaced and keep --pulldown 32 in there? What would that do? Hard-telecine it?

It's a flag to fool the player and satisfy the BluRay standard AFAIK. x264 will encode the video as progressive, and MediaInfo will report the stream as progressive but report it in the encoding details as interlaced=fake. The video is still soft-telecined by --pulldown 32. I thought it may have an impact how your playback sceanrio deals with it.

Well, like I mentioned in a previous post, the judder with my re-telecined file turned out to be my BD player sometimes playing it wrong, probably because the script I used to encode it resulted in it being identified as progressive video. Whenever the player randomly decided to play it correctly there was no judder, it looked exactly the same as my plain IVTC'd files.

Strange behavior. Therefore my desperate proposal with enabling/disabling the --fake-interlace (and other interlace specific settings as per previous scripts).

The prominent interlacing artifacts that all of my encodes have had so far are player-dependent too, so I wouldn't expect anyone to be able to reproduce it unless they have the same BD player that I have (Sony BDP-S480) or one with the same hardware and firmware. As I mentioned, my WD TV Live hardware player doesn't produce the prominent interlacing artifacts when playing my encodes.

Furthermore, even if you had the same BD player that I do, you'd also need a 15 kHz CRT TV, ....

Agree.

Yes to all three questions. The source and my re-telecined encodes have the same pattern: 3 progressive frames followed by 2 interlaced fields, followed by 3 progressive frames, followed by 2 interlaced fields, and so on. My IVTC'd encodes are all progressive frames, as you'd expect.

ok, you probably mean ... 3 progressive frames followed by 2 interlaced (combed) frames ...

As for my most recent encode, which I'll refer to as the "fake-interlaced" one, which is also the one that has the worst interlacing artifacts on my BD player / TV, I'm only seeing progressive frames in that one when stepping through it in VirtualDub.

How do you watch or remux the output.264 video file which comes out of the piped commandline? Does the progressive video you see in VirtualDub play at 23.976fps, like the IVTC'd variant? When you watch the frames of the output.264 you will see the 2:3 pattern, similar as for hard-telecine. And the duration of the video remains always the same (which will keep audio and video in sync). So the soft-pulldown seems to work..... at least here.

[MaximRecoil]

Originally Posted by Sharc

ok, you probably mean ... 3 progressive frames followed by 2 interlaced (combed) frames ...

Well, on a PC in VDub or similar, I guess it always shows frames, with the interlaced ones from the telecining process looking like a blend of a progressive frame and a subsequent [combed] field, like this:



When the video is actually playing in a player that can generate an analog 480i / NTSC video signal from the digital video, they all get turned into fields (half of a frame, combed), 59.94 of them per second, and that blend of a field and frame that you always see when stepping through in VDub and similar PC programs never actually happens during proper 480i playback.

The progressive video you see in VirtualDub plays at 29.97fps rather than the IVTC'd variant of 23.976fps, right?

Yes. With the "fake-telecined" one, I manually counted the number of frames in each second just to be sure and there were 30 of them for 1.01 seconds. And like I said, they all displayed as progressive frames.

How do you watch or remux the output.264 video file which comes out of the piped commandline?

Like I said in post #45, I compiled it along with the original AC3 audio as a BD using DVDLogic EasyBD Lite 1.1. Then I copied the 00000.m2ts file from the BDMV\STREAM folder to a USB drive and tried it in my BD player. The interlacing artifacts were even worse than with my plain IVTC'd encodes.

And the duration of the video remains the same (which will keep audio and video in sync). So the soft-pulldown seems to work.

Yes.

By the way, do you know if it's a good idea in general to have...

--colorprim "smpte170m" --transfer "smpte170m" --colormatrix "smpte170m"

... in the script when encoding SD video from an HD source?

I know that BD-compliant full HD videos are BT.709 and BD- or DVD-compliant SD videos are BT.601, and specifying "smpte170m" in the encoding script results in BT.601 according to MediaInfo, but what happens if you don't include that in the script when encoding a BT.709 HD video to SD resolution? MediaInfo doesn't show any information about it in my HD-to-SD encodes that didn't specify "smpte170m" in the script.

[Sharc]

Originally Posted by MaximRecoil

.

I know that BD-compliant full HD videos are BT.709 and BD- or DVD-compliant SD videos are BT.601, and specifying "smpte170m" in the encoding script results in BT.601 according to MediaInfo, but what happens if you don't include that in the script when encoding a BT.709 HD video to SD resolution? MediaInfo doesn't show any information about it in my HD-to-SD encodes that didn't specify "smpte170m" in the script.

If it is unspecified it will normally default according to the frame size, means "601" for SD resolutions (<720 vertical pixels) and "709" for HD resolutions (>=720 vertical pixels), as far as I know. When it is known it should better be specified. When it is wrong the picture will get a color tint shift.

With the "fake-telecined" one, I manually counted the number of frames in each second just to be sure and there were 30 of them for 1.01 seconds. And like I said, they all displayed as progressive frames.

Hmm, when you inspect the soft-telecined output.264 you should see the same 2:3 interlaced (combed)/progressive pattern as for the hard-telecined case. When you remux the raw .264 video and put it into a container you may however eventually see it IVTC'd, means all progressive. Depends how the tools process it.

[MaximRecoil]

Originally Posted by Sharc

If it is unspecified it will normally default according to the frame size, means "601" for SD resolutions (<720 vertical pixels) and "709" for HD resolutions (>=720 vertical pixels), as far as I know. When it is known it should better be specified. When it is wrong the picture will get a color tint shift.

I think a slight color shift when encoding a 709 HD file to SD resolution may be inevitable, because if it defaults to 601 for SD, that results in a color shift. And if you specify 601, you'll get the same color shift. I've compared frames of my SD encodes to the same frames in the source and you can see a slight color difference. The frames I compared had grass in them, and they were two different shades of green. It doesn't seem like you can specify 709 for an SD encode, because, according to this, it's more than just a color space:

The most recent version is BT.709-6 released in 2015. BT.709-6 defines the Picture characteristics as having a (widescreen) aspect ratio of 16:9, 1080 active lines per picture, 1920 samples per line, and a square pixel aspect ratio.

And if you can't specify 709 for your SD encode when the source is 709, I don't see any way to avoid getting a color shift.

Hmm, when you inspect the soft-telecined output.264 you should see the same 2:3 interlaced (combed)/progressive pattern as for the hard-telecined case. When you remux the raw .264 video and put it into a container you may however eventually see it IVTC'd, means all progressive. Depends how the tools process it.

I didn't look at the output.264 file, other than playing a little bit of it in MPC-HC just to make sure it was a valid file before muxing it into an .m2ts container. It was the .m2ts file that I stepped through in VDub, and it had 29.97 frames per second (which I verified by frame stepping 30 times while watching the time stamp), all of which displayed as pure progressive frames. I can't try it with the .264 file because I deleted both it and the .m2ts file. It was the worst result so far (in terms of interlacing artifacts when played in my BD player) so I saw no reason to keep it.

I got some Newhart (TV Series 1982–1990) DVDs that I ordered in the mail today, seasons 3 to 8, and luckily, they are authentic (for some strange reason Amazon and eBay are flooded with bootleg Newhart DVD sets, featuring single-layer DVDs and video files shrunk with DVDFab software to fit onto single-layer DVDs, about 60% the size of the originals). I ripped season 3 so I can watch it on my BD player (like I said before, its disc drive is screwed up, so ripping discs to a USB drive is the only way I can watch them on that player). I've watched several episodes so far and I have yet to notice any interlacing artifacts at all. The same goes for all my other DVDs. I wish I knew why my BD player handles the interlacing so well with DVDs but not with AVC encodes, not even a BD-compliant one (which turned out to be the worst of all, ironically).

[Sharc]

Originally Posted by MaximRecoil

And if you can't specify 709 for your SD encode when the source is 709, I don't see any way to avoid getting a color shift.

These settings are metadata only. The player may even fully discard these. If you want to (or have to) adjust the video you need to reencode it using the corresponding color matrix. See for example Avisynth documentation.

Summary of my findings regarding (re-)telecining in AVC:
- IVTC works with ffmpeg as discussed
- Hard telecining works with ffmpeg as discussed
- Soft telecining with ffmpeg requires x264 piping as discussed. The resulting telecined elementary .264 output needs to be correctly remuxed into a container though. Feasability is tool (and player) dependent. Usually remuxing and BD authoring tools will request to remove or ignore the soft-pulldown, or the tool removes it automatically, hence outputting progressive (IVTC'd) frames. May need some more tests, but I give up for now ;-)

[MaximRecoil]

Originally Posted by Sharc

These settings are metadata only. The player may even fully discard these. If you want to (or have to) adjust the video you need to reencode it using the corresponding color matrix. See for example Avisynth documentation.

Yes, but the metadata corresponds to some standard, 601 or 709, that's been adhered to during the encoding process. I don't think SD video allows the 709 standard, since that standard specifies 1920x1080, among other things, in addition to a particular color space. And if you can't encode SD video with the 709 standard, how can you end up with the same 709 color space that the source has?

Summary of my findings regarding (re-)telecining in AVC:
- IVTC works with ffmpeg as discussed
- Hard telecining works with ffmpeg as discussed
- Soft telecining with ffmpeg requires x264 piping as discussed. The resulting .264 output needs to be correctly remuxed into a container (mkv, mp4, m2ts) though. Feasability is tool (and player) dependent.

Yes, they all work, it's just that none of them look as good as a DVD on my BD player in terms of interlacing artifacts.

Plain IVTC = prominent interlacing artifacts and moire when things are onscreen that are susceptible to those effects such as chrome trim on a moving car from certain angles (sawtooth effect), or a thin, closely-spaced pinstripe pattern on a shirt (moire effect).

Hard-telecine = Exactly the same as plain IVTC when the player decides to play it properly; otherwise, severe judder.

Fake-interlace = Significantly worse interlacing artifacts than plain IVTC and hard-telecine.

Commercial DVD (as a point of comparison) = perfect.

One thing I forgot to check is the source file for interlacing artifacts. I did check for judder by watching the opening scene of an episode in which the camera pans (and it does have some judder, not severe), but I didn't check for interlacing artifacts in the car pulling into the driveway scene that I've been using for reference. I'll do that later.

[Sharc]

In the DVD/mpeg2 realm hard- and soft telecine is standard and well supported.
In the Blu-Ray realm I have seen
- telecined Extras (Trailers etc.) in SD resolution and mpeg2 format
- hard-telecined Extras in HD resolution and AVC format.
I have however never met soft-telecined AVC HD material on Blu-Ray discs.
Of course my view is incomplete.

In my tests I found hard-telecining for AVC (x264) to be much less problematic for various muxing and playback scenarios. Soft-telecine for AVC (x264) has more pitfalls and dependencies, although it is more efficient.

[MaximRecoil]

Originally Posted by MaximRecoil

One thing I forgot to check is the source file for interlacing artifacts. I did check for judder by watching the opening scene of an episode in which the camera pans (and it does have some judder, not severe), but I didn't check for interlacing artifacts in the car pulling into the driveway scene that I've been using for reference. I'll do that later.

I used tsMuxerGUI to demux the source file which is in a MakeMKV-produced MKV container, then I compiled it as a BD in DVDLogic EasyBD Lite 1.1, and then I copied the 00000.m2ts file from the BDMV\STREAM folder to a USB drive and tried it in my BD player. It had the same minor judder (plus a slight strobing effect in sync with the judder) that it had when I tried it in a tsMuxerGUI-produced .m2ts file, and in the car-pulling-into-a-driveway scene, it has the same sawtooth interlacing artifacts as my plain IVTC'd encode and my hard-telecined encode.

Overall the source is worse in my BD player than my IVTC'd encode, because there's no improvement on the interlacing artifacts, plus it has some judder + strobing that my IVTC'd encodes don't have.

If professionally encoded interlaced AVC files (from Geneon Universal Entertainment) can't match a DVD in my player in terms of how well the interlacing is handled, then there's pretty much no chance that I can do any better with anything I try. I guess I'll just stick with plain IVTC'd encodes for these files. It must be a case of my BD player simply not handling interlacing with AVC files as well as it does with DVD/MPEG-2, because, like you said, "in the DVD/mpeg2 realm hard- and soft telecine is standard and well supported."

Sony probably didn't place a lot of importance on handling AVC interlacing well, because it's not common to begin with (I have no idea why they decided to interlace these source files in the first place). My player was made in 2011 when BD had been around for 5 years and DVD had been around for 15 years.

[Sharc]

Out of pure curiosity:
How does this file play when you put it on an USB stick and play it from there with your BD player?
Excessive judder? interlacing artefatcs? etc.
https://www.mediafire.com/file/nswlq...muxed.zip/file

[MaximRecoil]

Originally Posted by Sharc

Out of pure curiosity:
How does this file play when you put it on an USB stick and play it from there with your BD player?
Excessive judder? interlacing artefatcs? etc.
https://www.mediafire.com/file/nswlq...muxed.zip/file

When I go to your link, MediaFire says:

Well, looks like we can’t go any further

The file you requested has been blocked for a violation of our Terms of Service.

[Sharc]

Try again. Still the same?
https://www.mediafire.com/file/nswlq...ldown.zip/file