Any filter listed in the MLT Framework documentation, yes. Not all FFmpeg filters have MLT wrappers. And some are specifically black-listed because they modify the frame rate, which would break the MLT engine.
Note that frei0r and a few other goodies are in the MLT Framework list, too.
Apologies, I may have misinterpreted your question. If you were asking which of the three filters are the best for fixing this video clip, that is unfortunately difficult to say.
Those three filters tackle deblocking in different ways. They each specialize for a different kind of source. Deblocking isn’t a set-it-and-forget-it type of thing and there are no optimized generic settings. It takes a quick test, usually with several parameter sets, to match the filter to the specific type of artefact produced by the camera.
Wish I had a faster solution for you, but I don’t. This is where filter UIs would be very helpful.
To my eye, that couch is looking pretty good, or at least complementary to everything else in the scene. Are the blocks more noticeable during playback?
I don’t have an FSPP recommendation because the settings are so tightly bound to the source… I would have to play with it same as you. However, there is another filter called deband that dithers flat color areas, which might create the illusion of more detail.
They are, but I think I figured out how to get rid of the flicker.
The “magic” is FSPP + HQDN3D
FSPP settings higher than 5/8/8 or 5/10/5 range don’t do much apart from washing out picture. Wavelet didn’t work out on that noise neither. However, HQDN3D Temporal 10% got rid of the temporal flicker. Yey!
You should not have to add your own deinterlace filter. I’m pretty sure Shotcut deinterlaces the frame before handing it to the first filter in the chain, then re-interlaces for export if required. I don’t mess with interlaced any more than I absolutely have to, so I could be wrong, but that’s the best I recall.
That wouldn’t make any sense. Why deinterlace at the end of the pipeline right before re-interlacing it again for export? Also, most filters don’t work on interlaced material.
Is this in the preview window or final export? The preview window is controlled from the menu by Settings > Deinterlacer > One Field or Linear Blend. Neither will look as good as YADIF and will be visible during preview.
If you do bring in YADIF, what about deinterlacing with ffmpeg and bwdif prior to bringing the clip into Shotcut just to make life easy?
I don’t believe this is accurate because in my opinion Export Frame being interlaced when MLT is progressive=“0” proves that export deinterlacer is applied at the end. When MLT is progressive=“1” some internal deinterlacer is applied and whatever is set in Export > Advanced > Video tab > Deinterlacer is irrelevant since timeline is Progressive.
Anyway, I think I might have figured out how to deal with the same flickering noise on 1080i material.
As I thought denoisers were tripping because they cannot deal with interlaced material, so most important and first thing to do with 1080i is to deinterlace. It could be done simply by importing 1080i material into 1080p MLT or setting progressive=“1” in profile in MLT.
My CPU is utilized 50% and from experience this 50% CPU utilization on 2 threads per core processors is ffmpeg filters thing. I don’t know enough about mltframework relationship with ffmpeg, thus the question - can I make mltframework thread more somehow?
I’m not following the logic. If a deinterlacer was applied at the end, the exported video would be progressive by virtue of being deinterlaced. If a deinterlacer was applied at the end and immediately re-interlaced to meet the output format requirement, the export just did busywork to get back where it already was.
Correct, which means Shotcut uses an internal deinterlacer before handing the frame to the filters. Best I recall (my memory is sketchy on this), Shotcut doesn’t actually re-interlace (separate the fields). It just sets the flags to signal that the content is interlaced.
Shotcut should be doing this internally automatically.
This isn’t necessary to invoke the deinterlacer. All this will do is leave the export format progressive, as opposed to flag it as interlaced for the export.
Technically, half. 1080i is 60 fields per second, which is half a frame, therefore half the information.
Yeah, these are heavy filters and they don’t thread well. MLT is just a wrapper and can’t generally control threading. MLT just hands off to FFmpeg and then FFmpeg does whatever it does at native speed. Are you noticing a command-line FFmpeg transcode going faster than Shotcut UI?
I haven’t tried that nor do I think plain FFmpeg would go faster. My memory is sketchy on this but I have this preconception from years ago that FFmpeg filters or at least some FFmpeg filters just don’t load CPU fully. I was just hoping that over years (over a decade already actually) things got better and it is just my prejudice
Looking at my notes on [commercial] Red Giant Denoiser that trips on this noise in the first place… fspp+hqdn3d is at least 3-5 to 10 times faster!
Technically 60 fields are from different frames, so… depending on deinterlacing it could be between 1/2 and 1/4 of the information. That is why I am so curious about Shotcut’s internal deinterlacer that we have misunderstanding about.
I believe when 1080i is brought into 1080p timeline/mlt some internal de-interlacer is applied prior to any other filter and then material is progressive and Export > Advanced > Video tab > Deinterlacer has no effect. Look at this post
The question is what is that
When mlt is progressive=“0”, I believe, based on clearly interlaced Export Frame that I uploaded earlier that included my filters and all, that Export > Advanced > Video tab > Deinterlacer is applied AFTER all filters and before feeding now progressive frame to the encoder.
Do I, may be, explaining the difference more clearly?
In my experience with “my couch noise” there is a big difference between when I have interlaced mlt vs. exactly the same mlt with progressive=“1” in mlt profile.