# linux-3.9 oss/alsa and mencoder framedrops for tv://

## mv

Hello,

since ages I had huge delays when I used mencoder with alsa. For instance, a line like

```
mencoder -tv driver=v4l2:device=/dev/videotv:input=2:width=768:height=576:alsa:audiorate=44100:forcechan=2:amode=1 -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:v4mv:vbitrate=4000 -oac copy -o 1.avi -- tv://
```

would cause insane framedrops and produce a result with only about 1 frame per second (on a machine which is certainly fast enough). When using OSS emulation instead (i.e. dropping ":alsa" in the above line) there never was such a prolblem. This was always independent of the sound card, i.e. it happened with my 

```
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01)
```

 as well as with e.g. usb-webcam. I read somewhere that this should be normal since the alsa-architecture causes huge delays.

I have neither  jack nor pulseaudio installed (and SND_JACK is not enabled in the kernel).

Unfortunately, since kernel-3.9, OSS emulation has the same delay as well, i.e. mencoder has become unusable.

Anybody had the same issue or (even better) an idea how to fix it?

I upgraded to linux-headers-3.9, to newest testing alsa-lib/alsa-utils and reemerged mplayer afterwards - no improvement. Also enbling SND_JACK in the kernel did not change anything.

----------

## salahx

Try using ffmpeg/avconv instead:

Something like this should work:

```
avconv -f video4linux2 -s 768x576 -i /dev/videotv  -f alsa -ar 44100 -ac 2 -i hw\:1,0 -c:v mpeg4 -c:a copy -vb 4000k -y 1.avi
```

You might want to try a minimal command line and build up if it doesn't work as hoped:

```
avconv -f video4linux2 -i /dev/videotv  -f alsa  -i hw\:1,0 -c:v mpeg4 -y 1.avi
```

(assuming here hw:1,0 is the audio output of your capture device. Replace it with the correct value if its not)

----------

## mv

 *salahx wrote:*   

> Try using ffmpeg/avconv instead

 

Similar problem, only that it even shows no framedrops: Sound and video in the recording start to desynchronize immediately, desynchronization increases over time - after 1 minute there is no relation anymore between image and sound.

This is not surprising, since all three use essentially the same codebase...

----------

## Ant P.

Try replacing avi with mkv - I've had similar problems with screen recording and the latter seemed to help with a/v desync.

----------

## mv

With mkv the hangs just become clearly visible.  I am afraid that there is a new oss emulation in the kernel which "blocks" the recording somehow.

As a side note, I would much prefer to get mencoder working, not a poor man's substitute: ffmpeg and libav both record interlaced (maybe I must set an option to avoid this, but I would not like to add a filter which reduces quallity when mencoder obviously does not need such a filter; I think mencoder just "talks" to the hardware in a more appropriate way), and some things which I occassionally need like setting brightness/hue/saturation of the tv card do not seem to have analogous options at all. I think this was also historically so: ffmpeg was part of mplayer/mencoder (at least in a way) but originally not meant as a replacement, and what I heard libav even followed the policy to remove some functionality - in my experience mencoder was always superior (and had a much more userfriendly commandline interface, anyway).

----------

## mv

I still have not solved the original mencoder issue, but at least I have solved part of the riddle why ffmpeg/libav have produced so much inferior quality - I can use them now for recording, although it is not perfect yet (see the last paragraph in the posting):

My full commandline (here for ffmpeg, but for libav it was similar) has always looked roughly like this:

```
ffmpeg -f video4linux2 -channel 2 -i /dev/videotv -vf crop=720:416:24:,hqdn3d,yadif -b:v 4000k \

  -f oss -i /dev/dsp -ar 44100 -ac 2 -c:a libmp3lame -q:a 0 -b:a 128k -b:v 4000k -- 1.avi
```

This had appeared logical to me: First the input device for the video, then the filters for the video, then the input device for the audio, then the data for output encoding.

However, correct would have been another order: The video filters must appear after the audio input. More precisely, the following worked:

```
ffmpeg -f video4linux2 -channel 2 -i /dev/videotv -f oss -i /dev/dsp -ar 44100 -ac 2 \

  -c:a libmp3lame -q:a 0 -b:a 128k -vf crop=720:416:24:,hqdn3d,yadif -b:v 4000k -- 1.avi
```

In fact, the first line was accepted but the filters were ignored without any errors so that actually interlaced data was compressed which produced poor quality, of course. I do not understand why this order is necessary, but now it works   :Smile: 

With lame and CBR 128k also the audio-video-desynchronization has vanished, and there are no more hangs.

Sometimes (e.g. whenever I was starting avidemux) the above command fails because the TV card reports only half a resolution in width and height. When I record briefly with mencoder (although I get then dropped frames) the issue is repaired, i.e., afterwards the above ffmpeg command works again. It looks like mencoder sends some initalization sequence(s) to the TV card which ffmpeg/libav fails to send.

----------

