PDA

View Full Version : Couldn't get controls...



cwilling
01-10-2004, 12:31 AM
I'm trying the ml linux/examples vidtomem & vidtogfx, using:
% ./vidtomem -d "bttv video via v4l:0" -j Composite1 -s PAL

but always receive the error:
Couldn't get controls on path: ML_STATUS_INVALID_PARAMETER
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x304012') (length -1)

Running:
mlquery -d "bttv video via v4l:0" -j Composite1 control

gives:
JACK: Composite1
parent: bttv video via v4l
direction: input
type: Composite


This is with a bttv driver for Hauppauge "WinTV GO" capture card (otherwise working normally). Any idea what is causing the problem?

chris

fjaubert
01-13-2004, 10:03 AM
Parameter 0x304012 is "ML_VIDEO_SIGNAL_PRESENT_INT32" -- see line 324 of vidtomem.c

Unfortunately, it seems that the v4l device (mlmodule) does not implement this control -- hence the INVALID_PARAMETER when the control is sent to the device.

This is a shortcoming in the vidtomem sample program, which should check the availability of controls before using them. (It is OK for the v4l sample module to not implement this control: not all boards are capable of detecting incoming signal timing).

I'll make a note to see if we can fix this for the next release.

In the meantime, you can disable the part of the code in vidtomem that attempts to determine the input signal timing (roughly, lines 320 to 345). (Of course, you could also do it the "right way", and call mlGetCapabilities() to determine if the control is supported -- this would result in code that works on a wider variety of hardware).

cwilling
01-14-2004, 12:04 PM
Thanks for the reply & tips, following which I eventually had videotomem completing OK.

Then, moving on to videotogfx, I now have a picture. However it looks like its not capturing in PAL - its mono with strange line structure. I've put an example at http://www.vislab.usyd.edu.au/staff/chris/openml/gfxout.html

Below is the command line output, showing attempt to set 720x576 failing (my debug msg "FAILED mlSetControls"). The pgm code then does a mlGetControls to find window size to use, returning 640x480, before showing the video.

I had a quick browze through the ml/oss/devices/v4l/linux/mlmodule/src directory and found a ML_TIMING_525 item in v4lTimingEnums[] and v4lTimingNames[], but no reference to anything like ML_TIMING_625 which I would expect for PAL.

Does this mean PAL is not supported at present?

If no PAL, do you have a timeline for PAL support?


chris


Here is output command line output.
~/ml/linux/usr/src/ml/examples# ./vidtogfx -D -d 'bttv video via v4l:2' -j Composite0 -s PAL
Couldn't get controls on path: ML_STATUS_INVALID_PARAMETER
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x304012') (length -1)
FAILED mlGetControls
Input Timing Present = ML_TIMING_625
Timing 3
Couldn't set controls on path: ML_STATUS_INVALID_PARAMETER
ML_VIDEO_COLORSPACE_INT32 = ML_COLORSPACE_CbYCr_601_HEAD
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x314012') (length -1)
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x315012')
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x316012')
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x311012')
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x312012')
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x313012')
ML_IMAGE_WIDTH_INT32 = 720
ML_IMAGE_HEIGHT_1_INT32 = 576
ML_IMAGE_HEIGHT_2_INT32 = 0
ML_IMAGE_TEMPORAL_SAMPLING_INT32 = ML_TEMPORAL_SAMPLING_FIELD_BASED
(error 'ML_STATUS_INVALID_PARAMETER' while decoding param '0x412012')
ML_IMAGE_COMPRESSION_INT32 = ML_COMPRESSION_UNCOMPRESSED
ML_IMAGE_COLORSPACE_INT32 = ML_COLORSPACE_RGB_601_FULL
ML_IMAGE_SAMPLING_INT32 = ML_SAMPLING_444
ML_IMAGE_PACKING_INT32 = ML_PACKING_8
ML_IMAGE_INTERLEAVE_MODE_INT32 = ML_INTERLEAVE_MODE_INTERLEAVED
ML_DEVICE_EVENTS_INT32_ARRAY = [ML_EVENT_VIDEO_SEQUENCE_LOST]
FAILED mlSetControls
ML_IMAGE_WIDTH_INT32 = 640
ML_IMAGE_HEIGHT_1_INT32 = 480 (length -1)
ML_IMAGE_HEIGHT_2_INT32 = 0
.................................................. ..........Shutdown

fjaubert
01-16-2004, 09:33 AM
I think there are 2 issues going on here. The first is similar to the problem you were having with "vidtomem" -- the sample program uses controls without first checking if the device supports them.

In this case, the following params are not supported by the "v4l" sample module:
- VIDEO_SIGNAL_PRESENT
- VIDEO_START_X, VIDEO_START_Y_F1, VIDEO_START_Y_F2
- VIDEO_WIDTH, VIDEO_HEIGHT_F1, VIDEO_HEIGHT_F2
- IMAGE_DOMINANCE

Because of this, the "setControls" fails, and *none* of the controls are applied. So your card is not being set-up properly.

To fix this, you would need to make the same sort of changes you did for "vidtomem" -- ie, remove the un-supported parameters from the set-controls message.

However, as you noticed yourself, it appears that the "v4l" sample module does not support PAL at all... on the other hand, looking through the "v4l" code, I don't see the timing actually used anywhere. So even though PAL timing isn't supported, it might still work... it's worth a try, at any rate.

As for a timeline for all this to be fixed, I'm not sure. Obviously, we'd like to have fully-functional samples and demos -- but that's all these are: samples and demos. They are not designed to be "production-grade" modules or applications. So until we have the SDK fully implemented, they are a bit lower on our priority list.

cwilling
01-17-2004, 10:56 AM
OK, I changed some PAL/NTSC related things in v4lDevice.c of the mlmodule directory and now the vidtogfx sample app works fine!

As for timelines, I realize that the sample apps are not the highest priority, but I did not realize at first that the v4l module was just a sample module. If the v4l module depends on further development of the SDK, then my question is more like:
do you have any idea of a timeline for sufficient implementation of the SDK to allow a more sophisticated v4l module?

Are we talking about 1 year? 2 years? 1 month? 2 months? No contract needed, just an opinion or a guess would be welcome ;)

Thanks,
chris

fjaubert
01-22-2004, 10:07 AM
Actually, the SDK is now fully implemented, and there should be nothing missing in order to get a fully-functional module (such as v4l) working.

The only thing missing in v4l is development time -- it was written as a sample (and proof-of-concept), and to get things going on platforms where no other module exists yet; for now there hasn't been time to polish it and make it full-featured.

I'm not certain if any more time has been budgeted for it this year. Right now, we're focusing on finishing the SDK for the mlDC and UST components.

Would you be interested in sending me your PAL-related modifications? If you're willing to do that, I'm sure I can find the time to integrate them into the source tree.

Thanks,

Fabrice