On Thu, 28 Oct 2004, Dik Takken wrote:
> Sorry, lame mistake. Rephrase:
:)
> Ok, thanks for pointing that out. Should -q 2 be safe enough? The thing is
It might be. And you might be lucky enough to not encounter the
artifacting - it's dependent on the material to a degree.
> 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.
> > 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. One of the HDTV formats in the US
is 1280x720 progressive at 60000/1001 frames/sec. So to put that on
a DVD I need to scale (obviously) and interlace (which drops the
rate from 60000/1001 to 30000/1001 of course).
> 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
Maybe it makes a difference how you're doing the interlacing. More
on that in a minute or two ...
> 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.
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.
> I had a little theory about what might go wrong, but I'm no expert, it's ...
>
> 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!
It sounds like you're taking the two fields from the same frame - the
top lines of frame #1 and the bottom lines of frame #1. That's not
how interlacing needs to be done (if I'm not totally off base - and if
I'm spouting off incorrectly someone will let me know I'm sure ;)).
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.
In a progressive image both fields ARE FROM THE SAME POINT IN TIME.
Assuming a 625 line 50 field/sec video system...
1) Your input data is a 50 frame/sec (100 field/sec) progressive stream.
2) FIELD 1 is the first 1/50th of a second and comes from the "top"
lines of frame #1. NOTE: field 2 of frame 1 is _still_ from the first
1/50th of a second!
3) FIELD 2 is the second 1/50th of a second and comes from the "bottom"
lines of frame #2 - NOT the bottom lines of frame #1!
4) The output stream rate should be set to 25:1 instead of 50:1
y4minterlace will do this automatically).
Frame #1 is a complete representation of the first 1/50th of a
second - both fields of frame #1 come from the same instant in time.
> Each source frame has been split by png2yuv into two fields. One field
So you have 2 fields FROM THE SAME POINT IN TIME. You can't use both
of those - you can only use either the "top" or the "bottom" field.
The NEXT point in time (the next 1/50th of a second) has to come from
the NEXT FRAME - and you take the "bottom" field from that frame.
> 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 ;)
> 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?
>
Close - I think what's actually been discovered is an incorrect
way to interlace a progressive stream :-)
If you check out the cvs version (or just browse the source online
thru the cvsweb interface) take a look at 'y4minterlace'. That works,
it's what I've used to deal with progressive streams that need to
end up on a interlaced based medium.
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 ;)
> Thanks for answering my mail,
Quite welcome.
Cheers,
Steven Schultz
-------------------------------------------------------
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
