>Cool. Maybe I should try this from another angle, given that I
>capture at 352x480, and say, by experimentation, that I discover that
>I need to crop 57 lines from the top and 57 lines from the bottom to
>be rid of the black, bit-wasting bars.
Hmm... how many bits do true black bars waste? Just curious --- 'cause
this cropping might make things complicated. (What are these black bars
from? Letterboxing or something else?)
>Now given that my frame height is now 368 (480 - 56 - 56) and width is
>704 with a pixel ratio of 10:11, and my formula for arriving at the
>display aspect ratio being:
>
> width * 10
> ---------- : height
> 11
>
>my display aspect ratio for 704x368 would be (704 * 10 / 11) / 368
>(aka 640:368) which is 1.7391.
Yep, those numbers look correct.
>Maintaining field parity is very important, and assuming that when
>given the parameter of "-fs" MPlayer _centers_ the image veritcally, I
>really should only crop either 56 or 58 lines so that an odd field
>starts on a odd line and and even field starts on an even line. Is
>this a correct assessment?
Actually, I would think that if your cropping utility were interlacing-aware,
it wouldn't allow cropping by an odd number of lines to begin with.
Anyhow, I get the feeling that most of your problems are related to
interlacing. I don't know anything about MPEG4, but I suspect that
the info that your source is interlaced isn't being encoded, or that
mplayer isn't treating it as interlaced when you finally play it back.
>From your first email:
>With the TV-Out, I also get some inverted field parity artifacts
>throughout (although not a complete field inversion) the display. To
>give an example, if I cpature a television broadcast with a horizontal
>running text banner on the bottom of the screen, like CNN, the top
>half of the text in the banner has proper field parity while the lower
>half is inverted -- so only some lines of the display are inverted,
>not all. If I override the aspect ratio when playing to the
>television with -aspect 4:3, the picture looks good again with no
>top/bottom borders and field parity looks correct. So the aspect
>seems to want to be 4:3.
Your original source was in fact 4:3, display aspect ratio (as you
know by now). It seems like the output was getting scaled vertically,
slightly, and was being treated as non-interlaced. Since each frame was,
in fact, two interleaved fields, the scaling caused the fields to mix
gradually and eventually swap places.
If the G400 TV-out isn't actually interlaced (i.e. its framebuffer isn't
actually aware of the temporal ordering of the fields), you might be better
off deinterlacing your video before MPEG4 encoding. (If the G400 TV-out
is truly interlaced, tell me how you did it, because I have a G400, and
it would be good to know it does that! :)
-matt m.
ps: Another interlacing issue: if your frame data is in JPEG 4:2:0 chroma
subsampled format (which it definitely starts out as in MJPEG), then,
in interleaved frames (two fields), each chroma scanline will actually
correspond to *every other* luma scanline (i.e. a pair from one field).
If the output decoder/device isn't aware of the interlacing, it will
end up mixing the chroma together between fields. Yechh.
4:2:0 encoded Upsampling Chroma
scanlines Right Wrong
-------------------------------------
Yt0 Ct0 ----> Ct0' Ct0'
Yb0 Cb0 Cb0 Ct0'
Yt1 Ct0' Cb0'
Yb1 Cb0' Cb0'
Yt2 Ct1 Ct1' Ct1'
Yb2 Cb1 Cb1' Ct1'
Yt3 Ct1' Cb1'
Yb3 Cb1' Cb1'
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
