On Fri, 29 Oct 2004, Martin Samuelsson wrote:
A better strategy, albeit more space consuming, would be to convert them into YUV4MPEG2 (if it still is called that nowadays; the raw YUV files produced by lav2yuv) instead. If you have more CPU than disk, you could convert-stream-and-feed-the-encoder via pipes instead. The YUV4MPEG2 header is not that hard to filter away in such a setup. This would give you better source material to work with, as it hasn't been MJPEG compressed.
Well, the MJPEG file at -q 98 looks *very* good, better than the resulting MPEG2 stream. But the tiny compression artifacts in the MJPEG file are probably difficult to encode, thereby wasting bits.
This leads me to another question: Does lav2yuv do any postprocessing on the MJPEG data to reduce compression artifacts? This would make mpeg2enc's job a bit easier. I know MPlayer has a nice deblocking and deringing filter to do just that.
The YUV file is very simple and straightforward; with some scripting, you could even create it with a tool like convert from ImageMagick.
Hmm.. that's an interesting idea. Any advantages over having ImageMagick save the frame in png format and use png2yuv to do that?
contains lots of thin horizontal lines. Could this mean that the TV image starts flickering at 50 fps?
Yes. At least antialias it a bit, or rethink the graphics. Make sure no lines are one pixel high, and make sure that any two-pixel lines occupy approximately the same place in the viewed image. Otherwise you will get those "bad weather map effects" the news programs has learned to avoid.
/Sam
-------------------------------------------------------
This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
