FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
assume alpha is premultiplied, others assume it is independent. If there is
to be any hope for order in this chaos, we need to start by defining an enum
for the possible range of values.
This commit adds support for the additional side data type
AV_FRAME_DATA_EXIF, which contains a buffer of an EXIF metadata
payload.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This is possible without deprecation period, because said field
is documented as only for our libav* libraries and not the general
public.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
It should be more clear what this flag is indicating with a more
verbose comment documenting it.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Marth64 <marth64@proxyid.net>
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matching *all*
properties, but I think this is sufficiently useless in practise to not warrant
inclusion in the API.
Many filters modify certain aspects of frame data, e.g. through resizing
(vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
possibly others.
When this happens, we should strip all frame side data that will no
longer be correct/relevant after the operation. For example, changing
the image size should invalidate AV_FRAME_DATA_PANSCAN because the crop
window (given in pixels) no longer corresponds to the actual image size.
For another example, tone-mapping filters (e.g. from HDR to SDR) should
strip all of the dynamic HDR related metadata.
Since there are a lot of different side data types that are affected by such
operations, it makes sense to establish this information in a common, easily
accessible way. The existing side data properties enum is a perfect fit for
this.
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
av_frame_side_data_get() has a const AVFrameSideData * const *sd
parameter; so calling it with an AVFramesSideData **sd like
AVCodecContext.decoded_side_data (or with a AVFramesSideData * const
*sd) is safe, but the conversion is not performed automatically
in C. All users of this function therefore resort to a cast.
This commit changes this: av_frame_side_data_get() is renamed
to av_frame_side_data_get_c(); furthermore, a static inline
wrapper for it name av_frame_side_data_get() is added
that accepts an AVFramesSideData * const * and converts this
to const AVFramesSideData * const * in a Wcast-qual safe way.
This also allows to remove the casts from the current users.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not only this is information that relies on the concept of a sequence of
frames, which is completely out of place as a field in AVFrame, but there are
no known or intended uses of this field.
Signed-off-by: James Almer <jamrial@gmail.com>
These fields are supposed to store information about the packet the
frame was decoded from, specifically the byte offset it was stored at
and its size.
However,
- the fields are highly ad-hoc - there is no strong reason why
specifically those (and not any other) packet properties should have a
dedicated field in AVFrame; unlike e.g. the timestamps, there is no
fundamental link between coded packet offset/size and decoded frames
- they only make sense for frames produced by decoding demuxed packets,
and even then it is not always the case that the encoded data was
stored in the file as a contiguous sequence of bytes (in order for pos
to be well-defined)
- pkt_pos was added without much explanation, apparently to allow
passthrough of this information through lavfi in order to handle byte
seeking in ffplay. That is now implemented using arbitrary user data
passthrough in AVFrame.opaque_ref.
- several filters use pkt_pos as a variable available to user-supplied
expressions, but there seems to be no established motivation for using them.
- pkt_size was added for use in ffprobe, but that too is now handled
without using this field. Additonally, the values of this field
produced by libavcodec are flawed, as described in the previous
ffprobe conversion commit.
In summary - these fields are ill-defined and insufficiently motivated,
so deprecate them.
Their usefulness is questionable, very few decoders set them, and their type
should have been int64_t. A replacement field can be added later if a valid use
case is found.
Signed-off-by: Marton Balint <cus@passwd.hu>
