>On Tue, 6 Jul 2004, Matto Marjanovic wrote:
 >
 >> 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".
 >
 >You were right, MPlayer was generating a progressive datastream, because 
 >the MJPEG avi appears to be stored in progressive format. I don't 
 >understand why, it would make more sense if it was stored in interlaced 
 >format as it was captured from TV. But that doesn't matter, because you 
 >can have MPlayer output it in interlaced format anyway. If you say:
 >
 >mplayer movie.avi -vo yuv4mpeg:interlaced
 >
 >or
 >
 >mplayer movie.avi -vo yuv4mpeg:interlaced_bf
 >
 >if your source has bottom fields first, MPlayer will output an interlaced 
 >stream. These options of the yuv4mpeg output driver are not documented, 
 >but I found a CVS commit that adds this option.

There is a difference between "producing a stream whose header claims
 to be interlaced" and "producing an interlaced stream".  I've never
 really looked at the mplayer source code myself, but my (cynical) guess
 would be that this option does #1, not #2.

 >So, although the captured avi is stored in progressive format, I can make 
 >MPlayer re-interpret it as being interlaced and output interlaced 

And, I don't know if this secret option changes how mplayer interprets
 the *input* stream, which is going to affect all of the processing that
 mplayer does on the stream before pumping it out as YUV4MPEG2.

 >yuv4mpeg. I don't have access to a videocapture box rightnow, so I cannot 
 >test this interlaced output. Hopefully it will work.

Cross your fingers, but don't hold your breath....

Recall that digital video is like drugs:  you gotta know your source, or
 you're gonna get burned.  Is your source stream mis-tagged as progressive?
 Or, is it interlaced temporally disjoint fields, which have been subsampled
 progressively (bad!)?  Or, a half-size grab of every-other field from TV
 (which is thus truly progressive)?

 >I am developing a simple Kommander GUI to capture video and burn it to 
 >DVD. It's just that I want to have a lot of processing possibilities at 
 >hand so that's why MPlayer is my weapon of choice. There is nothing 
 >specific that I miss about the MJPEG Tools. Also, I don't think that it 
 >should try to offer as many processing possibilities as MPlayer has.

Good luck.  mplayer is cool in that it plays just about anything, but I
 get the impression that it has a reputation of being a big hacked-together
 mess of code.  In my experience, this means that fidelity is not going to
 be a strong point.

 >Thanks for helping me out,

You're welcome.
(It was about time for me to come out of my spider-hole and try to be
 helpful again.)

-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

Reply via email to