The cached bitstream reader was originally written by Alexandra Hájková
for Libav, with significant input from Kostya Shishkov and Luca Barbato.
It was then committed to FFmpeg in ca079b0954, by merging it with the
implementation of the current bitstream reader.
This merge makes the code of get_bits.h significantly harder to read,
since it now contains two different bitstream readers interleaved with
#ifdefs. Additionally, the code was committed without proper authorship
attribution.
This commit re-adds the cached bitstream reader as a standalone header,
as it was originally developed. It will be made useful in following
commits.
Integration by Anton Khirnov.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Current code stores a pointer to allocated data in libx265 and frees it
when the encoded packet is retrieved. This will leak if the packet is
never retrieved, e.g. if the encoder is closed without being flushed.
Restructure the code such that only indices to an array stored in our
private data are given to libx265. This ensures no allocated memory can
be lost.
Similar to how the encoder looks at frame color information to write the frame
header bitstream.
Should workaround ticket #10091, where container level color parameters passed
to the decoder context were being overwritten.
Signed-off-by: James Almer <jamrial@gmail.com>
PFM (aka Portable FloatMap) encodes its scanlines from bottom-to-top,
not from top-to-bottom, unlike other NetPBM formats. Without this
patch, FFmpeg ignores this exception and decodes/encodes PFM images
mirrored vertically from their proper orientation.
For reference, see the NetPBM tool pfmtopam, which encodes a .pam
from a .pfm, using the correct orientation (and which FFmpeg reads
correctly). Also compare ffplay to magick display, which shows the
correct orientation as well.
See: http://www.pauldebevec.com/Research/HDR/PFM/ and see:
https://netpbm.sourceforge.net/doc/pfm.html for descriptions of this
image format.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
EAGAIN is not correct in this scenario. FFCodec.cb.decode() callback decoders
always return the amount of bytes consumed from the input packet (if any), and
report if a frame was generated by setting got_frame.
Signed-off-by: James Almer <jamrial@gmail.com>
Add encoding of 32 bit-per-sample PCM to FLAC files to libavcodec.
Coding to this format is at this point considered experimental and
-strict experimental is needed to get ffmpeg to encode such files.
It works since most of Android devices don't output B frames by
default. The behavior is documented by Android now, although there
is some exception in history, which should have been fixed now.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Use input PTS as DTS has multiple problems:
1. If there is no reordering, it's better to just use the output
PTS as DTS, since encoder may change the timestamp value (do it
on purpose or rounding error).
2. If there is reordering, input PTS should be shift a few frames
as DTS to satisfy the requirement of PTS >= DTS. I can't find a
reliable way to determine how many frames to be shift. For example,
we don't known if the encoder use hierarchical B frames. The
max_num_reorder_frames can be get from VUI, but VUI is optional.
3. Encoder dropping frames makes the case worse. Android has an
BITRATE_MODE_CBR_FD option to allow it explicitly.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
