vlc - chroma selection failed

[bbox244]

I can see that this question has already been asked a dozen times, but, nobody ever replies to it. Well, here goes:

When I try to start a vla capture from my Video4Linux device, I get the following error:
00000269] v4l demuxer error: chroma selection failed

Now, after searching for hours, I found this snippit of code:

if( ioctl( i_fd, VIDIOCMCAPTURE, &p_sys->vid_mmap ) < 0 )
{
msg_Warn( p_demux, "%4.4s refused", (char*)&p_sys->i_fourcc );
msg_Err( p_demux, "chroma selection failed" );
goto vdev_failed;
}

This is a generic error, so it could be any number of things. The other calls passed, such as setting up the mmap, so, only the capture call is failing.

I also noticed that the call is a v4l call which is still supported, yet, older, as there are new calls in the V4L2 API.

My question is this:

Do I give up and look elsewhere?

or:

Do I assume that the problem is because the v4l and v4l2 API's really are n't compatible anymore?

or:

Do I rewrite the vlc.c interface to support the v4l2 API.

My card works great under xawtv, tvtime, ZoneMinder, etc. Its a newer Connectant Chip, CX23883.

Thanks in advance to anyone who takes the time to read and reply to this post.

-Damian

-Damian

[bbox244]

I've done a bit more research and I'm thinking that this is definitely a v4l2 compatibility issue.

Any thoughts?

[pm]

Is vlc _really_ still using v4l interface, not v4l2?

[bbox244]

Yes, with the exception of the pvr access module. The v4l access module uses the v4l interface, not, v4l2.

For example, tvtime uses VIDIOCMCAPTURE for v4l and VIDIOC_QBUF for v4l2. vlc uses VIDIOCMCAPTURE.

--excerpt from tvtime...
if( vidin->isv4l2 ) {
if( ioctl( vidin->grab_fd, VIDIOC_QBUF, &vidin->capbuffers[ frameid ].vidbuf ) < 0 ) {
fprintf( stderr, "videoinput: Can't free frame %d: %s\n",
frameid, strerror( errno ) );
}
vidin->capbuffers[ frameid ].free = 1;
} else {
if( ioctl( vidin->grab_fd, VIDIOCMCAPTURE, vidin->grab_buf + frameid ) < 0 ) {
fprintf( stderr, "videoinput: Can't free frame %d: %s\n",
frameid, strerror( errno ) );
}
}

[bbox244]

I'm currently reading through the coding standards for vlc. I'm thinking about writing either a patch, or a seperate access module for v4l2.

[pm]

Back to the original problem: I'm seeing that here too, using an SAA7134-based, recent TV card. vlc appears unable to choose a format that is supported by this card, and fails at that point.

Debug excerpt (this is vlc-0.8.4a)

[00000223] main playlist debug: adding playlist item `v4l://' ( v4l:// )
[00000223] main playlist debug: creating new input thread
[00000232] main input debug: set input option: v4l-vdev to /dev/video
[00000232] main input debug: set input option: v4l-adev to /dev/dsp1
[00000232] main input debug: set input option: v4l-norm to 0
[00000232] main input debug: set input option: v4l-frequency to -1
[00000232] main input debug: set input option: v4l-caching to 300
[00000232] main input debug: set input option: v4l-chroma to I420
[00000232] main input debug: set input option: v4l-fps to -1.000000
[00000232] main input debug: set input option: v4l-samplerate to 44100
[00000232] main input debug: set input option: v4l-channel to 0
[00000232] main input debug: set input option: v4l-tuner to -1
[00000232] main input debug: set input option: v4l-audio to -1
[00000232] main input debug: set input option: v4l-stereo to true
[00000232] main input debug: set input option: v4l-width to 0
[00000232] main input debug: set input option: v4l-height to 0
[00000232] main input debug: set input option: v4l-brightness to -1
[00000232] main input debug: set input option: v4l-colour to -1
[00000232] main input debug: set input option: v4l-hue to -1
[00000232] main input debug: set input option: v4l-contrast to -1
[00000232] main input debug: set input option: v4l-mjpeg to false
[00000232] main input debug: set input option: v4l-decimation to 1
[00000232] main input debug: set input option: v4l-quality to 100
[00000232] main input debug: waiting for thread completion
[00000232] main input debug: thread 1086323040 (input) created at priority 0 (src/input/input.c:230)
[00000232] main input debug: `v4l://' gives access `v4l' demux `' path `'
[00000232] main input debug: creating demux: access='v4l' demux='' path=''
[00000233] main demuxer debug: looking for access_demux module: 1 candidate
[00000233] v4l demuxer debug: V4L device LifeView FlyTV Platinum FM 4 channels 0 audios 48 < w < 720 32 < h < 578
[00000233] v4l demuxer debug: invalid width 0
[00000233] v4l demuxer debug: invalid height 0
[00000233] v4l demuxer debug: setting channel Television(0) 1 tuners flags=0x1 type=0x1 norm=0x0
[00000233] v4l demuxer debug: will use 720x578
[00000233] v4l demuxer debug: v4l device uses brightness: 37265
[00000233] v4l demuxer debug: v4l device uses colour: 33026
[00000233] v4l demuxer debug: v4l device uses hue: 32896
[00000233] v4l demuxer debug: v4l device uses contrast: 33026
[00000233] v4l demuxer debug: v4l device uses frame size: 624240
[00000233] v4l demuxer debug: v4l device uses chroma: I420
[00000233] v4l demuxer warning: I420 refused
[00000233] v4l demuxer error: chroma selection failed


From the source code, I understand that it's not necessarily the color format that's being refused, but rather any of the parameters passed to this particular v4l call. I think that the error needs to be looked at more precisely than just printing the same error message for any result code <0.

[bbox244]

I agree. The difficult part is that detecting the precise error would require a bit of digging into the v4l interface. Looking at the v4l2 interface code in xawtv, and tvtime, I don't think it would be that difficult to build a v4l2 input handler. The enemy of course is time

However, I do want to do this, and I like the coding standards specification of videolan, my favorite of which of course is the use of (I'm sure I'll get flamed on this one....) Allman style braces. I find K&R highly unreadable.