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
For the history, the parallel disable port has been introduced by:
"00be69f omxvideodec: Disable output port when setting a new format"
and then replicated to videoenc, audiodec and audioenc.
This is only required to do 'parallel' if buffers are shared between ports.
But for decoders and encoders the input and output buffer are of different
nature by definition (bitstream vs images). So they cannot be shared.
Also starting from IL 1.2.0 it is written in the spec that the parallel
disable is not allowed and will return an error. Except when buffers are
shared.
Again here we know in advance that they are not shared so let's always
do a sequential disable.
Tested on Desktop, rpi and zynqultrascaleplus.
https://bugzilla.gnome.org/show_bug.cgi?id=786348
The OMX specification doesn't provide any API to expose the latency
introduced by encoders and decoders. We implemented this as a custom
extension as declaring the latency is needed for live pipelines like
video conferencing.
https://bugzilla.gnome.org/show_bug.cgi?id=785125
Use the stride and slice height information from the first buffer meta
data to adjust the settings of the input port.
This will ensure that the OMX input buffers match the GStreamer ones
and so will save us from having to copy line-by-line each one.
This is also the first step to allow the OMX encoder to receive dmabuf.
Tested on rpi and zynqultrascaleplus.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
No significant change for now. Just delay the input port configuration
of the buffer size related fields (stride, slice height, buffer size)
until the component is activated.
This will allow us to use the actual stride/height of the first input
and so avoid the buffer copying code path in most cases.
Tested on rpi and zynqultrascaleplus.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
Allocating OMX components buffers in set_format() is too early.
Doing it when receiving the first buffers will allow the element to use
the information from the allocation query and/or the first incoming
buffer to pick to best allocation mode.
Tested on raspberry pi with dynamic resolution changes on decoder and
encoder input.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
Makes the code simpler as we no longer need to restart the thread in
gst_omx_video_enc_flush() and It's more symetric which the omxvideodec
implementation.
I'm also going to move the enabling of the OMX component in
handle_frame() and the src pad thread needs to be started after it.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
No semantic change, just factor out the code enabling and disabling the
component to their own functions.
Makes the code easier to read as the set_format() method was already
pretty big. Will also allow us to easily change the enabling logic.
https://bugzilla.gnome.org/show_bug.cgi?id=785967
gst_omx_video_enc_open will only update GstOMXVideoEnc->port->port_def.
Note that the component is reopen only if the flag
GST_OMX_HACK_NO_COMPONENT_RECONFIGURE is set.
https://bugzilla.gnome.org/show_bug.cgi?id=782418
gstomxvideoenc.c: In function ‘gst_omx_video_enc_fill_buffer’:
CC libgstomx_la-gstomxaacdec.lo
gstomxvideoenc.c:1316:27: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘OMX_U32 {aka long unsigned int}’ [-Wformat=]
GST_LOG_OBJECT (self, "Matched strides - direct copy %u bytes",
^
outbuf->omx_buf->nFilledLen);
~~~~~~~~~~~~~~~~~~
Without this commit the decoder streaming thread stops without ever attending
the drain request, leaving the decoder input thread waiting forever.
https://bugzilla.gnome.org/show_bug.cgi?id=758274
Identical functionality spread of two different components.
We can't use a common base class because of different inheritance,
but let's try to share the code anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=726024
Fixes "GThread-ERROR **: file gthread-posix.c: line 171
(g_mutex_free_posix_impl): error 'Device or resource busy' during
'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'" in _finalize.
Fix printf formats again, so that gst-omx compiles warning-
free on the Raspberry Pi as well. Unfortunately OMX_UINT32
maybe be typedefed to uint32_t or unsigned long, which
doesn't work well with our debugging printf format strings,
so just use %u for those and cast to guint.
