Porting dshowvideosrc to 1.0

Jérôme Laheurte jerome-bugzilla at jeromelaheurte.net
Tue Sep 2 06:57:06 PDT 2014


Hello. Full disclosure: I’m a gstreamer beginner. As the title states, I’m currently porting dshowvideosrc (and dshowaudiosrc) to 1.0 (actually 1.4.1); the sad current state is that it works (at least the video part for now), but I’m not sure why. So here are a bunch of questions:

1. (audio) I’m guessing the ‘timestamp’ parameter to the read() method is an OUT parameter that must be filled. I tried the following:

GstClock *clock = gst_element_get_clock(GST_ELEMENT(src));
*timestamp = gst_clock_get_time(clock);
gst_object_unref(clock);

but I still get discontinuity errors. Am I wrong ? The code is actually the same that produces the timestamp in the video part…

2. (video) I thought that set_caps() was discontinued in favor of a GST_EVENT_CAPS event on the source pad. But in practice the event is never fired, though set_caps is still invoked (if I override it of course). Quid ? The event function is set in the instance’s init(), using gst_pad_set_event_function(GST_BASE_SRC_PAD(src), xxx).

3. (video) I removed get_caps() and implemented a query function. GST_QUERY_CAPS is fired, I list the supported caps using the old get_caps method and intersects them with the filter returned by gst_query_parse_caps. gst_base_src_default_negotiate logs a « fixated » set of caps which actually include pretty much every supported cap and the negotiation fails. If I explicitly set the caps (using « gst-launch-1.0 dshowvideosrc ! « video/x-raw, format=I420, width=640, height=480, framerate=30/1! videoconvert ! autovideosink » instead of « gst-launch-1.0 dshowvideosrc !  videoconvert ! autovideosink ») it works. Am I supposed to return only one cap from this query or what ?

I can put the actual code somewhere if needed, though the setup to build it is kind of a pain in the ass. Which reminds me of another question:

4. (build) Building this plugin cannot be supported through autoconf. It must be built with Visual since it’s C++ that links with the SDK base classes; G++ and Visual don’t agree on name mangling so… I see that there are a bunch of .sln files that have been discontinued for some time in win32/. I’d rather use CMake since it allows the user to generate a project file for whatever flavor of Visual he likes. That doesn’t go against any philosophical choice in GStreamer does it ?

I apologize in advance if there’s something really dumb up there :)



More information about the gstreamer-devel mailing list