Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Le 2014-11-04 14:58, Sakari Ailus a écrit : Have you tried with a different application to see if the problem persists? Tried mplayer and cheese now, and it seems they are not affected, so it's an issue with vlc. I wonder why it doesn't like newer flags.. Ohwell, sorry for the noise. I guess the newer VLC could indeed pay attention to the monotonic timestamp flag. Remi, any idea? VLC takes the kernel timestamp, if monotonic, since version 2.1. Otherwise, it generates its own inaccurate timestamp. So either that code is wrong, or the kernel timestamps are. -- Rémi Denis-Courmont -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Le mardi 04 novembre 2014, 15:42:37 Rémi Denis-Courmont a écrit : Le 2014-11-04 14:58, Sakari Ailus a écrit : Have you tried with a different application to see if the problem persists? Tried mplayer and cheese now, and it seems they are not affected, so it's an issue with vlc. I wonder why it doesn't like newer flags.. Ohwell, sorry for the noise. I guess the newer VLC could indeed pay attention to the monotonic timestamp flag. Remi, any idea? VLC takes the kernel timestamp, if monotonic, since version 2.1. Otherwise, it generates its own inaccurate timestamp. So either that code is wrong, or the kernel timestamps are. From a quick check with C920, the timestamps from the kernel are quite jittery, and but seem to follow a pattern. When requesting a 10 Hz frame rate, I actually get a frame interval of about 8/9 (i.e. 89ms) jumping to 1/3 every approximately 2 seconds. From my user-space point of view, this is a kernel issue. The problem probably just manifests when both VLC and Linux versions support monotonic timestamps. Whether the root cause is in the kernel, the device driver or the firmware, I can´t say. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
uvcvideo USERPTR mode busted?
Hello, Trying to use USERPTR buffers with UVC, user space gets stuck either in poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever returns a frame in USERPTR mode. The symptoms are identical with kernel versions 3.6, 3.7 and 3.8. I also tested 3.2, but it did not support USERPTR. Tested hardware was Logitech HD Pro Webcam C920 with YUY2 pixel format. The same hardware and the same driver work fine with MMAP buffers. The same USERPTR userspace code works fine with the vivi test device... Did any have any better luck? -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replacement for vloopback?
On Wed, 06 Feb 2013 14:57:43 +0100, Neuer User auslands...@gmx.de wrote: So, my question ist: Is vloopback the right way to go for this requirement? If yes, how to get it working? No. Video loopback is just a way for an application to expose a virtual camera, for another application to use. It is not a way to share a camera within two applications. Sharing a camera is fundamentally impossible due to the limitation of the hardware, which cannot capture in two different formats and sets of buffers simultaneously. Live with it. -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux v3.7-rc2 DVB breaks user space compilation
Hello, The following patch broke our userspace software builds. While it does preserve BINARY compatibility, it breaks SOURCE compatibility as the parameter names have changed. I don't see the rationale for breaking compatibility in the patch description. Please consider reverting to the old names. Thank you. commit 287cefd096b124874dc4d6d155f53547c0654860 Author: Evgeny Plehov evgenyple...@ukr.net Date: Thu Sep 13 10:13:30 2012 -0300 [media] dvb_frontend: add multistream support Unify multistream support at the DVBAPI: several delivery systems allow it. Yet, each one had its own name. So, instead of adding a third version of this field, remove the per-standard naming, unifying it into a common name. The legacy code number can still be used by old applications. Version increased to 5.8. [mche...@redhat.com: joined the va1j5jf007s patch, in order to avoid compilation breakage] Signed-off-by: Evgeny Plehov evgenyple...@ukr.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Timestamps and V4L2
Le lundi 15 octobre 2012 22:59:06, Sakari Ailus a écrit : For the latter the realtime clock fits poorly to begin with: it jumps around e.g. when the daylight saving time changes. Wrong. The real time clock is always UTC. It is not subject to time zone offsets. It only jumps when the clock is manually adjusted. (That is not to deny that clock warping is a problem. All serious multimedia frameworks and network protocol stacks use the monotonic clock nowadays.) -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR 4000 and DVB-API
Le lundi 24 septembre 2012 10:51:23, Dominique Michel a écrit : The WinTV HVR-4000-HD is a multi-tuners TV card with 2 dvb tuners. It look like its driver doesn't have been updated to the new DVB-API. Multi-standard frontends required DVB API version 5.5. That is found in kernel versions 3.2 and later. So you might need to update the kernel. If you already have, then well, you need to get someone to update the driver. Also the application needs to be updated to support DVBv5.5 too. I don't know which versions of VDR support multi-standard frontends, if any as yet. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Timestamps and V4L2
Le dimanche 23 septembre 2012 14:43:42, Sakari Ailus a écrit : I think I like this idea best, it's relatively simple (even with adding support for reporting flags in VIDIOC_QUERYBUF) for the purpose. If we ever need the clock selection API I would vote for an IOCTL. The controls API is a bad choice for something such fundamental as type of clock for buffer timestamping IMHO. Let's stop making the controls API a dumping ground for almost everything in V4L2! ;) Why would the control API be worse than an IOCTL for choosing the type of the timestamp? The control API after all has functionality for exactly for this: this is an obvious menu control. What comes to the nature of things that can be configured using controls and what can be done using IOCTLs I see no difference. It's just a mechanism. That's what traditional Unix APIs do in general: provide mechanism, not a policy. Seriously? Timestamp is _not_ a controllable hardware feature like brightness or flash. Controls are meant to build user interface controls for interaction with the user. Timestamp is _not_ something the user should control directly. The application should figure out what it gets and what it needs. Or why do you use STREAMON/STREAMOFF instead of a STREAM boolean control, eh? -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Timestamps and V4L2
if timeval is retained. That being said, I think microsecond precision will be enough for longer than the foreseeable future. We are not even measuring frame rates in kHz yet. Even audio sampling rate is not reaching the MHz. So I don't really care. Also, many applications will anyway convert the field to some internal timestamp representation. Kernel version as indicator of timestamp Conversion of drivers to use monotonic timestamp is trivial, so the conversion could be done once and for all drivers. The kernel version could be used to indicate the type of the timestamp. Was there never a V4L driver exposing a version number higher than 3 16? If there was, the version number cannot be used for comparison and this is moot. If this approach is taken care must be taken when new drivers are integrated: developers sometimes use old kernels for development and might also use an old driver for guidance on timestamps, thus using real-time timestamps when monotonic timestamps should be used. The quality insurance problem will exist no matter what solution you pick. In particular, the same problem exists with the capability flag, if it ends up being set by the core blindly for all drivers. Also, with control solution, the driver could ignore the file handle value and blindly set the timestamp. Capability flag for monotonic timestamps A capability flag can be used to tell whether the timestamp is monotonic. However, it's not extensible cleanly to provide selectable timestamps. These are not features that are needed right now, though. Control for timestamp type -- Using a control to tell the type of the timestamp is extensible but not as easy to implement than the capability flag: each and every device would get an additional control. The value should likely be also file handle specific, and we do not have file handle specific controls yet. In the meantime the control could be read-only, and later made read-write when the timestamp type can be made selectable. Much of he work of timestamping can be done by the framework: drivers can use a single helper function and need to create one extra standard control. Should the control also have an effect on the types of the timestamps in V4L2 events? Likely yes. Device-dependent timestamp -- Should we agree on selectable timestamps, the existing timestamp field (or a union with another field of different type) could be used for the device-dependent timestamps. Alternatively we can choose to re-use the existing timecode field. At the moment there's no known use case for passing device-dependent timestamps at the same time with monotonic timestamps. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Le vendredi 14 septembre 2012 23:25:01, Sakari Ailus a écrit : I had a quick discussion with Laurent, and what he suggested was to use the kernel version to figure out the type of the timestamp. The drivers that use the monotonic time right now wouldn't be affected by the new flag on older kernels. If we've decided we're going to switch to monotonic time anyway, why not just change all the drivers now and forget the capability flag. That does not work In Real Life. People do port old drivers forward to new kernels. People do port new drivers back to old kernels User space needs a flag is needed. Full point. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 13/28] Add V4L2_CAP_MONOTONIC_TS where applicable.
Le vendredi 7 septembre 2012 16:29:13, Hans Verkuil a écrit : diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c index 9a05c81..3a50547 100644 --- a/drivers/media/platform/davinci/vpbe_display.c +++ b/drivers/media/platform/davinci/vpbe_display.c @@ -620,7 +620,8 @@ static int vpbe_display_querycap(struct file *file, void *priv, struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev; cap-version = VPBE_DISPLAY_VERSION_CODE; - cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; + cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING | + V4L2_MONOTONIC_TS; Typo ? strlcpy(cap-driver, VPBE_DISPLAY_DRIVER, sizeof(cap-driver)); strlcpy(cap-bus_info, platform, sizeof(cap-bus_info)); strlcpy(cap-card, vpbe_dev-cfg-module_name, sizeof(cap-card)); -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: use of timestamp/sequence in v4l2_buffer
Le mardi 4 septembre 2012 13:38:06, Hans Verkuil a écrit : 7) Should the timestamp field always be monotonically increasing? Or it is possible to get timestamps that jump around? This makes sense for encoders that create B-frames referring to frames captured earlier than an I-frame. I would expect an encoder to output frames in DTS order rather than PTS and a decoder to output frames in PTS order. The timestamp field is the only indication of the PCR, so an application might not recover if the timestamp jumps backward. If there is an ambiguity between PTS and DTS, I think it should be documented and specified per format what the timestamp is. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/10] v4l: Remove experimental tag from certain API elements
Le lundi 3 septembre 2012 16:48:35, Hans Verkuil a écrit : From: Sakari Ailus sakari.ai...@iki.fi Remove experimantal tag from the following API elements: V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY buffer type. V4L2_CAP_VIDEO_OUTPUT_OVERLAY capability flag. VIDIOC_ENUM_FRAMESIZES IOCTL. The patch correctly but silently clears ENUM_FRAMEINTERVALS too... VIDIOC_G_ENC_INDEX IOCTL. VIDIOC_ENCODER_CMD and VIDIOC_TRY_ENCODER_CMD IOCTLs. VIDIOC_DECODER_CMD and VIDIOC_TRY_DECODER_CMD IOCTLs. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Le lundi 13 août 2012 15:27:56 Hans Verkuil, vous avez écrit : 1) What is the right/best way to set the timestamp? The spec says gettimeofday, but is it my understanding that ktime_get_ts is much more efficient. Some drivers are already using ktime_get_ts. Options: a) all drivers must comply to the spec and use gettimeofday gettimeofday() is wrong for use other than getting the wall clock time. In particular, it breaks if the real-time clock gets adjusted while streaming. Practically all modern multimedia applications on Linux use the monotonic POSIX clock in a way or another. b) we change the spec and all drivers must use the more efficient ktime_get_ts Unfortunately, that would not be enough to be immediately useful. Userspace needs a way to know that it can (finally!) trust the timestamps. Currently, since different drivers use different clocks, the only reasonable option for user space consists of ignoring the V4L2 timestamp. Thus userspace has to fall back to the current clock time after ioctl(DQBUF) returns, as an approximation. c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a monotonic clock like ktime_get_ts is used and all drivers that use ktime_get_ts should set that flag. Yes, either a buffer or a capability flag ought to work. If we go for c, then we should add a recommendation to use one or the other as the preferred timestamp for new drivers. IMHO, all drivers should be adapted to the new specification as far as possible. Of course, that will break any user space application that would have trusted V4L2 to return valid CLOCK_REALTIME timestamps so far. I'd argue such an application was already broken in practice even if it conformed to the letter of the V4L2 specification. -- Rémi Denis-Courmont C/C++ software engineer looking for a job http://www.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. That's contradictory. If most drivers do not support it, then it won't work during streaming. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The smallest of the maxima of all drivers. The minimum is usually between 1 and 3, depending on hardware limitations. And that's clearly insufficient without memory copy to userspace buffers. It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for REQBUFS+USERBUF then. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I want to receive the video buffers in user space for processing. Typically processing is software encoding or conversion. That's what virtually any V4L application does on the desktop... But what prevents you from using MMAP ? As I wrote several times earlier, MMAP uses fixed number of buffers. In some tightly controlled media pipeline with low latency, it might work. But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. By the way, this was already discussed a few months ago for the exact same DMABUF patch series... -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for v3.6] VIDIOC_ENUM_FREQ_BANDS fix
Le mercredi 1 août 2012 22:52:46 Hans Verkuil, vous avez écrit : When VIDIOC_ENUM_FREQ_BANDS is called for a driver that doesn't supply an enum_freq_bands op, then it will fall back to reporting a single freq band based on information from g_tuner or g_modulator. By the way... Isn't V4L2_TUNER_CAP_FREQ_BANDS expected to tell whether the driver can enumerate bands? Why is there a need for fallback implementation? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit : But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. I am not sure DMABUF even supports transmitting data efficiently to userspace. In my understanding, it's meant for transmitting data between DSP's bypassing userspace entirely, in other words the exact opposite of what USERBUF does. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez écrit : On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. hmm, this sounds like the problem is device pre-allocating buffers? Basically, yes. Anyways, last time I looked, the vb2 core supported changing dmabuf fd each time you QBUF, in a similar way to what you can do w/ userptr. So that seems to get you the advantages you miss w/ mmap without the pitfalls of userptr. It might work albeit with a higher system calls count overhead. But what about libv4l2 transparent format conversion? Emulated USERBUF, with MMAP in the back-end would provide by far the least overhead. I don't see how DMABUF would work there. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez écrit : Hi Rémi, On Tuesday 31 July 2012 16:39:00 Rémi Denis-Courmont wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. Could you please share your use case(s) with us ? I want to receive the video buffers in user space for processing. Typically processing is software encoding or conversion. That's what virtually any V4L application does on the desktop... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Wed, 25 Jul 2012 08:21:05 +0200, Hans Verkuil hverk...@xs4all.nl wrote: On Tue July 24 2012 22:37:35 Rémi Denis-Courmont wrote: Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) Devin Ditto. Input from user application developers is something that kernel developers need and value greatly. Note, that I will not be at the workshop of Plumbers this year. :( Is the media summit timed with LPC or the kernel summit? If I come, I have to leave on Thursday to catch the VideoLAN conference in Paris on the next week- end... It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Thu, 26 Jul 2012 11:42:15 +0200, Hans Verkuil hverk...@xs4all.nl wrote: It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... Yes, that's firm. Sorry again... Does that mean nothing happens on Sunday and Monday? Also, when do get confirmed invitations to attend the media summit? -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hello, Le mardi 17 juillet 2012 20:30:53 Mauro Carvalho Chehab, vous avez écrit : As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. If it's of interest to anyone, I could probably present a bunch of issues with V4L2 and DVB from userspace perspective. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) Devin Ditto. Input from user application developers is something that kernel developers need and value greatly. Note, that I will not be at the workshop of Plumbers this year. :( Is the media summit timed with LPC or the kernel summit? If I come, I have to leave on Thursday to catch the VideoLAN conference in Paris on the next week- end... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media system Summit
Hello all, Le jeudi 12 juillet 2012 06:18:08 Mauro Carvalho Chehab, vous avez écrit : We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day Not sure what happened (or maybe my proposal were not clear enough), but I've submitted a proposal to have a media system summit on KS/2011. Last year was very productive for media developers, so we'd like to do it again ;) Do you guys expect to discuss anything relevant to userland? (V4L? DVB? ...?) -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 API and radio devices with multiple tuners
Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] v4l2: use __u32 rather than enums in ioctl() structs
On Mon, 7 May 2012 17:27:49 +0300, Sakari Ailus sakari.ai...@iki.fi wrote: From: Rémi Denis-Courmont r...@remlab.net I don't think I have written any surviving line in that patch. No objections though. -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add fc0011 tuner driver
Le mardi 8 mai 2012 00:00:31 Michael Büsch, vous avez écrit : + dev_dbg(priv-i2c-dev, Tuned to + fa=%02X fp=%02X xin=%02X%02X vco=%02X vcosel=%02X + vcocal=%02X(%u) bw=%u\n, + (unsigned int)regs[FC11_REG_FA], + (unsigned int)regs[FC11_REG_FP], + (unsigned int)regs[FC11_REG_XINHI], + (unsigned int)regs[FC11_REG_XINLO], + (unsigned int)regs[FC11_REG_VCO], + (unsigned int)regs[FC11_REG_VCOSEL], + (unsigned int)vco_cal, vco_retries, + (unsigned int)bandwidth); Just for the interest, is there any reason you use so much casting or is that only your style? Well it makes sure the types are what the format string and thus vararg code expects. it is true that most (probably all) of those explicit casts could be removed and instead rely on implicit casts and promotions. But I personally prefer explicit casts in this case (and only this case). Not sure Linux printk supports it, but C specifies the hh prefix for 'char', and the h prefix for 'short' for instance %02hhX, and this would also work for u8 and u16. The pedantic in me needs to add that the official prefixes for uint8_t and uint16_t are the PRIX8 and PRIX16 macros from inttypes.h, e.g.: printf(%02PRIX8\n, regs[0]); ...but that's definitely not valid in kernel. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
On Thu, 3 May 2012 00:39:15 +0300, Sakari Ailus sakari.ai...@iki.fi wrote: - ppc64: int is 64 bits there, and thus also enums, Really? (e)glibc assumes that signed int and unsigned int are 32-bits on all platforms. From bits/types.h: typedef signed int __int32_t; typedef unsigned int __uint32_t; - C does not specify which integer type enums actually use; this is what GCC manual says about it: The Linux ABI, at least as defined in GCC, requires 'short enums' be disabled, even on ARM. So enums should always be unsigned or int with gcc, thus with V4L2 code. -- Rémi Denis-Courmont -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Answering myself. On Thu, 03 May 2012 12:57:00 +0200, Rémi Denis-Courmont r...@remlab.net wrote: On Thu, 3 May 2012 00:39:15 +0300, Sakari Ailus sakari.ai...@iki.fi wrote: - ppc64: int is 64 bits there, and thus also enums, Really? No, really not: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUND-TYPE -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2
On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski t.stanisl...@samsung.com wrote: Am I understanding wrong or are you saying that you want to drop userptr from V4L2 API in long-term? If so, why? Dropping userptr is just some brainstorming idea. It was found out that userptr is not a good mean for buffer exchange between to two devices. I can believe that. But I am also inclined to believe that DMABUF is targetted at device-to-device transfer, while USERPTR is targetted at device-to-user (or user-to-device) transfers. Are you saying applications should use DMABUF and memory map the buffers? Or would you care to explain how DMABUF addresses the problem space of USERPTR? The USERPTR simplifies userspace code but introduce a lot of complexity problems for the kernel drivers and frameworks. It is not only a simplification. In some cases, USERPTR is the only I/O method that supports zero copy in pretty much any circumstance. When the user cannot reliably predict the maximum number of required buffers, predicts a value larger than the device will negotiate, or needs buffers to outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not. Now, I do realize that some devices cannot support USERPTR efficiently, then they should not support USERPTR. But for those devices that can, it seems quite a nice performance enhancement. -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2
On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski t.stanisl...@samsung.com wrote: The USERPTR simplifies userspace code but introduce a lot of complexity problems for the kernel drivers and frameworks. It is not only a simplification. In some cases, USERPTR is the only I/O method that supports zero copy in pretty much any circumstance. Only for devices that have its own IOMMU that can access system memory. Newer versions of the UVC driver have USERTPR, and simingly gspca seems too. That is practically all USB capture devices... That might be irrelevant for a smartphone manufacturer. That is very relevant for desktop applications. Moreover the userptr must come from malloc or be a mmaped file. The other case are drivers that touch memory using CPU in the kernel space like VIVI or USB drivers. I'd argue that USB is the most common case of V4L2 on the desktop... When the user cannot reliably predict the maximum number of required buffers, predicts a value larger than the device will negotiate, or needs buffers to outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not. What does outlive STREAMOFF means in this context? Depending how your multimedia pipeline is built, it is plausible that the V4L2 source is shutdown (STREAMOFF then close()) before buffers coming from it are released/destroyed downstream. I might be wrong, but I would expect that V4L2 MMAP buffers become invalid after STREAMOFF+close()? Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the best idea because it introduces an allocation overhead for negotiations of the number of the buffers. An allocation at mmap was to late. There is a need for some intermediate state between REQBUFS and mmap. The ioctl BUF_PREPARE may help here. Can you give me an example of a sane application is forced to negotiate a larger number of buffers than it is actually going to use? Outside the embedded world, the application typically does not know what the latency of the multimedia pipeline is. If the latency is not known, the number of buffers needed for zero copy cannot be precomputed for REQBUFS, say: count = 1 + latency / frame interval. Even for a trivial analog TV viewer application, lip synchronization requires picture frames to be bufferred to be long enough to account for the latency of the audio input, dejitter, filtering and audio output. Those values are usually not well determined at the time of requesting buffers from the video capture device. Also the application may want to play nice with PulseAudio. Then it will get very long audio buffers with very few audio periods... more latency. It gets harder or outright impossible for frameworks dealing with complicated or arbitrary pipelines such as LibVLC or gstreamer. There is far too much unpredictability and variability downstream of the V4L2 source to estimate latency, and infer the number of buffers needed. Now, I do realize that some devices cannot support USERPTR efficiently, then they should not support USERPTR. The problem is not there is *NO* device that can handle USERPTR reliably. The can handle USERPTR generated by malloc or page cache (not sure). Memory mmaped from other devices, frameworks etc may or may not work. Even if the device has its IOMMU the DMA layer provides no generic way to transform from one device to the mapping in some other device. I'm not saying that USERPTR should replace DMABUF. I'm saying USERPTR has advantages over MMAP that DMABUF does not seem to cover as yet (if only libv4l2 would not inhibit USERPTR...). I'm definitely not saying that applications should rely on USERPTR being supported. We agree that not all devices can support USERPTR. The userptr has its niches were it works pretty well like Web cams or VIVI. I am saying that if ever DMABUF becomes a good alternative for USERPTR than maybe we should consider encouraging dropping USERPTR in the new drivers as 'obsolete' feature and providing some emulation layer in libv4l2 for legacy applications. Sure. -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2 Device with H264 support
Hello, On Tue, 17 Apr 2012 12:02:25 +1200 (NZST), Pieter De Wit pie...@insync.za.net wrote: I would like to stream H264 from a v4l2 device that does hardware encoding. ffmpeg and all of those doesn't seem to understand H264, but v4l2 does. If I run qv4l2, it shows that H264 is in the encoding list and I can preview that. Using v4l2-ctl, I can set the pixel format to H264 and the get-fmt reports it correctly. Is there any way I can get a raw frame dump from the v4l2 device ? I have used all the samples I can find and none seems to work. If the device supports read(/write) mode, I suppose you could simply read the device node as a file. 'vlc v4l2c:///dev/video0 --demux h264' might work thanks to a software bug whereby the format is not reset, but I have not tried. V4L2 H.264 is supported in VLC version 2.0.2-git: 'vlc v4l2:///dev/video0:chroma=h264'. -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] V4L: Extend V4L2_CID_COLORFX with more image effects
On Tue, 17 Apr 2012 12:09:42 +0200, Sylwester Nawrocki s.nawro...@samsung.com wrote: This patch adds definition of additional color effects: - V4L2_COLORFX_AQUA, - V4L2_COLORFX_ART_FREEZE, - V4L2_COLORFX_SILHOUETTE, - V4L2_COLORFX_SOLARIZATION, - V4L2_COLORFX_ANTIQUE, There starts to be a lot of different color effects with no obvious way to determine which ones the current device actually suppots. Should this not be a menu control instead? - V4L2_COLORFX_ARBITRARY. The control's type in the documentation is changed from 'enum' to 'menu' - V4L2_CID_COLORFX has always been a menu, not an integer type control. The V4L2_COLORFX_ARBITRARY option enables custom color effects, which are impossible or impractical to define as the menu items. For example, the devices may provide coefficients for Cb and Cr manipulation, which yield many permutations, e.g. many slightly different color tints. Such devices are better exporting their own API for precise control of non-standard color effects. I don't understand why you need a number for this, if it's going to use another control anyway... ? -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2 Device with H264 support
Le mardi 17 avril 2012 23:30:43 Pieter De Wit, vous avez écrit : Thanks for the reply. I suspect that there is some tricks needed to get the h264 stream from this device, into something of a player. At least for UVC devices, it's pretty damn straight forward. You just need to set pixel format 'H264' with the standard VIDIOC_S_FMT. Then you get the H.264 elementary stream with the plain normal streaming or read/write modes of V4L2. E.g.: # v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=H264 # vlc v4l2c/h264:// -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [yavta PATCH 1/3] Support integer menus.
Le vendredi 13 avril 2012 22:47:14 Laurent Pinchart, vous avez écrit : Hi Sakari, Thanks for the patch. The code looks fine, but unfortunately breaks compilation when using kernel headers v3.5 (which is a pretty common case as of today ;-)). V4L2_CTRL_TYPE_INTEGER_MENU is an enumerated value, not a pre-processor #define, so it's difficult to test for it using conditional compilation. Same problem with BITMASK already. The most common solution to this problem, although not found in V4L consists of defining the enumeration members in the header linux/videodev2.h: #define V4L2_CTRL_TYPE_INTEGER_MENU V4L2_CTRL_TYPE_INTEGER_MENU Then #ifdef works fine. libc has plenty of these, e.g. bits/socket.h. Or per package, autoconf can be used: AC_CHECK_HEADERS([linux/videodev2.h sys/videoio.h]) AC_CHECK_DECLS([V4L2_CTRL_TYPE_INTEGER_MENU],,, [ #ifdef HAVE_LINUX_VIDEODEV2_H # include linux/videodev2.h #endif #ifdef HAVE_SYS_VIDEOIO_H # include sys/videoio.h #endif ]) Then this works: #if HAVE_DECL_V4L2_CTRL_TYPE_INTEGER_MENU -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
On Thu, 12 Apr 2012 11:55:12 -0300, Mauro Carvalho Chehab mche...@redhat.com wrote: I can see only two viable fixes for it: 1) add a typedef for the enum, using the sizeof(enum) in order to select the size of the used integer. Pros: - Patch is easy to write/easy to review; - Won't change the struct size, so applications compiled without strong gcc optimization won't break; Cons: - It will add a typedef, with is ugly; - struct size on 32 bits will be different thant he size on 64 bits (not really an issue, as v4l2-compat32 will handle that; On which platforms do enums occupy 64-bits? Alpha? More to the point, on which platform is enum not the same size as unsigned? At least on x86-64, enum is 32-bits and so is unsigned. - v4l2-compat32 code may require changes. 2) just replace it by a 32 bits integer. Pros: - no typedefs; - struct size won't change between 32/64 bits (except when they also have pointers); Cons: - will break ABI. So, a compat code is required; - will require a videodev2.h fork for the legacy API with the enum's; - will require a compat code to convert from enum into integer and vice-versa. Comments/Votes? -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
UVC frame interval inconsistency
Hello guys, I have been reworking the V4L2 input in VLC and I hit what looks like a weird bug in the UVC driver. I am using a Logitech HD Pro C920 webcam. By default, VLC tries to find the highest possible frame rate (actually smallest frame interval in V4L2), then the largest possible resolution at that frame rate. When enumerating the frame sizes and intervals on the device, the winner is 800x600 at 30 f/s. But when setting 30 f/s with VIDIOC_S_PARM, the system call returns 24 f/s. Does anyone know why it is so? Is this a firmware bug or what? -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
Hello, Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit : Using unsigned instead of enum is not a good idea, from API POV, as unsigned has different sizes on 32 bits and 64 bits. Fair enough. But then we can do that instead: typedef XXX __enum_t; where XXX is the unsigned integer with the right number of bits. Since Linux does not use short enums, this ought to work fine. Yet, using enum was really a very bad idea, and, on all new stuff, we're not accepting any new enum field. That is unfortunately not true. You do follow that rule for new fields to existing V4L2 structure. But you have been royally ignoring that rule when it comes to extending existing enumerations: linux-media does regularly add new enum values to existing enums. That is new stuff too, and every single time you do that, you do BREAK THE USERSPACE ABI. This is entirely unacceptable and against established kernel development policies. For instance, in Linux 3.1, V4L2_CTRL_TYPE_BITMASK was added. This broke userspace. And there are some pending patches adding more of the same thing... And V4L2_MEMORY_DMABUF will similarly break the user-to-kernel interface, which is yet worse. That's said, a patch like that were proposed in the past. See: http://www.spinics.net/lists/vfl/msg25686.html Alan said there [1] that: Its a fundamental change to a public structure from enum to u32. I think you are right but this change seems too late by several years. I cannot see how the kernel is protected against userspace injecting error values into enums. For all I know, depending how the kernel is compiled, userspace might be able to trigger undefined behavior in kernel space. Is it be several years too late to fix a bug? (...) I don't think anything has changed since then that would make it easier to apply a change like that. OK. But then you cannot update extend existing enums... No DMA buffers, no integer menu controls... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
Le mercredi 11 avril 2012 22:53:23 Mauro Carvalho Chehab, vous avez écrit : But you have been royally ignoring that rule when it comes to extending existing enumerations: The existing enumerations can be extended, by adding new values for unused values, otherwise API functionality can't be extended. Yes. That's why they should be some unsigned type. Yet, except for a gcc bug (or weird optimize option), I fail to see why this would break the ABI. From the perspective of the compiler, this is a feature not a bug. In C and C++, loading or storing a value in an enumerated variable whereby the value is not a member of the enumeration is undefined. In other words, the compiler can assume that this does not happen, and optimize it away. If this is all about some gcc optimization with newer gcc versions, then maybe the solution may be to add some pragmas at the code to disable such optimization when compiling the structs with enum's at videodev2.h. Maybe the Linux kernel could be specifically compiled to prevent GCC from range-optimizing enumerations. But as -fno-jump-table only disables one of several potential range optimizations, I doubt this is even possible. Regardless, you cannot require all of Linux userspace to rely on an hypothetic non-standard GNU C extension. Thus extending enums remains a silent userspace ABI break in any case. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] Documentation: media: description of DMABUF importing in V4L2
[VIDEO_MAX_PLANES];
+ int i;
+
+ memset(amp;buf, 0, sizeof buf);
+ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+ buf.memory = V4L2_MEMORY_DMABUF;
+ buf.index = index;
+ buf.m.planes = planes;
+ buf.length = n_planes;
+
+ memset(amp;planes, 0, sizeof planes);
+
+ for (i = 0; i lt; n_planes; ++i)
+ buf.m.planes[i].m.fd = dmafd[i];
+
+ if (ioctl (v4lfd, VIDIOC-QBUF;, amp;buf) == -1) {
+ perror (VIDIOC_QBUF);
+ return -1;
+ }
+
+ return 0;
+}
+ /programlisting
+/example
+
+paraFilled or displayed buffers are dequeued with the
+VIDIOC-DQBUF; ioctl. The driver can unpin the buffer at any
+time between the completion of the DMA and this ioctl. The memory is
+also unpinned when VIDIOC-STREAMOFF; is called, VIDIOC-REQBUFS;, or
+when the device is closed./para
+
+paraFor capturing applications it is customary to enqueue a
+number of empty buffers, to start capturing and enter the read loop.
+Here the application waits until a filled buffer can be dequeued, and
+re-enqueues the buffer when the data is no longer needed. Output
+applications fill and enqueue buffers, when enough buffers are stacked
+up output is started. In the write loop, when the application
+runs out of free buffers it must wait until an empty buffer can be
+dequeued and reused. Two methods exist to suspend execution of the
+application until one or more buffers can be dequeued. By default
+constantVIDIOC_DQBUF/constant blocks when no buffer is in the
+outgoing queue. When the constantO_NONBLOCK/constant flag was
+given to the func-open; function, constantVIDIOC_DQBUF/constant
+returns immediately with an EAGAIN; when no buffer is available. The
+func-select; or func-poll; function are always available./para
+
+paraTo start and stop capturing or output applications call the
+VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
+constantVIDIOC_STREAMOFF/constant removes all buffers from both queues
and +unlocks/unpins all buffers as a side effect. Since there is no notion
of doing +anything now on a multitasking system, if an application needs
to synchronize +with another event it should examine the v4l2-buffer;
+structfieldtimestamp/structfield of captured buffers, or set the field
+before enqueuing buffers for output./para
+
+paraDrivers implementing user pointer I/O must support the
User pointer again??
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] v4l: vb2: add support for shared buffer (dma_buf)
*(*cookie)(void *buf_priv);
@@ -75,6 +103,7 @@ struct vb2_mem_ops {
struct vb2_plane {
void*mem_priv;
+ struct dma_buf *dbuf;
};
/**
@@ -83,12 +112,14 @@ struct vb2_plane {
* @VB2_USERPTR: driver supports USERPTR with streaming API
* @VB2_READ:driver supports read() style access
* @VB2_WRITE: driver supports write() style access
+ * @VB2_DMABUF: driver supports DMABUF with streaming API
*/
enum vb2_io_modes {
VB2_MMAP= (1 0),
VB2_USERPTR = (1 1),
VB2_READ= (1 2),
VB2_WRITE = (1 3),
+ VB2_DMABUF = (1 4),
};
/**
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
With an enumeration, the compiler assumes that the integer value is one
allowed by the underlying enumeration type. With optimization enabled
this can result in byte code that is unable to cope with other values.
For instance, GCC can compile a switch() block using a jump table to
avoid repetitive conditional branching.
This can be a problem both from user to kernel and kernel to user.
* Evil user space can pass error values to the kernel via system
calls. There are no sane ways to protect the kernel: the compiler may
optimize away range checks if it deems that all legitimate values are
within the range.
* The kernel can break the user space binary interface whenever a new
value is added to an existing enumeration. A newer kernel can then
return an enumerated value that was not allowed by older kernel headers
against which the user program was compiled. In principles, V4L2 user
space needs to be recompiled whenever videodev2.h has updated enums...
(This an obvious problem with V4L2_QUERYCTRL.)
Fortunately, the Linux ABI disables short-enums on all platforms. Even
the Linux variant of the ARM AAPCS contradicts the standard ARM AAPCS
in doing so.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
include/linux/videodev2.h | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c9c9a46..df3b8f0 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -292,10 +292,10 @@ struct v4l2_pix_format {
__u32 width;
__u32 height;
__u32 pixelformat;
- enum v4l2_field field;
+ unsignedfield;
__u32 bytesperline; /* for padding, zero if unused
*/
__u32 sizeimage;
- enum v4l2_colorspacecolorspace;
+ unsignedcolorspace;
__u32 priv; /* private data, depends on
pixelformat */
};
@@ -432,7 +432,7 @@ struct v4l2_pix_format {
*/
struct v4l2_fmtdesc {
__u32 index; /* Format number */
- enum v4l2_buf_type type; /* buffer type*/
+ unsignedtype; /* buffer type*/
__u32 flags;
__u8description[32]; /* Description string */
__u32 pixelformat; /* Format fourcc */
@@ -573,8 +573,8 @@ struct v4l2_jpegcompression {
*/
struct v4l2_requestbuffers {
__u32 count;
- enum v4l2_buf_type type;
- enum v4l2_memorymemory;
+ unsignedtype;
+ unsignedmemory;
__u32 reserved[2];
};
@@ -636,16 +636,16 @@ struct v4l2_plane {
*/
struct v4l2_buffer {
__u32 index;
- enum v4l2_buf_type type;
+ unsignedtype;
__u32 bytesused;
__u32 flags;
- enum v4l2_field field;
+ unsignedfield;
struct timeval timestamp;
struct v4l2_timecodetimecode;
__u32 sequence;
/* memory location */
- enum v4l2_memorymemory;
+ unsignedmemory;
union {
__u32 offset;
unsigned long userptr;
@@ -708,7 +708,7 @@ struct v4l2_clip {
struct v4l2_window {
struct v4l2_rectw;
- enum v4l2_field field;
+ unsignedfield;
__u32 chromakey;
struct v4l2_clip__user *clips;
__u32 clipcount;
@@ -745,14 +745,14 @@ struct v4l2_outputparm {
* I N P U T I M A G E C R O P P I N G
*/
struct v4l2_cropcap {
- enum v4l2_buf_type type;
+ unsignedtype;
struct v4l2_rectbounds;
struct v4l2_rectdefrect;
struct v4l2_fract pixelaspect;
};
struct v4l2_crop {
- enum v4l2_buf_type type;
+ unsignedtype;
struct v4l2_rectc;
};
@@ -1156,7 +1156,7 @@ enum v4l2_ctrl_type {
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
struct v4l2_queryctrl {
__u32id;
- enum v4l2_ctrl_type type;
+ unsigned type;
__u8 name[32]; /* Whatever */
__s32minimum; /* Note signedness */
__s32maximum;
@@ -1788,7 +1788,7 @@ enum v4l2_jpeg_chroma_subsampling {
struct v4l2_tuner {
__u32 index;
__u8name[32];
- enum v4l2_tuner_typetype;
+ unsignedtype;
__u32
Re: dvb-c usb device for linux
Le dimanche 11 mars 2012 15:08:25 Claus Olesen, vous avez écrit : PS. If linux supported the 290e for dvb-c as supported by its chipset CXD2820 as also used by the ET T2C for dvb-c then it would be my choice. The Linux driver does support DVB-C. However you need software that understands multi-standard frontends from the Linux DVB API v5.4, and that is hard to come by as of today. As I said in my previous email then I found that the 290e works for dvb-c using dvbviewer and just now I found that it works for dvb-c also using dvblink I have 290e showing DVB-C channels with hacked VLC on Linux 3.3-rc6. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mapping frontends to demuxes
By the way, the bt8xx driver exposes ATSC but not ITU J.83 annex B. This is contrary to all other ATSC frontends. Is this correct? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mapping frontends to demuxes
Le dimanche 11 mars 2012 17:34:50 Devin Heitmueller, vous avez écrit : 2012/3/11 Rémi Denis-Courmont r...@remlab.net: By the way, the bt8xx driver exposes ATSC but not ITU J.83 annex B. This is contrary to all other ATSC frontends. Is this correct? Many of the older cards didn't support J.83 annex B (i.e. ClearQAM). Whether the device supports ClearQAM or not is actually controlled by the demodulator driver, not the bridge driver. Ah ok, thanks. On the topic of J.83, what's the intended difference between SYS_ISDBC and SYS_DVBC_ANNEX_C ? (I cannot find any driver with SYS_ISDBC.) -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils migrated to autotools
On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage. These days, automake has a silent mode that looks much like a kernel compilation. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils migrated to autotools
On Wed, 18 Jan 2012 10:43:21 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 18-01-2012 10:31, Rémi Denis-Courmont escreveu: On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage. These days, automake has a silent mode that looks much like a kernel compilation. Thanks for pointing it! I've enabled this with this small patch. You can even do AM_SILENT_RULES([yes]) if you want silence by default. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-utils migrated to autotools
On Wed, 18 Jan 2012 13:44:09 +0100, Patrick Boettcher pboettc...@kernellabs.com wrote: I love cmake and can't understand why people are not preferring it over autotools for user-space applications and conditional+configurable builds. In my experience, cmake sucks at cross-compilation. It is also rather limited when it comes to compiling libraries, as opposed to libtool. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit : You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid arguments etc. will be returned as usual. That's a limitation, not a feature. You should not transmit unwanted programs over the network, nor copy them to kernel space. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Fri, 02 Dec 2011 09:14:47 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: If you're referring to the device name under /dev, a daemon emulating a physical device could create Unix sockets under /dev/dvb. Hmm, how would that work if a real physical device gets added afterward and udev wants to create the nodes? -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Fri, 02 Dec 2011 12:48:35 +0100, Andreas Oberritter o...@linuxtv.org wrote: Btw, applications like vdr, vlc, kaffeine and others already implement their own ways to remotelly access the DVB devices without requiring any kernelspace piggyback driver. Can vdr, vlc, kaffeine use remote tuners on hosts not running vdr, vlc or kaffeine? Should we implement networking protocols in scan, w_scan, czap, tzap, szap, mplayer, dvbsnoop, dvbstream, etc. instead? VLC does not support remote control of digital (nor analog) tuners as of today. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit : Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. I see. So if you think it is nice to get dvb-core, make a wrapper around to get it usable in userspace and maintain totally same functionality by myself then I say it is no go. If it looks for you like good idea I must disagree. Code duplication? Sure, some core code would be duplicated. That is not a big deal. This proposal however has three big advantages: - Proprietary drivers are not enabled as the library would be GPL. - The virtual DVB device runs in the same process as the DVB application, which saves context switching and memory copying. - It would be your project. You do not need to agree with Mauro ;-) Two maintaners? That is crazy idea man. Someone would have to maintain the device driver anyway. I don't see much of a difference on maintainance side. And I can't see any advantage on yours ;) Putting something that belongs to userspace into kernelspace just because it is easier to re-use the existing code inside the kernel is not a good argument. It is only your POV that it should be in userspace. Except for backward compatiblity, this would actually belong in userspace. It would be more efficient and easier to maintain as a userspace library than as a kernel driver. If you need backward compatibility, I am still inclined to believe that you could write a CUSE frontend, so it does involve some extra work and looses the performance benefit. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV ported to Windows
Hello, A GPL troll, as the Vicious Nokia Employee [that got] VLC Removed from Apple App Store I cannot resist... Le mercredi 30 novembre 2011 19:23:26 Devin Heitmueller, vous avez écrit : Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. If you have any doubt, I would suggest you ask the SFLC. They tend to give valuable insights into that sort of problems. It might be intricate and/or not what you want to hear from them though (Been there done that). I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. As long as the distributed binaries do not include any GPL-incompatible code (presumably from Microsoft), there should be no GPL contamination problem. So it boils down to whether the driver binary has non-GPL code in it. I don't see how the license of the Windows code is relevant, so long as NetUp is not distributing the Windows OS alongside the driver (or vice versa). And while I do not know the Windows DDK license, I doubt it cares much about the driver license, so long as Microsoft does not need to distribute nor certify the driver. There may however be problems with the toolchain. The driver binary must be recompilable with just the GPL'd source code and anything that is normally distributed with the operating system. VisualStudio is not distributed with Windows. In fact, it is sold as a separate product, except for restrictive freeware versions. So unless this driver can be compiled with a GPL-compatible toolchain (and the toolchain is provided by NetUp), it might not be possible to distribute binary copies of the driver. Then again, I am not a laywer. Someone that cares, please ask SFLC or friends. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device
Hello, On Wed, 30 Nov 2011 22:38:33 +0100, HoP jpetr...@gmail.com wrote: I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? I am not a LinuxTV developer so I am not in position to take a stand for or against this. Ultimately though, either your driver is rejected or it is accepted. This is not really a matter of being aggressive or not. It just so happens that many Linux-DVB contributors feel the same way against that class of driver. Also note the fear of GPL avoidance is not unique to Linux-DVB. If I am not mistaken there is no user-space socket API back-end for the same reasons. And there is also no _in-tree_ loopback V4L2 device driver in kernel. Then would be better to remove loadable module API fully from kernel. Is it the right way? You seem to been misrepresenting things on purpose here, and this will never play in your favor. Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. Sure. On That said, the Network Block Device, USB-IP and TUNTAP are not really competing with real drivers because of their high perfomance impact, so they are probably not the best examples to support your argument. uinput and ALSA loopback would seem like better examples to me. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me. Did you try to implement this through CUSE? Then there should be no GPL problems. Also then you do not need to convince anybody to take your driver in the kernel. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gnutv should not ignore SIGPIPE
Le vendredi 25 novembre 2011 15:05:44 Brian J. Murrell, vous avez écrit : Is there a good reason I am not seeing why gnutv should be ignoring SIGPIPE? In general, ignoring SIGPIPE is the easiest way to protect against denial of service when a peer connection socket is hung up remotely. MSG_NOSIGNAL is a more modern alternative. Anyway, the problem is not so mucgh ignoring SIGPIPE as ignoring EPIPE write errors. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Query] V4L2 Integer (?) menu control
On Wed, 23 Nov 2011 23:26:22 +0100, Sylwester Nawrocki snj...@gmail.com wrote: I don't seem to find a way to implement this in current v4l2 control framework. Such functionality isn't there, or is it ? You can use the menu control type, but you will need to remap the control values so they are continuous. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] [media] dvb: Allow select between DVB-C Annex A and Annex C
Le dimanche 20 novembre 2011 16:56:11 Mauro Carvalho Chehab, vous avez écrit : DVB-C, as defined by ITU-T J.83 has 3 annexes. The differences between Annex A and Annex C is that Annex C uses a subset of the modulation types, and uses a different rolloff factor. A different rolloff means that the bandwidth required is slicely different, and may affect the saw filter configuration at the tuners. Also, some demods have different configurations, depending on using Annex A or Annex C. So, allow userspace to specify it, by changing the rolloff factor. I assume you'll bump the minor DVB version at some point too? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVBv5 frontend library
Hello kernel-space friends, On Wed, 09 Nov 2011 17:01:59 -0200, Mauro Carvalho Chehab mche...@redhat.com wrote: As I've commented with some at the KS, I started writing a new DVB library, based on DVBv5. It is currently at very early stages. Help and suggestions are welcome. It is at: http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils It currently doesn't do much, but the hole idea is to offer a library that can easily upgraded to support new standards, and based on DVBv5. IMHO, adding new standards with DVBv5 is already fairly easy, as opposed to with DVBv3. The only issue I've had (while porting VLC to DVBv5) lied in determining which parameters needed to be set and what values they would accept. (...) The frontend library is inside: dvb-fe.c dvb-fe.h And the pertinent parameters needed by each delivery system is provided into a separate header: dvb-v5-std.h As a documentation, it's nice to have. It should also enumerate the legal values, a bit like V4L2 user controls. However, I'm not sure how useful it can really be used to abstract away tuning standards. There are a number of problems remaining: 1) User-space may need localization of parameters names and enumeration value names. For frequency, we also need a unit, since it depends on the delivery system. In VLC, we have to replicate and keep the list of well-known V4L2 controls parameters just so gettext sees them. The same problem would affect DVB if you carry on with this. And unfortunately, even if v4l-utils had its own gettext domain, I doubt it would get as good visibility among translators as end-user applications have (e.g. VLC has 78 locales as of today). 2) Some user-space are cross-platform, say across Linux DVB and Windows BDA. Since Windows BDA does not abstract delivery subsystems, such software cannot leverage dvb-v5-std.h. 3) Some settings are absolutely required (e.g. frequency), some may be required depending on hardware and/or driver, some are not normally required to tune. When writing a UI, you need to know that. 4) Systems like DVB-H (R.I.P.) or ATSC-M/H cannot be abstracted meaningfully as they don't provide a TS feed, so the user-space can't use them. 5) Unless/Until the library implements scanning and some kind of channel or transponder abstraction (e.g. unique ID per transponder), it is dubious that it can really abstract new delivery systems. I mean, the tuning parameters need to come from somewhere, so the application will have to know about the delivery systems. So hmm, that's a lot of problems before I could use that library. Maybe some other user-space guys are less demanding bitches though :-) -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Monotonic clock usage in buffer timestamps
On Wed, 2 Nov 2011 11:58:04 +0100, Daniel Glöckner daniel...@gmx.net wrote: Converting between the two can be done when making the timestamp but it's non-trivial at other times and likely isn't supported. I could be wrong, though. This might lead to e.g. timestamps that are taken before switching to summer time and for which the conversion is done after the switch. This might be a theoretical possibility, but there might be also unfavourable interaction with the NTP. Summertime/wintertime is purely a userspace thing. UTC as returned by gettimeofday is unaffected by that. Right, DST is a non-issue. NTP AFAIK adjusts the speed of the monotonic clock, so there is a constant delta between wall clock time and clock monotonic For NTP it depends. Simple NTP, as in ntpdate, warps the wall clock. Full-blown NTP only adjusts the speed. unless there is a leap second or someone calls settimeofday. Applications currently using the wall clock timestamps should have trouble dealing with that as well. I can think of at least three other sources of wall clock time, that could trigger a warp: - GPS receiver (TAI), - cellular modem (NITZ), - and, of course, manual setting. So if at all possible I'd much prefer monotonic over real timestamps. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Monotonic clock usage in buffer timestamps
Hello, On Tue, 1 Nov 2011 13:24:35 +0100, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: We should instead fix the V4L2 specification to mandate the use of a monotonic clock (which could then also support hardware timestamps when they are available). Would such a change be acceptable ? I'd rather have the real time clock everywhere, than a driver-dependent clock, if it comes to that. Nevertheless, I agree that the monotonic clock is better than the real time clock. In user space, VLC, Gstreamer already switched to monotonic a while ago as far as I know. And I guess there is no way to detect this, other than detect ridiculously large gap between the timestamp and the current clock value? -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
Le lundi 8 août 2011 16:25:26 Mauro Carvalho Chehab, vous avez écrit : So the presentation and summary are on Tuesday, but when is the workshop itself? Is it on the Monday or the Sunday? It would be nice to know so I can plan my stay in Prague and my planning with the other conferences going on at the same time. The workshop itself will be on Sunday, and the presentations on Tuesday. Monday will be for KS/2011 only invitees. The LinuxCon and ELC Europe will start on Wed. So the workshop is only Sunday, is that right? Is it tied to any of the registration fees (LinuxCon is steep if you are not sponsored nor studying)? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T issues w/ kernel 3.0
Le mercredi 27 juillet 2011 17:30:50 Toralf Förster, vous avez écrit : Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 On a tangential note, what actual version is VLC there? VLC 1.2.0 git DVB plugin is a complete rewrite from VLC 1.1.x, using Linux DVBv5 (the so called S2API)... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le dimanche 17 juillet 2011 03:56:36 Mauro Carvalho Chehab, vous avez écrit : After all, you cannot connect both a DVB-C cable and a DVB-T antenna at the same time, so the vast majority of users won't ever want to switch modes at all. You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. As Antti and Rémi pointed, there are issues with some cable operators. Not sure how critical is that, but an userspace application changing it via sysfs might work while the applications are not ported to support both ways. Telling applications to use sysfs... I can see many ways that you might regret that in the future... Accessing sysfs directly from an application is against all the good practices I thought I had learnt regarding Linux. There is the theoretical possibility that udev gets explicit support for Linux DVB and exposes the properties nicely. But that would be rather inconvenient, and cannot be used to change properties. Antti/Rémi, how the current applications work with one physical frontend supporting both DVB-T and DVB-C? Do they allow to change channels from one to the other mode on a transparent way? I don't know. VLC does not care if you switch from DVB-T to DVB-C, to the DVD drive or to YouTube. Each channel (or at least each multiplex) is a different playlist item. So it'll close the all device nodes and (re)open them. There are obviously other applications at stake. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le dimanche 17 juillet 2011 05:51:33 Andreas Oberritter, vous avez écrit : On 16.07.2011 18:37, Rémi Denis-Courmont wrote: Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies. Is there any channel available on DVB-T which isn't available on DVB-C in this cable network? Probably, I wouldn't know. My S**g TV won't provision channels from both systems at the same time. And Linux does not support DVB-T on my TT-connect CT-3650 tuner. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. In conjunction with Dreamtuner userland project [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger user can create virtual DVB device on client side and connect it to the server. When connected, user is able to use any Linux DVB API compatible application on client side (like VDR, MeTV, MythTV, etc) without any need of code modification. As server can be used any Linux DVB API compatible device. IMHO, this needs a Documentation file for the userspace API (kinda like tuntap.txt). -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Hello again, Le lundi 20 juin 2011 20:41:44 Devin Heitmueller, vous avez écrit : Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it easier for evil tuner manufacturers to leverage all the hard work done Err? My point is exactly the opposite: without a dedicated virtual DVB device, (open-source) developers are stuck with CUSE, which if it would work at all, would be a major waste of effort. And then, it won't work for unprivileged processes due to CUSE ioctl's restrictions. In other words, my point was technical, not political. by the LinuxTV developers while providing a closed-source solution. This does not enable much that evil closed-source device vendors couldn't already do. Virtually any Linux-DVB-capable tool will also accept MPEG-TS feed piped from standard input. Tuning would have to use a dedicated interface; that's pretty much the only inconvenience. DVB_NET can be implemented with the TUNTAP driver easily if it comes to that. And remote control can be mulated with the uinput driver all the same. There is even a mem2mem V4L2 device nowadays, is there not? And while uinput and tuntap allow proprietary userspace drivers, they come with major limitations inherent to userspace which limit their usefulness for proprietary device drivers. FWIW, virtual device driver enables (open-source) innovation. There are countless useful IP tunnels or emulators using TUN or TAP for instance. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I am afraid I don't understand how is Linux-DVB different from other Linux subsystems, such as the (much larger in terms of non-driver-specific code) networking one. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Le mardi 24 mai 2011 17:09:45 Mauro Carvalho Chehab, vous avez écrit : If we do that, then all other places where the association between an alsa device and a video4linux node is needed will need to copy it, and we'll have a fork. Also, we'll keep needing it at v4l-utils, as it is now needed by the new version of v4l2-sysfs-path tool. Btw, this lib were created due to a request from the vlc maintainer that something like that would be needed. After finishing it, I decided to add it at xawtv in order to have an example about how to use it. Hmm errm, I said VLC would need to be able to match a V4L2 device to an ALSA input (where applicable). Currently, V4L2 devices are enumerated with (lib)udev though. I am not very clear how v4l2-utils fits there (and oh, ALSA is a bitch for udev-hotplugging but I'm getting side tracked). I guess I misunderstood that /dev/media would logically group related devices. Now I guess it is _solely_ intended to plug DSPs together à la OpenMAX IL. Sorry about that. Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). I'm not a big fan or exporting the rest of stuff at libv4l2util.a either, but I think that at least the get_media_devices stuff should be exported somewhere, maybe as part of libv4l. Should it be exposed as a udev device attribute instead then? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Le samedi 28 mai 2011 15:44:52 Mauro Carvalho Chehab, vous avez écrit : int libv4l2_get_associated_devive(int fd, enum libv4l2_associated_device_types type, ...); Where fd is the fd of an open /dev/video node, and ... is a param through which the device gets returned (I guess a char * to a buffer of MAX_PATH length where the device name gets stored, this could be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc. Using the fd will be more complex, as we'll loose the device node (is there a glibc way to get the device path from the fd?). Well, we may associate the fd descriptor with the device node internally at libv4l. Not really. fstat() can tell you fd is a character device, and provide the major and minor though. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV nanoStick T2 290e support - Thank you!
Le vendredi 27 mai 2011 01:58:22 Antti Palosaari, vous avez écrit : On 05/27/2011 12:25 AM, Nicolas WILL wrote: Just installed mine for MythTV. Works great on the first try! Many, many thanks! Thank you for the feedback! By the way, what is the V4L2 device node supposed to be? I don't suppose the hardware supports analog nor hardware decoding!? Is it just a left over from the em28xx driver? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV nanoStick T2 290e support - Thank you!
On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork bj...@mork.no wrote: Antti Palosaari cr...@iki.fi writes: On 05/27/2011 12:25 AM, Nicolas WILL wrote: Just installed mine for MythTV. Works great on the first try! Many, many thanks! Thank you for the feedback! I'm a bit curious about this device. It seems to only be marketed as a DVB-T2 device in areas where that spec is used. But looking at your driver, it seems that the device also supports DVB-C. Is that correct? At least, DVB-C worked for me. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb: one demux per tuner or one demux per demod?
Le mardi 24 mai 2011 16:00:14 Antti Palosaari, vous avez écrit : Yes I did, since I didn't know there is better way. Is there any other driver which implements it differently? I think all current MFE drivers does it like I did. For example look NetUP cx23885 + stv0367. /dev/dvb/adapter0/ crw-rw+ 1 root video 212, 2 May 24 15:51 demux0 crw-rw+ 1 root video 212, 3 May 24 15:51 dvr0 crw-rw+ 1 root video 212, 0 May 24 15:51 frontend0 crw-rw+ 1 root video 212, 1 May 24 15:51 frontend1 crw-rw+ 1 root video 212, 4 May 24 15:51 net0 So there is always only one demux per adapter then? That would work for me, but it contradicts the example code at Documentation/DocBook/dvb/examples.xml -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb: one demux per tuner or one demux per demod?
Hello, - Message d'origine - I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? That would be one scheme: there would only ever be one demux per adapter then. But from archives of this very mailing list, I gather that say HVR 3000 shows up as two frontends (DVB-T and DVB-S) with a demux each... Not consistent if true (I do not have such a device to check). For seamless setup in userspace, I need a consistent mapping scheme, whatever that is. Ideally, I would be able to distinguish multiproto frontends from dual tuners from dual tuners with dual antenna. At the very least, I need a way to find the demux that corresponds to a frontend. And until DMX_OUT_TSDEMUX_TAP works correctly, to a dvr. Otherwise, user needs to configure frontend AND demux, which is really unfriendly and error-prone. -- Rémi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Le vendredi 20 mai 2011 18:32:45 Mauro Carvalho Chehab, vous avez écrit : However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. If VLC counts as a generic application, I'd be more than API to use the media_controller (or whatever else) if only to find which ALSA (sub)device, if any, corresponds to the V4L2 node of a given USB webcam or such. I don't know any solution at the moment, and this is a major inconvenience on Linux desktop compared to DirectShow. -- Rémi Denis-Courmont http://www.remlab.info/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
