After the AVFrame has been wrapped into a buffer,
it is owned by the buffer and must not be freed manually
any more. Yet this happens on subsequent errors.
This bug was introduced in 6ca43a9675.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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.
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames continue to be copied.
Additionally, this enabled passing through video frames that previously
were impossible to process, like hardware frames or other special
formats that couldn't be packed into a rawvideo packet.
The length of this list is a compile-time constant, so there is
no need to calculate it again at runtime.
(This also avoids an implicit requirement of -1 == AV_SAMPLE_FMT_NONE.)
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An AVBPrint's internal string is always already zero-terminated;
writing another '\0' is unnecessary as long as one treats
the string only as a C-string.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented that freeing the last (and only) entry of
an AVDictionary frees the dictionary.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since bae8844e35, the AVPacket that is
intended to be used to return the demuxed packet is automatically
unreferenced when the demuxer returns an error. This makes an
av_packet_unref() in the lavfi demuxer redundant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_new_packet() already sets the size. And if the packet is not
allocated by av_new_packet() (which seems to be impossible atm), both
pkt->size as well as size are 0, so setting it again is unnecessary in
this scenario, too.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avdevice_register_all() is still required to register devices into
lavf (this is required due to lavd being somewhat of a hack).
Signed-off-by: Josh de Kock <josh@itanimul.li>
Fixes the following warnings:
libavdevice/lavfi.c:136:16: warning: assignment discards 'const' qualifier from pointer target type
libavdevice/lavfi.c:137:17: warning: assignment discards 'const' qualifier from pointer target type
FAIL(ret) expands to statements including a silly ret=ret.
This triggers a -Wself-assign on confirmed clang 3.6, and so we fix it.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Example of non-mappable file is /dev/stdin. Previously passing it as
graph_file value returned error.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
MSVC does not allow passing file pointers between libs
This API can thus not work with MSVC and as it was very recently added
and its it was in no release its removial should not cause any problems
A better API will be implemented, but its not finished yet, this revert is
to avoid potentially blocking the release
Found-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Andreas Rheinhardt
Paul B Mahol
Anton Khirnov
Timo Rothenpieler
James Almer
Yun Zhang
Andreas Rheinhardt
Limin Wang
Zhao Zhili
Josh de Kock
Marton Balint
Carl Eugen Hoyos
Muhammad Faiz
Nicolas George
Michael Niedermayer
Eddie Hao
Ganesh Ajjanagadde
Ronald S. Bultje
Andreas Cadhalpun
Michael Niedermayer
Andrey Utkin