On Wed, 7 Jul 2004, Matto Marjanovic wrote:
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.
Well I tested this by feeding a progressive DixV movie to mplayer and outputting it as interlaced yuv4mpeg. mpeg2enc showed no warnings and produced a good looking mpeg2 stream. So, MPlayer is actually creating an interlaced stream.
>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.
Well, apparently not. if it did, my little test above would have failed.
>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 have no idea. The source is a bttv video grabber that outputs 25 interlaced-looking frames per second. If I use mplayer to split the fields into two seperate frames and play the output of the capture card at 50 frames per second, it looks *really* smooth. So, I guess this grabber card is doing the right thing.
>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.
Yes, mplayer is said to be extremely messy. But it is the most powerful video processing tool available, AFAIK.
In my experience, this means that fidelity is not going to be a strong point.
You mean the quality of the output will be a problem? I haven't tried using a long filter chain, but the output looks really good to me.
About any specific processing that I need MPlayer for, there is one thing. I use mplayer to decode the MJPEG video into high quality yuv4mpeg, using postprocessing filters like deblocking and deringing. It really helps reducing compression artifacts a lot, if there are any. I haven't compared it's output to the output of MJPEG tools, maybe it does the same. Another thing that I want to experiment with is adding noise. Some old videotapes look quite bad (details are gone) and adding some noise to them makes it look more crisp again. Removing color information may help as well, especially if the color bleeding is very bad.
Anyway, MPlayer is, to my knowledge, the best tool to experiment with.
>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
