* mencoder fails with Linux kernel from linus's git tree (2 Nov 2005)
@ 2005-11-03 4:26 Junichi Uekawa
2005-11-10 21:40 ` [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 " Junichi Uekawa
0 siblings, 1 reply; 24+ messages in thread
From: Junichi Uekawa @ 2005-11-03 4:26 UTC (permalink / raw)
To: linux-kernel, video4linux-list
Hi,
I've noticed that mencoder no longer works with bttv
capture on my system; with today's git tree
(ec1890c5df451799dec969a3581ff72e1934b5ee),
while it used to work on 2.6.14-rc5.
xawtv functions.
I'm looking for people who experienced the same problem,
or possibly for a fix.
The devices are:
0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
0000:03:0b.0 0400: 109e:036e (rev 11)
0000:03:0b.1 0480: 109e:0878 (rev 11)
I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's
for x86_64 architecture.
$ mencoder --version
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
--version is not an MEncoder option
Exiting... (error parsing cmdline)
Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
mencoder output on 2.6.14 (today's git)
channel: 12
minutes: 30
output filename: /home/dancer/XXX/XXX/
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices (Family: 8, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 9 data: 0x0 - 0x0
TV detected! ;-)
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski
comment: first try, more to come ;-)
Selected device: BT878 video (IODATA GV-BCTV5/PC
Tuner cap:
Tuner rxs: MONO
Capabilites: video capture video overlay VBI capture device tuner read/write streaming
supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUYV
v4l2: current audio mode is : STEREO
Selected channel: 12 (freq: 217.250)
v4l2: ioctl queue buffer failed: Bad address
Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux
mencoder output on 2.6.14-rc5:
channel: 12
minutes: 1
output filename: /tmp/aaaa.avi
MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2
success: format: 9 data: 0x0 - 0x0
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <olschewski@zpr.uni-koeln.de>
comment: first try, more to come ;-)
Selected device: BT878 video (IODATA GV-BCTV5/PC
Tuner cap:
Tuner rxs: MONO
Capabilites: video capture video overlay VBI capture device tuner read/write streaming
supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUYV
v4l2: current audio mode is : STEREO
Selected channel: 12 (freq: 217.250)
[V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420)
VDec: using Planar I420 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4])
High quality encoding selected (non real time)!
Selected video codec: [rawi420] vfm: raw (RAW I420)
==========================================================================
Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??...
MP3 audio selected
Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
Writing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Forcing audio preload to 0, max pts correction to 0
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128]
Flushing video frames
CBR audio: 16000 bytes/sec, 384 bytes/block
Writing AVI index...
Fixing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames
Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs
v4l2: 139 frames successfully processed, 0 frames dropped.
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
^ permalink raw reply [flat|nested] 24+ messages in thread* [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-03 4:26 mencoder fails with Linux kernel from linus's git tree (2 Nov 2005) Junichi Uekawa @ 2005-11-10 21:40 ` Junichi Uekawa 2005-11-10 22:58 ` Mike Krufky [not found] ` <87mzj4uoys.dancerj%dancer@netfort.gr.jp> 0 siblings, 2 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-11-10 21:40 UTC (permalink / raw) To: linux-kernel, video4linux-list, debian-amd64; +Cc: dancer Hi, I've tried running mplayer v4l2 input on a bt878 card, and it fails. xawtv works fine, and 2.6.14-rc5 used to work fine. On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 : $ mplayer tv://1 -tv driver=v4l2 MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Failed to open /dev/rtc: Permission denied (it should be readable by the user.) Opening joystick device /dev/input/js0 Can't open joystick device /dev/input/js0 : Permission denied Can't init input joystick Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://1. Cache fill: 0.00% (0 bytes) Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski <olschewski@zpr.uni-koeln.de> comment: first try, more to come ;-) Selected device: BT878 video (IODATA GV-BCTV5/PC Tuner cap: Tuner rxs: MONO Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; inputs: 0 = Television; 1 = Composite1; 2 = S-Video; Current input: 0 Current format: YUV420 v4l2: current audio mode is : MONO v4l2: ioctl queue buffer failed: Bad address v4l2: 0 frames successfully processed, 0 frames dropped. At Thu, 03 Nov 2005 13:26:25 +0900, Junichi Uekawa wrote: > > Hi, > > I've noticed that mencoder no longer works with bttv > capture on my system; with today's git tree > (ec1890c5df451799dec969a3581ff72e1934b5ee), > while it used to work on 2.6.14-rc5. > xawtv functions. > I'm looking for people who experienced the same problem, > or possibly for a fix. > > > The devices are: > 0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) > 0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) > 0000:03:0b.0 0400: 109e:036e (rev 11) > 0000:03:0b.1 0480: 109e:0878 (rev 11) > > > I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's > for x86_64 architecture. > > $ mencoder --version > MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team > CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) > Detected cache-line size is 64 bytes > CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 > Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > > --version is not an MEncoder option > > Exiting... (error parsing cmdline) > > > > > > Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux > mencoder output on 2.6.14 (today's git) > > channel: 12 > minutes: 30 > output filename: /home/dancer/XXX/XXX/ > MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team > CPU: Advanced Micro Devices (Family: 8, Stepping: 0) > Detected cache-line size is 64 bytes > CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 > Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > > File not found: 'frameno.avi' > Failed to open frameno.avi > success: format: 9 data: 0x0 - 0x0 > TV detected! ;-) > Selected driver: v4l2 > name: Video 4 Linux 2 input > author: Martin Olschewski > comment: first try, more to come ;-) > Selected device: BT878 video (IODATA GV-BCTV5/PC > Tuner cap: > Tuner rxs: MONO > Capabilites: video capture video overlay VBI capture device tuner read/write streaming > supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; > inputs: 0 = Television; 1 = Composite1; 2 = S-Video; > Current input: 0 > Current format: YUYV > v4l2: current audio mode is : STEREO > Selected channel: 12 (freq: 217.250) > v4l2: ioctl queue buffer failed: Bad address > > > > Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux > > mencoder output on 2.6.14-rc5: > channel: 12 > minutes: 1 > output filename: /tmp/aaaa.avi > MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team > CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) > Detected cache-line size is 64 bytes > CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 > Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > > success: format: 9 data: 0x0 - 0x0 > Selected driver: v4l2 > name: Video 4 Linux 2 input > author: Martin Olschewski <olschewski@zpr.uni-koeln.de> > comment: first try, more to come ;-) > Selected device: BT878 video (IODATA GV-BCTV5/PC > Tuner cap: > Tuner rxs: MONO > Capabilites: video capture video overlay VBI capture device tuner read/write streaming > supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; > inputs: 0 = Television; 1 = Composite1; 2 = S-Video; > Current input: 0 > Current format: YUYV > v4l2: current audio mode is : STEREO > Selected channel: 12 (freq: 217.250) > [V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334 > ========================================================================== > Opening audio decoder: [pcm] Uncompressed PCM audio decoder > AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) > Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) > ========================================================================== > Opening video filter: [expand osd=1] > Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1 > ========================================================================== > Opening video decoder: [raw] RAW Uncompressed Video > VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420) > VDec: using Planar I420 as output csp (no 0) > Movie-Aspect is undefined - no prescaling applied. > videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4]) > High quality encoding selected (non real time)! > Selected video codec: [rawi420] vfm: raw (RAW I420) > ========================================================================== > Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??... > MP3 audio selected > Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le... > Writing AVI header... > ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. > Forcing audio preload to 0, max pts correction to 0 > New_Face failed. Maybe the font path is wrong. > Please supply the text font file (~/.mplayer/subfont.ttf). > subtitle font: load_sub_face failed. > ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. > Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128] > Flushing video frames > > > CBR audio: 16000 bytes/sec, 384 bytes/block > > Writing AVI index... > Fixing AVI header... > ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. > > Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames > > Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs > v4l2: 139 frames successfully processed, 0 frames dropped. > > > > regards, > junichi > -- > dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-10 21:40 ` [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 " Junichi Uekawa @ 2005-11-10 22:58 ` Mike Krufky 2005-11-11 0:05 ` Junichi Uekawa [not found] ` <87mzj4uoys.dancerj%dancer@netfort.gr.jp> 1 sibling, 1 reply; 24+ messages in thread From: Mike Krufky @ 2005-11-10 22:58 UTC (permalink / raw) To: Junichi Uekawa; +Cc: linux-kernel, video4linux-list, debian-amd64 Junichi Uekawa wrote: >Hi, > >I've tried running mplayer v4l2 input on a bt878 card, and it fails. >xawtv works fine, and 2.6.14-rc5 used to work fine. > >On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 : > >$ mplayer tv://1 -tv driver=v4l2 >MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) >Detected cache-line size is 64 bytes >CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > > BTTV currently only supports v4l1. We are still in the process of porting the bttv driver from v4l1 to v4l2. Nickolay is working on it. -Michael Krufky >Failed to open /dev/rtc: Permission denied (it should be readable by the user.) >Opening joystick device /dev/input/js0 >Can't open joystick device /dev/input/js0 : Permission denied >Can't init input joystick >Setting up LIRC support... >mplayer: could not connect to socket >mplayer: No such file or directory >Failed to open LIRC support. >You will not be able to use your remote control. >Playing tv://1. >Cache fill: 0.00% (0 bytes) >Selected driver: v4l2 > name: Video 4 Linux 2 input > author: Martin Olschewski <olschewski@zpr.uni-koeln.de> > comment: first try, more to come ;-) >Selected device: BT878 video (IODATA GV-BCTV5/PC > Tuner cap: > Tuner rxs: MONO > Capabilites: video capture video overlay VBI capture device tuner read/write streaming > supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; > inputs: 0 = Television; 1 = Composite1; 2 = S-Video; > Current input: 0 > Current format: YUV420 >v4l2: current audio mode is : MONO >v4l2: ioctl queue buffer failed: Bad address >v4l2: 0 frames successfully processed, 0 frames dropped. > > > >At Thu, 03 Nov 2005 13:26:25 +0900, >Junichi Uekawa wrote: > > >>Hi, >> >>I've noticed that mencoder no longer works with bttv >>capture on my system; with today's git tree >>(ec1890c5df451799dec969a3581ff72e1934b5ee), >>while it used to work on 2.6.14-rc5. >>xawtv functions. >>I'm looking for people who experienced the same problem, >>or possibly for a fix. >> >> >>The devices are: >>0000:03:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) >>0000:03:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) >>0000:03:0b.0 0400: 109e:036e (rev 11) >>0000:03:0b.1 0480: 109e:0878 (rev 11) >> >> >>I'm using mencoder Debian package '1:1.0-pre7cvs20051102-0.0' from marillat's >>for x86_64 architecture. >> >>$ mencoder --version >>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) >>Detected cache-line size is 64 bytes >>CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 >> >>--version is not an MEncoder option >> >>Exiting... (error parsing cmdline) >> >> >> >> >> >>Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux >>mencoder output on 2.6.14 (today's git) >> >>channel: 12 >>minutes: 30 >>output filename: /home/dancer/XXX/XXX/ >>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >>CPU: Advanced Micro Devices (Family: 8, Stepping: 0) >>Detected cache-line size is 64 bytes >>CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 >> >>File not found: 'frameno.avi' >>Failed to open frameno.avi >>success: format: 9 data: 0x0 - 0x0 >>TV detected! ;-) >>Selected driver: v4l2 >> name: Video 4 Linux 2 input >> author: Martin Olschewski >> comment: first try, more to come ;-) >>Selected device: BT878 video (IODATA GV-BCTV5/PC >> Tuner cap: >> Tuner rxs: MONO >> Capabilites: video capture video overlay VBI capture device tuner read/write streaming >> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; >> inputs: 0 = Television; 1 = Composite1; 2 = S-Video; >> Current input: 0 >> Current format: YUYV >>v4l2: current audio mode is : STEREO >>Selected channel: 12 (freq: 217.250) >>v4l2: ioctl queue buffer failed: Bad address >> >> >> >>Linux dancer64 2.6.14-rc5dancer-gb563c9b1 #1 Thu Oct 27 12:55:05 JST 2005 x86_64 GNU/Linux >> >>mencoder output on 2.6.14-rc5: >>channel: 12 >>minutes: 1 >>output filename: /tmp/aaaa.avi >>MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) >>Detected cache-line size is 64 bytes >>CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 >> >>success: format: 9 data: 0x0 - 0x0 >>Selected driver: v4l2 >> name: Video 4 Linux 2 input >> author: Martin Olschewski <olschewski@zpr.uni-koeln.de> >> comment: first try, more to come ;-) >>Selected device: BT878 video (IODATA GV-BCTV5/PC >> Tuner cap: >> Tuner rxs: MONO >> Capabilites: video capture video overlay VBI capture device tuner read/write streaming >> supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; >> inputs: 0 = Television; 1 = Composite1; 2 = S-Video; >> Current input: 0 >> Current format: YUYV >>v4l2: current audio mode is : STEREO >>Selected channel: 12 (freq: 217.250) >>[V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334 >>========================================================================== >>Opening audio decoder: [pcm] Uncompressed PCM audio decoder >>AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) >>Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) >>========================================================================== >>Opening video filter: [expand osd=1] >>Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1 >>========================================================================== >>Opening video decoder: [raw] RAW Uncompressed Video >>VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420) >>VDec: using Planar I420 as output csp (no 0) >>Movie-Aspect is undefined - no prescaling applied. >>videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4]) >>High quality encoding selected (non real time)! >>Selected video codec: [rawi420] vfm: raw (RAW I420) >>========================================================================== >>Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??... >>MP3 audio selected >>Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le... >>Writing AVI header... >>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. >>Forcing audio preload to 0, max pts correction to 0 >>New_Face failed. Maybe the font path is wrong. >>Please supply the text font file (~/.mplayer/subfont.ttf). >>subtitle font: load_sub_face failed. >>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. >>Pos: 4.1s 124f ( 0%) 26fps Trem: 0min 0mb A-V:0.000 [1082:128] >>Flushing video frames >> >> >>CBR audio: 16000 bytes/sec, 384 bytes/block >> >>Writing AVI index... >>Fixing AVI header... >>ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. >> >>Video stream: 1082.222 kbit/s (135277 B/s) size: 559707 bytes 4.137 secs 124 frames >> >>Audio stream: 128.000 kbit/s (16000 B/s) size: 66048 bytes 4.128 secs >>v4l2: 139 frames successfully processed, 0 frames dropped. >> >> >> >>regards, >> junichi >>-- >>dancer@{debian.org,netfort.gr.jp} Debian Project >> >> >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > -- Michael Krufky ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-10 22:58 ` Mike Krufky @ 2005-11-11 0:05 ` Junichi Uekawa 2005-11-11 3:24 ` Michael Krufky 0 siblings, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2005-11-11 0:05 UTC (permalink / raw) To: Mike Krufky; +Cc: Junichi Uekawa, linux-kernel, video4linux-list, debian-amd64 Hi, > >I've tried running mplayer v4l2 input on a bt878 card, and it fails. > >xawtv works fine, and 2.6.14-rc5 used to work fine. > > > >On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 : > > > >$ mplayer tv://1 -tv driver=v4l2 > >MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team > >CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) > >Detected cache-line size is 64 bytes > >CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 > >Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > > > > > BTTV currently only supports v4l1. We are still in the process of > porting the bttv driver from v4l1 to v4l2. Nickolay is working on it. > Thanks for the info. It's strange since this is a regression (pre 2.6.14 used to work. New code made it fail). Do you mean there was a change that broke v4l2 support in bttv ? Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more than one and a half years...) regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 0:05 ` Junichi Uekawa @ 2005-11-11 3:24 ` Michael Krufky 2005-11-11 12:06 ` Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Michael Krufky @ 2005-11-11 3:24 UTC (permalink / raw) To: Junichi Uekawa; +Cc: linux-kernel, video4linux-list, debian-amd64 Junichi Uekawa wrote: >Hi, > >>>I've tried running mplayer v4l2 input on a bt878 card, and it fails. >>>xawtv works fine, and 2.6.14-rc5 used to work fine. >>> >>>On git 3b44f137b9a846c5452d9e6e1271b79b1dbcc942 : >>> >>>$ mplayer tv://1 -tv driver=v4l2 >>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) >>>Detected cache-line size is 64 bytes >>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 >>> >>bttv currently only supports v4l1. We are still in the process of >>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it. >> >Thanks for the info. It's strange since this is a regression >(pre 2.6.14 used to work. New code made it fail). >Do you mean there was a change that broke v4l2 support in bttv ? >Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more >than one and a half years...) > > v4l2 support could not have been broken, since it was never present. You were going through a compat layer.... Maybe that's where the regression is. Anyhow, I will discuss this with the other v4l guys... One of us will get back to you, maybe ask you to test a patch or two. One question -- At exactly what point does this break for you? The git commit key above was from today, but at what point did this LAST work for you? It would be really helpful if you can do a git bisection test, so that we can isolate the trouble patch if in fact it is a regression. You might also like to join us in #v4l on irc.freenode.net ... Sometimes it's much quicker to troubleshoot this stuff over irc instead of email. -Michael Krufky ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 3:24 ` Michael Krufky @ 2005-11-11 12:06 ` Junichi Uekawa 2005-11-11 13:11 ` Michael Krufky 2005-11-11 13:29 ` Junichi Uekawa 0 siblings, 2 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-11-11 12:06 UTC (permalink / raw) To: Michael Krufky Cc: Junichi Uekawa, linux-kernel, video4linux-list, debian-amd64 Hi, > >>>$ mplayer tv://1 -tv driver=v4l2 > >>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team > >>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) > >>>Detected cache-line size is 64 bytes > >>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 > >>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 > >>> > >>bttv currently only supports v4l1. We are still in the process of > >>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it. > >> > >Thanks for the info. It's strange since this is a regression > >(pre 2.6.14 used to work. New code made it fail). > >Do you mean there was a change that broke v4l2 support in bttv ? > >Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more > >than one and a half years...) > > > > > v4l2 support could not have been broken, since it was never present. > You were going through a compat layer.... Maybe that's where the > regression is. > One question -- At exactly what point does this break for you? The git > commit key above was from today, but at what point did this LAST work > for you? It would be really helpful if you can do a git bisection test, > so that we can isolate the trouble patch if in fact it is a regression. df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues) 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv > You might also like to join us in #v4l on irc.freenode.net ... Sometimes > it's much quicker to troubleshoot this stuff over irc instead of email. joined, but currently rebooting sporadically to test different kernels. regards, junichi ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 12:06 ` Junichi Uekawa @ 2005-11-11 13:11 ` Michael Krufky 2005-11-11 13:29 ` Junichi Uekawa 1 sibling, 0 replies; 24+ messages in thread From: Michael Krufky @ 2005-11-11 13:11 UTC (permalink / raw) To: Linux and Kernel Video Cc: Junichi Uekawa, debian-amd64, linux-kernel, Andrew Morton Junichi Uekawa wrote: >>>>> mplayer tv://1 -tv driver=v4l2 >>>>>MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team >>>>>CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) >>>>>Detected cache-line size is 64 bytes >>>>>CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 >>>>>Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 >>>>> >>>>bttv currently only supports v4l1. We are still in the process of >>>>porting the bttv driver from v4l1 to v4l2. Nickolay is working on it. >>>> >>>Thanks for the info. It's strange since this is a regression >>>(pre 2.6.14 used to work. New code made it fail). >>>Do you mean there was a change that broke v4l2 support in bttv ? >>>Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more >>>than one and a half years...) >>> >>v4l2 support could not have been broken, since it was never present. >>You were going through a compat layer.... Maybe that's where the >>regression is. >> >> >>One question -- At exactly what point does this break for you? The git >>commit key above was from today, but at what point did this LAST work >>for you? It would be really helpful if you can do a git bisection test, >>so that we can isolate the trouble patch if in fact it is a regression. >> >> >df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv >d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues) >6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv > > This info was quite helpful... Looking through gitweb, it looks like the trouble began for you BEFORE Mauro started to send our new patchsets over to akpm. If I am correct, this indicates that the problem patch is from elsewhere in the kernel. I saw a thread about some i2c related bttv problem... I don't know if that's a red herring or not, but it was also around the time that you say your kernel breaks. At this point, the best thing that you can do is run a git bisection regression test, like I had previously suggested. Linus has written a HOWTO thread about it a few months ago on LKML. Does anybody know if there is a howto online for git bisection testing? Maybe there's a copy of the thread on kerneltrap.org? just a guess... If we can narrow this down to the exact patch that is causing the problem for you, it would be a lot easier to deal with. >>You might also like to join us in #v4l on irc.freenode.net ... Sometimes >>it's much quicker to troubleshoot this stuff over irc instead of email. >> >> >joined, but currently rebooting sporadically to test >different kernels. > > Okay, well here are a few other things that I would have you try: #1) Try using v4l-kernel cvs, and tell us if you still have the problem. Since I think that the problem is occurring for you elsewhere in the kernel, using our code in cvs should yeild no change in behavior. Even though this doesn't sound promising, it can help us to prove whether v4l is responsible for this problem or not: http://linuxtv.org/v4lwiki/index.php/How_to_build_from_CVS First, try out latest cvs. Yes, there is still some new code in cvs that we have not yet sent upstream, including some compat_ioctl32.c fixes from Nickolay from this morning. #2) After testing the latest cvs, then I would ask for you to wipe out the cvs tree and try again, but using older code..... Say, from October first or so, maybe even September first. To do this, follow the same procedure in the wiki-howto above, but add the -D parameter to the cvs checkout command. ( cvs co -D 2005-09-01 -- see man cvs) I would assume that there will be no difference in behavior between the different cvs versions, but maybe you will find otherwise. #3) Another thing you can try is to build the current cvs modules against the last known working kernel. If the new cvs modules in the older kernel break it again, then it tells us that some new v4l code IS to blame. #4) Once again, the -git bisection regression testing is the best thing to do here. Regards, Michael Krufky ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 12:06 ` Junichi Uekawa 2005-11-11 13:11 ` Michael Krufky @ 2005-11-11 13:29 ` Junichi Uekawa 2005-11-11 14:06 ` Hugh Dickins 2005-11-11 14:21 ` Junichi Uekawa 1 sibling, 2 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-11-11 13:29 UTC (permalink / raw) To: Michael Krufky Cc: Junichi Uekawa, linux-kernel, video4linux-list, debian-amd64 Hi, > > One question -- At exactly what point does this break for you? The git > > commit key above was from today, but at what point did this LAST work > > for you? It would be really helpful if you can do a git bisection test, > > so that we can isolate the trouble patch if in fact it is a regression. > > df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv > d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues) > 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv That was wrong; I re-tested it and it looks like 6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one. 2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional. $ git-bisect start $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a Bisecting: 721 revisions left to test after this regards, junichi ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 13:29 ` Junichi Uekawa @ 2005-11-11 14:06 ` Hugh Dickins 2005-11-12 22:22 ` Nickolay V. Shmyrev 2005-11-11 14:21 ` Junichi Uekawa 1 sibling, 1 reply; 24+ messages in thread From: Hugh Dickins @ 2005-11-11 14:06 UTC (permalink / raw) To: Junichi Uekawa Cc: Michael Krufky, Nick Piggin, linux-kernel, video4linux-list, debian-amd64 On Fri, 11 Nov 2005, Junichi Uekawa wrote: > > > > One question -- At exactly what point does this break for you? The git > > > commit key above was from today, but at what point did this LAST work > > > for you? It would be really helpful if you can do a git bisection test, > > > so that we can isolate the trouble patch if in fact it is a regression. > > $ git-bisect start > $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d > $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a > Bisecting: 721 revisions left to test after this This is probably going to converge on the PageReserved removal patch, and the way get_user_pages now refuses on a VM_RESERVED vma. I don't want to send you a patch for that immediately, we're still thinking through the implications of allowing VM_RESERVED there again (it might just hit another BUG, or leak memory). And we probably need to take the separate "vbetool" problem into account too. Though if you're curious and impatient, you could try just editing the " | VM_RESERVED" out of mm/memory.c get_user_pages. Hugh ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 14:06 ` Hugh Dickins @ 2005-11-12 22:22 ` Nickolay V. Shmyrev 2005-11-13 2:54 ` Matti Aarnio 2005-11-17 0:07 ` Junichi Uekawa 0 siblings, 2 replies; 24+ messages in thread From: Nickolay V. Shmyrev @ 2005-11-12 22:22 UTC (permalink / raw) To: Linux and Kernel Video Cc: Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 Hello all. We have even found the hack that fix that problem: Index: linux/drivers/media/video/video-buf.c =================================================================== RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v retrieving revision 1.21 diff -u -p -r1.21 video-buf.c --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000 +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000 @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf map->end = vma->vm_end; map->q = q; vma->vm_ops = &videobuf_vm_ops; - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED; + vma->vm_flags |= VM_DONTEXPAND; vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */ vma->vm_private_data = map; dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n", Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. I don't know the exact reason of that behavior and the correct way to fix that problem. Just kernel interfaces changed once again, the old point everyone knows. So if someone can explain it, that would be helpful. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-12 22:22 ` Nickolay V. Shmyrev @ 2005-11-13 2:54 ` Matti Aarnio 2005-11-13 4:24 ` Junichi Uekawa 2005-11-16 12:50 ` Nickolay V. Shmyrev 2005-11-17 0:07 ` Junichi Uekawa 1 sibling, 2 replies; 24+ messages in thread From: Matti Aarnio @ 2005-11-13 2:54 UTC (permalink / raw) To: Nickolay V. Shmyrev Cc: Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 On Sun, Nov 13, 2005 at 01:22:51AM +0300, Nickolay V. Shmyrev wrote: > Hello all. > > We have even found the hack that fix that problem: A hack, but working one.. (for the small while that I tested it) > Index: linux/drivers/media/video/video-buf.c > =================================================================== > RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v > retrieving revision 1.21 > diff -u -p -r1.21 video-buf.c > --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000 > +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000 > @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf > map->end = vma->vm_end; > map->q = q; > vma->vm_ops = &videobuf_vm_ops; > - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED; > + vma->vm_flags |= VM_DONTEXPAND; > vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */ > vma->vm_private_data = map; > dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n", > > Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. > I don't know the exact reason of that behavior and the correct way to fix > that problem. Just kernel interfaces changed once again, the old > point everyone knows. So if someone can explain it, that would be helpful. This EFAULT rejection is due to change in get_user_pages() function in mm/memory.c file of 2.6.14-git2 @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t continue; } - if (!vma || (vma->vm_flags & VM_IO) - || !(flags & vma->vm_flags)) + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED)) + || !(vm_flags & vma->vm_flags)) return i ? : -EFAULT; if (is_vm_hugetlb_page(vma)) { I don't know how to use git tools to see, whose patch actually did this particular change. /Matti Aarnio ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-13 2:54 ` Matti Aarnio @ 2005-11-13 4:24 ` Junichi Uekawa 2005-11-16 12:50 ` Nickolay V. Shmyrev 1 sibling, 0 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-11-13 4:24 UTC (permalink / raw) To: Matti Aarnio Cc: Nickolay V. Shmyrev, Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 Hi, > This EFAULT rejection is due to change in get_user_pages() function > in mm/memory.c file of 2.6.14-git2 > > > @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t > continue; > } > > - if (!vma || (vma->vm_flags & VM_IO) > - || !(flags & vma->vm_flags)) > + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED)) > + || !(vm_flags & vma->vm_flags)) > return i ? : -EFAULT; > > if (is_vm_hugetlb_page(vma)) { > > > I don't know how to use git tools to see, whose patch actually > did this particular change. To quote: > MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being > deprecated. We never completely handled it correctly anyway, and is be > reintroduced in future if required (Hugh has a proof of concept). diff-tree b5810039a54e5babf428e9a1e89fc1940fabff11 (from f9c98d0287de42221c62448Author: Nick Piggin <nickpiggin@yahoo.com.au> Date: Sat Oct 29 18:16:12 2005 -0700 [PATCH] core remove PageReserved Remove PageReserved() calls from core code by tightening VM_RESERVED handling in mm/ to cover PageReserved functionality. PageReserved special casing is removed from get_page and put_page. All setting and clearing of PageReserved is retained, and it is now flagged in the page_alloc checks to help ensure we don't introduce any refcount based freeing of Reserved pages. MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being deprecated. We never completely handled it correctly anyway, and is be reintroduced in future if required (Hugh has a proof of concept). Once PageReserved() calls are removed from kernel/power/swsusp.c, and all arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can be trivially removed. Last real user of PageReserved is swsusp, which uses PageReserved to determine whether a struct page points to valid memory or not. This still needs to be addressed (a generic page_is_ram() should work). A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and thus mapcounted and count towards shared rss). These writes to the struct page could cause excessive cacheline bouncing on big systems. There are a number of ways this could be addressed if it is an issue. Signed-off-by: Nick Piggin <npiggin@suse.de> Refcount bug fix for filemap_xip.c Signed-off-by: Carsten Otte <cotte@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> I think the relevant changes (snipped out) are: diff --git a/include/linux/mm.h b/include/linux/mm.h index 0c64484..da42093 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -157,7 +157,7 @@ extern unsigned int kobjsize(const void #define VM_DONTCOPY 0x00020000 /* Do not copy this vma on fork */ #define VM_DONTEXPAND 0x00040000 /* Cannot expand with mremap() */ -#define VM_RESERVED 0x00080000 /* Don't unmap it from swap_out */ +#define VM_RESERVED 0x00080000 /* Pages managed in a special way */ #define VM_ACCOUNT 0x00100000 /* Is a VM accounted object */ #define VM_HUGETLB 0x00400000 /* Huge TLB Page VM */ #define VM_NONLINEAR 0x00800000 /* Is non-linear (remap_file_pages) */ diff --git a/mm/memory.c b/mm/memory.c index da642b5..e83f944 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -967,7 +992,7 @@ int get_user_pages(struct task_struct *t continue; } - if (!vma || (vma->vm_flags & VM_IO) + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED)) || !(flags & vma->vm_flags)) return i ? : -EFAULT; regards, junichi ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-13 2:54 ` Matti Aarnio 2005-11-13 4:24 ` Junichi Uekawa @ 2005-11-16 12:50 ` Nickolay V. Shmyrev 2005-11-16 17:47 ` Hugh Dickins 1 sibling, 1 reply; 24+ messages in thread From: Nickolay V. Shmyrev @ 2005-11-16 12:50 UTC (permalink / raw) To: Matti Aarnio Cc: Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 В Вск, 13/11/2005 в 04:54 +0200, Matti Aarnio пишет: > On Sun, Nov 13, 2005 at 01:22:51AM +0300, Nickolay V. Shmyrev wrote: > > Hello all. > > > > We have even found the hack that fix that problem: > > A hack, but working one.. > (for the small while that I tested it) > > > Index: linux/drivers/media/video/video-buf.c > > =================================================================== > > RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v > > retrieving revision 1.21 > > diff -u -p -r1.21 video-buf.c > > --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000 > > +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000 > > @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf > > map->end = vma->vm_end; > > map->q = q; > > vma->vm_ops = &videobuf_vm_ops; > > - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED; > > + vma->vm_flags |= VM_DONTEXPAND; > > vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */ > > vma->vm_private_data = map; > > dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n", > > > > Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. > > I don't know the exact reason of that behavior and the correct way to fix > > that problem. Just kernel interfaces changed once again, the old > > point everyone knows. So if someone can explain it, that would be helpful. > > This EFAULT rejection is due to change in get_user_pages() function > in mm/memory.c file of 2.6.14-git2 > > > @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t > continue; > } > > - if (!vma || (vma->vm_flags & VM_IO) > - || !(flags & vma->vm_flags)) > + if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED)) > + || !(vm_flags & vma->vm_flags)) > return i ? : -EFAULT; > > if (is_vm_hugetlb_page(vma)) { > > > I don't know how to use git tools to see, whose patch actually > did this particular change. > > > /Matti Aarnio It's sad, but I still don't understand the way it should be fixed. Removal of VM_RESERVED is certainly not a solution, since we don't going to swap mmaped pages and VM_RESERVED is used in other drivers (for example, some sound drivers) So, we need to find the problem itself. After looking at the code I've found that the x86_64 dependency of that problem lies in the check in memory.c:get_user_pages if (vma && in_gate_area (task, start)) x86_64 defines it's own arch-dependant function in_gate_area which fails in our case. Can someone trace that code and find why do we fail and fail only on x86_64. It would be nice if someone could point me to get_user_pages documentation, why it's so differently behaves for 64 bit arch. Also it seems that I had traces of video-buf module with debug enabled on 64 bit, but lost them. Can someone just enable debug option to video- buf module and collect those traces. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-16 12:50 ` Nickolay V. Shmyrev @ 2005-11-16 17:47 ` Hugh Dickins 2005-12-01 0:09 ` Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Hugh Dickins @ 2005-11-16 17:47 UTC (permalink / raw) To: Nickolay V. Shmyrev Cc: Matti Aarnio, Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 On Wed, 16 Nov 2005, Nickolay V. Shmyrev wrote: > > It's sad, but I still don't understand the way it should be fixed. > Removal of VM_RESERVED is certainly not a solution, since we don't going > to swap mmaped pages and VM_RESERVED is used in other drivers (for > example, some sound drivers) Early in this thread (last Friday) I said that I was working on the fix for this and some other PageReserved removal problems. I suggested then: Though if you're curious and impatient, you could try just editing the " | VM_RESERVED" out of mm/memory.c get_user_pages. Does that not work for you? It's not the full solution to all the issues, but I'd expect it to be enough to get you going. If it does not work for you, then I need to understand why not in a hurry: please let me know either way. I'm at last getting near with my patches, hope to post later tonight (but everything always takes me longer than I expect). > So, we need to find the problem itself. After looking at the code I've > found that the x86_64 dependency of that problem lies in the check in > memory.c:get_user_pages > > if (vma && in_gate_area (task, start)) > > x86_64 defines it's own arch-dependant function in_gate_area which fails > in our case. Why would you expect "in_gate_area" to pass in your case? I'd be very surprised if the user pages you're trying to get are in the gate area. I doubt that has anything to do with it: please try what I suggested. Hugh > Can someone trace that code and find why do we fail and > fail only on x86_64. It would be nice if someone could point me to > get_user_pages documentation, why it's so differently behaves for 64 bit > arch. > > Also it seems that I had traces of video-buf module with debug enabled > on 64 bit, but lost them. Can someone just enable debug option to video- > buf module and collect those traces. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-16 17:47 ` Hugh Dickins @ 2005-12-01 0:09 ` Junichi Uekawa 0 siblings, 0 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-12-01 0:09 UTC (permalink / raw) To: Hugh Dickins Cc: Nickolay V. Shmyrev, Matti Aarnio, Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 Hi, > Does that not work for you? It's not the full solution to all the > issues, but I'd expect it to be enough to get you going. If it does > not work for you, then I need to understand why not in a hurry: > please let me know either way. > > I'm at last getting near with my patches, hope to post later tonight > (but everything always takes me longer than I expect). I am assuming that the following patch went in as a fix for this problem. I have tested linus' tree as of today, and bttv works fine on x86_64, problem solved. Thanks! commit ed5297a94090d9a9f27b0ce1f9601ebe73561cff tree 00d28144ae949b3f9d566279cb12be0c802f86e6 parent aa1a64ee12ae130706f3fc0007841ce9b0ddf9c2 author Hugh Dickins <hugh@veritas.com> committer Linus Torvalds <torvalds@g5.osdl.org> [PATCH] unpaged: get_user_pages VM_RESERVED regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-12 22:22 ` Nickolay V. Shmyrev 2005-11-13 2:54 ` Matti Aarnio @ 2005-11-17 0:07 ` Junichi Uekawa 1 sibling, 0 replies; 24+ messages in thread From: Junichi Uekawa @ 2005-11-17 0:07 UTC (permalink / raw) To: Nickolay V. Shmyrev Cc: Linux and Kernel Video, Junichi Uekawa, Nick Piggin, Michael Krufky, linux-kernel, debian-amd64 Hi, Verified that with the following patch, I can run mencoder fine. $ uname -a Linux dancer64 2.6.15-rc1dancer-gf6ff56cd #1 Thu Nov 17 08:18:33 JST 2005 x86_64 GNU/Linux Applied upon linus' git from yesterday: commit f6ff56cd56b83d8edf4b3cffc5c53c56b37a5081 tree 0ec4807d49a602ba785e60e5352b542f1581d4c9 parent fb6d73d3014babb69f5cc2d1d78b31e9d09fc5df parent 5a6f294e43e432bd207a702fea49ebb303ef9b23 author Linus Torvalds <torvalds@g5.osdl.org> Tue Nov 15 16:59:38 UTC 2005 committer Linus Torvalds <torvalds@g5.osdl.org> Tue Nov 15 16:59:38 UTC 2005 Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 > > We have even found the hack that fix that problem: > > Index: linux/drivers/media/video/video-buf.c > =================================================================== > RCS file: /cvs/video4linux/v4l-kernel/linux/drivers/media/video/video-buf.c,v > retrieving revision 1.21 > diff -u -p -r1.21 video-buf.c > --- linux/drivers/media/video/video-buf.c 16 Oct 2005 12:13:58 -0000 > +++ linux/drivers/media/video/video-buf.c 12 Nov 2005 22:19:13 -0000 > @@ -1248,7 +1248,7 @@ int videobuf_mmap_mapper(struct videobuf > map->end = vma->vm_end; > map->q = q; > vma->vm_ops = &videobuf_vm_ops; > - vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED; > + vma->vm_flags |= VM_DONTEXPAND; > vma->vm_flags &= ~VM_IO; /* using shared anonymous pages */ > vma->vm_private_data = map; > dprintk(1,"mmap %p: q=%p %08lx-%08lx pgoff %08lx bufs %d-%d\n", > > Somehow since 2.6.15-rc1 VM_RESERVED makes get_user_pages return EFAULT. I don't know the exact reason of > that behavior and the correct way to fix that problem. Just kernel interfaces changed once again, the old > point everyone knows. So if someone can explain it, that would be helpful. > regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 13:29 ` Junichi Uekawa 2005-11-11 14:06 ` Hugh Dickins @ 2005-11-11 14:21 ` Junichi Uekawa 2005-11-12 21:11 ` Ricardo Cerqueira 1 sibling, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2005-11-11 14:21 UTC (permalink / raw) To: Michael Krufky Cc: Junichi Uekawa, linux-kernel, video4linux-list, debian-amd64 Hi, > That was wrong; I re-tested it and it looks like > 6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one. > 2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional. > > $ git-bisect start > $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d > $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a > Bisecting: 721 revisions left to test after this After that I tried: $ git-bisect bad Bisecting: 1966 revisions left to test after this [23fd07750a789a66fe88cf173d52a18f1a387da4] Merge ../linux-2.6 by hand I'm not quite sure why the following happened. 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 30 Oct is broken 741b2252a5e14d6c60a913c77a6099abe73a854a 27 Oct is functional 6e6ece5dc6022e8086c565498d23511bbceda811 10 Nov is broken 23fd07750a789a66fe88cf173d52a18f1a387da4 31 Oct -- does not boot due to USB/PCI quirks Maybe I'm doing something wrong. $ git-bisect log git-bisect start # bad: [6e9d6b8ee4e0c37d3952256e6472c57490d6780d] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d # good: [741b2252a5e14d6c60a913c77a6099abe73a854a] Linux v2.6.14 git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a # bad: [6e6ece5dc6022e8086c565498d23511bbceda811] PCI: fix for Toshiba ohci1394 quirk git-bisect bad 6e6ece5dc6022e8086c565498d23511bbceda811 regards, junichi ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005) 2005-11-11 14:21 ` Junichi Uekawa @ 2005-11-12 21:11 ` Ricardo Cerqueira 0 siblings, 0 replies; 24+ messages in thread From: Ricardo Cerqueira @ 2005-11-12 21:11 UTC (permalink / raw) To: Linux and Kernel Video Cc: Michael Krufky, Junichi Uekawa, debian-amd64, linux-kernel Hello again; We just got confirmation from someone at freenode that this problem exists with other chips as well (saa7134, in this case), so it's not chip dependent. It seems to be confined to x86_64 and 2.6.15, though. On Fri, 2005-11-11 at 23:21 +0900, Junichi Uekawa wrote: > Hi, > > > That was wrong; I re-tested it and it looks like > > 6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one. > > 2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional. > > > > $ git-bisect start > > $ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d > > $ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a > > Bisecting: 721 revisions left to test after this > > After that I tried: > $ git-bisect bad > Bisecting: 1966 revisions left to test after this > [23fd07750a789a66fe88cf173d52a18f1a387da4] Merge ../linux-2.6 by hand > > I'm not quite sure why the following happened. > 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 30 Oct is broken > 741b2252a5e14d6c60a913c77a6099abe73a854a 27 Oct is functional > 6e6ece5dc6022e8086c565498d23511bbceda811 10 Nov is broken > 23fd07750a789a66fe88cf173d52a18f1a387da4 31 Oct -- does not boot due to USB/PCI quirks > > Maybe I'm doing something wrong. > > > > $ git-bisect log > git-bisect start > # bad: [6e9d6b8ee4e0c37d3952256e6472c57490d6780d] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev > git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d > # good: [741b2252a5e14d6c60a913c77a6099abe73a854a] Linux v2.6.14 > git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a > # bad: [6e6ece5dc6022e8086c565498d23511bbceda811] PCI: fix for Toshiba ohci1394 quirk > git-bisect bad 6e6ece5dc6022e8086c565498d23511bbceda811 > > > > regards, > junichi > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list -- Ricardo Cerqueira ISP - Service & Platform Architectures Novis Telecom - Estrada da Outurela, 118 A / 2795-606 Carnaxide / Portugal Tel: +351 2 1010 4686 - Fax: +351 2 1012 9248 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <87mzj4uoys.dancerj%dancer@netfort.gr.jp>]
* [x86_64] linux 2.6.15-rc6 mplayer fails to record ALSA audio. [not found] ` <87mzj4uoys.dancerj%dancer@netfort.gr.jp> @ 2005-12-19 23:10 ` Junichi Uekawa 2006-01-14 7:33 ` Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2005-12-19 23:10 UTC (permalink / raw) To: linux-kernel, video4linux-list, debian-amd64; +Cc: dancer [-- Attachment #1: Type: text/plain, Size: 376 bytes --] Hi, With today's git tree I'm still experiencing the same problem that audio isn't captured with mencoder. Linux dancer64 2.6.15-rc6dancer-gdf7addbb #1 Mon Dec 19 23:18:41 JST 2005 x86_64 GNU/Linux successful recording is done with 2.6.14-rc5, failure case is done with 2.6.15-rc6, I'm suspecting that v4l is giving some wrong ideas about audio information to mencoder. [-- Attachment #2: success.txt --] [-- Type: text/plain, Size: 2563 bytes --] MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) Detected cache-line size is 64 bytes CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 success: format: 9 data: 0x0 - 0x0 Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski <olschewski@zpr.uni-koeln.de> comment: first try, more to come ;-) Selected device: BT878 video (IODATA GV-BCTV5/PC Tuner cap: Tuner rxs: MONO Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; inputs: 0 = Television; 1 = Composite1; 2 = S-Video; Current input: 0 Current format: YUYV v4l2: current audio mode is : STEREO Selected channel: 12 (freq: 217.250) [V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334 ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== Opening video filter: [expand osd=1] Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1 ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420) VDec: using Planar I420 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4]) High quality encoding selected (non real time)! Selected video codec: [rawi420] vfm: raw (RAW I420) ========================================================================== Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??... MP3 audio selected Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le... Writing AVI header... ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. Forcing audio preload to 0, max pts correction to 0 New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. [-- Attachment #3: Type: text/plain, Size: 0 bytes --] [-- Attachment #4: fail.txt --] [-- Type: text/plain, Size: 2065 bytes --] MEncoder dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0) Detected cache-line size is 64 bytes CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 success: format: 9 data: 0x0 - 0x0 Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski <olschewski@zpr.uni-koeln.de> comment: first try, more to come ;-) Selected device: BT878 video (IODATA GV-BCTV5/PC Tuner cap: Tuner rxs: MONO Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = PAL; 1 = NTSC; 2 = SECAM; 3 = PAL-Nc; 4 = PAL-M; 5 = PAL-N; 6 = NTSC-JP; 7 = PAL-60; inputs: 0 = Television; 1 = Composite1; 2 = S-Video; Current input: 0 Current format: YUV420 v4l2: current audio mode is : STEREO Selected channel: 12 (freq: 217.250) [V] filefmt:9 fourcc:0x30323449 size:320x240 fps:29.97 ftime:=0.0334 Opening video filter: [expand osd=1] Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1 ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 320 x 240 (preferred colorspace: Planar I420) VDec: using Planar I420 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. videocodec: libavcodec (320x240 fourcc=34504d46 [FMP4]) High quality encoding selected (non real time)! Selected video codec: [rawi420] vfm: raw (RAW I420) ========================================================================== Writing AVI header... ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. Forcing audio preload to 0, max pts correction to 0 New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. [-- Attachment #5: Type: text/plain, Size: 1830 bytes --] > The last version known to work: 2.6.14-rc5 (probably 2.6.15 works also) > > With 2.6.15-rc3 or so, with the following fix, bttv started functioning. > > commit ed5297a94090d9a9f27b0ce1f9601ebe73561cff > > tree 00d28144ae949b3f9d566279cb12be0c802f86e6 > > parent aa1a64ee12ae130706f3fc0007841ce9b0ddf9c2 > > author Hugh Dickins <hugh@veritas.com> > > committer Linus Torvalds <torvalds@g5.osdl.org> > > [PATCH] unpaged: get_user_pages VM_RESERVED > > However, mplayer doesn't want to read from ALSA input, and no sound is recorded. > > I'm trying to record video from /dev/video0, and audio from ALSA,0,0 > (which is ATIIXP card). Audio is physically routed from the video > capture board to ATIIXP card. > > I'm attaching the encoding script I use, and strace output > for 2.6.14-rc5 and 2.6.15-rc5. > > I'm using Debian sid, and this regression is killing me... > > If you know of good fix, or know of a reason of this breakage, I'm all > ears. > > regards, > junichi > -- > dancer@{debian.org,netfort.gr.jp} Debian Project > > > [2 encodetv.sh-strace <application/octet-stream (7bit)>] > #!/bin/bash > #interactive script to encode TV. > > if [[ $# != 3 ]]; then > echo "encodetv [channel] [minutes] [output filename]" > exit 0; > fi > echo "channel: $1" > CHANNEL=$1 > echo "minutes: $2" > MINUTES=$2 > echo "output filename: $3" > OUTFILE=$3 > > strace -f \ > mencoder tv://${CHANNEL} \ > -tv \ > driver=v4l2:\ > device=/dev/video0:\ > width=320:\ > height=240:\ > normid=6:\ > alsa:\ > amode=1:\ > adevice=ixp:\ > chanlist=japan-bcast:\ > forcechan=2:\ > -o "${OUTFILE}.avi" \ > -ovc lavc -lavcopts vcodec=mpeg4:vhq -oac mp3lame -lameopts br=128:cbr:mode=0 -endpos $(( 60 * $MINUTES )) > regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] linux 2.6.15-rc6 mplayer fails to record ALSA audio. 2005-12-19 23:10 ` [x86_64] linux 2.6.15-rc6 mplayer fails to record ALSA audio Junichi Uekawa @ 2006-01-14 7:33 ` Junichi Uekawa 2006-01-19 23:11 ` [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2006-01-14 7:33 UTC (permalink / raw) To: linux-kernel, video4linux-list, debian-amd64; +Cc: dancer Hi, With recent git tree I'm still experiencing the same problem that audio isn't captured with mencoder. $ uname -a Linux dancer64 2.6.15dancer-ga4fc7ab1-dirty #1 Thu Jan 12 08:32:49 JST 2006 x86_64 GNU/Linux last successful one was 2.6.14-rc5. I've noticed that there is a v4l-info command, which dumps v4l2 information, and it seems to signify that v4l2 is giving a different answer. The following is a diff, which seems to signify that this difference exists in the two versions: - audioset : 1 + audioset : 0 What caused this change and how to revert is a mystery, yet. $ diff -u 261[45]/v4l-info --- 2614/v4l-info 2006-01-14 16:22:58.000000000 +0900 +++ 2615/v4l-info 2006-01-14 16:19:00.000000000 +0900 @@ -25,7 +25,7 @@ framelines : 525 VIDIOC_ENUMSTD(2) index : 2 - id : 0x7f0000 [SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L] + id : 0xff0000 [SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] name : "SECAM" frameperiod.numerator : 1 frameperiod.denominator : 25 @@ -71,25 +71,25 @@ index : 0 name : "Television" type : TUNER - audioset : 1 + audioset : 0 tuner : 0 - std : 0x7f3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L] + std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x100 [NO_H_LOCK] VIDIOC_ENUMINPUT(1) index : 1 name : "Composite1" type : CAMERA - audioset : 1 + audioset : 0 tuner : 0 - std : 0x7f3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L] + std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x0 [] VIDIOC_ENUMINPUT(2) index : 2 name : "S-Video" type : CAMERA - audioset : 1 + audioset : 0 tuner : 0 - std : 0x7f3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L] + std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x0 [] tuners @@ -98,8 +98,8 @@ name : "Television" type : ANALOG_TV capability : 0x2 [NORM] - rangelow : 0 - rangehigh : 4294967295 + rangelow : 704 + rangehigh : 15328 rxsubchans : 0x1 [MONO] audmode : MONO signal : 0 @@ -332,11 +332,11 @@ VIDIOC_G_FMT(VBI_CAPTURE) type : VBI_CAPTURE fmt.vbi.sampling_rate : 35468950 - fmt.vbi.offset : 244 + fmt.vbi.offset : 128 fmt.vbi.samples_per_line: 2048 fmt.vbi.sample_format : 0x59455247 [GREY] fmt.vbi.start[0] : 7 - fmt.vbi.start[1] : 319 + fmt.vbi.start[1] : 320 fmt.vbi.count[0] : 16 fmt.vbi.count[1] : 16 fmt.vbi.flags : 0 full output of v4l-info: ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : "bttv" card : "BT878 video (IODATA GV-BCTV5/PC" bus_info : "PCI:0000:03:0b.0" version : 0.9.16 capabilities : 0x5010015 [VIDEO_CAPTURE,VIDEO_OVERLAY,VBI_CAPTURE,TUNER,READWRITE,STREAMING] standards VIDIOC_ENUMSTD(0) index : 0 id : 0xff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K] name : "PAL" frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(1) index : 1 id : 0x1000 [NTSC_M] name : "NTSC" frameperiod.numerator : 1001 frameperiod.denominator : 30000 framelines : 525 VIDIOC_ENUMSTD(2) index : 2 id : 0xff0000 [SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] name : "SECAM" frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(3) index : 3 id : 0x400 [PAL_Nc] name : "PAL-Nc" frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(4) index : 4 id : 0x100 [PAL_M] name : "PAL-M" frameperiod.numerator : 1001 frameperiod.denominator : 30000 framelines : 525 VIDIOC_ENUMSTD(5) index : 5 id : 0x200 [PAL_N] name : "PAL-N" frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(6) index : 6 id : 0x2000 [NTSC_M_JP] name : "NTSC-JP" frameperiod.numerator : 1001 frameperiod.denominator : 30000 framelines : 525 VIDIOC_ENUMSTD(7) index : 7 id : 0x800 [PAL_60] name : "PAL-60" frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 inputs VIDIOC_ENUMINPUT(0) index : 0 name : "Television" type : TUNER audioset : 0 tuner : 0 std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x100 [NO_H_LOCK] VIDIOC_ENUMINPUT(1) index : 1 name : "Composite1" type : CAMERA audioset : 0 tuner : 0 std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x0 [] VIDIOC_ENUMINPUT(2) index : 2 name : "S-Video" type : CAMERA audioset : 0 tuner : 0 std : 0xff3fff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,PAL_M,PAL_N,PAL_Nc,PAL_60,NTSC_M,NTSC_M_JP,SECAM_B,SECAM_D,SECAM_G,SECAM_H,SECAM_K,SECAM_K1,SECAM_L,?ATSC_8_VSB] status : 0x0 [] tuners VIDIOC_G_TUNER(0) index : 0 name : "Television" type : ANALOG_TV capability : 0x2 [NORM] rangelow : 704 rangehigh : 15328 rxsubchans : 0x1 [MONO] audmode : MONO signal : 0 afc : 0 video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type : VIDEO_CAPTURE flags : 0 description : "8 bpp, gray" pixelformat : 0x59455247 [GREY] VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE) index : 1 type : VIDEO_CAPTURE flags : 0 description : "8 bpp, dithered color" pixelformat : 0x34324948 [HI24] VIDIOC_ENUM_FMT(2,VIDEO_CAPTURE) index : 2 type : VIDEO_CAPTURE flags : 0 description : "15 bpp RGB, le" pixelformat : 0x4f424752 [RGBO] VIDIOC_ENUM_FMT(3,VIDEO_CAPTURE) index : 3 type : VIDEO_CAPTURE flags : 0 description : "15 bpp RGB, be" pixelformat : 0x51424752 [RGBQ] VIDIOC_ENUM_FMT(4,VIDEO_CAPTURE) index : 4 type : VIDEO_CAPTURE flags : 0 description : "16 bpp RGB, le" pixelformat : 0x50424752 [RGBP] VIDIOC_ENUM_FMT(5,VIDEO_CAPTURE) index : 5 type : VIDEO_CAPTURE flags : 0 description : "16 bpp RGB, be" pixelformat : 0x52424752 [RGBR] VIDIOC_ENUM_FMT(6,VIDEO_CAPTURE) index : 6 type : VIDEO_CAPTURE flags : 0 description : "24 bpp RGB, le" pixelformat : 0x33524742 [BGR3] VIDIOC_ENUM_FMT(7,VIDEO_CAPTURE) index : 7 type : VIDEO_CAPTURE flags : 0 description : "32 bpp RGB, le" pixelformat : 0x34524742 [BGR4] VIDIOC_ENUM_FMT(8,VIDEO_CAPTURE) index : 8 type : VIDEO_CAPTURE flags : 0 description : "32 bpp RGB, be" pixelformat : 0x34424752 [RGB4] VIDIOC_ENUM_FMT(9,VIDEO_CAPTURE) index : 9 type : VIDEO_CAPTURE flags : 0 description : "4:2:2, packed, YUYV" pixelformat : 0x56595559 [YUYV] VIDIOC_ENUM_FMT(10,VIDEO_CAPTURE) index : 10 type : VIDEO_CAPTURE flags : 0 description : "4:2:2, packed, YUYV" pixelformat : 0x56595559 [YUYV] VIDIOC_ENUM_FMT(11,VIDEO_CAPTURE) index : 11 type : VIDEO_CAPTURE flags : 0 description : "4:2:2, packed, UYVY" pixelformat : 0x59565955 [UYVY] VIDIOC_ENUM_FMT(12,VIDEO_CAPTURE) index : 12 type : VIDEO_CAPTURE flags : 0 description : "4:2:2, planar, Y-Cb-Cr" pixelformat : 0x50323234 [422P] VIDIOC_ENUM_FMT(13,VIDEO_CAPTURE) index : 13 type : VIDEO_CAPTURE flags : 0 description : "4:2:0, planar, Y-Cb-Cr" pixelformat : 0x32315559 [YU12] VIDIOC_ENUM_FMT(14,VIDEO_CAPTURE) index : 14 type : VIDEO_CAPTURE flags : 0 description : "4:2:0, planar, Y-Cr-Cb" pixelformat : 0x32315659 [YV12] VIDIOC_ENUM_FMT(15,VIDEO_CAPTURE) index : 15 type : VIDEO_CAPTURE flags : 0 description : "4:1:1, planar, Y-Cb-Cr" pixelformat : 0x50313134 [411P] VIDIOC_ENUM_FMT(16,VIDEO_CAPTURE) index : 16 type : VIDEO_CAPTURE flags : 0 description : "4:1:0, planar, Y-Cb-Cr" pixelformat : 0x39565559 [YUV9] VIDIOC_ENUM_FMT(17,VIDEO_CAPTURE) index : 17 type : VIDEO_CAPTURE flags : 0 description : "4:1:0, planar, Y-Cr-Cb" pixelformat : 0x39555659 [YVU9] VIDIOC_G_FMT(VIDEO_CAPTURE) type : VIDEO_CAPTURE fmt.pix.width : 320 fmt.pix.height : 240 fmt.pix.pixelformat : 0x56595559 [YUYV] fmt.pix.field : INTERLACED fmt.pix.bytesperline : 640 fmt.pix.sizeimage : 153600 fmt.pix.colorspace : unknown fmt.pix.priv : 0 video overlay VIDIOC_ENUM_FMT(0,VIDEO_OVERLAY) index : 0 type : VIDEO_OVERLAY flags : 0 description : "8 bpp, gray" pixelformat : 0x59455247 [GREY] VIDIOC_ENUM_FMT(1,VIDEO_OVERLAY) index : 1 type : VIDEO_OVERLAY flags : 0 description : "8 bpp, dithered color" pixelformat : 0x34324948 [HI24] VIDIOC_ENUM_FMT(2,VIDEO_OVERLAY) index : 2 type : VIDEO_OVERLAY flags : 0 description : "15 bpp RGB, le" pixelformat : 0x4f424752 [RGBO] VIDIOC_ENUM_FMT(3,VIDEO_OVERLAY) index : 3 type : VIDEO_OVERLAY flags : 0 description : "15 bpp RGB, be" pixelformat : 0x51424752 [RGBQ] VIDIOC_ENUM_FMT(4,VIDEO_OVERLAY) index : 4 type : VIDEO_OVERLAY flags : 0 description : "16 bpp RGB, le" pixelformat : 0x50424752 [RGBP] VIDIOC_ENUM_FMT(5,VIDEO_OVERLAY) index : 5 type : VIDEO_OVERLAY flags : 0 description : "16 bpp RGB, be" pixelformat : 0x52424752 [RGBR] VIDIOC_ENUM_FMT(6,VIDEO_OVERLAY) index : 6 type : VIDEO_OVERLAY flags : 0 description : "24 bpp RGB, le" pixelformat : 0x33524742 [BGR3] VIDIOC_ENUM_FMT(7,VIDEO_OVERLAY) index : 7 type : VIDEO_OVERLAY flags : 0 description : "32 bpp RGB, le" pixelformat : 0x34524742 [BGR4] VIDIOC_ENUM_FMT(8,VIDEO_OVERLAY) index : 8 type : VIDEO_OVERLAY flags : 0 description : "32 bpp RGB, be" pixelformat : 0x34424752 [RGB4] VIDIOC_ENUM_FMT(9,VIDEO_OVERLAY) index : 9 type : VIDEO_OVERLAY flags : 0 description : "4:2:2, packed, YUYV" pixelformat : 0x56595559 [YUYV] VIDIOC_ENUM_FMT(10,VIDEO_OVERLAY) index : 10 type : VIDEO_OVERLAY flags : 0 description : "4:2:2, packed, YUYV" pixelformat : 0x56595559 [YUYV] VIDIOC_ENUM_FMT(11,VIDEO_OVERLAY) index : 11 type : VIDEO_OVERLAY flags : 0 description : "4:2:2, packed, UYVY" pixelformat : 0x59565955 [UYVY] VIDIOC_G_FMT(VIDEO_OVERLAY) type : VIDEO_OVERLAY fmt.win.w.left : 0 fmt.win.w.top : 0 fmt.win.w.width : 320 fmt.win.w.height : 240 fmt.win.field : ANY fmt.win.chromakey : 0 fmt.win.clips : (nil) fmt.win.clipcount : 0 fmt.win.bitmap : (nil) VIDIOC_G_FBUF capability : 0x4 [LIST_CLIPPING] flags : 0x0 [] base : (nil) fmt.width : 0 fmt.height : 0 fmt.pixelformat : 0x56595559 [YUYV] fmt.field : ANY fmt.bytesperline : 0 fmt.sizeimage : 0 fmt.colorspace : unknown fmt.priv : 0 vbi capture VIDIOC_ENUM_FMT(0,VBI_CAPTURE) index : 0 type : VBI_CAPTURE flags : 0 description : "vbi data" pixelformat : 0x59455247 [GREY] VIDIOC_G_FMT(VBI_CAPTURE) type : VBI_CAPTURE fmt.vbi.sampling_rate : 35468950 fmt.vbi.offset : 128 fmt.vbi.samples_per_line: 2048 fmt.vbi.sample_format : 0x59455247 [GREY] fmt.vbi.start[0] : 7 fmt.vbi.start[1] : 320 fmt.vbi.count[0] : 16 fmt.vbi.count[1] : 16 fmt.vbi.flags : 0 controls VIDIOC_QUERYCTRL(BASE+0) id : 9963776 type : INTEGER name : "Brightness" minimum : 0 maximum : 65535 step : 256 default_value : 32768 flags : 0 VIDIOC_QUERYCTRL(BASE+1) id : 9963777 type : INTEGER name : "Contrast" minimum : 0 maximum : 65535 step : 128 default_value : 32768 flags : 0 VIDIOC_QUERYCTRL(BASE+2) id : 9963778 type : INTEGER name : "Saturation" minimum : 0 maximum : 65535 step : 128 default_value : 32768 flags : 0 VIDIOC_QUERYCTRL(BASE+3) id : 9963779 type : INTEGER name : "Hue" minimum : 0 maximum : 65535 step : 256 default_value : 32768 flags : 0 VIDIOC_QUERYCTRL(BASE+9) id : 9963785 type : BOOLEAN name : "Mute" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+0) id : 134217728 type : BOOLEAN name : "chroma agc" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+1) id : 134217729 type : BOOLEAN name : "combfilter" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+2) id : 134217730 type : BOOLEAN name : "automute" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+3) id : 134217731 type : BOOLEAN name : "luma decimation filter" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+4) id : 134217732 type : BOOLEAN name : "agc crush" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+5) id : 134217733 type : BOOLEAN name : "vcr hack" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+6) id : 134217734 type : INTEGER name : "whitecrush upper" minimum : 0 maximum : 255 step : 1 default_value : 207 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+7) id : 134217735 type : INTEGER name : "whitecrush lower" minimum : 0 maximum : 255 step : 1 default_value : 127 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+8) id : 134217736 type : INTEGER name : "uv ratio" minimum : 0 maximum : 100 step : 1 default_value : 50 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+9) id : 134217737 type : BOOLEAN name : "full luma range" minimum : 0 maximum : 1 step : 0 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(PRIVATE_BASE+10) id : 134217738 type : INTEGER name : "coring" minimum : 0 maximum : 3 step : 1 default_value : 0 flags : 0 ### video4linux device info [/dev/video0] ### general info VIDIOCGCAP name : "BT878 video (IODATA GV-BCTV5/PC" type : 0xab [CAPTURE,TUNER,OVERLAY,CLIPPING,SCALES] channels : 3 audios : 1 maxwidth : 924 maxheight : 576 minwidth : 48 minheight : 32 channels VIDIOCGCHAN(0) channel : 0 name : "Television" tuners : 1 flags : 0x3 [TUNER,AUDIO] type : TV norm : 0 VIDIOCGCHAN(1) channel : 1 name : "Composite1" tuners : 0 flags : 0x2 [AUDIO] type : CAMERA norm : 0 VIDIOCGCHAN(2) channel : 2 name : "S-Video" tuners : 0 flags : 0x2 [AUDIO] type : CAMERA norm : 0 tuner VIDIOCGTUNER tuner : 0 name : "Television" rangelow : 0 rangehigh : 704 flags : 0x0 [] mode : unknown signal : 0 audio VIDIOCGAUDIO audio : 0 volume : 0 bass : 0 treble : 0 picture VIDIOCGPICT brightness : 32768 hue : 32768 colour : 32768 contrast : 32768 whiteness : 0 depth : 16 palette : YUV422 buffer VIDIOCGFBUF base : (nil) height : 0 width : 0 depth : 16 bytesperline : 0 window VIDIOCGWIN x : 0 y : 0 width : 320 height : 240 chromakey : 0 flags : 0 regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV. 2006-01-14 7:33 ` Junichi Uekawa @ 2006-01-19 23:11 ` Junichi Uekawa 2006-02-02 9:13 ` Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2006-01-19 23:11 UTC (permalink / raw) To: linux-kernel, video4linux-list, debian-amd64; +Cc: dancer Hi, With 2.6.16-rc1, it's recording no audio, and it's recording black-and-white noise on video. Wooo, it's getting worse. $ uname -a Linux dancer64 2.6.16-rc1dancer-dirty #1 Wed Jan 18 08:11:24 JST 2006 x86_64 GNU/Linux >From the information that I've gathered so far it seems like: 1. bttv was rewritten to support v4l2 2. record via v4l2 is broken, v4l1 is not (xawtv works, mencoder broken.) I've heard mencoder should work with v4l1, but I have not yet confirmed. bttv-cards.c: [BTTV_BOARD_GVBCTV5PCI] = { .name = "IODATA GV-BCTV5/PCI", .video_inputs = 3, .audio_inputs = 1, .tuner = 0, .svhs = 2, .gpiomask = 0x0f0f80, .muxsel = {2, 3, 1, 0 }, .audiomux = {0x030000, 0x010000, 0, 0, 0x020000, 0}, .no_msp34xx = 1, .pll = PLL_28, .tuner_type = TUNER_PHILIPS_NTSC_M, .tuner_addr = ADDR_UNSET, .radio_addr = ADDR_UNSET, .audio_hook = gvbctv5pci_audio, .has_radio = 1, }, dmesg gives me an impression that this path is taken properly: bttv: driver version 0.9.16 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). bttv0: Bt878 (rev 17) at 0000:03:0b.0, irq: 22, latency: 64, mmio: 0xfdcff000 bttv0: detected: I-O Data Co. GV-BCTV5/PCI [card=81], PCI subsystem ID is 10fc:d018 bttv0: using: IODATA GV-BCTV5/PCI [card=81,autodetected] bttv0: gpio: en=00000000, out=00000000 in=00f6f0f7 [init] bttv0: using tuner=17 bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found bttv0: i2c: checking for TDA9887 @ 0x86... not found tuner 0-0061: chip found @ 0xc2 (bt878 #0 [sw]) tuner 0-0061: type set to 17 (Philips NTSC_M (MK2)) bttv0: registered device video0 bttv0: registered device vbi0 bttv0: registered device radio0 bttv0: PLL: 28636363 => 35468950 .. ok v4l-info is dumped with: printf("inputs\n"); for (i = 0;; i++) { memset(&input,0,sizeof(input)); input.index = i; if (-1 == ioctl(fd,VIDIOC_ENUMINPUT,&input)) break; printf(" VIDIOC_ENUMINPUT(%d)\n",i); print_struct(stdout,desc_v4l2_input,&input,"",tab); } printf("\n"); which is probably handled in bttv-driver.c:static int bttv_common_ioctls(struct bttv *btv, unsigned int cmd, void *arg) which unconditionally sets: i->audioset = 0; > last successful one was 2.6.14-rc5. > > > I've noticed that there is a v4l-info command, which dumps v4l2 > information, and it seems to signify that v4l2 is giving a different > answer. > > The following is a diff, which seems to signify that this difference > exists in the two versions: > > - audioset : 1 > + audioset : 0 > regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV. 2006-01-19 23:11 ` [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV Junichi Uekawa @ 2006-02-02 9:13 ` Junichi Uekawa 2006-02-02 13:53 ` Manu Abraham 0 siblings, 1 reply; 24+ messages in thread From: Junichi Uekawa @ 2006-02-02 9:13 UTC (permalink / raw) To: linux-kernel, video4linux-list, debian-amd64; +Cc: dancer Hi, status update, it's still like this; I probably don't have much time to sit around debugging this problem myself, but if anyone else has met this problem and fixed it, I'd be delighted to know about it. Linux dancer64 2.6.16-rc1dancer-ga6df590d-dirty #1 Wed Feb 1 18:36:00 JST 2006 x86_64 GNU/Linux regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project At Fri, 20 Jan 2006 08:11:34 +0900, Junichi Uekawa wrote: > > Hi, > > With 2.6.16-rc1, it's recording no audio, and it's recording > black-and-white noise on video. Wooo, it's getting worse. > > $ uname -a > Linux dancer64 2.6.16-rc1dancer-dirty #1 Wed Jan 18 08:11:24 JST 2006 x86_64 GNU/Linux > > > From the information that I've gathered so far it seems like: > 1. bttv was rewritten to support v4l2 > 2. record via v4l2 is broken, v4l1 is not (xawtv works, mencoder broken.) > I've heard mencoder should work with v4l1, but I have not yet confirmed. > > bttv-cards.c: > > [BTTV_BOARD_GVBCTV5PCI] = { > .name = "IODATA GV-BCTV5/PCI", > .video_inputs = 3, > .audio_inputs = 1, > .tuner = 0, > .svhs = 2, > .gpiomask = 0x0f0f80, > .muxsel = {2, 3, 1, 0 }, > .audiomux = {0x030000, 0x010000, 0, 0, 0x020000, 0}, > .no_msp34xx = 1, > .pll = PLL_28, > .tuner_type = TUNER_PHILIPS_NTSC_M, > .tuner_addr = ADDR_UNSET, > .radio_addr = ADDR_UNSET, > .audio_hook = gvbctv5pci_audio, > .has_radio = 1, > }, > > dmesg gives me an impression that this path is taken properly: > bttv: driver version 0.9.16 loaded > bttv: using 8 buffers with 2080k (520 pages) each for capture > bttv: Bt8xx card found (0). > bttv0: Bt878 (rev 17) at 0000:03:0b.0, irq: 22, latency: 64, mmio: 0xfdcff000 > bttv0: detected: I-O Data Co. GV-BCTV5/PCI [card=81], PCI subsystem ID is 10fc:d018 > bttv0: using: IODATA GV-BCTV5/PCI [card=81,autodetected] > bttv0: gpio: en=00000000, out=00000000 in=00f6f0f7 [init] > bttv0: using tuner=17 > bttv0: i2c: checking for TDA9875 @ 0xb0... not found > bttv0: i2c: checking for TDA7432 @ 0x8a... not found > bttv0: i2c: checking for TDA9887 @ 0x86... not found > tuner 0-0061: chip found @ 0xc2 (bt878 #0 [sw]) > tuner 0-0061: type set to 17 (Philips NTSC_M (MK2)) > bttv0: registered device video0 > bttv0: registered device vbi0 > bttv0: registered device radio0 > bttv0: PLL: 28636363 => 35468950 .. ok > > > v4l-info is dumped with: > > printf("inputs\n"); > for (i = 0;; i++) { > memset(&input,0,sizeof(input)); > input.index = i; > if (-1 == ioctl(fd,VIDIOC_ENUMINPUT,&input)) > break; > printf(" VIDIOC_ENUMINPUT(%d)\n",i); > print_struct(stdout,desc_v4l2_input,&input,"",tab); > } > printf("\n"); > > > which is probably handled in > bttv-driver.c:static int bttv_common_ioctls(struct bttv *btv, unsigned int cmd, void *arg) > > which unconditionally sets: > i->audioset = 0; > > > > > last successful one was 2.6.14-rc5. > > > > > > I've noticed that there is a v4l-info command, which dumps v4l2 > > information, and it seems to signify that v4l2 is giving a different > > answer. > > > > The following is a diff, which seems to signify that this difference > > exists in the two versions: > > > > - audioset : 1 > > + audioset : 0 > > > > > regards, > junichi > -- > dancer@{debian.org,netfort.gr.jp} Debian Project > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV. 2006-02-02 9:13 ` Junichi Uekawa @ 2006-02-02 13:53 ` Manu Abraham 2006-02-02 23:04 ` Junichi Uekawa 0 siblings, 1 reply; 24+ messages in thread From: Manu Abraham @ 2006-02-02 13:53 UTC (permalink / raw) To: Linux and Kernel Video; +Cc: linux-kernel, debian-amd64, dancer Junichi Uekawa wrote: > Hi, > > status update, it's still like this; I probably don't have much time > to sit around debugging this problem myself, but if anyone else has > met this problem and fixed it, I'd be delighted to know about it. > > Linux dancer64 2.6.16-rc1dancer-ga6df590d-dirty #1 Wed Feb 1 18:36:00 JST 2006 x86_64 GNU/Linux > > Are you referring to bugzilla 5895 ? I just closed that ticket. http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=dc3ce5a86001;style=gitweb Manu ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV. 2006-02-02 13:53 ` Manu Abraham @ 2006-02-02 23:04 ` Junichi Uekawa 0 siblings, 0 replies; 24+ messages in thread From: Junichi Uekawa @ 2006-02-02 23:04 UTC (permalink / raw) To: Manu Abraham; +Cc: Linux and Kernel Video, linux-kernel, debian-amd64, dancer Hi, > Junichi Uekawa wrote: > > Hi, > > > > status update, it's still like this; I probably don't have much time > > to sit around debugging this problem myself, but if anyone else has > > met this problem and fixed it, I'd be delighted to know about it. > > > > Linux dancer64 2.6.16-rc1dancer-ga6df590d-dirty #1 Wed Feb 1 18:36:00 JST 2006 x86_64 GNU/Linux > > > > > > Are you referring to bugzilla 5895 ? I just closed that ticket. > > http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=dc3ce5a86001;style=gitweb That sounds like a different module; I'm using 'bttv' module. I've tried rmmod bttv rmmod tuner rmmod compat_ioctl32 rmmod v4l2-common rmmod tveeprom rmmod videodev rmmod ir-common insmod v4l2-common.ko insmod tveeprom.ko insmod videodev.ko insmod compat_ioctl32.ko insmod tuner.ko insmod ir-common.ko insmod bttv.ko on $ hg log|head changeset: 3295:02699cfc26d5 tag: tip user: Manu Abraham <manu@linuxtv.org> date: Thu Feb 2 07:59:47 2006 +0400 summary: bugfix [5895], return an error value and I can reproduce the situation. The current situation being that no images come through mencoder, which probably means it's not 1. tuning the tuner (If there has been a i2c breakage, sounds possible) 2. getting the images or both. I am able to see TV through xawtv, and I am assuming that means it's working with v4l1 compatibility layer of some sort. regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2006-02-02 23:04 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-03 4:26 mencoder fails with Linux kernel from linus's git tree (2 Nov 2005) Junichi Uekawa
2005-11-10 21:40 ` [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 " Junichi Uekawa
2005-11-10 22:58 ` Mike Krufky
2005-11-11 0:05 ` Junichi Uekawa
2005-11-11 3:24 ` Michael Krufky
2005-11-11 12:06 ` Junichi Uekawa
2005-11-11 13:11 ` Michael Krufky
2005-11-11 13:29 ` Junichi Uekawa
2005-11-11 14:06 ` Hugh Dickins
2005-11-12 22:22 ` Nickolay V. Shmyrev
2005-11-13 2:54 ` Matti Aarnio
2005-11-13 4:24 ` Junichi Uekawa
2005-11-16 12:50 ` Nickolay V. Shmyrev
2005-11-16 17:47 ` Hugh Dickins
2005-12-01 0:09 ` Junichi Uekawa
2005-11-17 0:07 ` Junichi Uekawa
2005-11-11 14:21 ` Junichi Uekawa
2005-11-12 21:11 ` Ricardo Cerqueira
[not found] ` <87mzj4uoys.dancerj%dancer@netfort.gr.jp>
2005-12-19 23:10 ` [x86_64] linux 2.6.15-rc6 mplayer fails to record ALSA audio Junichi Uekawa
2006-01-14 7:33 ` Junichi Uekawa
2006-01-19 23:11 ` [x86_64] bttv: linux 2.6.16-rc1 mplayer fails to record ALSA audio and fails tune TV Junichi Uekawa
2006-02-02 9:13 ` Junichi Uekawa
2006-02-02 13:53 ` Manu Abraham
2006-02-02 23:04 ` Junichi Uekawa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).