| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
They do the same.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them would be undefined behaviour
if they had not been initialized successfully.
Furthermore cleanup() always locked a mutex regardless of whether there
was any attempt to initialize these mutexes at all.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
| |
Also combine two if blocks that check for the same condition
and don't check had_partial if we already have a complete packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
| |
There are no preallocated buffer packets any more; this feature only
worked with the old encode API and only until said API was turned into
a wrapper for the new API in 93016f5d1d280f9cb7856883af287fa66affc04c.
So remove its remnants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
|
|
| |
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Integer overflow in the Q16 framerate calculation was sending
invalid values to the OMX encoder.
On the RPI4, this manifested as bitrate controls being ignored
on video streams with 60000/1001 framerates. Video streams with
30000/1001 framerates were not affected.
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://trac.ffmpeg.org/ticket/7687
If an encoded frame is returned split over two or more
IL buffers due to the size, then there is a race between
whether get_buffer will fail, return NULL, and a truncated
frame is passed on, or IL will return the remaining part
of the encoded frame.
If get_buffer returns NULL, part of the frame is left behind
in the codec, and will be collected on the next call. That
then leaves a frame stuck in the codec. Repeat enough times
and the codec FIFO is full, and the pipeline stalls.
A performance improvement in the Raspberry Pi firmware means
that the timing has changed, and now frequently drops into the
case where get_buffer returns NULL.
Add code such that should a buffer be received without
OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
set, so we wait for the remainder of the frame.
This code has been made conditional on the Pi build in case
other IL implementations don't handle ENDOFFRAME correctly.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
| |
fixes https://trac.ffmpeg.org/ticket/6586
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
| |
Print the right library name, which is trying to open, on the log message.
Signed-off-by: Alejandro Solozabal <a.solozabal@hotmail.com>
|
|\
| |
| |
| |
| |
| |
| | |
* commit '57ec83e4246b21c2f0c068b9151d806737d4497f':
omx: Use the EOS flag to handle flushing at the end
Merged-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids having to count the number of frames sent to the codec
and the number of output packets received; instead just wait until
the encoder returns a buffer with the EOS flag set.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| |
| |
| | |
Also use av_mallocz_array().
Bug-Id: CID 1396839
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
| |
| |
| |
| |
| |
| | |
The encode function is supposed to just return 0 on success.
This stems from a mixup with the return value of decode functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| |
| | |
This adds "-profile[:v] profile_name"-style option.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| |
| | |
Fixes CID1396849
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
| |
| |
| |
| |
| | |
Also use av_mallocz_array().
Fixes CID1396839.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '5c2fb561d94fc51d76ab21d6f7cc5b6cc3aa599c':
h264: add H264_ prefix to the NAL unit types
Conflicts:
libavcodec/h264_parse.c
libavcodec/h264_parser.c
libavcodec/h264_slice.c
libavcodec/h264dec.c
Merged-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| |
| | |
This will prevent conflicts e.g. in code that deals with both h264 and
hevc.
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '251cbb44003caf179fb17afbb8a6c56643c2a646':
h264: create a new header for common h264 definitions
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| |
| |
| | |
Move the NAL unit types into it. This will allow to stop including the
whole decoder-specific h264dec.h in some code that is unrelated to the
decoder and only needs some enum values.
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '9df889a5f116c1ee78c2f239e0ba599c492431aa':
h264: rename h264.[ch] to h264dec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| | |
This is more consistent with the naming of other decoders.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The encode function is supposed to just return 0 on success.
This stems from a mixup with the return value of decode functions.
Reviewed-by: Jan Gerber <j@v2v.cc>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| | |
Tested-by: Jan Gerber <j@v2v.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb':
cosmetics: Fix spelling mistakes
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| | |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '1bb56abb9b37bd208a66164339c92cad59b1087b':
omx: Add support for zerocopy input of frames
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can only be used if the input data happens to be laid out
exactly correctly.
This might not be supported on all encoders, so only enable it
with an option, but enable it automatically on raspberry pi,
where it is known to be supported.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit 'f1cd9b03f3fa875eb5e394281b4b688cec611658':
omx: Add support for broadcom OMX on raspberry pi
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The raspberry pi uses the alternative API/ABI for OMX; this makes
such builds incompatible with all the normal OpenMAX implementations.
Since this can't easily be detected at configure time (one can
build for raspberry pi's OMX just fine using the generic, pristine
Khronos OpenMAX IL headers, no need for their own extensions),
require a separate configure switch for it instead.
The broadcom host library can't be unloaded once loaded and started;
the deinit function that it provides is a no-op, and after started,
it has got background threads running, so dlclosing it makes it
crash.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|/
|
|
|
|
|
| |
* commit 'e8919ec486a5559fdcf366e347be0656d904a87f':
libavcodec: Add H264/MPEG4 encoders based on OpenMAX IL
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|