On Mon, 24 Jan 2005, Trent Piepho wrote:
> On Tue, 25 Jan 2005, E.Chalaron wrote:
> > I was wondering what could be the most efficient method to slow down a movie
> > I have here some Super 8mm material that I reshoot frame by frame in ppm
I was curious how the Super8 conversion was going - good to hear it's
progressed to the stage of encoding the data.
> Or you could covert to 25fps with yuvfps, but doing that will encode the
> duplicate frames, wasting bits. It won't be as smooth either.
The duplicated frames will compress very well but I agree that the
motion will not be as smooth.
> The reason mpeg2enc is complaining is that you are trying to use NTSC frame
> rates with pal sized frames.
And square pixels. I rather thought that issue would come up
at some point when going from still photos/images to DVD :)
> > INFO: [mpeg2enc] Aspect ratio code: 1 = 1:1 pixels
>
> This is wrong, your pixels are not 1:1. Pick aspect code 2.
Many times when the "Aspect ratio code: 1 = 1:1" message is seen
it means the data has not been properly prepared prior to going
into the encoder. The right thing to do is NOT force the
aspect with "-a" but instead make sure that the data has been
correctly scaled.
From a digital camera the pixels will be square (or are there
digital cameras that use non-square pixels for still pictures?).
The next step is to use y4mscaler to resample/scale the data
using "PAL"'s SAR of 59:54. I forget which model of digital
camera Edouard finally decided on (was it the 1280x960 or the 1024x768
model?).
> > cat *.ppm | ppmtoy4m -F 18000:1000 -L |
After that and before mpeg2enc add:
y4mscaler -I sar=1:1 -O infer=exact -O sar=59:54 -O size=704x576 -S
option=sinc:6
Alternatively you could use
y4mscaler -I sar=1:1 -O sar=PAL -O preset=DVD -S option=sinc:6
but that will pad to 720 with 8 pixels on each side I think (won't
be visible on a TV set of course due to overscan).
At that point the data has been correctly "converted" from square
to rectangular pixels (preserving the display aspect ratio, etc) and
no override (-a) is needed with the encoder.
Perhaps 'yuvfps' needs to be modified in a way that the pull-up
pattern could be specified - that would seem to be a good thing
to have about now ;)
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Mjpeg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
