On Fri, 29 Oct 2004, Steven M. Schultz wrote:
This is a task well suited for the various yuv* tools; yuvdenoise, yuvcorrect,
Hmmm, if it's "post encoding" processing you're talking about would it be better to do that in the encoder rather than the filtering the input stream prior to encoding? There are lots of filters to manipulate the "YUV" stream prior to mpeg2enc but deblocking and deringing feel like things which need to be done after the DCT/iDCT of the encoder.
I have done a bit of testing, comparing these two encoding pipelines:
png images -> yuv4mpeg -> mjpeg -> mpeg2
png images -> yuv4mpeg -> mpeg2
The quality produced by the second pipeline is clearly a lot better. The mjpeg compression step itself should not lead to any *visual* image degradation, because I used the -q 100 flag. Sure, it's still lossy, but there should be no visual degradation. I tried compressing one of the source png images to high quality jpg with the GIMP, and I could not see the difference between the png and jpg version.
My only explanation is that mjpeg2enc amplifies the mjpeg compression artifacts far enough to become visible. This does make sense, because compression artifacts are hard to compress, which leads to even more artifacts.
I should try using mplayer to feed the mjpeg file to mpeg2enc and see if that yields a better mpeg2 stream. If that works, mpeg2enc could benefit from the MPlayer pp filters as well.
Dik
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
