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
> 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
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?
> > 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).
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
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.
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).
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
Didn't try that yet, but I do many things at once so my cores will never
get bored ...
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.
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