* 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 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
* 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-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-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
* [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).