Simply produce the result into the output image provided by the base
class. This avoid useless copy. This also removes unchecked buffer map
and ensure that GstVideoMeta is respected (for stride mostly).
https://bugzilla.gnome.org/show_bug.cgi?id=775377
If a sub class of GstGLContext does not create a group
then it currently crashes:
0 g_atomic_int_get (&share->refcount)
1 _context_share_group_is_shared (context->priv->sharegroup)
2 gst_gl_context_is_shared
3 _default_set_sync_gl
https://bugzilla.gnome.org/show_bug.cgi?id=774518
Configure the display mode when setting the negotiated caps instead of
during showing the first frame.
A framebuffer is required to set the mode. Allocate a buffer object
according to the negotiated caps and use it to set the mode. This buffer
object cannot be freed until another page flip happened on the crtc
(i.e., until the first frame is rendered).
https://bugzilla.gnome.org/show_bug.cgi?id=773473
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The force-modesetting parameter forces the kmssink to ignore already
configured display modes, to configure the display mode itself and use
the base plane for output.
https://bugzilla.gnome.org/show_bug.cgi?id=773473
If the input buffers have a different size than the display, the frames
would have to be scaled or positioned on the display. The kmssink cannot
decide which behaviour would be appropriate for which use case.
In order to avoid scaling or positioning of the input stream, allow only
the supported connector resolutions in the sink caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773473
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Displays usually support multiple modes. Therefore, the kmssink should
not only support the preferred mode, but any mode that is supported by
the display.
https://bugzilla.gnome.org/show_bug.cgi?id=773473
The kmssink assumed that the mode was already set by another application
and used an overlay plane for displaying the frames.
Use the preferred mode of the monitor and render to the base plane if
the crtc does not have a valid mode.
https://bugzilla.gnome.org/show_bug.cgi?id=773473
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This is a subblass of VideoFilter but yet does not use any of it's
features. This also fixes issue in case the incoming images have custom
strides as the VideoMeta is no longer ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=775288
When a MSS server hosts a live stream the fragments listed in the
manifest usually don't have accurate timestamps and duration, except
for the first fragment, which additionally stores timing information
for the few upcoming fragments. In this scenario it is useless to
periodically fetch and update the manifest and the fragments list can
be incrementally built by parsing the first/current fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=755036
gstdecklink.cpp: In member function ‘virtual HRESULT GStreamerDecklinkInputCallback::VideoInputFrameArrived(IDeckLinkVideoInputFrame*, IDeckLinkAudioInputPacket*)’:
gstdecklink.cpp:766:34: error: ‘base_time’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
capture_time -= base_time;
^
The schroedinger headers unconditionally #define over C99's rint when
compiling with msvc which messes up the later inclusion of math.h.
Including math.h before schroedinger headers avoids getting syntax
errors in math.h
https://bugzilla.gnome.org/show_bug.cgi?id=775293
a) Use get_pkgconfig_variable() to get the opencv prefix
b) Place an upper limit on the opencv version
c) Ensure that headers are available
(b) and (c) just copy what the configure.ac checks do.
First of all, all the HD and UHD modes should be top-field-first, as
also returned by the Decklink mode iterator API.
Then we should include the caps field "field-order" in the caps of the
source (not the sink due to negotiation problems with optional fields).
And finally we should set the TFF flag on interlaced buffers that are
top-field-first.
On some hardware the first few frames are bogus and not very useful.
Their timestamps are off, they have no timecodes, or there are spurious
black frames / no-signal frames. After a few frames this stabilizes
though.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
Based on this we calculate the actual capture time, which should get us
rid of any capturing jitter by averaging it out.
Also add a output-stream-time property which forces the elements to
output the stream time directly instead of doing any conversion to the
pipeline clock. Use with care.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
The hardware timestamps have no relation to when frames were produced,
only when frames arrived somewhere in the hardware. Especially there is
no guarantee that audio and video will have the same hardware timestamps
although they belong together, and even more important: the rate with
which the hardware timestamps increase is completely unrelated to the
rate with which the frames are captured!
As such we can as well use the pipeline clock directly and stop doing
complicated calculations. Also as a side effect this allows now running
without any pipeline clock, by directly making use of the stream times
as reported by the driver.
https://bugzilla.gnome.org/show_bug.cgi?id=774850
Calling g_main_context_push_thread and then g_main_context_invoke()
(used by gst_gl_window_send_message_async()) in the same thread will
cause the invoked function to run immediately instead of being delayed.
This had implications for the creation of the OpenGL context not waiting
until the main loop had completely started up and as a result would
sometimes deadlock in short create/destroy scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=775171
626bcccff9 removed some locks that
allowed the main loop quit to occur before the context was fully
created.
2776cef25d attempted to readd them but
missed the scop of the quit() call.
Also remove the use of g_thread_join() as that's not safe to use when
it's possible to lose the last reference from the GL thread.
https://bugzilla.gnome.org/show_bug.cgi?id=775171
For frame->buffer, baseparse is doing that automatically for us. For
frame->output_buffer it doesn't and assumes that the subclass is already
doing that. Consistency!
The way how strchr() was called here, it could easily read after the end
of the string. Use g_ascii_isspace() instead.
Detected by asan in the unit test.
