| Age | Commit message (Collapse) | Author |
|---|
|
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 adds "-profile[:v] profile_name"-style option.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
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>
|
|
Fixes CID1396849
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Also use av_mallocz_array().
Bug-Id: CID 1396839
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
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>
|
|
* commit '251cbb44003caf179fb17afbb8a6c56643c2a646':
h264: create a new header for common h264 definitions
Merged-by: Clément Bœsch <u@pkh.me>
|
|
* commit '9df889a5f116c1ee78c2f239e0ba599c492431aa':
h264: rename h264.[ch] to h264dec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>
|
|
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>
|
|
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>
|
|
* commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb':
cosmetics: Fix spelling mistakes
Merged-by: Clément Bœsch <u@pkh.me>
|
|
This will prevent conflicts e.g. in code that deals with both h264 and
hevc.
|
|
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.
|
|
This is more consistent with the naming of other decoders.
|
|
* commit '1bb56abb9b37bd208a66164339c92cad59b1087b':
omx: Add support for zerocopy input of frames
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
* commit 'f1cd9b03f3fa875eb5e394281b4b688cec611658':
omx: Add support for broadcom OMX on raspberry pi
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
* commit 'e8919ec486a5559fdcf366e347be0656d904a87f':
libavcodec: Add H264/MPEG4 encoders based on OpenMAX IL
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
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>
|
|
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>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
