It's container level information on some formats (Matroska, MXF, yuv4mpeg), so
it should be printed at higher log levels than debug.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The calculation of width/height should round up, not round down to
prevent setting width or height to 0.
Also image->comps[compno].w is unsigned (at least in openjpeg2), so the
calculation could silently wrap around without the explicit cast to int.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
openjpeg 2 sets the data pointers of the image components to NULL,
causing segfaults if the image is reused.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Use check_lib2 to test the header together with the function. This is
necessary, because '-DOPJ_STATIC' changes what the included header does.
Also add '-DOPJ_STATIC' to CPPFLAGS, so that it isn't necessary to
hardcode this in libavcodec/libopenjpeg{dec,enc}.c.
Finally, check for non-static openjpeg 2.1, too.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This fixes a build problem for MIPS architecture that looks like this:
libavcodec/mips/h264dsp_msa.c:2498:6: error: conflicting types for
‘ff_weight_h264_pixels16_8_msa’
void ff_weight_h264_pixels16_8_msa(uint8_t *src, int stride,
This bug was introduced by commit bc26fe89275c267d169b468356c82ee59874407d:
avcodec/h264: Use ptrdiff_t for (bi)weight functions
That commit changed the data type of some function parameters in some
function definitions. However, the implementation of those functions in
libavcodec/mips/h264dsp_msa.c wasn't changed accordingly.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The hardware handling of packed bframes was always questionable but
it used to ok with my workaround. Today, not so much. But today we
have a bsf to unpack the bframes, so let's just use that and be
done with it.
With all the various refactorings that have happened over the years,
the current pts logic is very broken for non-trivial cases (ie: ones
where not every frame/field has a meaningful pts assocated with it).
Generally, we do not want to write AV_NOPTS_VALUE as the output
timestamp, regardless of anything else. It's better to pass zero
if there's no other information.
Additionally, interlaced content where the decoder returns each field
separately can result in the first field carrying the timestamp and
the second having AV_NOPTS_VALUE. It's clearly wrong to overwrite
the valid timestamp.
So, let's just never write AV_NOPTS_VALUE into an output frame.
Empirically, this fixed playback of interlaced mpeg2 and h.264 and
mpeg4-asp with packed b-frames in an avi container.
Using lfg was an overkill in this case where the random numbers
were only used for encoder descisions. Should increase result
uniformity between different FPUs and gives a slight speedup.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The slice index expected by D3D11VA is the one from the texture not from the
array or texture/slices.
In VLC the slices we provide the decoder don't start from 0 and thus pictures
appear in bogus order. With possible crashes and corruptions when using an
invalid index.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is really no need for two aac wrappers, we already have
libfdk-aac which is better. Not to mention that faac doesn't
even support HEv1, or HEv2. It's also under a license which is
unusable for distribution, so it would only be useful to people
who will compile their own ffmpeg, only use it themselves (which
at that point should just use fdk-aac).
Signed-off-by: Josh de Kock <josh@itanimul.li>
With the new decode API, doing this in ffmpeg.c is impractical. There
was resistance against removing the warning, so put it into libavcodec.
Not bothering with reducing the warning to verbose log level for
subsequent wanrings. The warning should be rare, and only happen when
developing new codecs for the old API.
Includes a change suggested by Michael Niedermayer.
When the input frames contain side data, it will accumulate endlessly in
the coded frame, as av_frame_copy_props will append any new side data.
Fixes ticket #5799.
Rick Kern
Aman Gupta
James Almer
Andreas Cadhalpun
Vicente Olivert Riera
Timo Rothenpieler
Philip Langdale
Rostislav Pehlivanov
Matthieu Bouron
Steve Lhomme
Moritz Barsnick
Nablet Developer
Carl Eugen Hoyos
wm4
Adriano Pallavicino
Marton Balint
Josh de Kock
Sasi Inguva
Yogender Gupta
Michael Niedermayer
Jean-Yves Simon
Xiaolei Yu
Hendrik Leppkes