On Fri, 9 Jan 2004, George Kola wrote:
> That was a problem. I found that smil-utils-0.1.3 was released. I
> tried that and had problem with reading after 62% of the DV file. I picked
Interesting. What was the nature of the problem? Did smil2yuv
coredump or declare the file to be somehow broken?
> the version from CVS and it worked like a charm. Thanks for the suggestion.
Ah, super! It has been a while since 0.1.3 was released and there
have been numerous changes/fixes since then (as well as several new
utilities and filters).
> I was using libdv-0.99. I now picked up the latest from CVS.
Great. The libdv project does not release often so I have used the
CVS version for a long time (same thing for Kino).
> > checking libavcodec version (build >4644)... yes
>
> Originally, it was not finding it. Now I pointed it correctly
> and I get the line as above and it uses libavcodec.
Wonderful.
> I am able to generate VCD successfully. But I am having problem with mpeg-2.
> I am using
>
> smil2yuv -i 2 ../test.avi 2>smil.err | yuvdenoise -S 0 -l1 2>yuv.err |
> y4mscaler -O chromass=420_MPEG2 2>y4m.err |mpeg2enc -f 8 -M 2 -E -10 -2 1 -q
> 6 -K kvcd -o test.m2v >mpeg2.out 2>mpeg2.err
Good choice of parameters. If the filesize is not too large you
can use the TMPGEnc tables ("-K tmpgenc") for slightly higher
quality.
> (test.avi is a 13GB ODML DV file)
>
> I find that, the final mpeg2 generated contains only 16.39 minutes of video.
I'm curious - how was the playing time measured - with 'mplayer'?
> I generated the wav using smil2yuv -a test.wav and the audio is fine -- full
it is also possible to do both the video and audio at the same time -
just add the "-a test.wav" to the command:
smil2yuv -a test.wav -i 2 ...
> 1 hour. Similarly the MPEG-1 VCD is full 1 hour. Only the mpeg2 video is not
> fine. I am at a loss. If I dump the output of smil2yuv to disk, I get a 52 GB
> file (DV file is 13 GB), so that seems about right. None of the tools report
> any error.
The .y4m file was created with this I presume:
smil2yuv -i 2 ../test.avi |yuvdenoise -S 0 -l1 |y4mscaler -O chromass=420_MPEG2
> test.y4m
> [fireplace:mpeg2]$tail -3 y4m.err
> INFO: [y4mscaler] Frame number 107913
> INFO: [y4mscaler] Frame number 107914
> INFO: [y4mscaler] End of stream at frame 107914.
>
> [fireplace:mpeg2]$tail -7 mpeg2.err
> INFO: [mpeg2enc] Frame end 107910 B quant=6.00 total act=2769634.95788
> INFO: [mpeg2enc] Frame end 107911 I quant=6.00 total act=2769810.90260
> INFO: [mpeg2enc] GOP start (0 frames)
> INFO: [mpeg2enc] Frame end 107912 B quant=6.00 total act=2769827.68565
> INFO: [mpeg2enc] Frame end 107913 B quant=6.00 total act=2769844.56189
> INFO: [mpeg2enc] Guesstimated final muxed size = 803803550
> I think mpeg2enc may be the problem. I do not know if I need
> to pass any other option. The MPEG-2 is for archival purpose that
But mpeg2enc has logged that it encoded all 107913 frames. What does
"ls -l test.m2v" say? mpeg2enc's estimate is 803803550 (which
includes a 224k audio stream unless -B has been used).
No other options are required that I can think of.
What happens if you do something like this with the 52GB file:
mpeg2enc -f 8 -M 2 -E -10 -2 1 -q 6 -K kvcd -o testing.m2v < BIGFILE.y4m
Is the resulting file still only ~16 minutes?
> I have tried just passing output of smil2yuv to mpeg2enc and got the
> file with the same size.
And that size is? ;)
Another thing to try is:
smil2yuv test.avi |yuvplay -c
and see if the entire video portion of the movie is being output by
smil2yuv. Without the -c that would take ~1hr but with the -c
it will play as fast as your system can decode/display the data.
> For the successful VCD, I used
>
> smil2yuv test.avi | yuvscaler -O VCD | mpeg2enc -f 1 -o test.m1v
Another method would be "y4mscaler -S option=sinc:4 -O present=VCD", the
sinc scaling kernel can give better looking output.
Out of curiosity what system are you doing this on?
> p/s: Thanks Steven, for helping me out.
Welcome - hope the remaining issues can be resolved, at least some
progress has been made!
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
