No Deinterlacing When AViSynth Trim Used

[graham728]

Hi,

I've just updated to the latest version 1.4.0

I use a AVISynth node to trim a few seconds from the start and end of files. This is then passed over to a deinterlace node, then to a H264 1080p encoder.

I've noticed that in 1.4.0 the outputted H264 1080p files are no longer being deinterlaced. See screengrabs below.

The inputted files are AVC Intra 100 1080i MXF.

[emcodem]

Hi graham,

sorry for the delay, i thought @FranceBB will be very interested in this because all avisynth stuff is his baby but i guess it is too hot in italy currently to turn on PC's in the living room

Looks like the checkbox "clear media properties in the custom avisynth processor" is the guilty one here. If you uncheck that one, it should work as expected. @FranceBB if you implemented this, may you reconsider the design please? Why is there a checkbox that is by default on instead of e.g. just the default example text having this line there?

[FranceBB]

Hey guys,
yes it's very hot here and I can barely sleep at night despite having 2 fans both at 100% pointed directly towards my bed.
Hopefully August will be over soon... hopefully...
Still, 39°C is better than last year when we had peaks of 42°C, so I can't complain.
As for Graham's problem, are you actually sure to be running the latest version, namely FFAStrans 1.4.0.7?
This is what I get by clicking the "About" button:



In other words:
Workflow manager (FFAStrans.exe, x64) 1.4.0.100
Workflow processor (FFAStrans_Queuer.exe, x64) 1.4.0.101
REST-API Service (rest_service.exe, x64) 1.4.0.76

The reason why I'm asking is that the screenshot you showed when you clicked on the Custom Avisynth Script looks very much like FFAStrans 1.3.1 which is the last version to use the old behavior before frame properties were introduced.
In FFAStrans 1.4.0 (any version of it, including the latest stable release) you would see an additional box in the Custom Avisynth Script next to "auto-adapt color space" which is "Clear media properties":



Link to FFAStrans 1.4.0.7 Stable: https://github.com/steipal/FFAStrans-Pu ... 1.4.0.7.7z

What's happening in FFAStrans 1.3.1
In your workflow, you're indexing, trimming, deinterlacing and then delivering the output A/V Stream to the H.264 encoder.
Each node gets in input what the previous node outputted and in your case the deinterlacing node is set to "Autodetect" which means that it will use the metadata to understand whether the input is TFF, BFF or progressive instead of checking the actual content of the stream.
Unfortunately for you, the output of Trim() doesn't really carry any metadata, so the deinterlacing node assumes that it's dealing with a progressive stream and doesn't really do anything to deinterlace it.
The encoding node at that point, the one that is supposed to encode to H.264, takes the still-interlaced stream and encodes the fields as if they were progressive, thus producing a completely wrong output.

Workaround in FFAStrans 1.3.1
By changing the deinterlacing node from "Autodetect" to "Analyze" the filter is gonna analyze the actual stream coming out from Trim() and then decide whether it's TFF, BFF or progressive.
In your case, it will almost definitely detect it to be interlaced and perform the deinterlacing correctly.



By the way, I suggest you to change YADIF to BWDIF as it produces a far better output at roughly the same speed.




Workaround in FFAStrans 1.4.0
FFAStrans 1.4.0 uses frame properties, which means that - as long as the indexer is populating everything correctly - the metadata will be carried through the various nodes. In the Custom Avisynth Script untick the "Clear media properties" tickbox and this will make them be passed through all the way to the deinterlacing node and then to the encoding node.

[graham728]

Hi Thanks Both,

Frances - The screenshots in my first post are from 1.3.0 as I've been using that version for a little while. It's bug free for all the workflows I need it for, so I've been happy to continue using it. I shut down 1.4.0 and did the screenshots in 1.3.0.

When I ported all the workflows to 1.4.0 I noticed the deinterlacing issue.

I've tried changing the node to 'analyse' fields and to BWDIF leaving Clear Media Properties set to True.

Unfortunately, I'm still seeing the same issue of the files not being deinterlaced as they were being in 1.3.0

The fix of setting 'Clear Media Properties' to False does result in deinterlaced files. See screenshots.

Is it safe to set Clear Media Properties to False?

[FranceBB]

Yes it absolutely is safe as you're preserving the metadata inside Avisynth.
You're just using the Trim() function and nothing special so it's totally fine.
In general you may wanna leave "Clear Media Properties" unticked (i.e set to false) unless you're modifying things yourself inside the frameserver.

Let's take the following scenario: you have a PQ input and you wanna convert to HLG.
In this case, in 1.4.0, you would have to populate the frame properties yourself to tell the filter_builder what you've done so that it knows what to do when it creates the filterchain for the encoder in the encoding node.
For instance, here I'm telling the filter_builder that I've already converted to BT2020 HLG Limited TV range so that it doesn't have to do it:

Code: Select all

LoadPlugin("%s_ffastrans_dir%\Processors\avs_plugins\AVSCube\x64\vscube.dll")
LoadPlugin("%s_ffastrans_dir%\Processors\avs_plugins\avsresize.dll")
my_lut="%s_ffastrans_dir%\Processors\avs_plugins\LUTs\WarnerBros_PQToHLG_MaxCLL_%s_my_nits%.cube"

#Getting rid of frame properties
propClearAll(m_clip)

#Bring everything to RGB Planar 16bit Narrow Range
AssumeFrameBased()
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#From PQ to HLG with 16bit precision
Cube(my_lut, fullrange=1, interp=1)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#Clipping 
Limiter(min_luma=64, max_luma=940, min_chroma=64, max_chroma=960)

#Workaround for the filter builder
AssumeFieldBased() #workaround for filter builder in 1.3.1
propSet("_FieldBased", 0) #progressive
propSet("_ColorRange", 1) #Limited TV Range
propSet("_Matrix", 9) #BT2020
propSet("_Transfer", 18) #HLG
propSet("_Primaries", 9) #BT2020

m_clip=last

# The following MUST be the last line of your script
Return m_clip

In your case however you're just trimming, so you're not changing any of the frame properties, therefore it's totally fine to pass them through to the next node and if anything that's the correct behaviour.

[emcodem]

I can add that we discussed about why the "Clear media props" checkbox even exists and why it is on by default. The intention is to allow upgrading from older versions to 1.4 without having to change the existing workflows as usual (1.4 ships the shiny new avisynth dll that supports "frame properties"). So the thinking is that any script that was written before avisynth "frameprops feature" was introduced, needs to use propsclearall() to continue working after upgrading the underlying avisynth dlls...

In other words clear frameprops checkbox in the custom avisynth processor is "true" by default only to support old scripts and it should not be on by default for new scripts.