On Wed, 27 Oct 2004, Steven M. Schultz wrote:
On Wed, 27 Oct 2004, Dik Takken wrote:
I noticed something strange while playing with mpeg2enc. When I encode a sequence of frames to progressive mpeg2, the output quality is *much* better than when I encode the same image sequence to progressive mpeg2.
Something does not read properly in that paragraph. How can the quality of "progressive mpeg2" be different than "progressive mpeg2"?
Sorry, lame mistake. Rephrase:
I noticed something strange while playing with mpeg2enc. When I encode a sequence of frames to *progressive* mpeg2, the output quality is *much* better than when I encode the same image sequence to *interlaced* mpeg2.
It seems to me that something must be wrong here. I use these options for mpeg2enc:
... | mpeg2enc -f 8 -b 9500 -q 1 -a 3 -o output.m2v
Well - one thing that's wrong is using -q 1. Known, in some cases, to suffer from DCT/iDCT overflow in the MMX/SSE code. Or are you doing the encoding on an PPC system - the Altivec routines seem to not have the same problem.
Ok, thanks for pointing that out. Should -q 2 be safe enough? The thing is that I don't care about filesize, as long as my stand-alone DVD player will play it. The only restriction I need for that is to use -f 8 and -b < 9700 IIRC.
When I have png2yuv interpret the frames as top field first interlaced, it produces a mpeg file of the same size, but there are many more compression artifacts. It looks like it has been encoded with -q 10 or something. Why
Ah, but are they compression artifacts or interlacing "artifacts"?
They are clearly compression artifacts. It's the typical blocking and ringing effect of MPEG compression, especially around sharp edges. There is no comb effect or image instability.
If you're viewing the output on a progressive (i.e. computer monitor)
display then interlaced data will look poor compared to progressive
data. I suspect playing it on an interlaced display such as a TV
will likely look different than on a computer monitor.
I know, but that's not the problem. In fact, my input frames are pictures generated by ImageMagick. So, encoding them to progressive/interlaced MPEG should make no visual difference (at least not on a computer monitor, it might be really ugly on a TV, I don't know) provided that I use top field first interlacing.
Not sure if this will help - it might - but adding "-I 0" for
progressive and "-I 1" for interlaced content might make a different
(doubt it, but worth a try ;))
Are you using the cvs version, the last release version (1.6.2) or
an older version?
I use 1.6.2.
I've not seen any compression artifacts on interlaced content - but then
"-q 3" is as low as I've used (usually -q 4 is sufficient).
I'll try -q 4. Using -q 1 with progressive encoding looked very nice while the default value of 6 looked horrible. The input frames contain a lot of edges (lines, text) and MPEG compression does not like that. The animation itself is very smooth and slow, so that should be no problem at 9500 kbps.
I had a little theory about what might go wrong, but I'm no expert, it's just a wild guess:
The frames that I feed to mpeg2enc are actually not interlaced, they are ordinary 'progressive' images. But since I use png2yuv to generate an interlaced yuv stream from it, mpeg2enc will encode to interlaced mpeg2. Each source frame has been split by png2yuv into two fields. One field contains the odd scanlines, the other the even ones. If you would play these fields, you would see the image jumping up and down at 50 (or 60) frames per second. Mpeg2enc 'sees' this jumping and it needs a lot of bits to encode it. When the final mpeg2 stream is played on a computer monitor, the jumping is gone, because the field pairs are merged back into one frame again. So, we actually found a *very* inefficient way to store progressive material in an interlaced mpeg2 stream.
Could this wild guess be correct?
Thanks for answering my mail,
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
