Re: [Mjpeg-users] Jerky Picture on MPEG1

[Steven M. S. <sms@2BSD.COM>]

On Thu, 23 Jun 2005, Jonathan Bartlett wrote:

> It's coming from an MPEG2 file that I'm trying to downsize and make MPEG1.
> It's coming off of the hard drive.  The MPEG2 file does not have these...

> > 	How are you doing the conversion from analog to digital?  What are you
> 
> 1.6.2.  I'm using yuvscaler -O VCD -n n to bring down the image size, and

	Hmmm, ok - I doubt it's 1.6.2 related.  It's been so long since I've
	had a 1.6.2 version around I've lost track of all the stuff that's
	been fixed though ;)

> just -f 1 on the mpeg2enc.  mplayer is providing the yuv stream, using its
> -benchmark option to force it not to drop frames.

	Uh oh - that could be a problem area...

	Out of 'mplayer' what does the first line of the 'stream.yuv' output
	look like?   

	When I did something like 'mplayer -vo yuv4mpeg testing.mpg' I got:

YUV4MPEG2 W704 H480 F29969999:1000000 Ip A0:0

	(if you're coming from a commercial DVD it'll probably be W720 - that's
	fine).

	Notice several things:  1) it's tagged as "progressive" (even though 
	it most definitely is interlaced),  2) The frame rate is a little
	off, and 3) The sample aspect is "unknown" (0:0) so it's probably
	being treated as "square".

	The other thing that came to mind, and I have  encountered this 
	myself is that DVDs will switch frame rates.  One DVD started out
	as '23.976' ("converted film"), then went to 29.97 (NTSC "video"),
	then back to 23.976 and so on.  It finally settled down at 24000/1001.

	If you run into A/V sync issues then that MAY be one of the problems
	you're having.  I worked around it by telling mplayer to force the
	framerate to 23.976 and drop frames as necessary.  

	Having the wrong frame rate might cause the problems you're seeing.

	Hmmm, another thought - if the field order is wrong that would cause
	the motion to be jerky.  When I use 'y4mscaler' to do the scaling
	there's the choice of which field to drop.  I am not sure if
	yuvscaler does that or averages the two fields together (basically
	deinterlacing and scaling at the same time).

> I was wondering if perhaps full-camera moves/zooms would cause there to be
> too much data to change on the screen, and it to appear as if paused while
> the parts of the frame are being updated, but I guess not.

	Too much motion would "bit starve" the encoder - that'd show up as
	blockiness not frame drops/jerks.

	If you're coming from DVD down to VCD you are losing 1/2 the
	temporal resolution -  motion won't be quite as smooth  as it was but
	I don't think it should skip/judder.

	Good Luck!

	Steven Schultz