On Sat, Nov 07, 2009 at 12:19:49PM +0100, Miroslav Rovis wrote: > >> No, you misunderstand: -fps 25 tells MPlayer to assume the input to be > >> _exactly_ 25 fps no matter what, ignoring completely when the data arrives > >> from the capture card. > >> If you have a broken part in the video, it will not be able to capture _any_ > >> frames, so during that time it is actually 0 fps, and with -fps 25 you explicitly > >> _forbid_ MPlayer to correct this. > >> There is also a fps option for -tv which is something else and which is supposed > >> to work in a saner way. > >> Still, to handle it properly you'd need support for variable frame-rate in-/output > >> which MPlayer does not have. > >> > > I see now. Thanks for bearing up with me so nicely... > > ...thanks to your patient explanation. Trials follow... Aaarrghhh! > > > Ermmmhh... No variable frame-rate support... > What I can say is. this command gives such quality which I don't get > anywhere near with on Windoze: > > mybox # mencoder -ofps 25 -noskip -mc 0 -vf softskip,harddup tv:// -tv > input=1:driver=v4l2:device=/dev/video0:normid=3:input=1:alsa:adevice=hw.0:audiorate=48000:amode=1:width=768:height=576 > -ovc lavc -of mpeg -mpegopts muxrate=36000:tsaf -lavcopts > vcodec=mpeg4:autoaspect:vbitrate=8000:turbo -oac mp3lame -lameopts > cbr:preset=standard -endpos 14880 -o hvk307_`date +%H%M%S`.mpg [snip] That is a bit too much text, I am a bit confused as to where the issues are... So you now leave out the -fps, does that change anything with respect to the A-V sync issues? Without it in principle MPlayer should be able to handle it, even if not perfectly. I guess you'll have to remove -noskip -mc 0 though, possibly even use -mc 100. You could also try FFmpeg, it has variable-framerate support and also supports capturing from v4l2. Also if you do not care much about size and have a slow PC, you should remove bitrate from lavcopts and instead add vqscale=2:mbd=0 > BTW, for newbies who might need to understand. The latter command is a > fine improvement to the former. It allows some seeking through the > stream being captured. The former doesn't. With the former it is > necessary to issue something like: > mencoder -forceidx stream.avi -ovc copy -oac copy -o stream_SEEKABLE.avi > And that is a nuissance when you have a 5GB or 10GB file which you don't > know at which point of the tape it is... You can just use mplayer -forceidx to play the file, or anything that uses libavformat (e.g. mplayer -demuxer lavf) and seeking should be possible and more reliable than with MPEG.
