On Sun, 2010-11-14 at 11:14 +0100, Martin Dauskardt wrote: > Hi everybody, > > just a few comments from an application developer :-) > > > > From: Andy Walls <[email protected]> > > > That is valid behavior per the V4L2 API: > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-std.html > > the driver is allowed to return an errno of EBUSY when it is busy. > > Unfortunately the API is not precise enough and allows different handling.
I would certainly say in this case that the API provides *too many* ways of stopping streams. Every optional method an application writer and driver writer has of performing an action is an opportunity for interoperability problems. > Can you imagine this with a DVB driver? No, once you have a driver for a DVB > card you can use the card with any DVB application. > But not so with analogue encoder cards: The application needs to know the > specialities of the driver. > > > BTW, VIDIOC_STREAMOFF is only supported for Streaming I/O methods. The > > cx18 driver only supports the read() method. Calling close() once on > > all active analog capture stream (MPEG, YUV/HM12, PCM, and/or VBI) > > file descriptors is required to free up the CX23418's encoding engine. > > But we can't close the device without stopping the read thread before. Correct, unless you don't mind the read thread receiving EBADF on the next read(). :P > > The cx18 driver automatically closing all analog streams (MPEG, > > YUV/HM12, PCM, VBI) when someone calls a VIDIOC_S_STD ioctl() on a > > device node would be considered a non-compliance with the V4L2 API. I'm > > not sure it would be a desirable feature either. > > The cx88-blackbird driver (also cx2341x) internally calls an enoder stop > firmware command (CX2341X_ENC_STOP_CAPTURE) before changing frequency. > (But unfortunately, due to a driver bug, it never starts the encoder again... > but this is a different issue) > > There are only a few cases where the driver returns EBUSY on channel > switches. > It depends on a standard change, an input change and switch between radio/TV. > Instead of doing a lot of checks most applications (mythv and vdr plugin > pvrinput) will handle each channel switch equal. Yes, I was thinking of allowing 625/50 -> 625/50 and 525/60 -> 525/60 standards changes to happen without returning EBUSY, but that doesn't cover every case, so applications still have to deal with EBUSY from S_STD. > So we have different methods for changing channels: > > 1. stop reading, close, re-open, set frequency/change input, start reading > 2. use VIDIOC_STREAMOFF /VIDIOC_STREAMON (buggy at least for ivtv and pvrusb2) > 3. use V4L2_ENC_CMD_STOP / V4L2_ENC_CMD_START if the driver supports these > ioctl (only ivtv, cx18 and hdpvr does) > 4. call only VIDIOC_S_FREQUENCY and let the driver do all necessary (only > HVR1300/blackbird has this concept, but unfortunately the driver is so buggy > that using the encoder on this card is impossible) > > I prefer the first method. This way all internal buffers are cleared, we > start on the new channel with an i-frame and have smooth channel switching > (like a DVB receiver) without any artefacts. So it is really **useful** to > stop read thread and encoder for channel switchings. Right. People will gravitate to the most reliable mechanism. Which is a very good argument for getting rid of the mechanisms that don't always work and cutting down on API complexity. I'm thinking along tha same lines as Hans in getting rid of the read() methiod as a primary I/O method for any driver. I was stalling until videobuf2 was done. VIDIOC_ENC_COMMAND should probably be discouraged for new designs/implementations of both drivers and applications. Then we would have one less "approved" way to start and stop the stream. > > Ah, I found the problem in MythTV 0.21 source code. > > > > Look at > > > > lib/libmythtv/mpegrecorder.cpp:MpegRecorder::OpenV4L2DeviceAsInput() > > I'm not sure what "has_buggy_vbi" means and whether or not it needs to > > be set for the cx18 driver. > If I remember right, there is probably something wrong with vbi (closed > captions?) in the ivtv (and probably cx18) kernel driver. This is why some > mythtv guys still prefer the old standalone ivtv driver > see change in 02/2008: > http://svn.mythtv.org/trac/changeset/15734/trunk/mythtv/libs/libmythtv/mpegrecorder.cpp > "This also updates Hans' VBI bugs warning for ivtv drivers before 0.10.0 and > after 0.10.5 due to new VBI bugs in more recent ivtv drivers." So the has_buggy_vbi flag comment really refers to old ivtv driver versions, or modern ivtv driver versions only with the PVR-250 and PVR-350. Last time I checked the PVR-350 with a modern ivtv driver, zvbi worked with /dev/vbi0 just fine. I'll have to check MythTV playback of PVR-350 MPEG streams with ivtv VBI packets. > > VIDIOC_ENC_CMD with V4L2_ENC_CMD_STOP > > > > but that is marked as "experimental" in the API document. close() is > > not "experimental". ;) > > They were experimental in 2007 when Hans Verkuil introduced them. But now > they > should be a must for every mpeg encoder driver. They certainly should not be experimental anymore if MythTV has been relying on them for 3 years. Are there use cases for mandating their use in new driver implementations, if the MPEG drivers are all converted to streaming I/O methods so that VIDIOC_STREAMON/OFF are supported? Regards, Andy > Greets, > Martin _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
