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>
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>
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>
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>