On Sat, 2010-11-13 at 17:23 -0500, Devin Heitmueller wrote: > On Sat, Nov 13, 2010 at 3:06 PM, Andy Walls <[email protected]> wrote: > > On Sat, 2010-11-13 at 16:59 +0200, Artem Astafyev wrote: > >> Hi All, > > > > Hi. > > > >> I'm testing a new card GoTView PCI DVD3 with patch Alexey Chernov > >> provided recently. I have problem changing channel in MythTV but it > >> seems that it's not because of this patch. The problem is that cx18 > >> driver rejects standard changing if there are some active analog > >> streams. > > > > 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. > > > > That check exists, because it is not possible to change the capture and > > MPEG encoding engine between a 525 line standard (NTSC), 625 line > > stanadrd (PAL, SECAM), or audio only (FM radio) capture in mid-stream. > > Wow, so the only way to change channels is to close and reopen all > descriptors pointing to the device? Ouch.
No, there is another way to stop the stream, that MythTV actually uses for ivtv: VIDIOC_ENC_CMD with V4L2_ENC_CMD_STOP but that is marked as "experimental" in the API document. close() is not "experimental". ;) > I don't doubt that's how the cx18 works, but it's kind of a bitch for > application developers, especially since we have other drivers which > will put the tuner to sleep on v4l close (requiring a firmware reload > when it gets woken up). VIDIOC_STREAMOFF should be usable for drivers using the streaming IO method. MythTV does that too. > I guess it's less surprising to me now that the MythTV codebase is > littered with checks based on the driver and version it is interacting > with. MythTV should be looking at the capabilities flags being sent from the driver in response to VIDIOC_G_CAPABILITES (or whatever the call is). But I'll wager a $1 that those are inconsistent across all drivers. > There's got to be a less dumb way to deal with this issue. I can > understand the goal behind not allowing the user to change the > standard in the middle of streaming (returning EBUSY), but there > really should be some way to accomplish this without having to have > the application close all the filehandles No all filehandles. MythTV actually keeps two filehandles open on the same device node: one for control ioctl()s and one for read()s. It only would need to close and reopen 1 of them. Or use VIDIOC_ENC_CMD_STOP as it currently does for ivtv. > (and in some cases this > isn't even practical - think of users who run something like mplayer > to view the video and ZVBI to get captions). Changing the analog TV standard while the capture unit is pumping data along is what is not allowed. Changing the tuner channel does not mean you have to stop the user space app caturing VBI to switch the tuner channel on mplayer. If you're swithcing from SECAM-D/K to PAL-B/G (both 625 line/50 Hz) then yes, you need to stop your both the MPEG and VBI streams. Having the a driver automatically kill the VBI stream when the MPEG stream stopped would be an anti-feature however. People (i.e. me) do sometimes just capture VBI, but occasionally start and stop the video program to check it. The driver can't know what's going on in userspace in every use case. EBUSY indicates the device is in use, user and/or userspce needs to stop what is keeping the driver busy. > I guess this is less of an issue for those devices that let you > explicitly stop streaming, although I realize that interface is > typically associated with the "streaming" interface as opposed to the > read() interface. Yes, the read() interface is pretty basic. Regards, Andy > Devin > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
