- 30 Apr, 2016 15 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Janne Grunau authored
This reverts commit 33ac77e8.
-
wm4 authored
It qualifies as a system library. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
This uses a new MMAL feature, which limits the number of extra frames that can be buffered within the decoder. VIDEO_MAX_NUM_CALLBACKS can be defined as positive or negative number. Positive numbers are absolute, and can lead to deadlocks if the user underestimates the number of required buffers. Negative numbers specify the number of extra buffers, e.g. -1 means no extra buffer, (-1-N) means N extra buffers. Set a gratuitous default of -11 (N=10). This is much lower than the firmware default, which appears to be 96. This is backwards compatible, but needs a symbol only present in newer firmware headers. (It's an enum item, so it requires a check in configure.) Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
Slight simplification. The result is the same. Also, change the wording of the message as requested in patch review. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
The mmal decoders do not depend on the software decoders. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
Fixes apparent mmal_port_disable() freezes in ffmmal_stop_decoder() when calling ffmmal_decode() with flush semantics a large number of times in a row. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
The assert in ffmmal_stop_decoder() could trigger sometimes. The packets_buffered counter was indeed not correctly maintained, and packets were not subtracted from it if they were still in the waiting queue. For some reason, this happened especially with VC-1. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
wm4 authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Julian Scheel authored
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a matter of setting the correct MMAL_ENCODING on the input port. To ease the addition of further supported mmal codecs a macro is introduced to generate the decoder and decoder class structs. Signed-off-by: Julian Scheel <julian@jusst.de> Signed-off-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Julian Scheel authored
There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for integers. This fixes building mmaldec. Signed-off-by: Julian Scheel <julian@jusst.de> Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Michael Niedermayer authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 29 Apr, 2016 1 commit
-
-
Diego Biurrun authored
-
- 27 Apr, 2016 1 commit
-
-
Diego Biurrun authored
-
- 26 Apr, 2016 2 commits
-
-
Vittorio Giovara authored
-
Vittorio Giovara authored
The original sample was generated with invalid software.
-
- 25 Apr, 2016 1 commit
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 24 Apr, 2016 20 commits
-
-
Luca Barbato authored
And simplify and explain the expression. Fault introduced in f3fdef10
-
Anton Khirnov authored
It is always equal to nb_slice_ctx.
-
Anton Khirnov authored
This is more correct and avoids wasting space when frame threading is used.
-
Anton Khirnov authored
This limit is now unnecessary, we can easily support an arbitrary number of threads.
-
Anton Khirnov authored
Those should already be set to the correct values.
-
Anton Khirnov authored
-
Anton Khirnov authored
In such a case, decode the MBs in parallel without the loop filter, then execute the filter serially. The ref2frm array was previously moved to H264SliceContext. That was incorrect, since it applies to all the slices and should properly be in H264Context (it did not actually break decoding, since this distinction only becomes relevant with slice threading and deblocking_filter=1, which was not implemented before this commit). The ref2frm array is thus moved back to H264Context.
-
Anton Khirnov authored
It is not used for anything internally, just exported in the output frames. So remove the indirection and set it directly in frame_start().
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
It is no longer called from outside the h264 decoder.
-
Anton Khirnov authored
It is always unconditionally initialized in decode_postinit() and then immediately used in one place further below. All the other places where it is accessed are just useless fluff.
-
Anton Khirnov authored
This comment used to apply to code that was removed.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
It is very fragile against fields being moved and hides what is actually being copied. Copy all the fields explicitly instead.
-
Anton Khirnov authored
-
Anton Khirnov authored
This will allow decoupling the parser from the decoder.
-
Anton Khirnov authored
Make the SEI parsing independent of the H264Context, to allow decoupling the parser from the decoder.
-