Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
Otherwise a magic capsfilter after the source is required with
exactly the same caps as the input.
This would've failed before with invalid buffer sizes:
gst-launch-1.0 videotestsrc ! intervideosink intervideosrc ! "video/x-raw,width=640,height=480" ! xvimagesink
gstglwindow_cocoa.m: In function '-[GstGLNSView drawRect:]':
gstglwindow_cocoa.m:555: warning: 'GstGLNSView' may not respond to '-reshape'
gstglwindow_cocoa.m:555: warning: (Messages without a matching method signature
gstglwindow_cocoa.m:555: warning: will be assumed to return 'id' and accept
gstglwindow_cocoa.m:555: warning: '...' as arguments.)
The object lock only protects the session, as we modify
the session from other threads when the bitrate property
is changed. Don't hold it much longer than for session
related things.
And we need to release the video decoder stream lock before
enqueueing a frames. It might wait for our callback to dequeue
a frame from another thread, which will then take the stream
lock too and deadlock.
Replace the hardcoded -lpthread in most of the places with $PTHREAD_LIBS. For
openh264 also add $PTHREAD_LIBS to OPENH264_LIBS until upstream ships a .pc
file.
Audiomixer blocksize, cant be 0, hence adjusting the minimum value to 1
timeout value of aggregator is defined with MAX of MAXINT64,
but it cannot cross G_MAXLONG * GST_SECOND - 1
Hence changed the max value of the same
https://bugzilla.gnome.org/show_bug.cgi?id=738845
In simple profile, level set to 0 or 2 indicate low and medium level
respectively. In main profile, level set to 0, 2 or 4 indicate low,
medium and high level respectively.
Level values are defined in Annex J.1.2 of the SMPTE 421M.
https://bugzilla.gnome.org/show_bug.cgi?id=738230
Signal sparse streams properly in stream-start event and force sending
of pending sticky events which have been stored on the pad already and
which otherwise would only be sent on the first buffer or serialized
event (which means very late in case of subtitle streams). Playsink in
playbin waits for stream-start or another serialized event, and if we
don't do this it will wait for the multiqueue to run full before
starting playback, which might take a couple of seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=734040
