Deflickering/despotting

[Mephesto]

I have a somewhat-old cartoon sourced from a poor-quality master so it's full of flickering and scratches (not South Park, PDR). The cartoon has most sequences in 15 fps and others in 30 fps so I'll have to VFR this one. Problem is, the spots and scratches occur on the duplicate frames (the spots stay on 2 frames) so dirt-removal scripts fail even on strong settings (they remove legitimate objects while failing to remove the tiny white scratches).

I'm in an array of catch-22's here. Without removing as much noise/dirt/flickering as possible, I cannot properly Dedup. If I can't Dedup, I can't properly remove the dirt. And I'm not sure whether to NV denoise or deflicker first. I don't have an accurate noise profile anyway, and I'll have to watch through the entire childish movie once to get the best noise profile (I proof-watch my work after preprocessing) and once again after dedup/descratching which I can't be assed to do. It's a wonder I have this kind of patience at all and I got my OCD to thank for it.

So yeah, what should I do?

[jagabo]

Split the video into 15 fps and 30 fps sections. In the 15 fps segments merge the pairs of identical frames together. Then you can use spot removers and other noise filters. To merge the 15 and 30 fps sections together just duplicate frames in the 15 fps segments. In compressed formats like h.264 or MPEG 2 duplicate frames cost almost nothing in terms of bitrate. There's no need for VFR encoding.

[Mephesto]

Split the video into 15 fps and 30 fps sections.

NO. I am not scrounging thru 150,000 frames figuring out which is which, hoping to not miss those intermittent one-second parts of past pace 30 fps that happen.

In compressed formats like h.264 or MPEG 2 duplicate frames cost almost nothing in terms of bitrate. There's no need for VFR encoding.

DEAD. WRONG. Bitrate is nearly halved with twice as less frames. Even when the duplicate frames are bit-by-bit identical duplicates left in the stream, it requires twice the bitrate. No H264 codec recognizes and discards duplicate frames except for direct264. Don't argue with the master, comrade.

Right now I just need to know the best deflicker filter out there. Spots and scratches are duplicated with the frames, the noise and flickering isn't and everyone complains about NV not doing its job or even "causing" flickering and that's exactly what'll happen if I NV this hoe first, but I don't wanna further smear the noise and make it harder for NV to remove later so I'm not sure which to do first.

[jagabo]

Bitrate is nearly halved with twice as less frames. Even when the duplicate frames are bit-by-bit identical duplicates left in the stream, it requires twice the bitrate. No H264 codec recognizes and discards duplicate frames except for direct264. Don't argue with the master, comrade.

I didn't realize you were the master. Obviously, there's no helping you.

[poisondeathray]

I have a somewhat-old cartoon sourced from a poor-quality master so it's full of flickering and scratches (not South Park, PDR). The cartoon has most sequences in 15 fps and others in 30 fps so I'll have to VFR this one. Problem is, the spots and scratches occur on the duplicate frames (the spots stay on 2 frames) so dirt-removal scripts fail even on strong settings (they remove legitimate objects while failing to remove the tiny white scratches).

This is a bad situation, but I would still try to remove duplicates first, because they will screw up any temporal filtering. You can adjust the detection parameters or try different dup detectors . Most will have a visualization or debug mode for adjusting settings

In compressed formats like h.264 or MPEG 2 duplicate frames cost almost nothing in terms of bitrate. There's no need for VFR encoding.

DEAD. WRONG. Bitrate is nearly halved with twice as less frames. Even when the duplicate frames are bit-by-bit identical duplicates left in the stream, it requires twice the bitrate. No H264 codec recognizes and discards duplicate frames except for direct264. Don't argue with the master, comrade.

Only if you use intra compression, not if you use interframe temporal compression (long GOP). Stop and think about what P frames or B frames are. Think of how effective x264 b-frames are, and why they are used . Think of what mb-tree does. Only the differences are stored as residual in P and B frames. Thus, near duplicates are low cost, and absolute duplicates are extremely low cost bitrate wise

Right now I just need to know the best deflicker filter out there. Spots and scratches are duplicated with the frames, the noise and flickering isn't and everyone complains about NV not doing its job or even "causing" flickering and that's exactly what'll happen if I NV this hoe first, but I don't wanna further smear the noise and make it harder for NV to remove later so I'm not sure which to do first.

There is single "best" filter for every situation. You have to try out various deflicker filters, temporal smoothers

[poisondeathray]

Also if you post a sample, maybe at Doom9 there might be some good suggestions (I've seen some gurus lurking around there recently, they aren't around all the time - so it might be a good idea to catch them while they are around)

[Mephesto]

This is a bad situation, but I would still try to remove duplicates first, because they will screw up any temporal filtering. You can adjust the detection parameters or try different dup detectors . Most will have a visualization or debug mode for adjusting settings

If I raise it above noise level then that'll drown numerous legit frames with tiny difference (distant scene of a moving mouth/objects to name one).

Usually, having two removespots() in the script before the Dedup analysis pass (or any other filter that reduces temporal difference between frames) helps greatly in taming the noise and any other dirt artifacts that interfere with proper duplicate detection, but with cartoons that has a tendency to remove legit detail incorrectly detected as dirt, like a talking mouth without any moving objects in the background to back it up, and the frame ends up being marked with a very low value that passes it off as a duplicate.

It is imperative to remove all noise before dedupping, just for that purpose alone, and then with the clean dup.log denoise again with the same parameters for even better quality.

Only if you use intra compression, not if you use interframe temporal compression (long GOP). Stop and think about what P frames or B frames are. Think of how effective x264 b-frames are, and why they are used . Think of what mb-tree does. Only the differences are stored as residual in P and B frames. Thus, near duplicates are low cost, and absolute duplicates are extremely low cost bitrate wise

Stop and think about the fact that H.264 has a limit of 16 reference frames, which become lowered when you double the frame rate and there are less genuine frames to reference to. This is especially apparent with animated and other linear content.

Also, under x264 a frame does have a minimum size which is probably around 200 bytes, so even assuming duplicates won't interfere with efficiency of the refs, it will still add up to around 30 MB for a 2hr movie with 150,000 frames.

http://tasvideos.org/forum/viewtopic.php?t=11597

In one of my earliest experiments, two exact videos, 22.1 and 19.8 MB with 75,357 and 67,715 frames respectively. 10.1% less frames (absolute duplicates) and 10.4% less bitrate. Correlates well, me'thinks.

]There is single "best" filter for every situation. You have to try out various deflicker filters, temporal smoothers

I tried TemporalCleaner and TTempsmooth together but it created blurtrails. Note that I my intention is to remove flickering only, I can remove noise seperately with NV and don't want it temp-smeared because it'll be harder to remove.

Moreover, this is the absolute shittiest quality Blu-ray I ever came across, like the producers gave absolutely no **** and spent 3 seconds doing the transfer. The lines and edges appear to have ringing/macroblock/aliasing artifacts like a 700 MB 1080p rip, I plan to use Santiag to fix this but only heard of it when you helped give me that head-start for restoring my early seasons South park DVDs. I can't find any meaningful documentation, so what are the parameters again?

Must it be used alongside awarpsharp2 like before, why or why not?

jagabo, 'scuse my less-than-sugarcoated post that day, I was in a shitty mood. You are still wrong though, bro. Duplicates cost bitrate, evidence is evidence.

[poisondeathray]

Stop and think about the fact that H.264 has a limit of 16 reference frames, which become lowered when you double the frame rate and there are less genuine frames to reference to. This is especially apparent with animated and other linear content.

Also, under x264 a frame does have a minimum size which is probably around 200 bytes, so even assuming duplicates won't interfere with efficiency of the refs, it will still add up to around 30 MB for a 2hr movie with 150,000 frames.

http://tasvideos.org/forum/viewtopic.php?t=11597

In one of my earliest experiments, two exact videos, 22.1 and 19.8 MB with 75,357 and 67,715 frames respectively. 10.1% less frames (absolute duplicates) and 10.4% less bitrate. Correlates well, me'thinks.

No one is saying that you don't make any gains by encoding VFR. I'm one of the biggest proponents of encoding VFR. Encoding no frames is less than having to some frames. That's just logic.

But your claim of halving the bitrate because of halving the number of frames is wrong, unless you encode without P or B frames. Or you use absurd PB IP ratios 1:1

Bitrate is nearly halved with twice as less frames.

This assumes every frame is the roughly the same encoded size. Even on static content (like slide show presentations, where you have 100's of frames dup strings instead of maybe 2-8 like typical animation) , way more than typical animation - you won't come close to the numbers you claim. Or your testing methology at which you came to those conclusions is flawed

(also, most "dup" filters are capped around 20, unless you're using a modified filter)

Moreover, this is the absolute shittiest quality Blu-ray I ever came across, like the producers gave absolutely no **** and spent 3 seconds doing the transfer. The lines and edges appear to have ringing/macroblock/aliasing artifacts like a 700 MB 1080p rip, I plan to use Santiag to fix this but only heard of it when you helped give me that head-start for restoring my early seasons South park DVDs. I can't find any meaningful documentation, so what are the parameters again?

Must it be used alongside awarpsharp2 like before, why or why not?

santiag is used for antialiasing, and awarpsharp2 for linethinning - if you're not doing this, don't use those filters

for santiag, the value is the strength of horizontal steps e.g, (2,2) would give stronger effect for larger jaggies than (1,1)


I would post some of your atypical samples at doom9. You're probably get some good ideas and approaches you could try out. For example , if you had line noise that you were concerned about (noise surrounding ines), you might apply an edge filter mask to selectively filter those areas

[jagabo]

evidence is evidence.

15 fps and 30 fps (by duplicating each frame) at CRF 18. Less than 1 percent difference.

Even at veryslow with 16 re-frames and 8 b-frames the difference was only about 6 percent. Not worth worrying about.

[Mephesto]

poisondeathray, I guess I shouldn't have claimed so loosely that half frames automatically mean half the bitrate. I've compared two encodes of one of my South park episodes and a non-animated clip with half frames and doubled-fps, and it reduced bitrate by 2% with the same CRF on both.

I guess it depends on the content and I should stop extrapolating results done on retrogame replays to general video. The only reason I run experiments on game clips is because its the only type of video 100% free from noise, shaking, dirt and other artifacts but now I see this is exactly why encoding techniques that work exceptionally well for these videos will fail on 99% of other videos out there that inevitably won't be pure-CGI and artifact-free. Human-generated content is exactly why MPEG codecs exist in the first place. I'm a ******* dumbass.

santiag is used for antialiasing, and awarpsharp2 for linethinning - if you're not doing this, don't use those filters

for santiag, the value is the strength of horizontal steps e.g, (2,2) would give stronger effect for larger jaggies than (1,1)

Anti-aliasing is good, the lines in this cartoon are sometimes jagged, i'll use 3,3. Now that I think about it, they do need to be thinned out a bit as well, the smearing in addition to jaggedness is prevalent. What are the parameters for awarpsharp? I need them to lose about 2 pixels from their fat waists.

jagabo,

15 fps and 30 fps (by duplicating each frame) at CRF 18. Less than 1 percent difference.

Even at veryslow with 16 re-frames and 8 b-frames the difference was only about 6 percent. Not worth worrying about.

jagabo, 6% is a lot of saved bandwidth when your video is gonna be 700 or 4700 MB.

Attached Files

• fps15.mkv (6.99 MB, 4 views)
• fps30.mkv (7.03 MB, 4 views)

Striperella... a show about an LSD-abusing predatory plastic surgeon stuffing his patient's tits with nitroglycerin. Damn Jagabo, what would your mother say?

[jagabo]

6% is a lot of saved bandwidth when your video is gonna be 700 or 4700 MB.

6 percent is an unusual case. As you yourself noted it is more typically 1 to 2 percent. And it's definitely not the 100 percent you claimed -- as "the master".

[Mephesto]

As I said, it depends on the content. On the videos I tried, twice as less frames halved the bitrate, and 10.1% less frames resulted in 10.4% less bitrate. I never said 100%, that makes no sense. 100% less bitrate would be a net rate of 0.

We can't prove it is "typically" 2% without more conclusive experiments, but the benefit is minimal for non-animated content fersure.

you claimed -- as "the master".

Eat me, Jagabo. At least I have the decency to admit error. As you saw, I questioned myself as much as I questioned your doubts, I wouldn't have experimented and produced results to prove my own point wrong otherwise. You will very rarely come across anyone with this kind of modesty in your geek-pissing fests like the Doom9 community, not unless you do extensive asskissing and appease to some needledicked fanboy's fragile sense of self-worth (which incidentally is very often a mod.)

And you are hearing this shit from someone accustomed to having everything he says simply swallowed by the fans of his very high quality, tiny Blu-ray rips. I remind them of the virtue of skepticism and always questioning authority, and this thread would be a good example why.

[jagabo]

As I said, it depends on the content. On the videos I tried, twice as less frames halved the bitrate, and 10.1% less frames resulted in 10.4% less bitrate. I never said 100%

Yes, you did:

DEAD. WRONG. Bitrate is nearly halved with twice as less frames. Even when the duplicate frames are bit-by-bit identical duplicates left in the stream, it requires twice the bitrate.

Twice as much = 100 percent more. And then, after making that preposterous claim, you went on to say you were "the master" of video encoding and that I shouldn't argue with you -- implying that I didn't know enough about encoding to discuss it. I took offense at that.

I'll grant you, you were talking about "saved bandwidth" in post 10. I should have made it more clear which claim I was refering to.

[Mephesto]

Twice as much = 100 percent more.

We were discussing bitrate REDUCTION, and twice as less = 50% less. :P

And then, after making that preposterous claim

But the claim was correct, as the experiments I've done have validated them. Granted, the videos were a kind that benefitted linearly with more ref frames. The more the video benefits from extra refs, the wiser it is to remove duplicates. Sadly, most videos don't really benefit much from more than 3.

you went on to say you were "the master" of video encoding and that I shouldn't argue with you -- implying that I didn't know enough about encoding to discuss it. I took offense at that.

That was a different time on a different day where my patience was limited.


Anyway, back on topic: is there a significant distinction between temporal filters and "deflickers", all I want is to remove flickering and deal with the noise separately. Currently, a combo of TemporalCleaner and TTempSmooth has removed the flickering but blurrs trails of dark gradient backgrounds when the camera is scrolling. Brighter, active objects are not affected.

Should I consider myself lucky that the only blurtrailing I'm dealing with is with dark backgrounds or is there a more innovative solution?

Thanks.

[poisondeathray]

Anyway, back on topic: is there a significant distinction between temporal filters and "deflickers", all I want is to remove flickering and deal with the noise separately. Currently, a combo of TemporalCleaner and TTempSmooth has removed the flickering but blurrs trails of dark gradient backgrounds when the camera is scrolling. Brighter, active objects are not affected.

Should I consider myself lucky that the only blurtrailing I'm dealing with is with dark backgrounds or is there a more innovative solution?

It depends on what you are referring to specifically by "flicker"

luminance flicker?
localized vs. global flicker?
aliasing (edge) flicker?
frame rate cadence "flicker" ?

Filters like TTempSmoth will will average out frames temporally, so ghosting will occur if you use too high settings (it's essentially blending parts of frames). It primarily affects background more than foreground objects by motion, it's not a bright vs dark issue. (if you had bright background with dark foreground objects, the bright background would be affected more)