[MPlayer-users] Re: Crop before deinterlacing OK?
Matthias Wieser
mwieser at gmx.de
Mon Jul 25 15:02:22 CEST 2005
Am Montag, 25. Juli 2005 14:43 schrieb Rich Felker:
> On Mon, Jul 25, 2005 at 11:56:06AM +0200, Matthias Wieser wrote:
> > Am Montag, 25. Juli 2005 00:48 schrieb Rich Felker:
> > >
> > > It has all the same disadvantages as lb, plus the disadvantages of
> > > a sharpener (hurting compressibility and not improving quality).
> >
> > Maybe not improving psnr but I think it improves visual quality. I
> > have done some tests with different test patterns and the
> > deinterlaced result of pp=l5 is much more comparable to the original
> > as the one from pp=lb.
> >
> > (btw.: when measuring the psnr between the original and the scaled
> > down and encoded video, sws=2 or sws=6 often results in higher PSNR
> > than sws=1 or sws=7)
> >
> > > It's
> > > exactly the same thing as running pp=lb followed by a simple
> > > -1,4,-1 sharpening filter.
> >
> > But as pp=lb by the very nature of the system introduces some
> > vertical blurring this sharpening might improve the overall quality.
>
> If you weren't going to encode, yes. But a sharpening filter will just
> hurt compressibility and lower the psnr of the actual encode.
Do you always apply an gaussian blur filter before encoding because
mencoder -lavcopts [...]:psnr will then show a higher psnr? ;-)
The PSNR between the original frame and a pp=l5 processed frame is
significantly higher than the PSNR between the original and a pp=lb
processed frame. So why not encode the frames which are nearer to the
original?
> > The response time of most TFTs is dependent on the contrast between
> > the two colours. Sharp edges as they are produced by pp=fd result in
> > higher local contrast between the actual and the last frame which in
> > result is good for TFTs.
> > For example: a black object is moving over white ground.
> > when using pp=fd the response time from black to white and from white
> > to black is relevant.
> > When using pp=lb the respons timee from black to gray, gray to white,
> > white to gray and gray to black are relevant which often need much
> > more time than switches between black and white.
>
> Again I really do not think this is the issue at hand. I know what
> you're talking about but it's hardly relevant.
I thought you were using a 4/3 CRT?
> The ghosting you see is
> just because pp=lb created a nasty ghost. It's visible on CRT too.
The ghosting I see is the ghosting from pp=lb and the ghosting from my
TFT. As the ghosting from pp=lb lowers contrast of moving edges, the
ghosting from my TFT increases.
Regards,
Matthias
>
> Rich
>
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-users
More information about the MPlayer-users
mailing list