Still can't get videomixer to do live video at full frame rate

[wally_bkg]

Stefan Kost wrote:
> 
> On 08/19/11 18:12, wally_bkg wrote:
>> Stefan Kost wrote:
>>> On 08/17/11 18:37, wally_bkg wrote:
>>>> wally_bkg wrote:
>>>>         // shift a camera to bottom half of container frame
>>>> 	mixsink1=gst_element_get_pad(mixer,"sink_1");
>>> gst_element_get_static_pad
>>>
>>> Stefan
>>>
>>>> 	if(mixsink1){
>>>> 		g_object_set (G_OBJECT (mixsink1), "ypos", 480, NULL);	 
>>>> 	}else
>>>> 		g_print("Can't get mixer sink_1 pad!");
>> Thanks, but this is a bit confusing.  Are you saying I should just use
>> gst_element_get_static_pad() with the same arguments I used with
>> gst_element_get_pad()?  
>>
>> I though the mixer pads were "request".  The documentation says the
>> problem
>> with gst_element_get_pad() was after getting the pad reference it wasn't
>> clear which kind of pad it was.  
> 
> Sorry indeed those are request pads, so please use the other function.
> 
> 

OK but the documentation at:
http://developer.gnome.org/gstreamer/unstable/GstElement.html#gst-element-request-pad

says:
gst_element_get_request_pad()
This method is slow and will be deprecated in the future. New code should
use gst_element_request_pad() with the requested template.

I'm not trying to be difficult, but using "gst_element_request_pad() with
the requested template" would add complexity to my code for dubious
benefits.  If I'm missing understanding something, please explain.

Can I expect any real difference in using gst_element_get_pad() instead of
gst_element_get_request_pad()?   Other than  gst_element_get_pad() not being
there is some future gstreamer version?  Obviously this would be a good
reason for such a trivial change, although it could be moot if 
gst_element_get_request_pad() ends up suffering the same fate.

The similarity among the names makes my head spin and my eyes water! :(


I understand that in a media player that is building pipelines on the fly as
the media type is discovered, such complexity is required to prevent memory
leaks or worse, but once my pipeline is built and playing its unchanged for
the duration of the program.

I'm not freeing the pad requests or other references after I get them, and
far as I can tell nothing bad happens.  Having all these references hang
around was certainly convenient during development to be able to do queries
and g_prints of values to see what was going on without having to redo the
pad request and free along with it.

What is accomplished by my <500 lines of code (including whitespace, but I
hate white space :) ) speaks volumes to the power of gstreamer, but the
development time to write such a small program has been absurd given all the
arcane knowledge of the internals that I had to pick up along the way, with
great difficulty.

I'd vote these functions not be removed, but merely documented as being a
trade off of simplicity vs. speed/power that are really only suitable for
static pipelines.


Actually the issue in the title appears to be solved now, although some
combinations of capture devices seem to have a frame skew (camera0 image one
frame ahead or behind the camera1 image) on start up, while others don't. 
It may be a USB transport issue and/or differences in number of hardware
buffers in the capture device.  If its consistent, I suspect I can take
action based on the capture card "device-name" to drop a frame on start up
or not.  I've more testing to do.


Is there an element that would be easy to drop the first "n" frames and pass
the rest?




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Still-can-t-get-videomixer-to-do-live-video-at-full-frame-rate-tp3748457p3756111.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.