[mythtv-users] VIDIOCMCAPTURE0: Device or resource busy

[Andrew M. Bishop]

"David Madsen" <david.madsen at gmail.com> writes:

>>> I have a bttv card and experienced the problem with kernel 2.6.25 and
>>> 2.6.26 which stopped me using them with MythTV.  Because of this I
>>> switched back to 2.6.24 which was fine.  When this patch came out I
>>> tried it and at first it seemed to work; I could upgrade to kernel
>>> 2.6.26 and record with MythTV.
>>>
>>> After a while though I realised that the recordings were poor quality.
>>> During playback there were frames displayed at the wrong time, these
>>> are most easily seen when editing a recording.  For example I saw that
>>> one interlaced field in a frame should actually have been about 7
>>> frames earlier (estimating from a fast moving picture).  This occurs
>>> every second or so (it isn't regular) and only causes a visual
>>> disturbance with fast moving scenes.  The problem was definitely in
>>> the recorded data, not playback.
>>>
>>> Since switching back to kernel 2.6.24 and backing out the patch
>>> everything seems to be back to normal.

> I took a closer look at a few of a few of my most recent recording
> from the bttv tuner and didn't see anything similar to what you
> mentioned.  Do you see these misplaced frames regularly?  I
> singlestepped frames through about 1 minute blocks in several
> different places throughout the recordings and didn't find anything
> like what you described.

If it was fast moving pictures then in 1 minute of frame-by-frame I
would have expected you to see something.  In normal playback on slow
moving pictures some of them are too small to notice.  I would
estimate that they are every few seconds.


> My recording profile details:
> Mpeg4
> Resolution: 640x480
> Bitrate: 3300
> Max quality: 2
> Min quality: 15
> Quality diff between frames: 3
> +Scale bitrate to frame size
> +Enable high quality encoding
> +Enable 4MV encoding
> -Enable interlaced DCT encoding
> -Enable interlaced motion estimation
> Num threads: 1

I have been using MythTV on the same computer for a very long time.  I
have always used the rtjpeg option instead of mpeg4 because it lets me
encode two inputs and play back a third one at the same time.

Resolution 480x576 (PAL)
Codec: RTJPEG - quality=100, chroma=0, luma=0

> As far as the tuner itself:

> bttv: driver version 0.9.17 loaded
> bttv: using 8 buffers with 2080k (520 pages) each for capture

I also have 8 buffers, but with 2.6.24 it doesn't print this by default.

> bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
> tveeprom 1-0050: Hauppauge model 37381, rev B123, serial# 205xxxx
> tveeprom 1-0050: tuner model is Philips FM1236 (idx 23, type 2)
> tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
> tveeprom 1-0050: audio processor is MSP3430 (idx 7)
> tveeprom 1-0050: has radio
> bttv0: Hauppauge eeprom indicates model#37381
> bttv0: tuner type=2

bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
tveeprom 1-0050: Hauppauge model 44354, rev B121, serial# 2111677
tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5)
tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 1-0050: audio processor is MSP3415 (idx 6)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#44354
bttv0: tuner type=5

bttv1: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
tveeprom 2-0050: Hauppauge model 44354, rev D142, serial# 2645728
tveeprom 2-0050: tuner model is Temic 4009FR5 (idx 42, type 20)
tveeprom 2-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 2-0050: audio processor is MSP3415 (idx 6)
tveeprom 2-0050: has radio
bttv1: Hauppauge eeprom indicates model#44354
bttv1: tuner type=20

We have similar hardware, but obviously different frame rates.


If the V4L1 and V4L2 interfaces were passing exactly the same data to
MythTV then there can be no difference in encoded picture.  Since I am
seeing something it must be a V4L1 / V4L2 difference because the input
data to MythTV would be the same otherwise.


If others are not reporting the problem then go ahead and apply the
patch.  Don't delete the code that does V4L1 though so that I can
patch it back in again.

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop                             amb at gedanken.demon.co.uk
                                      http://www.gedanken.demon.co.uk/