GNOME Bugzilla – Bug 742562
ksvideosrc, dx9screencapsrc: fix latency handling
Last modified: 2018-11-03 13:29:42 UTC
when I render from dx9screencapsrc or ksvideosrc, display works but the reporting is switched. this also applies to "fps" and "drop rate".
So what you're saying is that with these two sources, most video buffers get dropped, yes? (i.e. the reporting is correct, it's just that we don't want it to report that) Probably just related to them not advertising any latency they might have? Could you provide a GST_DEBUG=*:6 debug log from a few seconds?
I'm saying it's happening regardless of source (I'll confirm with a file source). guessing here, but the text rendering has the variables switched around. the values look correct, but they're mislabeled.
sorry, my bad. it looks like it's actually just these two sources. I managed to get an mp4 video to playa and the overlay text looks as it should. dx9screencapsrc reports ALL dropped (~18 fps on my system) and NO rendered frames. ksvideosrc reports more rendered than dropped frames, but still a lot. both add to the nominal frame rate of my webcam. of course, the ksvideosrc throws lots of 'write map requested on non-writable buffer' but that's another issue.
Tried with a videotestsrc?
You can also try with sync=false on the sink, which makes it ignore timestamps and latencies.
if I set GST_DEBUG=*:6, lots of debug messages keep scrolling past but no output is happening (not even a window created) for as long as I care to wait.
"fpsdisplaysink sync=false" does correct reporting for dx9screencapsrc. "ksvideosrc ! fpsdisplaysink sync=false" report about twice the frame rate for rendered and dropped...
This looks like bugs with the latency reporting indeed, and more bugs than that in ksvideosrc.
I was testing something similar with camerabin today. What I see is that generally, I get ~20 dropped frames as things start up, and then usually none. At some point, however, I can trigger the ksvideosrc into a new mode where it drops nearly every 2nd frame. One way I found to trigger it is to cover the camera briefly, which triggers auto-exposure handling and a drop in produced framerate. It seems likely there's a problem there and ksvideosrc never recovers from it.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/202.