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

[MaximRecoil]

There doesn't seem to be a subforum for FFmpeg here, so I don't know exactly where this question belongs.

Previously I've only ever encountered telecined video in the form of DVD MPEG-2 streams, and I've always used "forced film" in DGIndex on those with good results.

Today I encountered telecined h.264 video, and DGIndex doesn't work with h.264 video files, so I tried DGAVCIndex, but "forced film" did nothing at all. I couldn't try DGIndexNV because I guess you need an Nvidia video card just to use it.

Then I tried the suggestions from this thread...

https://forum.doom9.org/showthread.php?t=172289

... but the results were bad. The original interlaced frames were turned into frames that looked like a blend of two frames, giving it a sort of ghost image effect on those frames.

Then I tried VirtualDub's built-in IVTC filter, and that worked good; it looked just as good to me as DGIndex's "forced film" does on telecined MPEG-2 videos. By using VirtualDub2 I can use that same IVTC filter and also be able to encode with h.264, unlike with the standard VirtualDub. That would be okay if I only had one file to encode, but I need to encode a bunch of them, and it will take a lot longer with VirtualDub. With FFmpeg I can use a batch file to encode them all unattended.

[microchip8]

https://ffmpeg.org/ffmpeg-all.html#fieldmatch

[MaximRecoil]

https://ffmpeg.org/ffmpeg-all.html#fieldmatch

That's what I tried from that post I linked to. The first one I tried was:

-vf fieldmatch,yadif=deint=interlaced,decimate

The results were bad. Then I tried:

-vf fieldmatch,yadif=deint=interlaced,mpdecimate=max=-4:hi=1000:frac=1 -r 23.976

I didn't see any difference with that. In both cases I got three good frames followed by two bad frames, and so on, that looked like blended frames, like this:

https://i.imgur.com/ZYgbPxD.png

That's worse than just leaving it in its original telecined state.

Like I said, VirtualDub's built-in IVTC filter worked great; every frame is a good frame, just like when you use DGIndex's "forced film" on a telecined MPEG-2 video.

[poisondeathray]

That's what I tried from that post I linked to. The first one I tried was:

-vf fieldmatch,yadif=deint=interlaced,decimate

The results were bad.

In what way were they "bad" ? - Wrong matches, wrong decimation, something else ?

Sometimes the source timestamps are not perfect and it can mess with various ffmpeg operations

Try adding -vf fps=30000/1001

-vf fps=30000/1001 ,fieldmatch,yadif=deint=interlaced,decimate

[MaximRecoil]

In what way were they "bad" ? - Wrong matches, wrong decimation, something else ?

"Bad" like in the screenshot I posted in my previous post. I don't know what specifically it did wrong which resulted in all those blended frames.

Sometimes the source timestamps are not perfect and it can mess with various ffmpeg operations

Try adding -vf fps=30000/1001

-vf fps=30000/1001 ,fieldmatch,yadif=deint=interlaced,decimate

I went ahead and tried that and I got the same bad results as before. I know it's possible to IVTC this file correctly because VirtualDub's IVTC filter does it with just its default settings; well, default except I changed the "field assembly mode" from "decomb frames only" to "reduce frame rate," which results in 23.976 FPS, the same as "decimate" does in FFmpeg:

https://i.imgur.com/GHvynxR.png

It's strange that FFmpeg doesn't seem to have a function to do it correctly while VirtualDub's IVTC filter, which is at the very least, 10 years old, has no problem with it.

[Sharc]

The suggested ffmpeg commandline works perfectly here for IVTC.
Is your source hard- or soft telecined? Upload a few seconds of your source, so someone may try.

[MaximRecoil]

The suggested ffmpeg commandline works perfectly here for IVTC.
Is your source hard- or soft telecined?

Hard telecined.

Upload a few seconds of your source, so someone may try.

Well this is weird. I cut out a 5-second clip and was about to upload it, but before I did I decided to try to IVTC it using just the "fieldmatch,yadif=deint=interlaced,decimate" command, and deleted the rest of the commands I had in there for cropping, resizing, etc., and it worked perfectly. So I tried it again with the rest of my commands in there and I got the bad results again. So I tried switching them around, i.e., made it so the IVTC command came first in the script, followed by the resizing commands, and that worked perfectly.

This is how I originally had it, which gave bad results:

-vf "crop=1440:1080,scale=704x480:flags=lanczos,pad=720:480:8:0,setsar=sar=10/11,fieldmatch,yadif=deint=interlaced,decimate"

But this gives perfect results:

-vf "fieldmatch,yadif=deint=interlaced,decimate,crop=1440:1080,scale=704x480:flags=lanczos,pad=720:480:8:0,setsar=sar=10/11"

I don't know why it gives screwy results if you tell it to IVTC after cropping/resizing/etc., but it does.

So this is solved, thanks. I guess I should have posted my script in the first place, but it never occurred to me that seemingly unrelated things like cropping and resizing could possibly make a difference.

[Sharc]

What crosses my mind:
In the first case you cropped and resized the combed ("interlaced") frames before restoring these to progressive frames by fieldmatching, which is no good as I understand because it screws the field structure up.

[Asmodian]

Yes, as you discovered, never scale interlaced video as if it was progressive!

You mix the lines together, generating those nasty blended frames and nothing is going to be able to help after that.

[MaximRecoil]

Yes, as you discovered, never scale interlaced video as if it was progressive!

You mix the lines together, generating those nasty blended frames and nothing is going to be able to help after that.

Yeah, that probably would have happened in VirtualDub too except that I happened to add the IVTC filter first, and then added the resizing, cropping, and padding filters.

By the way, I was reading this site...

https://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/141105.html

... and it says:

Here is the most basic usage of the filters:

-vf fieldmatch,decimate

So I tried encoding one of the videos that way and the results look just as good to me as with the "yadif=deint=interlaced" in between "fieldmatch" and "decimate," so I'm going to do it that way. One less operation for it to do makes it encode a little faster.

I'm not even sure what the purpose of "yadif=deint=interlaced" is if you're encoding purely telecined material. Is it for when you have a mix of film-source and video-source material in the same video file? Either way, if it accomplishes anything with purely telecined material it isn't anything I can notice with these particular video files, so I can do without it.

[poisondeathray]

I'm not even sure what the purpose of "yadif=deint=interlaced" is if you're encoding purely telecined material. Is it for when you have a mix of film-source and video-source material in the same video file? Either way, if it accomplishes anything with purely telecined material it isn't anything I can notice with these particular video files, so I can do without it.

It's for residual combing

You can have a 100% film source, but you can still have cadence breaks (e.g. post telecine edits, common with 90's and early 2000's North American TV series on DVD), which leave you with combed frames

If you have 100%, 3:2 pure, 100% no cadence breaks, then you wouldn't need it IVTC post processing . e.g most modern Hollywood movies on DVD are actually 100% soft telecine, perfect cadence. But you mentioned hard telecine... and that can sometimes be "iffy" . Sometimes just knowing what the title, what content, and what era it was produced in can provide clues as to what it is.

[MaximRecoil]

I have several different old TV series on Blu-ray. Sometimes I watch them directly from the Blu-ray on my PC, just to see how they look in HD, but more often than not I want to watch them the way they were seen when they originally aired, i.e., on a standard-resolution 4:3 CRT TV. That's a problem with Blu-ray though, because it's inherently 16:9, so 4:3 content is inevitably pillar-boxed. If you watch it as-is on a 4:3 TV, you end up with both the pillar-boxing that's hard encoded into the video stream and letter-boxing from the TV, i.e., window-boxing. So I rip them with MakeMKV and re-encode them to DVD resolution, since that's enough resolution to max out the quality potential of an SD TV. Going higher (e.g., 960 x 720 or 1440 x 1080) would just be a waste of drive space.

In any case, this is a 1970s shot-on-film TV series, and it's the first one I've encountered on Blu-ray that was hard telecined. In every other case, the ripped files were 23.976 FPS progressive as-is.

Like I mentioned before, I've never had to IVTC anything except for when re-encoding DVD rips, and I haven't done that in years, because I don't re-encode DVD rips anymore. I rip them with MakeMKV and remux them into an MPG (Mpeg-PS) container and my Blu-ray player can play them from a USB drive (which is nice for watching a TV series because you don't have to keep changing discs), and there's no difference in the way the telecining is handled compared to playing them directly from the DVD.

I've encoded and watched several episodes now without Yadif in the script and they all look perfectly fine.

[MaximRecoil]

I noticed that one of the episodes that I encoded both ways (with and without Yadif in the script) have the same file size, right down to the byte:

https://i.imgur.com/duMRfSq.png

So I did a binary file comparison:

https://i.imgur.com/o32fcLW.png

Then I did the same binary file comparison for several other episodes that I encoded both ways and they were also bit-for-bit identical in every case, so Yadif hasn't done anything to these files at all.

Even though Yadif isn't doing anything so far, I wonder if having it in the script slows down the encoding speed. They seemed to encode faster when I removed Yadif from the script, but that could have been a coincidence because there are a lot of constantly changing variables with an in-use PC that can affect encoding speed. If it doesn't affect encoding speed when there are no stray combed frames for it to deal with, then I wouldn't mind leaving it in the script just in case it happens to be needed in one or more of the several dozen episodes I still have to encode.

[Selur]

out of curiosity: can you share a short sample (a few seconds of horizontal movement would be enough) of your source?
I would like to see some telecined avc content.

Cu
Selur

[MaximRecoil]

out of curiosity: can you share a short sample (a few seconds of horizontal movement would be enough) of your source?
I would like to see some telecined avc content.

https://app.box.com/s/pxpj1tpbk24v13lbhosdmtmjuxyvpjej

[Sharc]

One finds hard-telecined AVC stuff often in Extras and Trailers on Blu-ray discs, sometimes in hybrid form like interviews=interlaced and movie= hard-telecined.

[Selur]

@MaxinRecoil: thanks :)
@Shar: good to know

[MaximRecoil]

Would it be possible to inverse telecine, crop and resize, and then re-telecine in the same script? I know I can't just leave the original telecining in there and resize it because I'll get those ugly blended frames.

I watch these old TV shows on a Blu-ray player from a USB drive, connected to a standard resolution (15 kHz / 480i) CRT TV, so when I play a progressive (23.976 FPS) video, the Blu-ray player has to convert it to 480i on the fly. It produces prominent interlacing artifacts when doing that, particularly noticeable on straight edges that are slanted, and also there are frequent moire and strobing effects that you can see in certain clothing, window blinds, etc.

On the other hand, when I play video that's already telecined, such as an untouched DVD rip of a film-source TV show, interlacing artifacts are barely noticeable.

I can't find much information about it online (probably because most people are only trying to get rid of telecining, not add it), other than this:

https://ffmpeg.org/ffmpeg-filters.html#telecine

If it's possible to do what I want, how would I incorporate it into the following script (I just want it to end up properly telecined like it started out as, but at 640x480 instead of pillar-boxed 1920x1080)?

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

[Sharc]

Would it be possible to inverse telecine, crop and resize, and then re-telecine in the same script?

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

Do you really want a small 640x480, re-telecined? If it's only for removing the side pillars you could probably do without vertical resizing, but just crop to 1440x1080 instead and encode it interlaced with DAR 4:3. No need to IVTC. Something like:
ffmpeg -i input mkv -vf crop=1440:1080,setfield=tff,setdar=4/3 -c:v libx264 -flags +ilme+ildct -crf 18 -c:a copy output.mp4

[MaximRecoil]

Add telecine to your filter, like:

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

Do you really want a small 640x480, re-telecined?

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.

If it's only for removing the side pillars you could probably do without vertical resizing, but just crop to 1440x1080 instead and encode it interlaced with DAR 4:3. No need to IVTC. Something like:

Yeah, but then each video would be huge, probably around 8 or 10 GB after encoding with a CRF of 18, and that additional file size and resolution would be of no benefit at all because a 15 kHz TV can only display up to ~480 lines (or up to ~240 lines if progressive), at ~60 Hz. DVD resolution maxes out the picture quality potential of a 15 kHz TV.

[Sharc]

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]

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:

https://i.imgur.com/i44WAVq.png

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]

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]

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:

https://i.imgur.com/mtgdQW8.png

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]

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]

Yes, my bad. Here the modified commandline:

Thanks.

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]

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]

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]

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]

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]

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

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:

https://i.imgur.com/JPOaA1w.png

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]

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

https://i.imgur.com/JPOaA1w.png

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]

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]

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]

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.

[MaximRecoil]

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]

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.

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


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

[MaximRecoil]

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]

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]

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]

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]

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:

https://i.imgur.com/8whPJnE.png

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]

.

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]

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]

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]

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]

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/nswlqnq2nvo15zg/telecine-soft_pulldown-fake-muxed.zip/file

[MaximRecoil]

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/nswlqnq2nvo15zg/telecine-soft_pulldown-fake-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/nswlqnq2nvo15zg/telecine-soft_pulldown.zip/file

[MaximRecoil]

Try again. Still the same?
https://www.mediafire.com/file/nswlqnq2nvo15zg/telecine-soft_pulldown.zip/file

Yeah, still blocked. Maybe if you password-protect the ZIP file so that MediaFire can't detect what's in it.

[Sharc]

Let's try again with this very short sample.
https://www.mediafire.com/file/lwgdwxtlvesbyzc/telecine-soft_pulldown_sample.zip/file

[MaximRecoil]

Let's try again with this very short sample.
https://www.mediafire.com/file/lwgdwxtlvesbyzc/telecine-soft_pulldown_sample.zip/file

Still blocked. They apparently have some algorithms that detect content. I suspect that the only way around it is to encrypt (password-protect) the .ZIP file. It's easy to do in 7-Zip.

[Sharc]

Sent you a PM.

[MaximRecoil]

Sent you a PM.

Password-protecting it worked, not that it makes sense for their content-matching algorithm to care about an 8-second clip in the first place.

I can't figure out what's going on with the aspect ratio of it. When I open it on my PC in MPC-HC, it's 4:3 (it's 4:3 in VDub too), which is clearly the wrong aspect ratio, but when I play it on my BD player, it's 16:9, which is the correct aspect ratio. I've never seen that happen before, i.e., MPC-HC and my BD player have always agreed on the aspect ratio of any given video file. MediaInfo says:

Display aspect ratio: 4:3
Original display aspect ratio: 16:9

So MPC-HC must be going by the DAR and my BD player is going by the original DAR. I actually ran into an issue like that with YouTube. I have a camcorder that, in its lower quality modes, records at 1440x1080 with a 16:9 DAR, and when I re-encoded it for YouTube I resized it to 1920x1080 and cropped it to 1440x1080 (because I wanted it to be 4:3), and MPC-HC displayed it correctly, but YouTube screwed up the aspect ratio. In order to get rid of that "original display aspect ratio" that somehow remained even after a re-encode, and that YouTube insisted on using, I had to explicitly set the SAR to 1/1 when re-encoding, like this:

-vf "scale=1920x1080:flags=lanczos,crop=1440:1080,setsar=sar=1/1"

In any case, there's a little bit of judder during the camera pan (i.e., a little more than the baseline inherent amount). It's about the same amount of judder that's in my 1080i source files when played on my BD player.

What sort of telecining did you do to it? Was it --pulldown 32 without --fake-interlaced? Stepping through it in VDub, it looks no different than progressive video; all progressive frames, 23.976 of them per second, but MediaInfo says it's interlaced, bottom field first.

[Sharc]

Yep, sorry. I missed to flag it correctly (was probably a copy/paste leftover from a former script). Also, possibly a discrepancy between container and stream. Anyway, I set the SAR for the x264 encoding correct, hence a player which reads the AVC stream SAR or forces 16:9 playback should display it with the intended Aspect Ratio. I would have to check.
Process:
Original hard-telecined HD source -> IVTC'd -> resized and applied --pulldown 32 including --fake-interlaced as proposed for the x264 piping commandline. Finally the soft-telecined elementary .264 remuxed to .mp4. As I said I didn't pay much attention to aspect ratios for this experiment
I was just curious to learn whether you would still get the excessive and random judder which you reported for your test with --pulldown 32 and --fake-interlaced, interlacing artifacts etc. with this sample.

I am not sure whether containers other than .m2ts are supposed to support soft-telecined AVC at all. So just an experiment.

Edit:
The Asect Ratio ambiguity (4:3 flag) was introduced by the tool which I used to shorten (trim) the duration of the original testclip.

Edit2:
Aspect Ratio mess fixed. See your PM.

[MaximRecoil]

The MediaFire link for the two .7z files inside a .zip file worked.

The .m2ts and the .mkv look exactly the same on my BD player and they both have significantly more judder than the .mp4.

All three files have a very smooth looking camera pan when played in MPC-HC on my PC, which is connected to a CRT monitor set to 1152x864 with a 75 Hz refresh rate; as judder-free as is possible on a setup in which the monitor's refresh rate isn't perfectly synced to the video's frame rate or an exact multiple thereof. My plain IVTC'd encodes on my BD player are also as judder-free as possible. The only issues I have with those are the sawtooth and moire interlacing artifacts in certain scenes. The same BD player plays DVDs with hardly any sawtooth or moire effects, and my other devices that output a 480i video signal also do so with hardly any sawtooth or moire effects, such as various VHS VCRs, my WD Live TV hardware media player (even when playing my plain IVTC'd AVC files), and a couple of ATSC TV tuner boxes.

MediaInfo identifies your .m2ts and .mkv file as progressive, and the .mp4 version as interlaced, bottom field first. All three of them are 23.976 FPS.

[Sharc]

ok, thanks.

All files are soft-telecined which can be verified by inspecting the top_field_first and repeat_pict flags of the stream, which show the expected cadence for 2:3 pulldown, like top_field_first = 001100110011..... and the repeat_pict flags = 01010101...... Hence the player can output the fields accordingly at 59.94 fields per second through its interface to an NTSC TV or similar device. On a progressive monitor or PC the frames are displayed at 23.97 fps as you noticed, as there is no need for "pulldown" of fields.
Basically this is the same for all 3 files (in 3 different containers), and when you get different results it's due to the player handling the containers/formats differently. I have seen this here as well. I am still of the opinion that hard-telecine is more "robust" for AVC on various playback scenarios and containers, but is less efficient (bigger files) as we know.

MediaInfo identifies your .m2ts and .mkv file as progressive, and the .mp4 version as interlaced, bottom field first.
Yes, I have seen this. Inspecting the stream however indicates that only 2 of the first 4 frames are flagged as interlaced (probably an editing effect, orphaned field or something), all the rest is progressive frames. So MediaInfo might have been fooled. When I re-did this .mp4 for fixing the AR issue MediaInfo reported it as progressive (with interlace=fake) as well.

[Sharc]

Regarding moire artifacts see also here:
https://forum.videohelp.com/threads/404932-Handling-moire
In Avisynth changing the IVTC algorithm or doing it manually helped, but I don't know how to do similar with ffmpeg.
It is also possible that the moire in your case was introduced by the sharp picture downscaling rather than by the IVTC or re-telecining.

[Sharc]

Here a new set based on your sample in post#15. Sorry, I missed your post.
https://mega.nz/file/PIsA1IKI#A1Us3d_5zmyANEyax5LcnO-xUiD8GdsNrVU0g0GQVTM

I wonder if AVC soft-telecine has ever been used for Blu-Rays.

[MaximRecoil]

Here a new set based on your sample in post#15. Sorry, I missed your post.
https://mega.nz/file/PIsA1IKI#A1Us3d_5zmyANEyax5LcnO-xUiD8GdsNrVU0g0GQVTM

I wonder if AVC soft-telecine has ever been used for Blu-Rays.

Thanks, but that was just a clip I provided for someone who asked to see an example of telecined AVC content with some horizontal movement. It's hard to tell anything from that clip in terms of judder or sawtooth & moire interlacing artifacts, because the camera isn't panning and there are no angled straight edges in it.

Here are the two scenes I've been using for reference (they are both from the same episode so they are both in a single video clip):

https://app.box.com/s/sdozvl0v3lu0nkgeyit03bgmboh9sek9

The first scene has a camera pan which is good for watching for judder, because it's easy to see by watching the edges of the picture frame on the wall and the lamp shade. The second scene is the car pulling into a driveway scene that I mentioned before. On my BD player there are prominent sawtooth interlacing artifacts on the car's chrome trim on its hood and top of the door when the car or camera is moving (or in the case of the soft-telecined / fake-interlaced / piped through x264.exe encode I did, the prominent sawtooth effect remained even when both the car and camera were stationary).

I didn't include the scenes which show a lot of moire on one of the actor's shirt collar, because I didn't want the clip to be too long. It's already 50 seconds long as it is.

By the way, this episode, along with all of the newer episodes starting in the late '80s, is 16:9, which annoys to me to no end, because they were originally broadcast in 4:3. At least they left the 1970s episodes (like in my clip from post #15) in the correct 4:3 aspect ratio. In any case, I've been letter-boxing the 16:9 ones (scale=704x360:flags=lanczos,pad=720:480:8:60,setsar=sar=10/11) instead of doing anamorphic 16:9 encodes, because anamorphic 16:9 has no benefit whatsoever over letter-boxed 4:3 on my type of TV, but they end up having a significantly bigger file size because you're encoding 704x480 picture information rather than 704x360 picture information.

[Sharc]

On my BD player there are prominent sawtooth interlacing artifacts on the car's chrome trim on its hood and top of the door when the car or camera is moving ...

Yes, I see these artifacts as well on the PC when playing the IVTC'd downscaled clip. Without downscaling it looks ok. So it seems to be the scaling which is the culprit. Don't know an easy fix, other than in postprocessing.
For DVD footage you won't have this scaling effect, or much less as the original source is 720x480 only.

[MaximRecoil]

Yes, I see these artifacts as well on the PC when playing the IVTC'd downscaled clip. Without downscaling it looks ok. So it seems to be the scaling which is the culprit. Don't know an easy fix, other than in postprocessing.
For DVD footage you won't have this scaling effect, or much less as the original source is 720x480 only.
In Avisynth it's slighly better, but it's also there.

I only see very minor sawtooth effects on the car's chrome trim on my PC with my SD IVTC'd encodes; not anywhere near as prominent as on my BD player. They are very minor when played on my WD Live TV hardware player too (which outputs an analog 480i video signal to my CRT TV, the same as my BD player does). Minor effects like that are normal / to be expected; the problem is that my BD player exaggerates them quite a bit, and even more so with that piped-to-x264 encode that I tried.

And yeah, with the source file there are pretty much no sawtooth effects when played on my PC, but it does have some judder in panning scenes, which my IVTC'd encodes don't have. The source file also has the same prominent sawtooth effect as my plain IVTC'd encodes have when played on my BD player.

Film-source DVDs are normally scaled down from a 2K or 4K master (not counting early ones that used D-1 masters, which are 720x486). I wonder what type of scaling filter they use. I've been using Lanczos.

[Sharc]

And yeah, with the source file there are pretty much no sawtooth effects when played on my PC, but it does have some judder in panning scenes, which my IVTC'd encodes don't have.
This is as expected and depends how your PC player decodes the video. With MPC-HC you have the choice:
For your hard-telecined source you will either see the 2:3 progressive sequence with the well known judder, or you see a sequence of 2 combed (interlaced) and 3 progressive frames.
The IVTC'd source is all progressive and basically judder-free with little remaining judder from the framerate (usually 23.976fps) and monitor refresh rate ratio not being an integer multiple.
For soft-telecined stuff it depends how the player handles the pulldown flags and outputs the fields on the 480i interface to your TV. The pulldown flags should be correct IMO for the samples which I provided.
As has been argued AVC soft-pulldown played via a BD player may only work for strict blu-ray compliant files, even burnt to a disc with the standard blu-ray structure rather than played from the USB stick in some container. I don't really know.


Film-source DVDs are normally scaled down from a 2K or 4K master (not counting early ones that used D-1 masters, which are 720x486). I wonder what type of scaling filter they use. I've been using Lanczos.
I don't know how studios do it, but as I understand, downscaling will always have to be preceeded by low-pass filtering (softening the picture) in order to prevent aliases.

[MaximRecoil]

The IVTC'd source is all progressive and basically judder-free with little remaining judder from the framerate (usually 23.976fps) and monitor refresh rate ratio not being an integer multiple.

Yeah, that applies to playing it on a PC, but on my BD player when outputting 480i, the output isn't progressive, it's 59.94 fields per second (the only progressive video that my CRT TV is even capable syncing to is 240p, but I don't have a video player that can output 240p, only old video game consoles), but it's still as judder-free as playing them on my PC. I don't know the exact process it uses to convert 23.976 frames per second progressive video to 59.94 fields per second interlaced video on the fly, I just know that it has to do it, because NTSC video is inherently 59.94 fields per second (originally 60 fields per second before they revised the standard in 1953 to accommodate color).

I don't know how studios do it, but as I understand, downscaling will always have to be preceeded by low-pass filtering (softening the picture) in order to prevent aliases.

That's interesting.

The down-scaling from HD to SD definitely has something to do with the sawtooth effect, but there's more to it than just that. Like I said, for some reason my BD player exaggerates it while my WD Live TV player doesn't. Also, on my BD player, the piped-to-x264 encode I did showed even worse sawtooth than my plain IVTC'd encodes, and that was down-scaled in exactly the same way, i.e., the down-scaling was done in FFmpeg using the same script as with my plain IVTC'd encodes.

If there were a method to down-scale without introducing any aliasing (or less aliasing at least), I wonder if that would eliminate the issue; the idea being that there would be nothing for the BD player to exaggerate in the first place. If I remember right, Lanczos, which I always use, has a bit of a sharpening effect, which would also increase its aliasing effect. I could try just plain bilinear scaling to see if that makes a difference.

[Sharc]

I don't know the exact process it uses to convert 23.976 frames per second progressive video to 59.94 fields per second interlaced video on the fly, I just know that it has to do it, because NTSC video is inherently 59.94 fields per second ....

Manual page 22 "Cinema Conversion Mode" and "Output Video Format". It telecines the progressive film source, obviously. It just doesn't tell whether it telecines as 2:3 or 2:3:3:2 (which would have little more judder).

[MaximRecoil]

It telecines the progressive film source, obviously.

Yeah, I meant that I don't know what pulldown pattern it uses (e.g., 2:3 or 2:3:3:2), and I also don't know what it does differently with 23.976 FPS progressive video when set to "auto" (which it should detect as film-source) vs. set to "video," which the manual says will make it treat everything like video-source. I've tried both settings on my plain IVTC'd encodes, car/driveway scene, and I didn't see any difference at all.

By the way, I tried an encode with bilinear scaling instead of Lanczos and I didn't see a difference on my BD player.

[Sharc]

Take a look here, e.g. the paragraphs 1080i Disc Playback and SD playback. It mentions jaggedness as well.
https://www.avforums.com/reviews/sony-bdp-s480-3d-blu-ray-player-review.54/
If it's true it detects pattern cadences, means it does not even (or not only) rely on flag reading. No idea what happens when there is a conflict between the flags and the player's cadence detection.
Or ask SONY what magic they applied ;-)

By the way, I tried an encode with bilinear scaling instead of Lanczos and I didn't see a difference on my BD player.
About scaling artefacts and moiré:
http://www.glennchan.info/broadcast-monitors/scaling-artifacts/scaling-artifacts.htm

In your example the jaggies become gradually annoying (viewed on PC) when I downscale (and upscale on the fly for viewing on PC monitor) the 1080 IVTC'd source to lower than about 640 vertically. In your case the downscaled active picture is 360 vertical only (1080->360).