If nb_samples is zero, the bit_rate calculation results in a division by
zero.
Since ff_get_buffer fails if frame->nb_samples is zero, this can be
fixed by moving the bit_rate calculation after that function call.
That also makes it possible to reuse the already calculated
frame->nb_samples value.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
get_bits should not be used with more than 25 bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
get_bits should not be used with more than 25 bits.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This fixes a segfault when decoding multi-channel MP3onMP4 files.
This is similar to commit cb72230d for MPADSPContext.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Thats what the spec says should be done
aka iterate in the wrong space and use special cases to patch that up.
It sometimes can result in different order
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This change introduces basic support for HEVC decoding through vdpau.
Right now, there are problems with the nvidia driver/library implementation
that mean that frames are incorrectly laid out in memory when they are
returned from the decoder, and it is normally impossible to recover the
complete decoded frame due to loss of data from alignment inconsistencies.
I obviously hope that nvidia will be fixing it in due course - I've verified
the problems exist with their example application.
As such, this support is not useful for any real world application, but I
believe that it is correct (with the caveat that the mangled frames may hide
problems) and will work properly once the nvidia problem is fixed.
Right now it appears that any file encoded by x265 or nvenc is decoded
correctly, but that's because these files don't use a bunch of HEVC
features.
Quick summary:
Features that seem to work:
1) Short Term References
2) Scaling Lists
3) Tiling
Features with known problems:
1) Long Term References
It's hard to tell what's going on here. After I read the nvidia example
app that does not set the IsLongTerm flag on LTRs, and changed my code,
a bunch of frames using LTR started to display correctly, but there
are still samples with glitches that are related to LTRs.
In terms of real world files, both x265 and nvenc only use short term
refs from this list. The divx encoder seems similar.
Signed-off-by: Philip Langdale <philipl@overt.org>
This also reduces the amount of memory needed
Fixes Ticket4672
The new code seems slightly faster as well, probably due to better cache usage
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Cross-compile toolchains without support for ranlib -D would fail.
This fixes the configure script to test the cross ranlib rather than the native ranlib.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Electronic Arts VP6 files may contain two video streams: one for the
primary video stream and another for the alpha mask. The file format
uses identical data structures for both streams.
Signed-off-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Drop unneeded var and avoid checking for NULL twice as
ffurl_closep() already does this.
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
* commit '5dbd491eb38efab1d1313d4129ed76ab2e98176d':
TextureDSP: fix erroneous condition which produced blocky output for DXT
Merged-by: Michael Niedermayer <michaelni@gmx.at>
