On Sat, 30 Oct 2004, Steven M. Schultz wrote:
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.
Ummm, but mplayer's a _de_coder ;)
Exactly. :)
I guess I'm not seeing how
a decoder's post processing can be put into the _en_coder.
Well, that was actually your suggestion. :) You suggested that the process of removing compression artifacts from yuv4mpeg data (caused by prior mjpeg compression) could best be done in the frequency domain. This makes sense, since the artifacts are also created in the frequency domain. I guess MPlayer is simply processing on the decoded data. That's probably why these filters are called post processing filters. :) If it is possible to detect and 'fix' compression artifacts by directly operating on the yuv4mpeg stream, one could just as well put this into another stream editor and call it 'yuvdeblock' or something. But if you want to do the fixing in frequency domain, it should go into the *encoder*.
Fact is that using MPlayer's post processing can make compressed material look better to the human spectator, but the question is still if an encoder like mpeg2enc will also like the post-processed stream better. I that would be the case, it would not need to spend bits on worthless artifacts caused by prior mjpeg compression.
Or are
you thinking, perhaps, of having mpeg2enc do the encoding, then decode
the result, run the post processing, and then encode as a 2nd pass?
No, thank you. :)
Cheers,
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
