On Thu, 28 Oct 2004, Dik Takken wrote:
> Quote from the mpeg2enc manual, -b option:
I replied earlier to that portion of the thread. In essence the
rate limiting is not instantaneous and spikes (sometimes considerably
higher than the -b value) get thru. The lower the -q value the higher
the spikes can be (at least that's what I've seen).
> Yes, I tried y4minterlace once, and I don't remember running into trouble
> like I do now.
Ah, good - wasn't sure how much use the program's getting. The
inspiration for y4minterlace was the desire to get 60000/1001 frame/sec
progressive data modified into something mpeg2enc could handle (the
HDTV rates are the next profile/level up in the MPEG encoder
hiearchy).
> 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.
It should handle it. The other thing that might help would be to use
thicker/bolder sans serif fonts (the serif fonts use thin lines for the
serifs and those will flicker when interlaced).
> > 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
Hmmm, there is the "-I 0" for progressive encoding and "-I 1" for
interlaced content. So the encoder may indeed be doing something
different if you alter the "I" tag in the header but leave the data
the same...
> > You don't want to take two fields from the same point in time.
Or rather, as I should have added: if you do take the two fields
from the same point in time then the encoder should set the flags
in the MPEG output stream saying that the two fields are temporally
coincident.
> 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
Yep - just have the encoder set the flags so that the DECODER knows
that the two fields are from the same point in time and all will be
fine.
> 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?
mpeg2enc does not have ESP (Extra Sensory Perception) - and there's
no "guessing" involved. It is just believing what you've told it
via the YUV4MPEG2 header. "It" means top field first with the bottom
field temporally 1/50th second later, "Ib" reverses the top/bottom
but still implies a time difference between the two fields. "Ip"
says no interlacing - the encoder will split the data into two portions
but flag the outputstream saying that both are from the same time.
Interlacing's a pain - basically we're still paying the penalty for
the technology limitations of the 1930s and 1940s. Today they're
talking about 1920x1080p (1920x1080i is in use for HDTV in the US).
> How can mpeg2enc know that the fields are taken at different points in
> time? 'Static' video (like a picture slideshow) also looks like replicated
You told it :)
It or Ib says that the fields are from different points in time - or
rather that's how the DEcoder will treat them. Only 'Ip' says the
two are from the same point in time.
> fields from the same point in time, and mpeg2enc should be able to encode
> video material with static images in it, right?
Yes, and the time (not quite a year and a half ago) when I was
creating a splashscreen fading thru an intro into a menu I didn't
encounter the problems you're having. Perhaps there wasn't enough
non-text info to see the problem but I didn't see any compression
artifacting (or it wasn't obvious enough in a short clip).
> > On the other hand you can just feed the progressive data into mpeg2enc
> > and it'll "do the right thing" ...
>
> 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.
Perhaps some experimentation with "-I 0" and "-I 1" will alter the
outcome. I don't think much has changed in the encoder since
1.6.2 was released but it would be interesting to hear if the current
cvs version behaves differently. If it does behave differently then
a bug was fixed, if not then well, I guess you just need to use the
method that works and let mpeg2enc receive progressive data and
set the MPEG2 header/stream flags <grin>
Cheers,
Steven Schultz
-------------------------------------------------------
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
