| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Instead of the deprecated gst_element_get_request_pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2180>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split plugin into features including
dynamic types which can be indiviually
registered during a static build.
More details here:
https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/661
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2110>
|
|
|
|
|
|
|
|
|
|
|
|
| |
volatile is not sufficient to provide atomic guarantees and real atomics
should be used instead. GCC 11 has started warning about using volatile
with atomic operations.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719
Discovered in https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/868
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2098>
|
|
|
|
|
|
| |
Hopefully that'll make hotdoc pick up the docs for these elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1428>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
|
| |
|
| |
|
|
|
|
|
| |
If user's video sink has been changed, it is unable to fetch
videoscale element by name and link to the video sink.
|
|
|
|
|
| |
Element sections were not rendered anymore after the hotdoc
port, fixing this revealed a few incorrect links.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=794568
|
|
|
|
|
| |
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- libgstgtksink.so -> libgstgtk.so
- libgstteletextdec.so -> libgstteletex.so
- libgstcamerabin2.so -> libgstcamerabin.so
- libgstonvif.so -> libgstrtponvif.so (meson only)
- sdp -> sdpelem (avoid clash with libgstsdp)
- gstsiren -> siren
- libgstkmssink.so -> libgstkms.so
https://bugzilla.gnome.org/show_bug.cgi?id=779344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
http://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=763081
|
|
|
|
|
|
|
|
| |
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753241
|
|
|
|
|
| |
Remember to set the source to NULL state as adding it to the pipeline
will set it to the READY state.
|
|
|
|
|
| |
Video source should be linked to videocrop and not to
videoconvert as it is done in the main linking path
|
|
|
|
| |
The structure is created and never used anymore. Remove it.
|
|
|
|
|
|
|
| |
Replace videocrop ! videoscale ! capsfilter with the digitalzoom
bin that has the same pipeline internally and already updates
the capsfilter automatically when caps change, removing this code
from wrappercamerabinsrc and making it cleaner.
|
|
|
|
|
|
|
|
| |
Avoids one extra uneeded renegotiation if the elements are already
configured to their final property values when the caps event
goes through.
Also avoids hitting bug https://bugzilla.gnome.org/show_bug.cgi?id=748344
|
|
|
|
| |
To avoid going through our capsfilter which would limit the choices.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It contains videocrop ! videoscale ! capsfilter and implements digital
zooming.
At this moment, it is a private element of the camerabin plugin.
This will remove some code used in wrappercamerabinsrc to make
code clearer and digitalzoom can potentially be used by other
applications in the future, it has nothing camerabin specific.
|
|
|
|
| |
This is not needed any longer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wrappercamerabinsrc has a videocrop element to be used for
zooming and for cropping when input caps is different when used
with the GstPhotography interface. The zooming part needs
the following elements:
capsfilter ! videocrop ! videoscale ! capsfilter
The capsfilters should always have the same caps to ensure the
zooming is done and preserves dimensions, unless when it is needed
to do more cropping due to input dimensions those caps
need to be modified accordingly to preserve the output dimensions.
This, however, makes it hard to get caps negotiation to work properly
as we need to have different caps in the capsfilters to account for
the extra cropping needed. It could be simple for fixed caps but it
gets tricky with unfixed ones.
To solve this, this patch splits the zooming and dimension reduction
cropping into 2 separate videocrop elements. The first one does
the dimension cropping, which is only needed when the GstPhotography
API is used and the source provides a caps that is different than
what is requested, while the second is dedicated to zoom crop only.
The first part of the pipeline goes from:
src ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
to
src ! videocrop ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
It might add an extra overhead in the image capture as the image might need
to be cropped twice but this can be solved by enabling videocrop to use
crop metas so only the later one does the real cropping.
It also makes the code a bit simpler.
|
|
|
|
|
| |
This is already handled in another place and doesn't make sense
in the function context anymore
|
|
|
|
|
| |
Post an error when preparing the image capture through photography
interface fails
|
|
|
|
|
| |
Intersect is enough to check if the requested caps are compatible
with what the source is going to provide. Equality will be too strict.
|
| |
|
|
|
|
|
| |
Avoids not-negotiated failures related to using image capture caps
still when adjusting to go back to viewfinder.
|
|
|
|
| |
gst_pad_peer_query doesn't take ownership of the query object
|
|
|
|
|
|
|
|
|
|
|
| |
Remove tee and output-selector and just link the source
pad to the outputs we want as needed.
The way we need to prioritize caps negotiation and allocation
queries depending on the mode enabled is too custom to be
handled using tee and output-selector.
This provides more flexibility and doesn't get in the way of proper
handling of negotiation and allocation queries.
|
|
|
|
|
| |
The variable was never set to true and can be removed along
with the probe in which it used to act
|
|
|
|
| |
It is already fixed
|
|
|
|
| |
We depend on 2.32 already
|
|
|
|
|
| |
Only get the pad if it is really going to be used to avoid
leaking it
|
|
|
|
|
|
|
|
| |
If the video source happens to allow max-zoom to be greater than our maximum hard coded
value of 10 then the user cannot set anything greater than our maximum specified in the
param spec. We have to update our param spec to prevent glib from capping the value
https://bugzilla.gnome.org/show_bug.cgi?id=745740
|
|
|
|
|
|
|
|
|
|
| |
To avoid useless renegotiation of the pipe we can check for
negotiated caps on src_filter and compare it with requested
filter. If the caps intersect, avoid restart.
Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
https://bugzilla.gnome.org/show_bug.cgi?id=672610
|
|
|
|
|
|
|
|
| |
The image capture mutex and the pad object lock would cause a race
if the pad query was made right when the image probe was running.
The image probe needs the capture mutex and the querying would need
the pad object lock.
|
|
|
|
|
| |
It is not an if/else situation but an if error abort otherwise
just continue. Remove else to make it more readable
|
|
|
|
|
|
|
|
|
| |
It might be racy with the image probe thread as it uses the capture
mutex just like the start-capture handler from camerabin. The
start-capture would be waiting for the source's streaming thread
to stop to be able to set the source state to ready while the
probe would be blocked waiting to acquire the capture mutex.
It causes a deadlock.
|
|
|
|
|
|
| |
The flush might clear any pending captures that are still in
queues being processed while the drain query will wait for those
to be properly done
|
| |
|