This makes it easier to use the lowres option when dealing with input
files in different codecs. If the codec doesn't support lowres=1 for
instance, it will throw a warning and use lowres=0 instead of erroring
out completely.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'e62ff72fc1052273deb708ba715f73e5187281d4':
lavc: make avcodec_open2() fail when the timebase is not set for encoding
Merged-by: Clément Bœsch <u@pkh.me>
Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.
Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.
* commit 'd12b5b2f135aade4099f4b26b0fe678656158c13':
build: Split test programs off into separate files
Some conversions done by: James Almer <jamrial@gmail.com>
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The deprecated avcodec_decode_video2() and avcodec_decode_audio4()
functions called av_packet_split_side_data() on the input packets. This
is required for packets produced by libavformat with the
AVFMT_FLAG_KEEP_SIDE_DATA flag unset (which is unfortunately the
default).
The new API didn't do this yet, although it didn't matter as no decoder
supports the new API yet. The emulation layer for the old API calls the
old API functions, which took care of the splitting. Add this code to
the new API codec entrypoints too, because we shouldn't send essentially
corrupted data to decoders.
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
From Libav commit 05f66706d1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The bits_per_raw_sample represents the number of bits of precision per sample.
The field is added at the logical place, not at the end as the code was just
recently added
This fixes the regression about losing the audio sample precision information
The change in the fate test checksum un-does the change from the merge
Previous version reviewed by: wm4 <nfxjfg@googlemail.com>
Previous version reviewed by: Dominik 'Rathann' Mierzejewski <dominik@greysector.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'a8068346e48e123f8d3bdf4d64464d81e53e5fc7':
lavc: add a variant of av_get_audio_frame_duration working with AVCodecParameters
Fixes from jamrial incorporated.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '998e1b8f521b73e1ed3a13caaabcf79eb401cf0d':
lavc: add codec parameters API
Fixes added in:
- bit_rate has been made int64_t to match.
- profile and level are properly initialize.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This should return an error to the decoder if the struct it tried to getbuffer is dirty
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some containers, like webm/mkv, will contain this mastering metadata.
This is analogous to the way 3D fpa data is handled (in frame and
packet side data).
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '7b3214d0050613bd347a2e41c9f78ffb766da25e':
lavc: add a field for passing AVHWFramesContext to encoders
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This API is intended to allow passing around codec parameters without
using full AVCodecContext (which also contains codec options and
encoder/decoder state).
VLC uses hwaccel with frame threads and it works fine, but returning
an error here made it fail.
This regression was introduced in commit 31741ae.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Warning message text by nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Libav, for some reason, merged this as a public API function. This will
aid in future merges.
A define is left for backwards compat, just in case some person
used it, since it is in a public header.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In the unlikely situation the user decides to set ticks_per_frame
and timebase to a value large enough to overflow.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'cea1eef25c3310a68dd327eb74aae14ad3c2ddef':
lavc: get the profile name through the codec descriptor in avcodec_string()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f0b769c16daafa64720dcba7fa81a9f5255e1d29':
lavc: add a packet side data type for VBV-like parameters
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Fixes out of array access
Fixes: 482d8f2fd17c9f532b586458a33f267c/asan_heap-oob_4a52b6_7417_1d08d477736d66cdadd833d146bb8bae.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
HWAccels with frame threads are fundamentally flawed in avcodecs current
design, and there are several known problems ranging from image corruption
to driver crashes.
These problems come down to two design problems in the interaction of
threads and HWAccel decoding:
(1)
While avcodec prevents parallel decoding and as such simultaneous access
to the hardware accelerator from the decoding threads, it cannot account
for the user code and its access to the hardware surfaces and the hardware
itself.
This can result in image corruption or even driver crashes if the
user code locks image surfaces while they are being used by the decoder
threads as reference frames.
The current HWAccel API does not offer any way to ensure exclusive access
to the hardware or the surfaces if frame threading is used.
(2)
Initialization of the HWAccel with frame threads is non-trivial, and many
decoders had and still have issues that cause excess calls to the
get_format callback.
This will potentially cause duplicate HWAccel initialization, which in
extreme cases can even lead to driver crashes if the HWAccel is
re-initialized while the user code is actively accessing the hardware
surfaces associated with it, or lead to image corruption due to lost
reference frames.
While both of these issues are solvable, fixing (1) would at least require
a huge API redesign which would move a lot of complexity into the user
code.
The only reason the combination of frame threads and HWAccel was
considered useful is to allow a seamless fallback to multi-threaded
software decoding if the HWAccel is not available, however the issues
outlined above far outweigh this.
The proper solution for a fallback is to re-open the AVCodecContext with
threading enabled if the HWAccel failed, which is a practice commonly used
by various user applications using avcodec today already.
Reviewed-by: Gwenole Beauchesne <gb.devel@gmail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3ee2c60cc296eee3f63d7b5fee9b4332eeeac9fa':
utils: Use data buffers directly instead of an AVPicture
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
It is only used inside libavcodec.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Use the new fields directly instead of the ones from AVPicture.
This removes a layer of indirection which serves no pratical purpose
whatsoever, and will help in removing AVPicture structure completely
later.
Every subtitle encoder/decoder seamlessly points to the new arrays,
so it is possible to deprecate AVSubtitleRect.pict.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
