fence_fd should stay in nativewindowpriv.c, no need to export it. It's not
needed by hw buffers (iomx-dr), and it's not used by gralloc until Android 5.0.
This reverts commit 06cb362f3a.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
- used for direct and non direct rendering (replace opaque.c)
- use nativewindowpriv: more control than the public api, since you can set
orientation, crop, cancel a buffer without displaying it and allocate more
than one buffers.
- fallback to nativewindow if nativewindowpriv fails (with only one buffer in
the pool then).
- Only one way to display subtitles: use a seperate android surface.
- Fix subtiles display in case or source aspect != 1.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
- Fix possible infinite loop with sw rendering if GetOutput failed.
- Don't return a pic and don't release the block in case of error_state.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
As iomx_hwbuffer.cpp contains mainly call to private native window from
system/window.h:
- move system window calls to modules/video_output/android/nativewindowpriv.c
- move get_hal_format to iomx.cpp
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
This would allow building libiomx-hc.so with -DANDROID_API=13
instead of =11 as right now - using 13 would probably be more
correct as the headers match 3.2.
Signed-off-by: Martin Storsjö <martin@martin.st>
This simplifies doing device/version specific overrides for the
hal format, which seems to be more necessary on older platform versions.
Signed-off-by: Martin Storsjö <martin@martin.st>
As soon as either the input packet has been written, or an output
buffer is available, we return from the function, allowing passing
the output frames down the pipeline as soon as possible. (For
direct rendering, a new output buffer only become available for
the codec to use once the picture is rendered or discarded.)
This fixes playback with IOMX direct rendering on Nexus S, which
only uses 2 output buffers in this mode (min_undequeued = 1,
nBufferCountMin = 1), and probably also for other devices with
a small number of output buffers.
(On the Nexus S, the number of output buffers can't be increased,
since this leads to blinking.)
This is similar to how available input/output buffers are checked
in the MediaCodec plugin.
This still isn't completely foolproof with respect to the case when
an input packet needs to be split up over multiple input buffers
though, but it wasn't completely correct previously either.
Also make sure we don't return from the function without consuming
the input packet or returning an output frame, which earlier would
lead to a skipped input packet and leaked memory. (This could
previously happen on reconfiguration, or on timeout while waiting for
an input buffer.)
Finally, make sure we don't block indefinitely in case the playback
is paused (causing the decoder to block while waiting for a free
output buffer). The same solution as in the android mediacodec
decoder is used here.
Signed-off-by: Martin Storsjö <martin@martin.st>
In HwBuffer, split Setup into Setup, GetMinUndequeued and SetBufferCount since
we want to control the buffer count logic from omxil.c.
Some OMX components (like OMX.TI.*.Decoder) may have nBufferCountActual that is
greater than nBufferCountMin + min_undequeued. In that case we decreased the
number of buffer wanted by the component and had an undefined behavior.
In order to fix it, we need to increase nBufferCountActual value from the
component only when it's smaller than nBufferCountMin + min_undequeued.
Signed-off-by: Martin Storsjö <martin@martin.st>
According to OMXCodec.cpp, we shouldn't call lockBuffer when we first allocate
all buffers, since we may cancel some of them (the min_undequeued ones).
We should call lockBuffer only before giving a buffer to OMX.
Signed-off-by: Martin Storsjö <martin@martin.st>
Jean-Baptiste Kempf
Thomas Guillem
Rémi Denis-Courmont
Thomas Guillem
Thomas Guillem
Martin Storsjö
Thomas Guillem