It is a remnant of the old way for user-supplied buffers;
it is always-true since 93016f5d1d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If one encodes MJPEG with a single slice and uses input with
AV_FRAME_DATA_ICC_PROFILE side data, the current allocation code
in ff_mpv_encode_picture() will always increase the size of the
temporary buffer used for allocating packets by the size needed
for to write the ICC chunk even when the current buffer is actually
large enough. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MJPEG is the only mpegvideo-based encoder making use of it.
Fixes linking failures in case mpegvideo_enc.c is compiled
with AMV, LJPEG and MJPEG encoders disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
PATH_MAX is posix. Some compilers (MSVC) don't define this
thus failing to compile the ipfsgateway file.
Defining it fixes the compile.
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It works, but it is not documented to work.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This field is currently used by checks
- skipping packets before the first keyframe
- skipping packets before start time
to test whether any packets have been output already. But since
frame_number is incremented after the bitstream filters are applied
(which may involve delay), this use is incorrect. The keyframe check
works around this by adding an extra flag, the start-time check does
not.
Simplify both checks by replacing the seen_kf flag with a flag tracking
whether any packets have been output by do_streamcopy().
The width and height for qsv frame to download need to be
aligned with 16. Add the alignment operation.
Now the following command works:
ffmpeg -hwaccel qsv -f rawvideo -s 1920x1080 -pix_fmt yuv420p -i \
input.yuv -vf "hwupload=extra_hw_frames=16,format=qsv,hwdownload, \
format=nv12" -f null -
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Do this by switching to bytestream2_(get|put)_le32u() from
bytestream2_(get|put)_le32(); it has after all already been checked
that the packet contains at least a full header, making all
the implicit checks in bytestream2_(get|put)_le32() dead code.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Therefore move the (Get|Put)ByteContext from the context to the stack.
It is transient anyway.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds support for:
- ffplay ipfs://<cid>
- ffplay ipns://<cid>
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway <url> to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The lensfun filter, at present, loads its database from a path hardcoded
at build time. This may not be known or available to end users.
Added option db_path allows custom path.
The test also requires a png decoder, which often can be disabled in
cross building setups, where zlib might be missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
SEI messages are naturally byte-aligned by adding padding bits
to achieve byte-alignment. The parsing code in libavcodec/hevc_sei.c
nevertheless uses a GetBitContext to read it. When doing so, parsing
the next SEI message starts exactly at the position where reading
the last message (if any) ended.
This means that one would have to handle both the payload extension data
(which makes most SEI messages extensible structs) as well as the
padding bits for byte-alignment. Yet our SEI parsing code in
libavcodec/hevc_sei.c does not read these at all. Instead several of
the functions used for parsing specific SEI messages use
skip_bits_long(); some don't use it at all, in which case it is possible
for the GetBitContext to not be byte-aligned at the start of the next
SEI message (the parsing code for several types of SEI messages relies
on byte-alignment).
Fix this by always using a dedicated GetBitContext per SEI message;
skipping the necessary amount of bytes in the NALU context
is done at a higher level. This also allows to remove unnecessary
parsing code that only existed in order to skip enough bytes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
