When the set-timestamps property is set, use PCRs on the provided
(or autodetected) pcr-pid to apply (or replace) timestamps on the
output buffers, using piece-wise linear interpolation.
This allows tsparse to be used to stream an arbitrary mpeg-ts file,
or to smooth jittery reception timestamps from a network stream.
The reported latency is increased to match the smoothing latency if
necessary.
The part of the configure.ac that consist to check if we
can include both GL and GLES2 at the same time is failing.
Indeed, in the case NEED_GLES2=yes and NEED_OPENGL=auto,
HAVE_OPENGL variable is updated whereas it should be HAVE_GL
variable that has to be updated (HAVE_OPENGL variable is not
used in the rest of the configure.ac).
https://bugzilla.gnome.org/show_bug.cgi?id=739348
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin GAIGNARD <benjamin.gaignard@linaro.org>
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
