- 25 1月, 2013 5 次提交
-
-
由 Luca Barbato 提交于
Signed-off-by: NDiego Biurrun <diego@biurrun.de>
-
由 Diego Biurrun 提交于
It is required for building the shared H.264 code.
-
由 Janne Grunau 提交于
The code was copied from per cpu extension init function so the checks for supported extensions was overlooked.
-
由 Janne Grunau 提交于
-
由 Janne Grunau 提交于
-
- 24 1月, 2013 7 次提交
-
-
由 Mans Rullgard 提交于
The sh4 optimizations are removed, because the code is 100% identical to the C code, so it is unlikely to provide any real practical benefit. Signed-off-by: NDiego Biurrun <diego@biurrun.de> Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com> Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>
-
由 Luca Barbato 提交于
The script can and will change.
-
由 Diego Biurrun 提交于
Previously PIC was enabled as a magic workaround for binaries that built fine, but failed to function at all. This problem no longer exists, possibly since the introduction of symbol versioning.
-
由 Martin Storsjö 提交于
In ff_rtp_get_payload_type, the AVFormatContext is used for checking whether the payload_type or rtpflags options are set. In rtpenc_chain, the rtpctx struct is a newly initialized struct where no options have been set yet, so no options can be fetched from there. All muxers that internally chain rtp muxers have the "rtpflags" field that allows passing such options on (which is how this worked before 8034130e), so this works just as intended. This makes it possible to produce H263 in RFC2190 format with chained RTP muxers. CC: libav-stable@libav.org Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Not sure if this actually happens, but we do the same check when checking payload_type further above in the function, so it might be needed. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This fixes encoding where the idct setting originally was set to FF_IDCT_AUTO and dsputil chose a default idct with a non-null permutation - even if the permutation tables were updated, dct_quantize in x86/mpegvideoenc_template.c also checked the value of this type variable. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This fixes crashes with muxing H263 into RTSP. CC: libav-stable@libav.org Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 23 1月, 2013 22 次提交
-
-
由 Xi Wang 提交于
The check `start + res < start' is broken since pointer overflow is undefined behavior in C. Many compilers such as gcc/clang optimize away this check. Use `res > end - start' instead. Also change `res' to unsigned int to avoid signed left-shift overflow. Signed-off-by: NXi Wang <xi.wang@gmail.com> Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Xi Wang 提交于
A negative `size' will bypass FFMIN(). In the subsequent memcpy() call, `size' will be considered as a large positive value, leading to a buffer overflow. Change the type of `size' to unsigned int to avoid buffer overflow, and simplify overflow checks accordingly. Also change a literal buffer size to use sizeof, and limit the amount of data copied in another memcpy call as well. Signed-off-by: NXi Wang <xi.wang@gmail.com> Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Xi Wang 提交于
Sanity checks like `data + size >= data_end || data + size < data' are broken, because `data + size < data' assumes pointer overflow, which is undefined behavior in C. Many compilers such as gcc/clang optimize such checks away. Use `size < 0 || size >= data_end - data' instead. Signed-off-by: NXi Wang <xi.wang@gmail.com> Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This makes sure that the restrict keyword is mapped to whatever keyword the compiler prefers/supports. This fixes building on MSVC (and possibly on GCC 2.x as well). Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Ronald S. Bultje 提交于
-
由 Ronald S. Bultje 提交于
These are never used.
-
由 Ronald S. Bultje 提交于
-
由 Ronald S. Bultje 提交于
This is never used.
-
由 Diego Biurrun 提交于
It does not help as an abstraction and adds dsputil dependencies. Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com>
-
由 Ronald S. Bultje 提交于
-
由 Ronald S. Bultje 提交于
The input is not guaranteed to be aligned.
-
由 Tim Walker 提交于
Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com>
-
由 Tim Walker 提交于
Also wrap usage of AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives. Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com>
-
由 Tim Walker 提交于
Allows users to configure the output based on what's actually decoded, rather than the full native layout. Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com>
-
由 Tim Walker 提交于
Fixes bug 401. Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com> CC:libav-stable@libav.org
-
由 Tim Walker 提交于
Fixes bug 208. Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com> CC:libav-stable@libav.org
-
由 Tim Walker 提交于
Also stop storing the channel arrangement in the header info, as it's unused outside of ff_mlp_read_major_sync. Signed-off-by: NJustin Ruggles <justin.ruggles@gmail.com> CC:libav-stable@libav.org
-
由 Diego Biurrun 提交于
-
由 Ronald S. Bultje 提交于
This makes the aac decoder and all voice codecs independent of dsputil.
-
由 Ronald S. Bultje 提交于
This makes wmadec/enc, twinvq and mpegaudiodec (i.e. mp2/mp3) independent of dsputil.
-
由 Ronald S. Bultje 提交于
Now, nellymoserenc and aacenc no longer depends on dsputil. Independent of this patch, wmaprodec also does not depend on dsputil, so I removed it from there also.
-
由 Ronald S. Bultje 提交于
-
- 22 1月, 2013 6 次提交
-
-
由 Michael Smith 提交于
Set interlaced to false if we don't have an interlaced frame Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>
-
由 Ronald S. Bultje 提交于
The function is only used in VP3 and VP5, so no need to have it in DSPContext.
-
由 Diego Biurrun 提交于
CC: libav-stable@libav.org
-
由 Martin Storsjö 提交于
Expose the current sequence number via an AVOption - this can be used both for setting the initial sequence number, or for querying the current number. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Luca Barbato 提交于
This reverts commit ce378f0d.
-
由 Diego Biurrun 提交于
Signed-off-by: NDiego Biurrun <diego@biurrun.de>
-