| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
If the source doesn't give us timecode information, do not append a zero
timecode to the frames.
https://bugzilla.gnome.org/show_bug.cgi?id=776900
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is special and handled in the decoder when doing rendering to a
surface. Printing a warning for this is just unnecessary noise
|
| |
|
|
|
|
|
| |
This is more consistent with how we already request the application
class loader and other application resources elsewhere.
|
| |
|
|
|
|
| |
These are unpositioned channel layouts.
|
|
|
|
|
|
|
|
| |
gst_pad_template_new() does not take ownership of
the caps passed to it, so we need to unref the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=776790
https://bugzilla.gnome.org/show_bug.cgi?id=776787
|
| |
|
|
|
|
| |
CID 1373421
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=776591
|
|
|
|
|
|
|
|
|
|
|
| |
This logic did not belong to the channel configuration
parser (only used by dvbbasebin) but to dvbsrc, which
is the element directly using this value and honoring
the "adapter" property.
Allows previously non-working cases like this to work:
GST_DVB_ADAPTER=1 gst-launch-1.0 dvbsrc delsys=11 modulation=7 frequency=689000000 ! fakesink
|
|
|
|
|
| |
Possible failure cases also include not finding the
requested channel.
|
|
|
|
| |
Drop redundant comment while at it.
|
|
|
|
|
|
|
|
| |
If they were not ported after 4+ years it seems unlikely that anybody is
ever going to need them again. They're still in the GIT history if
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774530
|
|
|
|
|
|
| |
The return value has to be unreffed at some point.
https://bugzilla.gnome.org/show_bug.cgi?id=776334
|
|
|
|
|
|
| |
Otherwise it fails to decode.
https://bugzilla.gnome.org/show_bug.cgi?id=740101
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=776076
|
|
|
|
| |
This is a C99 feature.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=774793
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=774793
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=775726
|
|
|
|
|
|
| |
The decoder only supports system memory output presently.
https://bugzilla.gnome.org/show_bug.cgi?id=774587
|
|
|
|
| |
It is not defined for < v5 minor 7
|
|
|
|
|
|
| |
A tuning operation can spawn multiple checks. Being
able to differentiate between them makes debugging
easier.
|
| |
|
|
|
|
| |
Its only purpose was to hold a wait time that was always 0
|
|
|
|
| |
It is always zero.
|
|
|
|
| |
It is not defined for < v5 minor 6
|
| |
|
|
|
|
|
| |
It is expected to post an error message in the bus if the device cannot
be started.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
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;
^
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
signal
https://bugzilla.gnome.org/show_bug.cgi?id=774850
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=774850
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calculate relationship
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pipeline clock
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
|
| |
|
|
|
|
|
| |
As drm.h is internal to libdrm, it expects to have already included
stdlib.h.
|
|
|
|
|
| |
drm.h does not include all what it needs to compile, in particular
stdlib.h which defines size_t
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libkms should not be used, because it imposes limitations on the DRM
API, especially regarding bpp and stride. Instead the DRM IOCTL should
be used directly.
Switch from libkms to the IOCTL interface. Set bpp and height for
framebuffer allocation to properly handle planar video formats.
https://bugzilla.gnome.org/show_bug.cgi?id=773473
Signed-off-by: Víctor Jáquez <vjaquez@igalia.com>
|
|
|
|
|
|
| |
And return FLUSHING instead of NOT_NEGOTIATED on flushing pads.
https://bugzilla.gnome.org/show_bug.cgi?id=774623
|