[MPlayer-users] uspp filter - colorspace

16 views
Skip to first unread message

chronosek

unread,
Mar 8, 2012, 1:33:08 PM3/8/12
to mplaye...@mplayerhq.hu
Hello,

First i would thanks for uspp filter what is part of mencoder.
I found lack of better colorspace in that filter so i just add in file
vf_uspp.c case IMGFMT_444P and compile.
It is working (i use: mencoder in.avi -o out.avi -nosound -oac copy -vf
format=444P,uspp=6:10,harddup -ovc lavc -lavcopts
vcodec=ffv1:pred=2:vstrict=-1:format=444P) but i have question:
- is just adding that colorspace would do better quality filtering?
I asking cause conversion rgb->yv12 is lost of 75% of color information,
and i am not programist i do not know how filter working, so maybe
filter it self degrading colorspace in progress.

Mike

PS. uspp=7 is broken
PS2. i wonder if someone could speed up that so good filter
(i use normally avisynth filters (with rgb24 colorspace) but use
mencoder too - only just for that filter)

_______________________________________________
MPlayer-users mailing list
MPlaye...@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users

Carl Eugen Hoyos

unread,
Mar 9, 2012, 7:32:54 AM3/9/12
to mplaye...@mplayerhq.hu
chronosek <chronosek <at> interia.eu> writes:

> I found lack of better colorspace in that filter so i just add in file
> vf_uspp.c case IMGFMT_444P and compile.
> It is working (i use: mencoder in.avi -o out.avi -nosound -oac copy -vf
> format=444P,uspp=6:10,harddup -ovc lavc -lavcopts
> vcodec=ffv1:pred=2:vstrict=-1:format=444P)

Are you sure that you input is not YV12 ?
(I know it is possible but that is not the typical case.)

The filter should also work in FFmpeg, did you test?

Carl Eugen

chronosek

unread,
Mar 9, 2012, 10:31:19 AM3/9/12
to MPlayer usage questions, feature requests, bug reports

> Are you sure that you input is not YV12 ?
> (I know it is possible but that is not the typical case.)
>
> The filter should also work in FFmpeg, did you test?
>
> Carl Eugen
>
> _______________________________________________
> MPlayer-users mailing list
> MPlaye...@mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>

I use a chain set of filters :
avisynth
(ffvideosource(yv12)->rgb24->spiline144resize->msucartoonrestore->huffyuv(rgb24))
mencoder(rgb->444P->uspp->ffv1(444P))
avisynth(444P->rgb24->msharpen->spilinere144size->lagarith(rgb24))

It is for restore quality bad sources, i want as less as posible use
colorspace losy conver so i just asked about uspp

PS. why huffyuv in mencoder can not use rgb24?

Carl Eugen Hoyos

unread,
Mar 9, 2012, 10:41:44 AM3/9/12
to mplaye...@mplayerhq.hu
chronosek <chronosek <at> interia.eu> writes:

> > Are you sure that you input is not YV12 ?
> > (I know it is possible but that is not the typical case.)
> >
> > The filter should also work in FFmpeg, did you test?

> I use a chain set of filters :


> avisynth
> (ffvideosource(yv12)->rgb24->spiline144resize->
> msucartoonrestore->huffyuv(rgb24))
> mencoder(rgb->444P->uspp->ffv1(444P))
> avisynth(444P->rgb24->msharpen->spilinere144size->lagarith(rgb24))

While I am certainly no expert for avisynth, I don't think this
makes any sense, using uspp on the original source and a
(lossless if you want, but I would recommend low constant quantizer)
yuv420p codec with ffmpeg should save a lot of disk space.

> It is for restore quality bad sources, i want as less as posible use
> colorspace losy conver so i just asked about uspp

There is no lossy conversion if you do
yv12 -> uspp -> yv12 encoder
(except for the filter itself)

> PS. why huffyuv in mencoder can not use rgb24?

huffyuv in FFmpeg does support RGB, please don't forget that MEncoder
is not an actively maintained application (FFmpeg is).

chronosek

unread,
Mar 9, 2012, 11:06:57 AM3/9/12
to MPlayer usage questions, feature requests, bug reports

>> I use a chain set of filters :
>> avisynth
>> (ffvideosource(yv12)->rgb24->spiline144resize->
>> msucartoonrestore->huffyuv(rgb24))
>> mencoder(rgb->444P->uspp->ffv1(444P))
>> avisynth(444P->rgb24->msharpen->spilinere144size->lagarith(rgb24))
> While I am certainly no expert for avisynth, I don't think this
> makes any sense, using uspp on the original source and a
> (lossless if you want, but I would recommend low constant quantizer)
> yuv420p codec with ffmpeg should save a lot of disk space.
>
>> It is for restore quality bad sources, i want as less as posible use
>> colorspace losy conver so i just asked about uspp
> There is no lossy conversion if you do
> yv12 -> uspp -> yv12 encoder
> (except for the filter itself)
>
>> PS. why huffyuv in mencoder can not use rgb24?
> huffyuv in FFmpeg does support RGB, please don't forget that MEncoder
> is not an actively maintained application (FFmpeg is).
>
> Carl Eugen
>
> _______________________________________________
> MPlayer-users mailing list
> MPlaye...@mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>

First - i need resize, cause uspp is blurry, but with 1,5x resize and
resize back after i get nice edges what can be easly and safly
msharpened, btw resizing in yv12 give bad results, so i want resize in rgb24
In end i use editor video what will use rgb24 so rgb is at end
But my question was about uspp , i tryed 444P cause it have yv12
structure, but don't know if only adding case of other colorspace at
input can help with quality filtering

PS. uspp in ffdshow use yv12 or similar colorspace, so it is the same as
in mencoder

Reimar Döffinger

unread,
Mar 10, 2012, 4:38:08 AM3/10/12
to MPlayer usage questions, feature requests, bug reports

uspp is supposed to remove blocking artefacts, resizing completely
breaks the block boundaries and uspp can't really work for that.
More importantly, it can't give good results unless it gets the
quantizer values from the decoder, i.e. you must also be decoding
with MPlayer.
Lastly, if you are not giving it proper Qp values in the input, you
can reduce its strength by just giving it a different fixed Qp value
(second argument).
For all these reasons nobody considered adding RGB support to make any
sense so far.

chronosek

unread,
Mar 10, 2012, 12:56:39 PM3/10/12
to MPlayer usage questions, feature requests, bug reports

> uspp is supposed to remove blocking artefacts, resizing completely
> breaks the block boundaries and uspp can't really work for that.
> More importantly, it can't give good results unless it gets the
> quantizer values from the decoder, i.e. you must also be decoding
> with MPlayer.
> Lastly, if you are not giving it proper Qp values in the input, you
> can reduce its strength by just giving it a different fixed Qp value
> (second argument).
> For all these reasons nobody considered adding RGB support to make any
> sense so far.
> _______________________________________________
> MPlayer-users mailing list
> MPlaye...@mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>
I know that i am not using that filter as it should be, but i have 3
years experience with that filter on almost all configurations, and
results for me are best with resize and my onw qp values.
I have many successful restoring quality in videos and always restoring
to size better to original. Uspp are best for artifacts what other
filters not saw them as artifact.
My best attempt was recover old anime movie from 1999 (with bad sources
640x352 divx5) and succesfully restore to hd 720p and quality was stunning.
I have own ways, thats why i asking about colorspaces in uspp

Reimar Döffinger

unread,
Mar 10, 2012, 1:09:03 PM3/10/12
to MPlayer usage questions, feature requests, bug reports
On Thu, Mar 08, 2012 at 07:33:08PM +0100, chronosek wrote:
> PS2. i wonder if someone could speed up that so good filter
> (i use normally avisynth filters (with rgb24 colorspace) but use
> mencoder too - only just for that filter)

Is is based on the snow encoder, so anything speeding that up will help.
One easy way is to add a way to disable the call to encode_subband
in it (should be about 20% faster).

chronosek

unread,
Mar 10, 2012, 1:25:59 PM3/10/12
to MPlayer usage questions, feature requests, bug reports
W dniu 2012-03-10 19:09, Reimar Döffinger pisze:
But maybe can use more threads ? (i have 6 cores all with ht , but uspp
uses only one thread....) maybe some ssse3 or sse4 operations can speed
that snow encoder? Maybe snow needs more internal buffering? even 20%
is good (with uspp=6:8 i have 0,68 fps encoding .....) 20% can be a few
hours difference, but don't know if without that option it will do the
same good job

Oliver Seitz

unread,
Mar 10, 2012, 1:30:39 PM3/10/12
to mplaye...@mplayerhq.hu

> But maybe can use more threads ? (i have 6 cores all with ht , but uspp
> uses only one thread....)

I think you can... You could split the video in six pieces, keep all
your cores busy with starting six instances of mencoder, and glue the
results back together.

Greets,
Kiste

chronosek

unread,
Mar 10, 2012, 1:41:15 PM3/10/12
to MPlayer usage questions, feature requests, bug reports
W dniu 2012-03-10 19:30, Oliver Seitz pisze:

Didn't try that yet, but I do many things at once so my cores will never
get bored ...

Reimar Döffinger

unread,
Mar 10, 2012, 2:24:51 PM3/10/12
to MPlayer usage questions, feature requests, bug reports
On Sat, Mar 10, 2012 at 07:25:59PM +0100, chronosek wrote:
> W dniu 2012-03-10 19:09, Reimar Döffinger pisze:
> >On Thu, Mar 08, 2012 at 07:33:08PM +0100, chronosek wrote:
> >>PS2. i wonder if someone could speed up that so good filter
> >>(i use normally avisynth filters (with rgb24 colorspace) but use
> >>mencoder too - only just for that filter)
> >Is is based on the snow encoder, so anything speeding that up will help.
> >One easy way is to add a way to disable the call to encode_subband
> >in it (should be about 20% faster).
> >_______________________________________________
> >MPlayer-users mailing list
> >MPlaye...@mplayerhq.hu
> >https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
> >
> But maybe can use more threads ? (i have 6 cores all with ht , but
> uspp uses only one thread....) maybe some ssse3 or sse4 operations
> can speed that snow encoder?

Threading: difficult and IMHO not the right thing to do at the stage the
decoder is, see next point.
SSSE3 etc.: Just asm-optimizing the core functions at all would be
a big help, so far it is all pure C.
I wouldn't be surprised if one could double the speed with that alone.
Don't expect me to do it, this is purely a FFmpeg thing anyway and
doesn't really have anything to do with MPlayer directly.
I would say the same applies to RGB or 4:4:4 support, the snow encoder
would have to support that first.

> even 20% is good (with uspp=6:8 i have 0,68 fps encoding
> .....) 20% can be a few hours difference, but don't know if without
> that option it will do the same good job

It only writes out the bitstream, which has completely no purpose
in this use case.
I implemented that.

chronosek

unread,
Mar 10, 2012, 5:08:07 PM3/10/12
to MPlayer usage questions, feature requests, bug reports

> Threading: difficult and IMHO not the right thing to do at the stage the
> decoder is, see next point.
> SSSE3 etc.: Just asm-optimizing the core functions at all would be
> a big help, so far it is all pure C.
> I wouldn't be surprised if one could double the speed with that alone.
> Don't expect me to do it, this is purely a FFmpeg thing anyway and
> doesn't really have anything to do with MPlayer directly.
> I would say the same applies to RGB or 4:4:4 support, the snow encoder
> would have to support that first.
>

just for try - I uncommented case YUV444P in ffmpeg snowenc.c , changed
PIX to YUV444P in snowdec.c , removed mp_autopull , and added case and
changed PIX for codec in vf_uspp.c
it compiled fine and working , colours looks some better
hmm wondering why was not default more colorspace cases

Mike

Reply all
Reply to author
Forward
0 new messages