Tested with basic video playback on a RPI 3B+
This is the code from the Raspbian patch ported to the 4.0 architecture.
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
Do not declare *_sys_t typedefs globally in vlc_common.h. Instead,
declare them locally in each module that provides a definition.
This paves the way to move C++ definitions into anonymous namespaces in
order to respect C++ ODR.
The picture_resource_t and sout_stream_id_sys_t typedefs will be handled
separately, since they require specific additional changes.
See #18033
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Queuing pictures internally into decoded_pictures is a relict from when
decoded pictures could only be returned out of decode() calls. Remove
this and send decoded pictures to the core right out of the output port
callback.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Reduce the number of extra buffers, which effectively controls the size
of the allocated picture pool inside the codec.
At the same time increase the input buffer count, so that it is big
enough to contain all possibly sent pictures from the vout.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Wait for all input buffers to be returned when flushing.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
There is no reason to disable ports before flushing, neither is there a
reason to reconfigure the port after flushing. In fact this lead to
weird issues with the whole mmal stack when the codec was flushed.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Avoid useless flushing by allowing to wait a little longer for buffers
to be available.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The mmal_queue is threadsafe and the block released from output callback
does not interfere with the block processing in decode. What could
happen was a use after free of block when checking the decode loop
condition after submitting the block to mmal. Avoid this by clearing the
block pointer before submitting to mmal and use it as extra loop
condition.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Use only one callback for every decoder types:
int (*pf_decode)(decoder_t *, block_t *p_block);
There is now only one way to send output frames/blocks from a decoder module:
using decoder_QueueVideo(), decoder_QueueAudio() and decoder_QueueSub()
functions.
This fixes transcoding not receiving any output when a decoder used
decoder_Queue*() function.
The pf_packetize callback is kept unchanged. A packetizer shouldn't be
asynchronous at all (and this simplify the locking for decoder core).
The pf_decode callback returns, for now, only one value: SUCCESS. This will
allow a module to send more status.
Decoder modules are now responsible for calling decoder_UpdateVideoFormat()
before decoder_NewPicture().
In a lot of modules, decoder_UpdateVideoFormat() could be called in a better
place. Just after dec->fmt_out is updated for example.
For now, a lot of decoder/packetizer are also flushing on
BLOCK_FLAG_DISCONTINUITY flag. Some others are also flushing on
BLOCK_FLAG_CORRUPTED flag (omxil, videotoolbox, avcodec audio).
This patch doesn't change the current behavior.
But maybe we shouldn't flush anymore on DISCONTINUOUS/CORRUPTED.
Assign the picture pointer to mmal buffers user_data right before passing it
into mmal instead of doing it in mmal_picture_lock. This is necessary, because
the picture pointer used to call mmal_picture_lock points to the original
picture instance, while the picture handed to the plugins from
picture_pool_Get is a clone of the original picture. Assigning the picture in
user_data caused picture_Release to be called on the original instead of the
clone. Since commit 22e61f10 this is fatal as the pf_destroy pointer is not
pointing to picture_pool_ReleasePicture anymore.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
When needed (fmt->b_packetized == false), create a packetizer before creating a
decoder. The fmt_in of the decoder is copied either from the fmt_out of the
packetizer, or from the fmt of CreateDecoder.
If a container does not provide pts fall back to use the provided dts instead.
This is sometimes seen with mp4 and mov containers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
As we use packetized input we normally don't need more than a handful of input
buffers. Using the default of mmal, which is 20, seems absolutely sufficient.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
To be able to handle seeking properly we need to do a full decoder flush on a
discontinuity. As flushing the in- and output ports alone would not cause the
codecs internal state to be reset we have to disable the ports, reconfigure
and reenable. To ensure the flushing is synchronous the input buffers in
transit are now tracked as well.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
When running in opaque mode the mmal codec, deinterlace and vout must be used
together, so it is known that all pictures in use are allocated by the mmal
vout and contain an associated mmal_buffer_header. This allows us to enable
the zerocopy feature of mmal, which allocates shared memory between GPU and
CPU for holding the buffer payloads. Albeit the payloads are just small opaque
handles that reference the GPU side pictures it saves a little bit of
performance, because less VCHIQ transfers are required.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
When running in opaque mode the codec must be used together with the mmal
vout. In this case each picture contains a mmal_buffer_header within the
picture_sys_t. That buffer header can be used instead of locally allocated
headers with the advantage of reducing complexity and avoiding possibly
error-prone mangling of buffer headers. Furthermore it is a prerequisite to
enable zero_copy mode on the ports.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The option named mmal-zerocopy until now is used to configure the codec to
generate pictures with MMAL_ENCODING_OPAQUE which in fact is a fake payload
format that just contains handles for pictures allocated on the GPU side.
While this in effect causes a zerocopy mode of pixel data the naming is
potentially misleading because mmal supports another mode called zero_copy. In
this mode the GPU and CPU use shared buffers via the vc_sm kernel module, so
that the buffer data is actually accessible from userspace but no copies are
required when transferring from or to mmal components.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
It is safe to flush enabled ports, so avoid unnecessary delays by disabling
and enabling the ports.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The data attached to the output port headers is not owned by the codec but by
the vout and only temporarily attached to the codecs buffers. To avoid
refcount issues within the mmal core clear the data field before releasing the
buffers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Depending on what parts of the format have changed it can be possible to apply
the changes without resetting the whole port. As this saves some time try to
make use of it.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Only lock when really needed. To do this feeding the mmal port with buffers is
done from one place only now.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
If a port is not enabled sending any buffers to it will cause an error, so
just don't try it.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Rémi Denis-Courmont
Steve Lhomme
John Cox
Romain Vimont
Julian Scheel
Steve Lhomme
Thomas Guillem