- Mar 03, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Mar 02, 2018
-
-
Nicolas Dufresne authored
This reverts commit 4211e4c2.
-
- Feb 28, 2018
-
-
Padding can be left undefined there is no point filling it with 0. https://bugzilla.gnome.org/show_bug.cgi?id=793694
-
The encoder and decoder on zynqultrascaleplus support these new 10 bits format. https://bugzilla.gnome.org/show_bug.cgi?id=793694
-
No semantic change, I'm going to re-use it to copy the NV12_10LE32 format. https://bugzilla.gnome.org/show_bug.cgi?id=793694
-
- Feb 21, 2018
-
-
Check input buffers for ROI meta and pass them to the encoder by using zynqultrascaleplus's custom OMX extension. Also add a new "default-roi-quality" in order to tell the encoder what quality level should be applied to ROI by default. https://bugzilla.gnome.org/show_bug.cgi?id=793696
-
This property isn't actually mutable in the PLAYING state. https://bugzilla.gnome.org/show_bug.cgi?id=793458
-
The 'target-bitrate' property can be changed while PLAYING (GST_PARAM_MUTABLE_PLAYING). Make it thread-safe to prevent concurrent accesses between the application and streaming thread. https://bugzilla.gnome.org/show_bug.cgi?id=793458
-
I spent quiet some time figuring out why performance of my pipeline were terrible. Turned out it was because of output frames being copied because of stride/offset mismatch. Add a PERFORMANCE DEBUG message to make it easier to spot and debug from logs. https://bugzilla.gnome.org/show_bug.cgi?id=793637
-
- Feb 15, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Feb 12, 2018
-
-
Also fix the 'nick' of the property. omxh265enc is based on the code from omxh264enc and suffers the same typo as we fixed in https://bugzilla.gnome.org/show_bug.cgi?id=784370 This element isn't part of a stable release yet so it's not an API break. https://bugzilla.gnome.org/show_bug.cgi?id=793390
-
- Feb 08, 2018
-
-
Tim-Philipp Müller authored
WARNING: Trying to compare values of different types (str, int). The result of this is undefined and will become a hard error in a future Meson release. Also remove unused libversion/soversion.
-
- Jan 30, 2018
-
-
The OMX specs defines 8 headers that implementations can use to define their custom extensions. We were checking and including 3 and ignoring the other ones. https://bugzilla.gnome.org/show_bug.cgi?id=792043
-
We are now always checking which files are present or not, even when using our internal copy of OMX, rather than hardcoding the ones present in it. https://bugzilla.gnome.org/show_bug.cgi?id=792043
-
Nicolas Dufresne authored
This reverts commit 9d37a92a.
-
constrained-intra-prediction and loop-filter-mode. Those map standard OMX settings. https://bugzilla.gnome.org/show_bug.cgi?id=792528
-
entropy-mode, constrained-intra-prediction and loop-filter-mode. Those map standard OMX settings. https://bugzilla.gnome.org/show_bug.cgi?id=792528
-
nTargetBitrate and nEncodeBitrate are defined in bits per second in the OMX spec. https://bugzilla.gnome.org/show_bug.cgi?id=792528
-
Custom property to control the number of internal buffers used in the decoder to smooth out entropy decoding performance. https://bugzilla.gnome.org/show_bug.cgi?id=792528
-
It seems cleaner to use the proper meson tools to include this path rather than manually tweak the build flags. This also allows us to simplify the OMX extensions detection code. We are now always checking which files are present, even when using our internal copy of OMX, rather than hardcoding the ones present in it. https://bugzilla.gnome.org/show_bug.cgi?id=792043
-
As we added in the parser (bgo#792039) expose the chroma and bit depth information in output caps. https://bugzilla.gnome.org/show_bug.cgi?id=792040
-
No semantic change so far. https://bugzilla.gnome.org/show_bug.cgi?id=792040
-
This hack tries to pass as much information as possible from caps to the decoder before it receives any buffer. These information can be used by the OMX decoder to, for example, pre-allocate its internal buffers before starting to decode and so reduce its initial latency. This mechanism is currently supported by the zynqultrascaleplus decoder. https://bugzilla.gnome.org/show_bug.cgi?id=792040
-
- Jan 29, 2018
-
-
I find it confusing when debugging that OMX calls returning an error where not logged as GST_LEVEL_ERROR making them harder to spot. Fix this by introducing simple log macros checking the return value of the OMX call and logging failures as errors. https://bugzilla.gnome.org/show_bug.cgi?id=791069
-
Can be used to log buffers exchange between OMX and gst-omx to profile performances of the OMX component. Ideally this should be done using tracer hooks but it's currently not possible to define custom hooks outside of core. Use GST_DEBUG="OMX_PERFORMANCE:8" to enable it. See also https://github.com/gdesmott/gst-log-parser/blob/master/src/bin/omx-perf.rs as a simple program consuming those logs to generate gnuplot files and stats. https://bugzilla.gnome.org/show_bug.cgi?id=791093
-
The Zynq UltraScale+ encoder implements a custom OMX extension to directly import dmabuf saving the need of mapping input buffers. This can be use with either 'v4l2src io-mode=dmabuf' or an OMX video decoder upstream. https://bugzilla.gnome.org/show_bug.cgi?id=792361
-
- Jan 22, 2018
-
-
Make use of the new GstVideoEncoder QoS API to drop late input frames. This may help a live pipeline to catch up if it's being late and all frames end up being dropped at the sink. https://bugzilla.gnome.org/show_bug.cgi?id=792783
-
- Jan 19, 2018
- Jan 07, 2018
-
-
If something goes wrong while trying to manually copy the input buffer, the 'break' was moving us out of the 'for' loop but not out of the switch block. So we ended up calling gst_video_frame_unmap() a second time (raising assertions) and returning TRUE rather than FALSE. Reproduced with a WIP zynqultrascaleplus OMX branch reporting wrong buffer sizes and so triggering this bug. https://bugzilla.gnome.org/show_bug.cgi?id=792167
-
- Dec 19, 2017
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
It's now in -base.
-
- Dec 14, 2017
-
-
Julien Isorce authored
If less than 1%. The dynamic format change should not happen when the resolution does not change and when only the framerate changes but very slightly, i.e. from 50000/1677=29.81 to 89/3=29.66 so a "percentage change" of less than 1% (i.e. 100*(29.81-29.66)/29.66 = 0.50 < 1 ). In that case just ignore it to avoid unnecessary renegotiation. https://bugzilla.gnome.org/show_bug.cgi?id=759043
-
Guillaume Desmottes authored
Prevent from copying the input buffers between GStreamer and OMX. Tested on zynqultrascaleplus and rpi (without dynamic buffers). https://bugzilla.gnome.org/show_bug.cgi?id=787093
-
Guillaume Desmottes authored
If the OMX component supports dynamic buffer mode and the input buffers are properly aligned avoid copying each input frame between OMX and GStreamer. Tested on zynqultrascaleplus and rpi (without dynamic buffers). https://bugzilla.gnome.org/show_bug.cgi?id=787093
-
Guillaume Desmottes authored
No semantic change so far. I'm going to add an alternate way to allocate input buffers. https://bugzilla.gnome.org/show_bug.cgi?id=787093
-
Guillaume Desmottes authored
OMX 1.2.0 introduced a third way to manage buffers by allowing components to only allocate buffers header during their initialization and change their pBuffer pointer at runtime. This new feature can save us a copy between GStreamer and OMX for each input buffer. This patch adds API to allocate and use such buffers. https://bugzilla.gnome.org/show_bug.cgi?id=787093
-