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 <walken@zoy....> 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
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.
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.
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).