Hi Steven > Some of the changes Matt made in y4mscaler 9.0 were specifically aimed > at the problem you were having with larger frame sizes and complex > scaling factors.
mmm then I must have done something wrong somewhere .... > I've been unable to reproduce the problem. I'm better than you : I still manage to reproduce it everyday :-) > I recall you mentioned at one time that the images produced by > the camera were 1280x960. Depending on the settings of my camera... No need to go so big for R8, the grain is coming up, looks like a bag of rice... > > > yuyvtoy4m -w 1116 -h 832 -a 1:1 -i p -r 17:1 | \ > > If the files are 1280x960 then the 'cat' command should produce a > "raw" (headerless) stream YUYV stream > > So, I simulated frames from the camera with 'y4mblack': > y4mblack -w 1280 -h 960 -a 1:1 -i p -x 422 > and fed that into y4mscaler thus: > y4mblack -w 1280 -h 960 -a 1:1 -i p -x 422 | \ > y4mscaler -I active=1116x832+82+64 -O sar=PAL -O size=704x576 Ha .. Ok, in fact I am now exporting most of my transfers to 1024*768 not in PAL size. PAL videos in mpeg2 are coming from the quictime 422 1024*768 > > NOTE: Do the y4munsharp and yuvdenoise ON THE SMALLER 4:2:2 frames. > It doesn't make sense to denoise the large 4:4:4 frames! Was wondering actually. I 'll make a couple of trials to see the difference. But applying a yuvdenoise - m 4,8,8 on a grainy frame would probably help more to reduce the grain than doing after scaling down.. Am I wrong ? > It also makes sense to denoise, unsharp, yuvcorrect the DOWN > scaled frames. Why correct 2 or 3 times as many pixels as > you are going to use? ;) Just to make sure I have missed none of them :-) > There might be some work left to do on that sequence of commands > but I think that'll be a LOT faster than the order you originally > were using. indeed :-) Cheers and thanks a lot E _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
