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

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