On Sat, 26 Mar 2005, E.Chalaron wrote:
> thanks for their time and patience (they should get an annual award of some
> sort)
Folks kind enough to say 'thanks' is sufficient ;)
> I am using the default values (e.g nothing behind it).
> however
> 1/ Reduced G to 10, q values where constantly "sky rocketing" after a
> 10~12
> frames.
Which means the 'prediction' (P) frames are decaying and it's time to,
as you noticed, start a new GOP. A size of 10 is quite reasonable for
video with a lot of motion. Eventually the dynamic GOP sizing
will be completed (the detection logic is already present - you
probably noticed some extra log messages from 'mpeg2enc' flagging
points at which it would start a new GOP) and you won't have to worry
as much about it. Until then 10's fine.
> 2/ Brought up a bit the -q to 3 instead of 1 then 2.
> 3/ -K Hi-res
So far so good - I wonder though if the default tables (skip the -K)
would work well.
> 4/ the usual -D 10 -R 0
Good.
> 5 no yudenoise at all. Default values of yuvdenoise where blurring
> the all
The defaults do seem to be a bit aggressive. You might try the
values I sent via private mail.
> 6/ y4mspatialfilter default values before mpeg2enc pipe
I tend to put that first in the pipeline - but I don't think that's
critical.
> I still have to test y4mdenoise properly, but values of -t 1 -z 1 seems far
> too high. Need to learn more about its parameters.
-t 3 -z 2 might be a worthwhile set of values to try.
> With this values peak and average bit rate are 9000 and 8000 respectively
Ok. If your video will fit on the media then you're all done - those
are reasonable values
> The option cubic seems important when using a Bayer filter, otherwise some
> pattern (Edge sens in my case) will ring a lot (see the y4mscaler page)
The cubicK4 (-S option=cubicK4) may be worth trying - it might be
better (but then it might not ;)) than a simpler 'cubic' scaling
kernel.
> Next steps :
> A/ include y4mdenoiser with proper values and learn the new yuvdenoise,
> make
> With ABC I will be able to avoid the DV stage hence very likely to improve
> quality
Yes indeed - that conversion to/from DV was definitely not improving
the quality (and you probably noticed it added quite a bit to the
processing time :)).
Sounds like you're having a lot of fun and moving right along - keep
us posted.
Cheers,
Steven Schultz
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
