libpostproc filters (lavfi=[pp=...]) show no effect

[fpgan]

I don't know if I'm missing something. The filter graph is initialized without errors. Other lavfi filters work fine, just pp=... doesn't show any effect (while the same graph works fine when reencoding with ffmpeg).

# mpv --log-file=output.txt --msg-level=lavfi=trace --vf 'lavfi=[pp=hb/vb/dr]' test.avi
Playing: test.avi
 (+) Video --vid=1 (mpeg4)
     Audio --aid=1 (mp3)
Opening video filter: [lavfi graph=pp=hb/vb/dr]
[lavfi] Setting option 'graph' = 'pp=hb/vb/dr' (flags = 0)
[lavfi] lavfi: create graph: 'pp=hb/vb/dr'
VO: [opengl] 640x360 yuv420p
V: 00:00:00 / 00:24:48 (0%) Cache: 10s+129458KB
[lavfi] lavfi: create graph: 'pp=hb/vb/dr'
Exiting... (Quit)

output.txt (this is with an empty mpv.conf) I tested mpv-0.9 and mpv-0.15 (on gentoo with ffmpeg-2.8.6 and 2.6.3). The same (no effect) in both versions. On the other hand: ffmpeg -i test.avi -vf 'pp=hb/vb/dr' -c:v libx264 -b:v 800k -preset slow -c:a copy out.avi produces cleanly deblocked output.

# mediainfo test.avi
[...]
Video
ID                                       : 0
Format                                   : MPEG-4 Visual
Format profile                           : Simple@L1
Format settings, BVOP                    : No
Format settings, QPel                    : No
Format settings, GMC                     : No warppoints
Format settings, Matrix                  : Default (H.263)
Codec ID                                 : DX50
Codec ID/Hint                            : DivX 5
Duration                                 : 24mn 48s
Bit rate                                 : 577 Kbps
Width                                    : 640 pixels
Height                                   : 360 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.100
Stream size                              : 102 MiB (80%)
Writing library                          : Lavc54.92.100

(it's the same for all files I tried so far) I would really like to see that work, as I have lots of old divx files around, and I don't see any other deblocking options. And I don't like to resort to using mplayer.

[mia-0]

FWIW, the debanding filter of mpv’s opengl video output (enabled by default with vo=opengl-hq) works quite well on those artifacts, too, so I suggest you try that in the meantime.

[fpgan]

I didn't know that, thanks. But the deblocking is just the first step in a filter graph I now use in mplayer, to get somewhat watchable video from massively blocking, low resolution divx files. Like (for mplayer): -vf pp=hb/vb/dr,hqdn3d=1:1:3:3,unsharp=l7x7:0.5,noise=2hpt:2hpt I'd like to reproduce that or similar in mpv, so I can finally abandon mplayer for all my files.

[mia-0]

On Thursday 04 February 2016 01:36:32 fpgan wrote:

I didn't know that, thanks. But the deblocking is just the first step in a filter graph I now use in mplayer, to get somewhat watchable video from massively blocking, low resolution divx files. Like (for mplayer): -vf pp=hb/vb/dr,hqdn3d=1:1:3:3,unsharp=l7x7:0.5,noise=2hpt:2hpt I'd like to reproduce that or similar in mpv, so I can finally abandon mplayer for all my files.

---

Reply to this email directly or view it on GitHub: https://github.com/mpv-player/mpv/issues/2792#issuecomment-179732894

The debanding filter reduces banding (as the name implies) and blocking, and can also add a variable amount of grain/noise (there are options). If you use opengl-hq, you should already get a sharper image than with mplayer (due to better scaling), and if that’s not enough, there are sub-options to control sharpening. If your GPU can handle it, also try the ewa_lanczossharp scaler, which should drastically reduce stairsteps when upscaling low-resolution video by large factors compared to other scalers. You might also be interested in the anti-ringing options to reduce any ringing caused by scaling.

With the kind of files you are playing, a denoiser is completely superfluous (since all the noise is already gone thanks to the low bit rate) and only introduces artifacts, especially in the case of low-quality denoisers like hqdn3d. You even introduce more noise later on with the noise filter, so I don’t see why you would add hqdn3d to begin with.

That said, you can probably replace your filter chain with just opengl-hq.

[ghost]

The pp filter doesn't work as you expect, because unlike mplayer and older mpv versions, the QP information isn't passed through. I suspect this breaks deblocking, but has no influence on the other filters. (I could add back the QP passthrough, as the way FFmpeg does it got a bit saner. Maybe later.)

[fpgan]

I just tried the debanding options (I wasn't aware of the lot, as I always looked at the manpage for 0.9). Looks very promising (especially as there is a grain option to be used in combination with vdpau!!).

The hqdn3d option is there primarily to smooth out "temporal glitches" (like dirt on old film; but also for what I would call a "jumping effect" due to block-changes at keyframes). It works very well for what I intend it to do (emphasis on the temporal component).

But it seems with the debanding I can just prepend that filter and it still works quite well. I will see if I can tune it to my liking. Only thing missing seems to be separate chroma/luma noise - as I don't want it to look like a noisy TV, but a little more like grainy film...

As for the pp filters: Until you can reenable them, I would suggest you print a warning or something if someone tries to use it, to spare them from the hassle of hours of testing :-)

[ghost]

We don't even know if someone is using the pp filter, because it's entirely opaquely handled by libavfilter.

[mia-0]

Note that using VDPAU hardware decoding will reduce the debanding quality, as it works best in the original video colorspace and currently VDPAU does the YUV-to-RGB conversion before opengl. It’s also useless for MPEG4-ASP (DivX, Xvid, etc.).

There is a deband-grain sub-option, though, and something like 60 should work if the default amount of grain is not enough.

[fpgan]

We don't even know if someone is using the pp filter, because it's entirely opaquely handled by libavfilter.

I thought of something like if (strstr("pp=", graphstring) != NULL) ... :-)

[ghost]

I thought of something like if (strstr("pp=", graphstring) != NULL) ... :-)

No, this could trigger on legitimate filter graphs which just happen to contain this sub-string.

[fpgan]

Note that using VDPAU hardware decoding will reduce the debanding quality, as it works best in the original video colorspace and currently VDPAU does the YUV-to-RGB conversion before opengl. It’s also useless for MPEG4-ASP (DivX, Xvid, etc.).

I need to use VDPAU mainly for HD content. In that case I like to encode the file with libx264 and the only issue I have there is the "blotchy" film grain in lower bitrates. So maybe I can use the deband-grain now in combination with VDPAU to restore that to a certain amount.

As for the deblocking (deband): I am not yet quite happy with the results. The blocking stays visible just after scene changes and is gone only after 2-3 frames. I cannot quite tackle it. It seems it's the quality of the stream, that's heavily blocked on scene changes and smoothes out a little a few frames later. The pp-filter can probably handle that better, because it adapts using that mysterious "QP" value I guess.

[ghost]

(I could add back the QP passthrough, as the way FFmpeg does it got a bit saner. Maybe later.)

Actually no. It's still a mess.

[fpgan]

So, no luck for me on that issue, I suppose :-/ In the meantime I did some more testing with the opengl settings, and got to the point where I am more or less content - just not really happy, because with the pp filters I had better control and could produce a cleaner image...

[mpvOWNZ]

@lachs0r

Note that using VDPAU hardware decoding will reduce the debanding quality, as it works best in the original video colorspace and currently VDPAU does the YUV-to-RGB conversion before opengl.

Am I right in my understanding that using vaapi with the EGL backend isn't affected by this, because there the YUV-to-RGB conversion is in fact being done by OpenGL? Which would mean that whether using hwdec=vaapi or not (with backend=x11egl) doesn't change the output-quality of opengl-hq in the slightest, right?

PS: mpv 0.16.0, bitte! ;)

[kevmitch]

Am I right in my understanding that using vaapi with the EGL backend isn't affected by this, because there the YUV-to-RGB conversion is in fact being done by OpenGL?

Yes use backend=x11egl with hwdec=vaapi should be identical to software decoding barring vaapi decoding errors . To avoid those, I specify hwdec-codecs=h264,h263,wmv3,mpeg2video,mpeg (i.e., exclude vc1).

[fpgan]

Not sure if you intended to add that while you're at it ... but --lavfi-complex='[vid1] pp=hb/vb/dr [vo]' also/still has no effect.

[ghost]

Not sure if you intended to add that

No.

[mpvOWNZ]

@kevmitch Thanks a lot for answering! Could You please tell me which Intel chip You are using and whether it's fast enough for something like vo=opengl-hq:scale=haasnsoft:cscale=ewa_lanczos:fbo-format=rgb32f:interpolation? I'm asking because I'm planning to order a Braswell NUC (the things I'm willing to do for mpv...). Also, the man page says that cscale should be in the hands of the VPU when doing hardware decoding, is this also true for vaapi with x11egl?

If You could take the time to answer my questions, I would be really grateful!

[kevmitch]

Could You please tell me which Intel chip

Ivy Bridge Linux and Haswell Windows

fast enough for something like vo=opengl-hq:scale=haasnsoft:cscale=ewa_lanczos:fbo-format=rgb32f:interpolation?

No. Neither of them can handle that. Intel Linux seems to require fbo-format=rgbaxxx. Making that substitution leads to constantly dropped frames.

Also, the man page says that cscale should be in the hands of the VPU when doing hardware decoding, is this also true for vaapi with x11egl?

Again, vaapi with x11egl does the chroma upscaling / rgb conversion in opengl.

Anyway, this is getting off topic.

[mia-0]

The pp filters are working now.