- 05 Jun, 2015 38 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
The input is already stopped if it has reached end or error.
-
Rémi Denis-Courmont authored
After each and every MainLoop() call is a call to End(), which inconditionally sets the input state to END_S.
-
Felix Paul Kühne authored
-
KO Myung-Hun authored
```-- CC access_output/file.lo access_output/file.c: In function 'Open': access_output/file.c:288:9: error: implicit declaration of function 'setmode' [-Werror=implicit-function-declaration] setmode (STDOUT_FILENO, O_BINARY); ^ cc1.exe: some warnings being treated as errors make.exe[4]: *** [access_output/file.lo] Error 1 ``` -- Signed-off-by:Jean-Baptiste Kempf <jb@videolan.org>
-
KO Myung-Hun authored
Signed-off-by: -
Julian Scheel authored
Use signed variables for calculating the buffers to be sent to the component as negative values may occur. Signed-off-by:
Julian Scheel <julian@jusst.de> Signed-off-by:
-
Julian Scheel authored
Save some memory by allocating fewer buffers. This is still not optimal, but close to where we can get with the current implementation. Signed-off-by:
-
Julian Scheel authored
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 authored
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 authored
Signed-off-by:
-
Julian Scheel authored
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 authored
Using mmal_port_pool_allocate/destroy adds some extra safety on maintaining the pool lifecycle in relation to the component lifecycle. Furthermore it is a prerequisite to use zerocopy mode for ports. Signed-off-by:
-
Julian Scheel authored
If the input port returns a buffer which has no picture attached to it it would be leaked. While this in fact should not happen it seems sane to at least release the buffer and spit a warning in case it does happen. Signed-off-by:
-
Julian Scheel authored
If the same picture, containing the same buffer header without being re-acquired in the meantime, is sent to image_fx twice it will portentially cause a double free within the mmal core as it destroys the internal refcounting. Use the same guarding mechanism which is already in place in mmal/vout to ensure this is not happening at any point. Signed-off-by:
-
Julian Scheel authored
The mmal deinterlace filter does currently support the mmal opaque encoding only and thus must be used together with mmal vout and mmal codec. This ensures that pictures being used contain valid mmal buffer headers in the picture_sys. Using them instead of locally allocated buffer headers simplifies the code and avoids error-prone dangling with the data attached to the buffer headers. Furthermore it is a prerequisite to enable zerocopy on the buffer ports, which can even be a good thing when using opaque buffers. If at some point in time the image_fx component in mmal will be fixed to also support I420 input we may reintroduce them for operating this filter independently from mmal codec and vout. Signed-off-by:
-
Julian Scheel authored
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 authored
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 authored
The reason for having a local picture pool within the deinterlace filter has been that the mmal core did not allow to initialise the image_fx filter with less than 20 output buffers. This limitation was removed from the mmal core, so that it is possible to operate with as less as 2 output buffers, which makes it possible to use pictures acquired from the core video output pool. Besides being much more conformant to VLC core design this also avoids some possible issues with buffer ownership and component lifecycle of the mmal components. Signed-off-by:
-
Julian Scheel authored
When an input picture can not be handled due to lack of resources we need to free it to avoid a picture leak. Signed-off-by:
-
Julian Scheel authored
The data attached to the output port headers is not owned by the deinterlace filter 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 authored
It is safe to flush enabled ports, so avoid unnecessary delays by disabling and enabling the ports. Signed-off-by:
-
Julian Scheel authored
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 authored
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 authored
Instead of dynamically allocating a mmal buffer from the mmal buffer pool use a fixed binding, where the same mmal buffer is used for the whole pictures lifecycle. This avoids some overhead on picture allocation and simplifies the code. As the mmal buffer pool is allocated in exactly the same size as the vlc picture pool there is no drawback doing it this way. Signed-off-by:
-
Julian Scheel authored
When not running in opaque mode the buffer headed over for rendering is only returned when the following buffer isrendered or the component is disabled. So in this case waiting for the buffer to be returned immediately deadlocks the rendering. As all buffers get immediately flushed on stop it is safe to skip this wait for non-opaque usecase. Signed-off-by:
-
Julian Scheel authored
Signed-off-by:
-
Julian Scheel authored
If the port is disabled it would refuse buffers with an error anyway. Avoid this by not sending them when the port is disabled. Signed-off-by:
-
Julian Scheel authored
The locking was incomplete and partly just wrong. Signed-off-by:
-
Julian Scheel authored
It is not required to disable mmal ports before flushing them. Signed-off-by:
-
Julian Scheel authored
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 authored
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 authored
Signed-off-by:
-
Jean-Baptiste Kempf authored
Close #14820
-
Rafaël Carré authored
-
- 04 Jun, 2015 2 commits
-
-
Rémi Denis-Courmont authored
Those values are writable by the input thread, and thus inaccessible to other threads. Any remaining use of those (in VLM, podcast and interfaces notably) is an undefined memory access, a bug.
-
Rémi Denis-Courmont authored
The input thread sends events. There is no point in checking manually since the input thread functions aresafe to "use" so long as the caller has a reference to the input thread (regardless of the input thread being dead or at EOF). Also the value of those flags can change asynchronously (outside the input thread) so the checks were racy.
-
