On Wed, 22 Sep 2004, James Bigler wrote:
> I couldn't think of another way to describe it. The image in the video
> erroneously glitches. An example can be found in some temporary web
Ah, not that I know what it means - I just never thought of it
as "popping" ;) "Jerk" or "Judder" are a couple ways I've seen
used with video.
> space at http://www.sci.utah.edu/~bigler/tmp/o1.m1v (~800KB). About
> halfway through and again towards the end of the video the video seems
> to pulse or "pop". I used this command line "mpeg2enc -f 0 -o o1.m1v".
I can only seem to see the one pause/jerk towards the end. I don't
see how the encoder would do that - would seem to be in the input
data somehow.
mplayer says this when I play the clip:
VIDEO: MPEG1 640x512 (aspect 1) 25.000 fps 1152.0 kbps (144.0 kbyte/s)
25fps and the default 1152 kbits/sec - that's very low for a 640x512
frame size.
> An example of using -g 1 -G 2 can be found at
> http://www.sci.utah.edu/~bigler/tmp/o5.m1v (~800KB).
Looks fine to me ;) Looks like that was intentionally done that way
but I take your word that the jerkiness isn't intended to be there.
24 or 25 fps will have less temporal resolution than 60 fields/sec
of mpeg-2.
Now MPEG-1 DOES permit frame rates (not field rates since MPEG-1 is
progressive frame) up to 60 frames/sec. So you could generate
30fps if desired - not sure if that would help or not but it would
make the motion smoother I think.
> I'm using a 1.6.1 version distributed for Mandrake 10 official.
1.6.1? Oh my goodness - that's ancient. 1.6.2 is even getting a bit
old but that did fix quite a few things from 1.6.1.
It might be worth upgrading that - not sure if it'll fix the problem
but if there is a problem then it'll get fixed in the current version
not something almost a couple years old...
> My system is a dual 2GHz Xeon system running Mandrake 10. Should I not
> be specifying -q of 3 or less on this architecture?
It's an Intel/AMD/"pc" architecture, right? -q of 3 or less has
been observed to artifact - arithmetic overflow in the DCT as I recall.
Altivec (PPC) architectures appear not to have the same problem.
> But the results should be better with the -H option instead of without
> correct?
Well, at 1152 kbit/s things are so bitrate constrained that the
quantization matrices that are used won't make any difference ;)
> I'm using xine to play back the video. I've discovered with further
At the moment I am using MPlayer. It's interesting to play back
the videos (both o1 and o5) at 1 frame/sec. The jerkiness is plain
to see but it's as if the generated data was like that in the first
place. Looks as if frames are out of order - if I saw something like
that from a video capture I'd say there was a field order inversion.
> I had to increase the video buffer size (I used -V 500). I guess the
> default video buffer size was limiting the effective bit rate of the video.
Ah yes - the default is 46KB and that would constrain the bitrate to
a low (1152kb/s level.
> > You are using the necessary options for VBR (Variable Bit Rate) I
>
> I've been using -q 4. I've tried other values, but they don't seem to
> make a huge difference.
Ok - that's a good value to use (and the presence of -q is what enables
VBR).
> The problem with MPEG-2 is the availability of decoders. Most Windows
> machines, for example, need a DVD player installed to get the proper
Wouldn't know about that - no windows systems here ;)
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
