On Mon, Feb 10, 2003 at 02:36:21PM -0500, Matto Marjanovic wrote: > > >If you plan HW playback it is not wise to crop the images to a unusal > >size. You should use there the yuvscaler -I > >ACTIVE_widthxheight+xoffset+yoffset for setting everything outside the > >area to real black. You can also use yuvdenoise for that. > > I second that. And, to plug my own program: > > y4mscaler -I active=WIDTHxHEIGHT+0+0cc -O scale=1/1
:-) Not hardware playing back though. MPlayer on a G400, TV-Out to CRTC2 (more below). On Mon, Feb 10, 2003 at 02:09:50PM -0500, Matto Marjanovic wrote: > > Hmm... how many bits do true black bars waste? I dunno to tell you the truth. But since it's an analog cable broadcast I am encoding, I bet they are not the "solid black" that would waste only few bits. > Just curious --- 'cause > this cropping might make things complicated. (What are these black bars > from? Letterboxing or something else?) Yeah. Some television broadcasts are coming in a "letterbox" format now. > Yep, those numbers look correct. Good. I tried it out and the results look good. I don't seem to have any inverse field parity problems (smooth motion and flicker free). > 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. 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. > Anyhow, I get the feeling that most of your problems are related to > interlacing. Well, since my output device is interlaced (television) maintaining the interlacing and parity is important. > 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. Doesn't matter actually, as long as field parity is maintained, because mplayer outputs both fields at the same time in a non-de-interlaced frame every 1/29.97 seconds, and the G400 takes that full frame and displays each field for 1/59.94 seconds maintaining the field parity. > Your original source was in fact 4:3, display aspect ratio (as you > know by now). Right. > It seems like the output was getting scaled vertically, > slightly, Right, because I was calculating my display aspect ratio at 704:height rather than 640:height. I knew that. What I didn't understand was how 704:480 was considered 4:3. The explanation of television pixels being 10:11 made it all come together. > 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. Yup. That sounds reasonable. > 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. True, but by G400 TV-out is aware of interlacing and displays interlaced fields properly for 1/59.94 of a second. > (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! :) Check out DirectFB. Anything past 0.9.15. You should of course use the latest (0.9.16 IIRC) as it will have the latest and greatest in it. DirectFB has an option to use the CRTC2 output in what is called "DVDMax" mode in the Windows Matrox drivers. This essentially gives you an overscanned, interlaced picture which with good material, is indistinquishable from broadcast (or DVD or whatever). Very much well worth it if you have a G400 and the CRTC2 pigtail cable. > 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). OK. I must admit that you have just gone over my head with what I know about video. > If the output decoder/device isn't aware of the interlacing, it will > end up mixing the chroma together between fields. Yechh. What is the visual result? Is it catastrophic (i.e. anyone and everyone will notice it) or is more subtle that only videophiles will notice? I use mencoder to convert lavrec's MJPEG to MPEG4 using FFmpeg's libavcodec. The results seem to be fine. b. -- Brian J. Murrell
msg00686/pgp00000.pgp
Description: PGP signature
