>I am trying to create an interlaced MPEG2 stream using mpeg2enc, but >mpeg2enc warns me that I am feeding it progressive video and the chroma of >the output is all messed up. It says: > >++ WARN: [mpeg2enc] Interlaced encoding selected with progressive input! >++ WARN: [mpeg2enc] (This will damage the chroma channels.) > >I had to use the -I2 flag to tell mpeg2enc to create a interlaced >output, because the input is interlaced video as well. mpeg2enc
(Secondary question: Why "-I2" instead of "-I1"? "-I2" invokes a deprecated field-encoding mode; however, both force processing as interlaced.) >gets it's input from a named pipe that is written to by MPlayer >(yuv4mpeg output): > >mplayer film.avi -vo yuv4mpeg > >The avi file contains some MJPEG encoded PAL video captured from >TV, so it is interlaced material. At least, it looks that way. But >mpeg2enc thinks otherwise. > >I think it's a bit strange that mpeg2enc knows it's not interlaced. >Progressive or interlaced is a matter of how the video data is >interpreted, right? How can I tell mpeg2enc to treat the input as >interlaced video? mpeg2enc only knows what the stream header tells it --- pipe the output of mplayer into "head -1" and you can see for yourself. My guess is that mplayer is indicating "Ip" for "progressive/non-interlaced". The progressive/interlaced question is not subject to "interpretation"; it fundamentally, but subtly, affects the structure of the data, so it has to be respected or the data gets a mangled. In the temporal realm, it affects whether or not adjacent scanlines were sampled at the same point in time. In the spatial realm for 4:2:0 material, it affects how the chroma subsampling is performed, and this is the root cause of the warning you quoted above. Interlaced 4:2:0 streams have each field's chroma planes subsampled independently; progressive 4:2:0 streams have the entire frame's chroma subsampled as a unit. The MPEG-2 stream has a marker indicating how this subsampling was performed, and mpeg2enc sets this marker depending on the 'I' tag in the stream header, or the user's overriding command-line preference. The marker is used by the MPEG player to determine how to decode/upsample the chroma. If your original source is indeed MJPEG encoded PAL video captured from TV, then it *should* be an interlaced 4:2:2 stream. The question then becomes, just what is mplayer doing to convert it to 4:2:0? Perhaps the header that mplayer produces is wrong; perhaps mplayer is deinterlacing, and the header is correct; perhaps mplayer is just dropping chroma scanlines and thus hopelessly (albeit subtly) mangling the stream. >I don't want to use mjpegtools to feed the avi file to mpeg2enc because I >need to do some processing that only MPlayer can do. That's why I have to >feed MPlayer generated yuv4mpeg video streams to mpeg2enc. Out of curiousity, what processing are you trying to do? Maybe you'll inspire someone to add a tool to the mjpegtools-box. -matt m. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
