Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
On 8/12/2014 10:23 am, Grazvydas Ignotas wrote: Hi, On Sun, Dec 7, 2014 at 9:23 PM, Laurent Pinchart wrote: Hi Grazvydas, (CC'ing Paulo Assis) On Saturday 06 December 2014 02:25:25 Grazvydas Ignotas wrote: On Fri, Dec 5, 2014 at 1:46 PM, Laurent Pinchart wrote: On Thursday 06 November 2014 00:29:53 Grazvydas Ignotas wrote: On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: Would you be able to capture images from the C920 using yavta, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. I've done 2 captures, if that helps: http://notaz.gp2x.de/tmp/c920_yavta/ The second one was done using low exposure setting, which allows camera to achieve higher frame rate. Thank you for the log, they were very helpful. They revealed that the USB SOF (Start Of Frame) counter values on the device and host side are not in sync. The counters get incremented are very different rates. What USB controller are you using ? 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7592 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at fe9fbc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Kernel driver in use: ehci-pci If it helps, I could try on an ARM board, currently don't have any other x86 hardware around. Actually the frequencies I've computed from the log are correct on the host side but quite off on the device side. I'm puzzled. The following patch allows accessing the contents of the clock data buffer through debugfs. Would you be able to apply it and execute the following steps ? 1. Load the uvcvideo module with the clock trace flag (0x1000) set. 2. Start capturing clock data. while true; do cat /sys/kernel/debug/usb/uvcvideo/2-6/clocks ; done > ~/samples.log 3. Capture 100 frames. yavta -c100 > yavta.log 4. Stop the "while true" with ctrl-C. 5. Capture the uvcvideo stats. cat /sys/kernel/debug/usb/uvcvideo/2-6/stats > stats.log 6. Capture the kernel log. dmesg > dmesg.log 7. Send me all the log files. Done: http://notaz.gp2x.de/tmp/c920_yavta/3/ -- Gražvydas Hello, I've reproduced this issue on a Logitech C920 in the following environments: 1. x86_64 Linux 3.19.3 (Gentoo, custom kernel) 2. x86_64 Linux 3.13.0-46-generic (Ubuntu) 3. armv7a Linux 3.19.3 (Arch Linux, custom kernel) I can confirm that the issue is not present in Linux 3.8.y. I'm not sure if there have been any developments in regards to this in recent months, but I'm happy to help out in any way possible. If someone is in need of new debug logs, I can follow the steps above and provide them. -- Milos -- 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
Hi, On Sun, Dec 7, 2014 at 9:23 PM, Laurent Pinchart wrote: > Hi Grazvydas, > > (CC'ing Paulo Assis) > > On Saturday 06 December 2014 02:25:25 Grazvydas Ignotas wrote: >> On Fri, Dec 5, 2014 at 1:46 PM, Laurent Pinchart wrote: >> > On Thursday 06 November 2014 00:29:53 Grazvydas Ignotas wrote: >> >> On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: >> >> > Would you be able to capture images from the C920 using yavta, with the >> >> > uvcvideo trace parameter set to 4096, and send me both the yavta log >> >> > and the kernel log ? Let's start with a capture sequence of 50 to 100 >> >> > images. >> >> >> >> I've done 2 captures, if that helps: >> >> http://notaz.gp2x.de/tmp/c920_yavta/ >> >> >> >> The second one was done using low exposure setting, which allows >> >> camera to achieve higher frame rate. >> > >> > Thank you for the log, they were very helpful. They revealed that the USB >> > SOF (Start Of Frame) counter values on the device and host side are not >> > in sync. The counters get incremented are very different rates. What USB >> > controller are you using ? >> >> 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI >> Controller (rev 01) (prog-if 20 [EHCI]) >> Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7592 >> Flags: bus master, medium devsel, latency 0, IRQ 23 >> Memory at fe9fbc00 (32-bit, non-prefetchable) [size=1K] >> Capabilities: [50] Power Management version 2 >> Capabilities: [58] Debug port: BAR=1 offset=00a0 >> Kernel driver in use: ehci-pci >> >> If it helps, I could try on an ARM board, currently don't have any >> other x86 hardware around. > > Actually the frequencies I've computed from the log are correct on the host > side but quite off on the device side. I'm puzzled. > > The following patch allows accessing the contents of the clock data buffer > through debugfs. Would you be able to apply it and execute the following > steps ? > > 1. Load the uvcvideo module with the clock trace flag (0x1000) set. > > 2. Start capturing clock data. > > while true; do > cat /sys/kernel/debug/usb/uvcvideo/2-6/clocks ; > done > ~/samples.log > > 3. Capture 100 frames. > > yavta -c100 > yavta.log > > 4. Stop the "while true" with ctrl-C. > > 5. Capture the uvcvideo stats. > > cat /sys/kernel/debug/usb/uvcvideo/2-6/stats > stats.log > > 6. Capture the kernel log. > > dmesg > dmesg.log > > 7. Send me all the log files. Done: http://notaz.gp2x.de/tmp/c920_yavta/3/ -- Gražvydas -- 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
Hi Grazvydas,
(CC'ing Paulo Assis)
On Saturday 06 December 2014 02:25:25 Grazvydas Ignotas wrote:
> On Fri, Dec 5, 2014 at 1:46 PM, Laurent Pinchart wrote:
> > On Thursday 06 November 2014 00:29:53 Grazvydas Ignotas wrote:
> >> On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote:
> >> > Would you be able to capture images from the C920 using yavta, with the
> >> > uvcvideo trace parameter set to 4096, and send me both the yavta log
> >> > and the kernel log ? Let's start with a capture sequence of 50 to 100
> >> > images.
> >>
> >> I've done 2 captures, if that helps:
> >> http://notaz.gp2x.de/tmp/c920_yavta/
> >>
> >> The second one was done using low exposure setting, which allows
> >> camera to achieve higher frame rate.
> >
> > Thank you for the log, they were very helpful. They revealed that the USB
> > SOF (Start Of Frame) counter values on the device and host side are not
> > in sync. The counters get incremented are very different rates. What USB
> > controller are you using ?
>
> 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> Controller (rev 01) (prog-if 20 [EHCI])
> Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7592
> Flags: bus master, medium devsel, latency 0, IRQ 23
> Memory at fe9fbc00 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Kernel driver in use: ehci-pci
>
> If it helps, I could try on an ARM board, currently don't have any
> other x86 hardware around.
Actually the frequencies I've computed from the log are correct on the host
side but quite off on the device side. I'm puzzled.
The following patch allows accessing the contents of the clock data buffer
through debugfs. Would you be able to apply it and execute the following
steps ?
1. Load the uvcvideo module with the clock trace flag (0x1000) set.
2. Start capturing clock data.
while true; do
cat /sys/kernel/debug/usb/uvcvideo/2-6/clocks ;
done > ~/samples.log
3. Capture 100 frames.
yavta -c100 > yavta.log
4. Stop the "while true" with ctrl-C.
5. Capture the uvcvideo stats.
cat /sys/kernel/debug/usb/uvcvideo/2-6/stats > stats.log
6. Capture the kernel log.
dmesg > dmesg.log
7. Send me all the log files.
>From 801372be5eeac86326bc7eb230783a4d2a491c2e Mon Sep 17 00:00:00 2001
From: Laurent Pinchart
Date: Sun, 7 Dec 2014 17:02:05 +0200
Subject: [PATCH] uvcvideo: Expose clock samples through debugfs
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_debugfs.c | 71 -
drivers/media/usb/uvc/uvc_video.c | 44 +++
drivers/media/usb/uvc/uvcvideo.h| 5 +++
3 files changed, 104 insertions(+), 16 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_debugfs.c
b/drivers/media/usb/uvc/uvc_debugfs.c
index 14561a5..4013dc5 100644
--- a/drivers/media/usb/uvc/uvc_debugfs.c
+++ b/drivers/media/usb/uvc/uvc_debugfs.c
@@ -19,16 +19,37 @@
#include "uvcvideo.h"
/*
-
- * Statistics
+ * Common Helpers
*/
-#define UVC_DEBUGFS_BUF_SIZE 1024
+#define UVC_DEBUGFS_BUF_SIZE 2048
struct uvc_debugfs_buffer {
size_t count;
char data[UVC_DEBUGFS_BUF_SIZE];
};
+static ssize_t uvc_debugfs_read(struct file *file, char __user *user_buf,
+ size_t nbytes, loff_t *ppos)
+{
+ struct uvc_debugfs_buffer *buf = file->private_data;
+
+ return simple_read_from_buffer(user_buf, nbytes, ppos, buf->data,
+ buf->count);
+}
+
+static int uvc_debugfs_release(struct inode *inode, struct file *file)
+{
+ kfree(file->private_data);
+ file->private_data = NULL;
+
+ return 0;
+}
+
+/*
-
+ * Statistics
+ */
+
static int uvc_debugfs_stats_open(struct inode *inode, struct file *file)
{
struct uvc_streaming *stream = inode->i_private;
@@ -44,29 +65,39 @@ static int uvc_debugfs_stats_open(struct inode *inode,
struct file *file)
return 0;
}
-static ssize_t uvc_debugfs_stats_read(struct file *file, char __user *user_buf,
- size_t nbytes, loff_t *ppos)
-{
- struct uvc_debugfs_buffer *buf = file->private_data;
+static const struct file_operations uvc_debugfs_stats_fops = {
+ .owner = THIS_MODULE,
+ .open = uvc_debugfs_stats_open,
+ .llseek = no_llseek,
+ .read = uvc_debugfs_read,
+ .release = uvc_debugfs_release,
+};
- return simple_read_from_buffer(user_buf, nbytes, ppos, buf->data,
- buf->count);
-}
+/*
-
+ * Clocks
+ */
-static int uvc_debugfs_stats_release(struct inode *inode, struct file *file)
+static int uvc_debugfs_clock
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi, On Fri, Dec 5, 2014 at 1:46 PM, Laurent Pinchart wrote: > Hi Grazvydas, > > On Thursday 06 November 2014 00:29:53 Grazvydas Ignotas wrote: >> On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: >> > Would you be able to capture images from the C920 using yavta, with the >> > uvcvideo trace parameter set to 4096, and send me both the yavta log and >> > the kernel log ? Let's start with a capture sequence of 50 to 100 images. >> >> I've done 2 captures, if that helps: >> http://notaz.gp2x.de/tmp/c920_yavta/ >> >> The second one was done using low exposure setting, which allows >> camera to achieve higher frame rate. > > Thank you for the log, they were very helpful. They revealed that the USB SOF > (Start Of Frame) counter values on the device and host side are not in sync. > The counters get incremented are very different rates. What USB controller are > you using ? 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7592 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at fe9fbc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Kernel driver in use: ehci-pci If it helps, I could try on an ARM board, currently don't have any other x86 hardware around. -- Gražvydas -- 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
Hi Sakari, On Wednesday 05 November 2014 18:11:47 Sakari Ailus wrote: > On Wed, Nov 05, 2014 at 10:13:45AM +, Paulo Assis wrote: > > 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > >> Sakari Ailus wrote: > >>> yavta does, for example, print both the monotonic timestamp from the > >>> buffer and the time when the buffer has been dequeued: > >>> > >>> http://git.ideasonboard.org/yavta.git> > >>> > >>> $ yavta -c /dev/video0 > >>> > >>> should do it. The first timestamp is the buffer timestamp, and the > >>> latter is the one is taken when the buffer is dequeued (by yavta). > > > > I've done exaclty this with guvcview, and uvcvideo timestamps are > > completly unreliable, in some devices they may have just a bit of > > jitter, but in others, values go back and forth in time, making them > > totally unusable. > > Honestly I wouldn't trust device firmware to provide correct > > timestamps, or at least I would have the driver perform a couple of > > tests to make sure these are at least reasonable: within an expected > > interval (maybe comparing it to a reference monotonic clock) or at the > > very least making sure the current frame timestamp is not lower than > > the previous one. > > Using the hardware timestamps provides much better accuracy than the > software ones --- the real time capabilities of the USB aren't exactly the > same as on some other busses. > > Freel free to try the follow-up patches; I've only compile tested them so > far. > > It might be possible to add some heuristics to detect bad implementations > but perhaps we could simply flag them for now. If heuristics would be used, > then one would likely have a few bad timestamps every time the device is > accessed the first time anyway. Besides, the timestamp type changes as a > result. > > I wonder what Laurent thinks. :-) I've been toying with the idea of a heuristic, but decided to delay the implementation until needed. I'd like to find the root cause of the issue first before deciding how to fix it. -- Regards, Laurent Pinchart -- 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
Hi Grazvydas, On Thursday 06 November 2014 00:29:53 Grazvydas Ignotas wrote: > On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: > > On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: > >> 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. > > > > Would you be able to capture images from the C920 using yavta, with the > > uvcvideo trace parameter set to 4096, and send me both the yavta log and > > the kernel log ? Let's start with a capture sequence of 50 to 100 images. > > I've done 2 captures, if that helps: > http://notaz.gp2x.de/tmp/c920_yavta/ > > The second one was done using low exposure setting, which allows > camera to achieve higher frame rate. Thank you for the log, they were very helpful. They revealed that the USB SOF (Start Of Frame) counter values on the device and host side are not in sync. The counters get incremented are very different rates. What USB controller are you using ? -- Regards, Laurent Pinchart -- 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
On 11/17/14 16:36, Grazvydas Ignotas wrote: > On Thu, Nov 6, 2014 at 12:29 AM, Grazvydas Ignotas wrote: >> On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart >> wrote: >>> Hi Rémi, >>> >>> On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: 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. >>> >>> Would you be able to capture images from the C920 using yavta, with the >>> uvcvideo trace parameter set to 4096, and send me both the yavta log and the >>> kernel log ? Let's start with a capture sequence of 50 to 100 images. >> >> I've done 2 captures, if that helps: >> http://notaz.gp2x.de/tmp/c920_yavta/ >> >> The second one was done using low exposure setting, which allows >> camera to achieve higher frame rate. > > So, has anyone had time to look at these? Laurent is on vacation for one more week. So you'll have to wait until he's back and has time to process his no doubt considerable pile of email. If you haven't heard anything from him by the end of next week, then try another ping just in case this got buried. Regards, Hans -- 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
On Thu, Nov 6, 2014 at 12:29 AM, Grazvydas Ignotas wrote: > On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart > wrote: >> Hi Rémi, >> >> On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: >>> 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. >> >> Would you be able to capture images from the C920 using yavta, with the >> uvcvideo trace parameter set to 4096, and send me both the yavta log and the >> kernel log ? Let's start with a capture sequence of 50 to 100 images. > > I've done 2 captures, if that helps: > http://notaz.gp2x.de/tmp/c920_yavta/ > > The second one was done using low exposure setting, which allows > camera to achieve higher frame rate. So, has anyone had time to look at these? Gražvydas -- 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
Laurent, see below yavta output and matching syslog ./yavta -c -s 800x600 -t 1/30 -f mjpeg /dev/video0 Device /dev/video0 opened. Device `Logitech Webcam C930e' on `usb-:00:1a.7-1' is a video output (without mplanes) device. Video format set: MJPEG (47504a4d) 800x600 (stride 0) field none buffer size 96 Video format: MJPEG (47504a4d) 800x600 (stride 0) field none buffer size 96 Current frame rate: 1/30 Setting frame rate to: 1/30 Frame rate set: 1/30 8 buffers requested. length: 96 offset: 0 timestamp type/source: mono/SoE Buffer 0/0 mapped at address 0x7fa53d2a9000. length: 96 offset: 962560 timestamp type/source: mono/SoE Buffer 1/0 mapped at address 0x7fa53c8d6000. length: 96 offset: 1925120 timestamp type/source: mono/SoE Buffer 2/0 mapped at address 0x7fa53c7eb000. length: 96 offset: 2887680 timestamp type/source: mono/SoE Buffer 3/0 mapped at address 0x7fa53c70. length: 96 offset: 3850240 timestamp type/source: mono/SoE Buffer 4/0 mapped at address 0x7fa53c615000. length: 96 offset: 4812800 timestamp type/source: mono/SoE Buffer 5/0 mapped at address 0x7fa53c52a000. length: 96 offset: 5775360 timestamp type/source: mono/SoE Buffer 6/0 mapped at address 0x7fa53c43f000. length: 96 offset: 6737920 timestamp type/source: mono/SoE Buffer 7/0 mapped at address 0x7fa53c354000. 0 (0) [-] any 0 78126 B 1967.041984 1967.046007 199.243 fps ts mono/SoE 1 (1) [-] any 1 83867 B 1967.065982 1967.074017 41.670 fps ts mono/SoE 2 (2) [-] any 2 83019 B 1967.157974 1967.166002 10.871 fps ts mono/SoE 3 (3) [-] any 3 83772 B 1967.249978 1967.258003 10.869 fps ts mono/SoE 4 (4) [-] any 4 83973 B 1967.341976 1967.350002 10.870 fps ts mono/SoE 5 (5) [-] any 5 81903 B 1967.433974 1967.441996 10.870 fps ts mono/SoE 6 (6) [-] any 6 83112 B 1967.497976 1967.506003 15.625 fps ts mono/SoE 7 (7) [-] any 7 80714 B 1967.565975 1967.573998 14.706 fps ts mono/SoE 8 (0) [-] any 8 81568 B 1967.633973 1967.641990 14.706 fps ts mono/SoE 9 (1) [-] any 9 80797 B 1967.697971 1967.705999 15.625 fps ts mono/SoE 10 (2) [-] any 10 81242 B 1967.765972 1967.773996 14.706 fps ts mono/SoE 11 (3) [-] any 11 79881 B 1967.833971 1967.841984 14.706 fps ts mono/SoE 12 (4) [-] any 12 77947 B 1967.897969 1967.905998 15.625 fps ts mono/SoE 13 (5) [-] any 13 75779 B 1967.965969 1967.973987 14.706 fps ts mono/SoE 14 (6) [-] any 14 73720 B 1968.029969 1968.038008 15.625 fps ts mono/SoE 15 (7) [-] any 15 73671 B 1968.097969 1968.105995 14.706 fps ts mono/SoE 16 (0) [-] any 16 80507 B 1968.165969 1968.173989 14.706 fps ts mono/SoE 17 (1) [-] any 17 82505 B 1968.229969 1968.237999 15.625 fps ts mono/SoE 18 (2) [-] any 18 82640 B 1968.297966 1968.305990 14.707 fps ts mono/SoE 19 (3) [-] any 19 82676 B 1968.365969 1968.373987 14.705 fps ts mono/SoE 20 (4) [-] any 20 82802 B 1968.429967 1968.437996 15.625 fps ts mono/SoE 21 (5) [-] any 21 83523 B 1968.497967 1968.505992 14.706 fps ts mono/SoE 22 (6) [-] any 22 83774 B 1968.565964 1968.573980 14.707 fps ts mono/SoE 23 (7) [-] any 23 83678 B 1968.629966 1968.637992 15.625 fps ts mono/SoE 24 (0) [-] any 24 83627 B 1968.697964 1968.705985 14.706 fps ts mono/SoE 25 (1) [-] any 25 83675 B 1968.761965 1968.773978 15.625 fps ts mono/SoE 26 (2) [-] any 26 84022 B 1968.829965 1968.837991 14.706 fps ts mono/SoE 27 (3) [-] any 27 83861 B 1968.897963 1968.905984 14.706 fps ts mono/SoE 28 (4) [-] any 28 83859 B 1968.961962 1968.969995 15.625 fps ts mono/SoE 29 (5) [-] any 29 84127 B 1969.029964 1969.037988 14.705 fps ts mono/SoE 30 (6) [-] any 30 83975 B 1969.097963 1969.105980 14.706 fps ts mono/SoE 31 (7) [-] any 31 83942 B 1968.705930 1969.170007 -2.551 fps ts mono/SoE 32 (0) [-] any 32 84151 B 1966.942496 1969.238004 -0.567 fps ts mono/SoE 33 (1) [-] any 33 84063 B 1966.407386 1969.305995 -1.869 fps ts mono/SoE 34 (2) [-] any 34 83821 B 6363.417588 1969.370002 0.000 fps ts mono/SoE 35 (3) [-] any 35 83856 B 8999.957765 1969.437996 0.000 fps ts mono/SoE 36 (4) [-] any 36 83654 B 25405.275813 1969.505986 0.000 fps ts mono/SoE 37 (5) [-] any 37 83619 B 19546.239569 1969.570001 -0.000 fps ts mono/SoE 38 (6) [-] any 38 83257 B 19546.049575 1969.637995 -5.263 fps ts mono/SoE 39 (7) [-] any 39 83211 B 25405.475806 1969.702002 0.000 fps ts mono/SoE 40 (0) [-] any 40 83231 B 19546.310550 1969.769993 -0.000 fps ts mono/SoE 41 (1) [-] any 41 83172 B 19546.249539 1969.837989 -16.390 fps ts mono/SoE 42 (2) [-] any 42 83177 B 25405.504127 1969.901997 0.000 fps ts mono/SoE 43 (3) [-] any 43 83055 B 19546.510529 1969.969995 -0.000 fps ts mono/SoE 44 (4) [-] any 44 82520 B 19546.320540 1970.037985 -5.263 fps ts mono/SoE 45 (5) [-] any 45 80593 B 19546.771538 1970.101999 2.217 fps ts mono/SoE 46 (6) [-] any 46 77431 B 19546.710555 1970.169986 -16.398 fps ts mono/SoE 47 (7) [-] any 47 75963 B 25406.007835 1970.233994 0.000 fps ts mono/SoE 48 (0) [-] any 48 74591 B 19546.971544 1970.301993 -0.000 fps ts mono/SoE 49 (1) [-] any 49 74606 B 19546.781526 1970.369988 -5.263 fps ts mono/SoE 50 (2) [-] an
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: > Hi Rémi, > > On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: >> 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. > > Would you be able to capture images from the C920 using yavta, with the > uvcvideo trace parameter set to 4096, and send me both the yavta log and the > kernel log ? Let's start with a capture sequence of 50 to 100 images. I've done 2 captures, if that helps: http://notaz.gp2x.de/tmp/c920_yavta/ The second one was done using low exposure setting, which allows camera to achieve higher frame rate. -- Gražvydas -- 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
Hi Rémi, On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: > 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. Would you be able to capture images from the C920 using yavta, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. -- Regards, Laurent Pinchart -- 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
Hi Paulo, On Wednesday 05 November 2014 10:13:45 Paulo Assis wrote: > 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > > Sakari Ailus wrote: > >> yavta does, for example, print both the monotonic timestamp from the > >> buffer and the time when the buffer has been dequeued: > >> > >> http://git.ideasonboard.org/yavta.git> > >> > >> $ yavta -c /dev/video0 > >> > >> should do it. The first timestamp is the buffer timestamp, and the latter > >> is the one is taken when the buffer is dequeued (by yavta). > > I've done exaclty this with guvcview, and uvcvideo timestamps are completly > unreliable, in some devices they may have just a bit of jitter, but in > others, values go back and forth in time, making them totally unusable. > > Honestly I wouldn't trust device firmware to provide correct timestamps, or > at least I would have the driver perform a couple of tests to make sure > these are at least reasonable: within an expected interval (maybe comparing > it to a reference monotonic clock) or at the very least making sure the > current frame timestamp is not lower than the previous one. I can add that to the uvcvideo driver, but I'd first like to find out whether the device timestamps are really unreliable, or if the problem comes from a bug in the driver's timestamp conversion code. Could you capture images using yavta with an unreliable device, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. > > Removing the uvcvideo module and loading it again with trace=4096 before > > capturing, and then kernel log would provide more useful information. -- Regards, Laurent Pinchart -- 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
Hi Paolo, On Wed, Nov 05, 2014 at 10:13:45AM +, Paulo Assis wrote: > Hi, > > 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > > Sakari Ailus wrote: > >> yavta does, for example, print both the monotonic timestamp from the buffer > >> and the time when the buffer has been dequeued: > >> > >> http://git.ideasonboard.org/yavta.git> > >> > >> $ yavta -c /dev/video0 > >> > >> should do it. The first timestamp is the buffer timestamp, and the latter > >> is > >> the one is taken when the buffer is dequeued (by yavta). > > I've done exaclty this with guvcview, and uvcvideo timestamps are > completly unreliable, in some devices they may have just a bit of > jitter, but in others, values go back and forth in time, making them > totally unusable. > Honestly I wouldn't trust device firmware to provide correct > timestamps, or at least I would have the driver perform a couple of > tests to make sure these are at least reasonable: within an expected > interval (maybe comparing it to a reference monotonic clock) or at the > very least making sure the current frame timestamp is not lower than > the previous one. Using the hardware timestamps provides much better accuracy than the software ones --- the real time capabilities of the USB aren't exactly the same as on some other busses. Freel free to try the follow-up patches; I've only compile tested them so far. It might be possible to add some heuristics to detect bad implementations but perhaps we could simply flag them for now. If heuristics would be used, then one would likely have a few bad timestamps every time the device is accessed the first time anyway. Besides, the timestamp type changes as a result. I wonder what Laurent thinks. :-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Hi, 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > Sakari Ailus wrote: >> yavta does, for example, print both the monotonic timestamp from the buffer >> and the time when the buffer has been dequeued: >> >> http://git.ideasonboard.org/yavta.git> >> >> $ yavta -c /dev/video0 >> >> should do it. The first timestamp is the buffer timestamp, and the latter is >> the one is taken when the buffer is dequeued (by yavta). I've done exaclty this with guvcview, and uvcvideo timestamps are completly unreliable, in some devices they may have just a bit of jitter, but in others, values go back and forth in time, making them totally unusable. Honestly I wouldn't trust device firmware to provide correct timestamps, or at least I would have the driver perform a couple of tests to make sure these are at least reasonable: within an expected interval (maybe comparing it to a reference monotonic clock) or at the very least making sure the current frame timestamp is not lower than the previous one. Regards, Paulo > > Removing the uvcvideo module and loading it again with trace=4096 before > capturing, and then kernel log would provide more useful information. > > -- > Sakari Ailus > sakari.ai...@iki.fi -- 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
Sakari Ailus wrote: > yavta does, for example, print both the monotonic timestamp from the buffer > and the time when the buffer has been dequeued: > > http://git.ideasonboard.org/yavta.git> > > $ yavta -c /dev/video0 > > should do it. The first timestamp is the buffer timestamp, and the latter is > the one is taken when the buffer is dequeued (by yavta). Removing the uvcvideo module and loading it again with trace=4096 before capturing, and then kernel log would provide more useful information. -- Sakari Ailus sakari.ai...@iki.fi -- 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
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi, On Tue, Nov 04, 2014 at 03:02:58PM +, Paulo Assis wrote: > I've add to change guvcview so that it now generates it's own > monotonic timestamps, kernel timestamps (uvcvideo at least), caused a > similar problem, e.g: > I would get a couple of frames with correct timestamps, then I would > get at least one with a value lower than the rest, this caused > playback to stutter. > I didn't had time to check the cause, but it has been like this for > quite some time now. Have you looked what kind of timestamps the device gives you? The uvc devices provide their own hardware timestamps which the UVC driver uses. If the device provides bad timestamps to the driver, the buffer timestamps could end up being very wrong. I don't know if the driver tries to cope with that. One thing to try would be to capture images with a program which prints the buffer timestamps. yavta does, for example, print both the monotonic timestamp from the buffer and the time when the buffer has been dequeued: http://git.ideasonboard.org/yavta.git> $ yavta -c /dev/video0 should do it. The first timestamp is the buffer timestamp, and the latter is the one is taken when the buffer is dequeued (by yavta). -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
I've add to change guvcview so that it now generates it's own monotonic timestamps, kernel timestamps (uvcvideo at least), caused a similar problem, e.g: I would get a couple of frames with correct timestamps, then I would get at least one with a value lower than the rest, this caused playback to stutter. I didn't had time to check the cause, but it has been like this for quite some time now. Regards, Paulo 2014-11-04 12:42 GMT+00:00 Rémi Denis-Courmont : > 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 -- 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 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
Hi Grazvydas, On Tue, Nov 04, 2014 at 01:16:03AM +0200, Grazvydas Ignotas wrote: > Hi, > > On Mon, Nov 3, 2014 at 12:57 AM, Sakari Ailus wrote: > > Hi Grazvydas, > > > > On Sun, Nov 02, 2014 at 04:03:55AM +0200, Grazvydas Ignotas wrote: > >> There is periodic stutter (seen in vlc, for example) since 3.9 where > >> the stream stops for around half a second every 3-5 seconds or so. > >> Bisecting points to 1b18e7a0be859911b22138ce27258687efc528b8 "v4l: > >> Tell user space we're using monotonic timestamps". I've verified the > >> problem is there on stock Ubuntu 14.04 kernel, 3.16.7 from kernel.org > >> and when using media_build.git . The commit does not revert on newer > >> kernels as that code changed, but checking out a commit before the one > >> mentioned gives properly working kernel. > >> > >> I'm using Logitech C920 which can do h264 compression and playing the > >> video using vlc: > >> cvlc v4l2:///dev/video0:chroma=h264:width=1280:height=720 > > > > I've got Logitech C270 here but I can't reproduce the problem. The frame > > rate with the above command is really low, around 5. With a smaller > > resolution it works quite smoothly. The reason might be that the pixel > > format is still YUYV. The other option appears to be MJPG. > > I've tried lower resolution and YUYV with MJPG too, this has the same problem: > cvlc v4l2:///dev/video0:chroma=h264:width=320:height=240 > cvlc v4l2:///dev/video0:chroma=yuyv:width=320:height=240 > > > > > My vlc is of version 2.0.3 (Debian). Which one do you have, and does it use > > libv4l2? > > Mine is 2.1.4, my distro is Ubuntu 14.04. I can see libv4l2.so.0.0.0 > in maps, but I have no idea what it's used for.. > > > 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? -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Hi, On Mon, Nov 3, 2014 at 12:57 AM, Sakari Ailus wrote: > Hi Grazvydas, > > On Sun, Nov 02, 2014 at 04:03:55AM +0200, Grazvydas Ignotas wrote: >> There is periodic stutter (seen in vlc, for example) since 3.9 where >> the stream stops for around half a second every 3-5 seconds or so. >> Bisecting points to 1b18e7a0be859911b22138ce27258687efc528b8 "v4l: >> Tell user space we're using monotonic timestamps". I've verified the >> problem is there on stock Ubuntu 14.04 kernel, 3.16.7 from kernel.org >> and when using media_build.git . The commit does not revert on newer >> kernels as that code changed, but checking out a commit before the one >> mentioned gives properly working kernel. >> >> I'm using Logitech C920 which can do h264 compression and playing the >> video using vlc: >> cvlc v4l2:///dev/video0:chroma=h264:width=1280:height=720 > > I've got Logitech C270 here but I can't reproduce the problem. The frame > rate with the above command is really low, around 5. With a smaller > resolution it works quite smoothly. The reason might be that the pixel > format is still YUYV. The other option appears to be MJPG. I've tried lower resolution and YUYV with MJPG too, this has the same problem: cvlc v4l2:///dev/video0:chroma=h264:width=320:height=240 cvlc v4l2:///dev/video0:chroma=yuyv:width=320:height=240 > > My vlc is of version 2.0.3 (Debian). Which one do you have, and does it use > libv4l2? Mine is 2.1.4, my distro is Ubuntu 14.04. I can see libv4l2.so.0.0.0 in maps, but I have no idea what it's used for.. > 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. -- Gražvydas -- 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
Hi Grazvydas, On Sun, Nov 02, 2014 at 04:03:55AM +0200, Grazvydas Ignotas wrote: > There is periodic stutter (seen in vlc, for example) since 3.9 where > the stream stops for around half a second every 3-5 seconds or so. > Bisecting points to 1b18e7a0be859911b22138ce27258687efc528b8 "v4l: > Tell user space we're using monotonic timestamps". I've verified the > problem is there on stock Ubuntu 14.04 kernel, 3.16.7 from kernel.org > and when using media_build.git . The commit does not revert on newer > kernels as that code changed, but checking out a commit before the one > mentioned gives properly working kernel. > > I'm using Logitech C920 which can do h264 compression and playing the > video using vlc: > cvlc v4l2:///dev/video0:chroma=h264:width=1280:height=720 I've got Logitech C270 here but I can't reproduce the problem. The frame rate with the above command is really low, around 5. With a smaller resolution it works quite smoothly. The reason might be that the pixel format is still YUYV. The other option appears to be MJPG. My vlc is of version 2.0.3 (Debian). Which one do you have, and does it use libv4l2? Have you tried with a different application to see if the problem persists? If the cause of the stutter you described is this patch, it might be how the information the flag provides is used in the user space. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
(bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi, There is periodic stutter (seen in vlc, for example) since 3.9 where the stream stops for around half a second every 3-5 seconds or so. Bisecting points to 1b18e7a0be859911b22138ce27258687efc528b8 "v4l: Tell user space we're using monotonic timestamps". I've verified the problem is there on stock Ubuntu 14.04 kernel, 3.16.7 from kernel.org and when using media_build.git . The commit does not revert on newer kernels as that code changed, but checking out a commit before the one mentioned gives properly working kernel. I'm using Logitech C920 which can do h264 compression and playing the video using vlc: cvlc v4l2:///dev/video0:chroma=h264:width=1280:height=720 -- Gražvydas -- 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
