On Fri, 17 Nov 2006, Delio Pereira Guimaraes wrote:
> In case someone is interested in the problem, the files are here: > http://delio.homelinux.com/mjpeg/ > teste.m2v is 3.2MB and That file plays fine and is 170 frames long accoring to mpeg2dec mpeg2dec -o null teste.m2v.mpg mpeg2dec-0.5.0-cvs - by Michel Lespinasse <[EMAIL PROTECTED]> and Aaron Holtzman 97 frames in 0.50 sec (194.00 fps), 97 last 0.50 sec (194.00 fps) 170 frames decoded in 0.92 seconds (184.78 fps) > teste.mpg is 3.5MB What might be as valuable would be the 170 frames of DV data used. That would be about 20MB though so it might not be practical to make it available. The .m2v and .mpg files play OK for me so having the DV data isn't necessary. smil2raw can be used to create a 'raw DV' file. > ---------- Original Message ---------- > > Date: Wednesday 15 November 2006 16:02 I was waiting for someone else to jump in ... > 1) Capturing in kino from (old) VHS tape. > VHS -> composite video/audio -> DV Camcorder -> firewire -> kino S-Video cable for the analog side would be better of course but that would involve a S-VHS tape deck. > 3) Encoded the above generated smil, like this: Ok, it's time for my "if you don't know what an option is, if you're not sure you need an option then don't use it" lecture. There are at least 2 errors in the commands below. NO, they are probably not the cause of the problem, however 1)when you're debugging a problem the fewer options you need to vary/test the better and 2) incorrectly using an option can mask/hide errors in the data! -H is rarely a good idea with noisy material (and VHS tapes are noisy;)) but if you are going to use -H then DO NOT use "-K tmpgenc". Why? Because "-H" is the same thing as "-K hi-res" and multiple -K options means that the last one 'wins'. -H -K tmpgenc is the same as -K tmpgenc. It is almost NEVER necessary to use "-n", "-a", or "-I". mpeg2enc will "do the right thing" for '-I' automatically. If you find it necessary to use -n or -a then there is a fairly high probability that the INPUT is BROKEN. If mpeg2enc can't figure out the video standard ('n', 'p') or aspect ratio then the incoming stream is likely to be malformed and overriding the encoder's objections may produce unexpected output. It's better to find out what the problem is and fix it before the data gets to the encoder. -r 32 is harmless but all it's doing is increasing the encoding time. The default value of 16 is fine. Oh, and when debugging it's not a good thing to set the verbosity to -v 0 - the more info the better. > smil2yuv $1.smil | mpeg2enc -H -v 0 -n n -I 1 -a 2 -b $2 -f 8 -q 4 -4 1 -2 > 1 -r 32 -g 6 -G 18 -B 260 -K tmpgenc -o vid_$1.m2v > log1_$1.txt 2> Which can be rewritten as: > ... mpeg2enc -b $2 -f 8 -q 4 -4 1 -2 1 -g 6 -G 18 -B 260 -K tmpgenc -o > vid_$1.m2v > log1_$1.txt 2> On to the next error - maybe it's a cut&paste error? > mplex -f 8 -R -V -o $1.mpg vid_$1.m2v aud_$1.mp2 >> log1_$1.txt 2>> > log2_$1.txt Why are you using -R with mplex? Do you know why you need to "force a run-in of exactly 'num' frame intervals"? The error is that '-R' takes an argument. The proper usage is "-R num" and if you're not sure what a 'run-in' is then maybe you should leave out the -R option. What is happening is that "-V" is being used as the 'num' arg of "-R". That is probably not what you intended ;) -V is not needed - mplex will do variable bit rate automatically. So the 'mplex' command should be: > mplex -f 8 -o $1.mpg vid_$1.m2v aud_$1.mp2 >> log1_$1.txt 2>> log2_$1.txt > mplex -f 8 -R -V -o teste.mpg teste.m2v teste.mp2 Don't use -R ;) If you do want to use -R then give it a numeric argument. "-R num" - but I have no idea what num should be in your case. > mencoder -o /home/delio/teste.mpg.avi -oac pcm -ovc lavc > /home/delio/teste.mpg lavinfo teste.mpg.avi > ============================== > results of this script is attached as mpeg_script_results.txt > ============================== > During mencoder run, this is what happens: > ... > 1 duplicate frame(s)! > Pos: 0.7s 22f ( 9%) 0fps Trem: 0min 3mb A-V:0.070 [0:1536] > Skipping frame! > Pos: 1.5s 47f ( 9%) 0fps Trem: 0min 3mb A-V:0.067 [60:1536] > Skipping frame! > Pos: 5.6s 170f (100%) 51fps Trem: 0min 2mb A-V:0.016 [1811:1536] > Flushing video frames I haven't used mencoder is a very long time. But if it's tossing away frames that's where your length problem is coming from. > 6) More information when importing files to kino: > Importing file teste.mpg results in 166 frames > Importing intermediate video file teste.m2v results in 168 frames Simply _playing_ the .m2v file I downloaded gives 170 frames. > 7) After much of testing, one last tool in my system: Avidemux! > pened in Avidemux, great! 0:40:46.179 ! Which file did you open? The 'DV' file, the .m2v file, the .mpg file? You're converting so many times (back/forth between MPEG and DV) I've lost count ;) > The question is: What is wrong? It seems xine and mplayer can not deal with > this mpeg stream. Is it some kind of outdated libs? Old versions perhaps. Maybe newer (cvs/subversion) builds of the various tools such as mplayer and ffmpeg would help. The problem's NOT in mpeg2enc - that much is clear. The encoded .m2v file plays/decodes to the correct 170 frames. Maybe the use of -R in the 'mplex' run is creating a stream that some tools do not understand. I really DOUBT this is the case. In any event you should omit the -R ;) > ************************************ > * Information: System and Versions * > ************************************ > > Main memory: 256 MB DDR I think my video card has more memory :) 256MB has to be slowing things down a lot. > mjpegtools: 1.9.0 (2.2.6) No known bugs in the cvs version of mjpegtools ;) > mencoder: 1.0pre7-4.0.2 I think that's fairly old - have you tried the current svn version? > dvdauthor: version 0.6.11. > qdvdauthor: 0.1.0 Are those current? I haven't been following those packages. I think you're battling a mencoder/mplayer problem - along the journey the data is taking a program is silently discarding frames. Ah, it may be a coincidence but the thought just came to me that 32 minutes is exactly 80% of 40 minutes. That is the SAME percentage as 'film rate / video rate' or '24 / 30'. I wonder if something in the processing is tossing in a 24 frame/sec value instead of 30. not a lot that we can do to help - it's not an mjpegtools problem that I can see. BOTH of the sample files play/decode without problem on my Powerbook (OSX). Good Luck! Cheers, Steven Schultz ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
