Digitizing VHS tapes with mencoder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



On Fri, Apr 23, 2010 at 09:27:56AM +0200, Josef Wolf wrote:
> On Thu, Apr 22, 2010 at 05:43:40PM -0700, RC wrote:
> > On Wed, 21 Apr 2010 23:32:56 +0200
> > Josef Wolf <jw at raven.inka.de> wrote:
> > 
> > > But this results in bad aspect ratio.
> > 
> > This is quite vague.
> >  
> > > The next resolution with proper aspect and both axes multiples of 16
> > > would be 704x528. But that would mean to throw away about 16% of the
> > > pixels. I'd rather not throw away _that_ much.
> > 
> > No amount of cropping will EVER change your aspect ratio...  You can
> > scale up/down the height/width, you can add black bars, or you can set
> > an aspect ratio in the file.  
> > 
> > x264 should pickup the current aspect ratio, adjust for crop/scale and
> > put that in the file.  Examine the output to determine why it is not... 
> > You should be able to change the aspect x264 chooses by providing
> > different values to -vf dsize while encoding.
> 
> Does that mean that the only thing I need to do is to remove the -aspect
> option when encoding?
> 
> But then I would need to add the -aspect option when capturing, right?

So now I capture with

  sudo ionice -c 1 nice -n -20 mencoder tv:// -tv driver=v4l2:mjpeg:width=768:height=576:input=1:fps=50:quality=100:norm=pal:buffersize=100:forceaudio:alsa:adevice=hw.0,0,0:amode=1:immediatemode=0:outfmt=yuy2 -forceidx -oac copy -ovc copy -of avi -endpos 4:10:00 -o outfile.avi

Here, I use fps=50 to avoid missing frames. I think this should be OK since
mencoder detects duplicate frames and throws them away. To get correct speed,
I use ofps=25 later when encoding.

File size is about 1.3 GB per minute. This does _not_ change when I use
fps=25. In some howto's, I read that file size should be about 690MB per
minute. Any ideas why I get the double file size? Those huge files (about
320 GB per tape) are dramatically slowing down my conversion process, since
I can not work on two or even more conversions in parallel.

Since I use the hardware mjpeg encoder while capturing, system load is low
and I _could_ encode and/or view (to check quality, find positions where
to snip the recordings) previous captures at the same time _if_ the files
would fit on the disk :-(

Instead of decimation=1, I use width=768:height=576 to get correct aspect
ratio. Will this reduce the quality of the captured frames? I guess using
the native resolution of the bt848 chip would give me the best results.
But what is the native horizontal resolution of the bt848 hardware? Is it
768 or 720 or 704? I find all those different numbers in articles describing
PAL.

The bt848 data sheet says that the chip has cropping support. But I can't
find an option to activate this HW cropping. I guess using HW crop would
reduce the amount of data written to the disk during capture. The risk of
loosing frames because the disk is too slow would be reduced then.

Once captured, I use this command to encode:

  nice mencoder -forceidx -ofps 25 \
    -ovc x264 -x264encopts me=umh:nr=400:partitions=all:trellis=2:crf=25:threads=4 \
    -oac mp3lame -lameopts preset=standard:mode=2 -srate 44100 \
    -vf yadif=0,harddup,crop=752:560:8:8 -mc 0 -noskip \
    -o outfile.avi infile.avi

I tried to use -ss and -endpos options to encode only specific parts of
the recording. But those don't seem to work. The whole files is encoded
no matter whether I use those options.

Any suggestions?


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux