[MPlayer-users] trying out qns

[Corey Hickey]

[cross-posted to ffmpeg-devel and mplayer-users]
[if anybody objects to this, tell me and I'll stop]

qns is a difficult parameter to evaluate, because it cannot be fairly
rated based upon PSNR. With the video sample I used, setting the qns
parameter equal to 1, 2, or 3 lead to slightly lower PSNR values, but
never worse overall quality.

-----------
Methods:
I tested a 100-second clip that I selected on the basis of having lots
of sharp-contrast edges (for example, a roof contrasting with the sky)
so that I could see how much it reduces ringing along edges. Also, the
clip has a variety of fast- to slow- motion.

The base encoding command:
mencoder dvd://1 -ss 352 -endpos 100 \
-vf crop=712:360:4:58,scale=672:288  -sws 2 -nosound \
-ovc lavc -lavcopts vcodec=mpeg4:trell:vratetol=1000:vpass=$i:psnr \
-ofps 23.976

I used -sws 2 to maintain sharp contrasts. Since the clip is short, I
used vratetol=1000 to constrain the bitrate; the four tests differ by
only 0.076 kbit/sec. Each test includes trell because Michael suggests
it in the mplayer man page, and in any case trell is pretty much a must
for archival encoding, in my opinion.

The fps values listed below are approximate, but probably reasonably
precise. They are taken from mencoder's output while my system was under
varying but light load. I doubt they would differ much from
user-time/#frames.

For each encode, I examined only the second of the two passes. I
compared each qns= video to the trell-only video. First, I dumped a
portion of the encoded videos to png and flipped back-and-forth between
corresponding frames to examine the differences in detail. Second, I
played each qns= video side-by-side with the trell video so I could get
a general feel for which looked better. I never used any postprocessing
for any of these tests.

------------
Results:

trell
Video stream:  799.478 kbit/s  (99934 bps)  size: 9995182 bytes  100.017
secs  2398 frames
PSNR: Y:33.25, Cb:41.44, Cr:41.71, All:34.70
52fps

The baseline test. The output looks pretty blocky, with lots of edge
ringing. 800 kbit/sec isn't enough to do the clip justice, but makes
differences in encoding quality more apparent.

---

trell:qns=1
Video stream:  799.426 kbit/s  (99928 bps)  size: 9994534 bytes  100.017
secs  2398 frames
PSNR: Y:33.16, Cb:41.60, Cr:41.85, All:34.63
15fps

The side-by-side and the frame-by-frame comparisons between this encode
and trell-only lead me to the same conclusion: some parts look better
and other parts look worse. When looking at them side-by-side, I
couldn't decide if either one looked better overall. Within individual
frames, some parts had more/less detail, and/or were more/less blocky.
To my perception, the losses seemed to cancel out the improvements, with
better-looking parts in different places rather than increased in number
or quality. One exception, however, is absolutely certain: ringing was
dramatically reduced, and sharp-contrast edges were surrounded by much
less blockiness.

---

trell:qns=2
Video stream:  799.502 kbit/s  (99937 bps)  size: 9995478 bytes  100.017
secs  2398 frames
PSNR: Y:33.13, Cb:41.56, Cr:41.82, All:34.60
9fps

The results of this test impressed me. Ringing was reduced at least as
much as with qns=1, and sometimes even a bit more. Like qns=1, many
parts looked better, but this time I could find very few parts that
looked worse, and nowhere that looked dramatically worse. In the
side-by-side comparison, I could identify the qns=2 video without
specifically looking at edges, simply because the overally perceptual
quality was improved.

---

trell:qns=3
Video stream:  799.452 kbit/s  (99931 bps)  size: 9994857 bytes  100.017
secs  2398 frames
PSNR: Y:33.12, Cb:41.57, Cr:41.81, All:34.59
3fps

The results here were more conflicting than the previous ones,
unfortunately. Ringing was usually about the same as with qns=2;
sometimes a bit more, sometimes a bit less. Overall, many frames seemed
sharper than in the other tests, but several parts were significantly
more blocky. Viewing this side-by-side with trell, I couldn't
differentiate between the quality of the two, except by looking for
ringing at the edges.

----------
Conclusion:

* qns=1 seems to me a bit better than the default simply on the basis of
having nicer ringing-free edges. Unfortunately, the considerable fps
drop may not make it worth it unless you're making an archival copy, in
which case using qns=2 would be preferable anyway.

* qns=2 gives noticable gains, and the performance drop isn't much worse
than with qns=1.

* Even if qns=3 were to produce better quality, it would still be
prohibitively slow unless you've got your own encoding-farm. :) As it
is, I don't see any reason to use qns=3 if this test is indicative of
video encoding in general.

...which brings me do a disclaimer I ought to mention: different source
video will produce different results! I'd be happy to see some other
people test qns with their own clips and report what happens. As for me,
I've typed enough for now.

----------

-Corey