On Fri, 18 Jun 2004 [EMAIL PROTECTED] wrote:
> I have found that the following:
>
> lav2yuv <filename> | yuvdenoise -F | mpeg2enc ...options... -o f.m2v
>
> yields a 30fps mpg after everything has been run through mplex. I don't
> know what exactly -F is doing here (avi is already progressive).
Well, then leave out the -F. Usually not a good idea to add options
unless it's known what they're doing or being used for ;)
The command looks the same, with the exception of yuvdenoise being
added, as the original one.
That says that the stream header is somehow being modified by
passing thru the extra stage.
I think it'd be interesting to see the stream header at a couple
points.
lav2yuv <filename> | head -n 1
will give the stream header after lav2yuv but before yuvdenoise.
Then
lav2yuv <filename> | yuvdenoise -F | head -n 1
and finally
lav2yuv <filename> | yuvdenoise | head -n 1
> If not mistaken, I have also read that the DVD standard only does progressive
> frames at 24fps.
From the DVD FAQ:
http://www.dvddemystified.com/dvdfaq.html#3.4
"Coded frame rates of 24 fps progressive from film, 25 fps interlaced from PAL
video, and 29.97 fps interlaced from NTSC video are typical. MPEG-2
progressive_sequence is not allowed, but interlaced sequences can contain
progressive pictures and progressive macroblocks."
It's unclear that you'll be able to play that unless you have a
progressive scan TV set. With DVDs that have undergone a 2:3 pulldown
the players will undo that and present the 23.976 progressive output
to a progressivescan TV - if you have a non-progressive TV then the
player does not perform the pulldown removal.
> Is it possible that because my cinelerra movie is 29fps
> progressive at the end of the it's render, that mplex is converting it
It was other than 30000/1001 at the beginning? Or was it 29.97...
interlaced at the beginning? Switching interlacing is not something
that the encoder knows how to do - the stream parameters are only
set once at the beginning of the encoding.
mplex doesn't, that I know of, do any "conversion" at all. The most
that might be happening is the wrong rate code being put in the
header - perhaps that's being caused by rate and/or interlacing
changes mid-stream.
Changing stream attributes isn't supported at the moment (the YUV4MPEG2
API has the hooks now to deal with the situation but the encoder, etc
have not been modified to handle streams that change attributes in the
middle of the stream).
Try rendering to 1 style of output for the entire stream - it'd be
interesting to see if that makes a difference.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
