- Feb 15, 2018
-
-
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
-
Matthew Waters authored
From e8c7a71 to 3fa2c9e
-
- Dec 13, 2017
-
-
Julien Isorce authored
The tee element can call gst_query_add_allocation_pool with pool as NULL. Checking nth > 0 is not enough so we need to verify if there is a pool. https://bugzilla.gnome.org/show_bug.cgi?id=730758 https://bugzilla.gnome.org/show_bug.cgi?id=784069
-
Julien Isorce authored
Some live streams can set the framerate to 50000/1677 (=29.81). GstVideoInfo.fps_n << 16 is wrong if the fps_n is 50000 (i.e. greater than 32767). https://bugzilla.gnome.org/show_bug.cgi?id=759043
-
- Dec 11, 2017
-
-
Julien Isorce authored
Will be easier to maintain. Also uniformize autotool build with meson build which is already retrieving the gl libs. https://bugzilla.gnome.org/show_bug.cgi?id=781606
-
Julien Isorce authored
And uses gst_omx_args instead of add_global_arguments. Similar to c6923285 which was only for configure.ac Useful to get omxvp8dec with meson too: meson . buildtmp -D with_omx_target=tizonia https://bugzilla.gnome.org/show_bug.cgi?id=782800
-
Julien Isorce authored
Useful mostly for testing/debugging purpose as this is a software based decoder (libfaad) for which GStreamer provides a direct wrapper. https://bugzilla.gnome.org/show_bug.cgi?id=791482
-
- Nov 29, 2017
-
-
The usual pattern when setting OMX params is to first get the struct param, override the values we want to set and then set the updated param. We were not doing this with OMX_IndexParamVideoPortFormat and so were resetting some fields such as OMX_VIDEO_PARAM_PORTFORMATTYPE.xFramerate https://bugzilla.gnome.org/show_bug.cgi?id=790979
-
Julien Isorce authored
Like done by gst_codec_utils_aac_caps_set_level_and_profile which is called by avenc_aac, ffaac and voaacenc. https://bugzilla.gnome.org/show_bug.cgi?id=735208
-
- Nov 28, 2017
-
-
As stated in the existing comment, when flusing we should wait for OMX to send the flush command complete event AND all ports being released. We were stopping as soon as one of those condition was met. Fix a race between FillThisBufferDone/EmptyBufferDone and the flush EventCmdComplete messages. The OMX implementation is supposed to release its buffers before posting the EventCmdComplete event but the ordering isn't guaranteed as the FillThisBufferDone/EmptyBufferDone and EventHandler callbacks can be called from different threads (cf 2.7 'Thread Safety' in the spec). https://bugzilla.gnome.org/show_bug.cgi?id=789475
-
No semantic change so far, I just made the 'while' end condition easier to understand as a first step before changing it. - move error/time out checks inside the loop to make it clearer on what we are actually waiting for. - group port->buffers checks together with parenthesis as they are part of the same conceptual check: waiting for all buffers to be released. https://bugzilla.gnome.org/show_bug.cgi?id=789475
-
- Nov 27, 2017
-
-
Matthew Waters authored
From 3f4aa96 to e8c7a71
-
- Nov 23, 2017
-
-
The Zynqultrascaleplus has support for extra AVC levels not defined in the OMX spec as a customer extension. https://bugzilla.gnome.org/show_bug.cgi?id=790758
-