On Wed, 27 Oct 2004, Steven M. Schultz wrote:
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.
Oh, it's not just the filesize or AVERAGE bitrate that's going to be the problem. It's the bitrate spikes! Low values of -q have pushed the average bitrate close to the value specified with '-b' leaving very little room for the inevitable peaks. There's a "thou shall not exceed" rate for DVDs and some players are very allergic to values over 9800. It's not uncommon to have the rate 10 or 20% (temporary) over the "-b" value. If you're using '-b 8400' you're probably OK, but at 9700 + 10%, well, you're over the limit.
Quote from the mpeg2enc manual, -b option:
"If variable bit-rate mode has been selected (see the -q option) this is the maximum bit-rate of the stream."
So, the "-b" value is not the average, but the upper limit when "-q" is specified. So, "-b 9800 -q <anything-but-1>" should be perfectly safe?
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
Ok. But I have taken progressive data and interlaced it (that's what 'y4minterlace' is for - but it's only in the CVS version at the moment) and not encountered the problem.
Yes, I tried y4minterlace once, and I don't remember running into trouble like I do now.
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
Hmmm, the default used to be 8 as far as I recall. Should be fine for "adequate but not great" quality. 6 should be fairly good looking.
Maybe I got the number wrong this time.. :) Anyway, the default number was insufficient to my taste.
Creating/designing titles/text so that it looks good on an interlaced
display is an artform. The font used, width of lines, etc all need
to be carefully chosen and tweeked.
Yes, I noticed that when I wrote a script to generate an interlaced scrolling end credits sequence from a 8x80 inch postscript file... It looked terrible, so I re-wrote the script to generate progressive mpeg2 in stead. That should solve problems for display on both TV and computer screens, shouldn't it? At least it passes the problem on to the DVD player.
The frames that I feed to mpeg2enc are actually not interlaced, they are ordinary 'progressive' images. But since I use png2yuv to generate an
Ok - that's what I figured. Now to interlace that you need to take the "top" field from frame #1 and the "bottom" field from frame #2!
That should only make a difference when the source material is actualy changing in time. For quasi-static material (photo slideshow) this should make no difference, correct? Besides, I just read someone saying that converting profressive film material to interlaced video also takes both fields from the same film frame.
The two fields in an interlaced frame are (forgive the "shouting" ;))
"FROM DIFFERENT POINTS IN TIME". You don't want to take two fields
from the same point in time.
I would guess this is not a requirement, but taking fields from different points in time can result in smoother animation. It does not seem to have anything to do with the problem I'm facing here: mpeg2enc choking on (perhaps not perfectly) interlaced material. This would suggest that mpeg2enc uses different encoding algorithms, based on how the material is interlaced. Mpeg2enc treats converted film material and 'real' interlaced material differently. Could the problem be caused by the fact that mpeg2enc is unable to guess how my material was interlaced?
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,
I think mpeg2enc is seeing the replicated fields from the same point in time and going a bit nuts ;)
How can mpeg2enc know that the fields are taken at different points in time? 'Static' video (like a picture slideshow) also looks like replicated fields from the same point in time, and mpeg2enc should be able to encode video material with static images in it, right?
On the other hand you can just feed the progressive data into mpeg2enc
and it'll "do the right thing" - set the appropriate flags in the
MPEG2 headers to say that the two fields come from the same point in
time. Basically mpeg2enc will do what you're trying to accomplish ;)
Yes, I know that, but I was just playing and trying to understand mpeg2enc's weird behavior in my little weird (but not insane) experiment.
:)
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
