On Mon, Feb 10, 2003 at 05:51:06PM -0500, Matto Marjanovic wrote: > > Isn't this: > > >True enough. But the cropping tool is mencoder, which is quite > >generic. From what I have been told, A'rpi (mencoder > >author/maintainer) doesn't much care for interlace output, so > >everything is (de-interlaced to) progressive anyway. > > mutually exclusive with this: > > >Well, since my output device is interlaced (television) maintaining > >the interlacing and parity is important. > > ? ;^)
No, not really. A'rpi not caring about interlaced output devices simply means that he does not design around/for them. He is not actively plotting against them or anything, just apathetic about them. Video output drivers in MPlayer for instance, AFAIK, have no way of knowing the field parity of the input stream. Fortunately, I think the reality of which field comes first in a lot of video streams is much more biased than the statistical probability of it. I can't really say much authoritatively here as I have not really analysed the demuxing code in MPlayer. From my POV, it seems to "just work". > How does the G400 know which field to display first, if the interlacing > information isn't maintained somewhere in the datastream? (A field has > two "parity" bits: top-bottom and first-second.) Well, you see, this is the reference I have above to difference between real-world practice and the statistical odds of which field comes first. I agree that the video out driver in MPlayer (dfbmga for the G400 with interlaced TV-Output support) needs to know which field is first in the video-stream. In fact, I have an experimental version of the G400 CRTC2 support code in DirectFB in which you specify which field is first and DirectFB keeps the field parity (right now code from CVS, dfbmga has to keep parity itself). There is no way that I know of to get that information from above the video output driver in MPlayer though so it's always set to 0 and (seems to) always works. I don't know about the Matrox Marvel (which I have and use lavrec to capture from), but the bttv driver (apparently) always delivers even (or is it odd?) field first, so in the case of somebody capturing with bttv and playing with MPlayer, which field comes first in the VO driver can be a static value. > I'm not trying to pick a fight Not at all. Yours are all valid points. > it's just not apparent to me what is > really happening with the interlacing. I think a lot of it (the field ordering) is luck. Or rather just "standard practice". > Either (1) it is being preserved > throughout the chain; In the case of MPlayer, I can tell you that the video out driver is not adjusting the G400 according to input parity. Maybe the demuxer in MPlayer is correcting for when fields are not top-first -- i.e. dropping a bottom-first field or something. I doubt it though. This would be A'rpi's apathy for interlaced output devices. If you don't care about interlaced output, it doesn't matter which field comes first as you will just do some kind of de-interlacing/smoothing/blending operations with adjacent fields anyway. > (2) the initial mencode is deinterlacing, so the > issue is no longer an issue; Nope. I am fairly certain that the MPEG4/AVI I get out of mencoder is interlaced due to all of the trouble not maintaining field parity has caused me. It's only been in the last couple of weeks or so that I finally nailed down the problem (with lots of help from Ville Syrj�l�, the author of the CRTC2 support in DirectFB) of field parity in MPlayer. I was seeing lots of interlace artifacts (on the TV-Out!) before that. > or (3) you've been lucky so far with your > G400/DirectFB choosing the correct field dominance. Bingo! That is my guess. I am also guessing that the real-world odds of getting video that is top-field dominant is a lot higher than the statistical odds of it. > If you start to get > tearing/combing artifacts in the future, you'll know it's (3). I have seen my share of tearing and combing and know them very well. But since installing code into MPlayer's dfbmga driver to maintain field parity, I have not seen any of it. I am very much pleased with the results I am getting from my G400-Marvel->lavrec->quicktime->glav->mencoder->MPEG4/AVI->DirectFB/CRTC2/TV-Out->G400-TV chain, as can be evidenced by my working on "gravy" type items like cropping black top/bottom bars out of the picture. :-) My wishlist at this point is to get rid of quicktime and avi in favour of a more friendly container (>2GB in a single file and readable while being written) and adjustable horizontal "rulers" in glav that I can move up and down (think of how word processor/layout tools let you graphically set top and bottom page margins) to tell me my top and bottom crop areas. Also, automated commerical detection/deletion would be nice. I have an idea to do it based on black frame detection and the length of segments between black frames. There are other techniques which could be employed too, but IMVHO the low hanging fruit is black-frame detection. > Cool, 'cause I have both. I'll try it out, sometime, when I find that > pigtail cable... Yes, very cool. When I use a TV app (like tvtime -- which understands field parity) with DirectFB and the CRTC2 support, I can toggle back and forth between the television's native tuner and the composite input from my DirectFB powered PVR and not see a difference in picture size, overscan, or quality. > I have no idea. :-) > But, it can't be any worse than VHS, eh? I guess not. My ignorance of video prevents me from really understanding that beyond, well, VHS looks like crap. :-) b. -- Brian J. Murrell
msg00688/pgp00000.pgp
Description: PGP signature
