- 12 Jan, 2017 1 commit
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
- 11 Jan, 2017 9 commits
-
-
Martin Vignali authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Zhengxu authored
Reason: For some cases, such as 2 or more graphics cards existing, the default command line may fail because ffmpeg does not open the correct device node: ffmpeg -hwaccel qsv -c:v h264_qsv -i test.264 -c:v h264_qsv out.264 Let user choose the proper one by running like below: ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv \ -i test.264 -c:v h264_qsv out.264 Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com> Signed-off-by: Huang, Zhengxu <zhengxu.maxwell@gmail.com> Signed-off-by: Andrew, Zhang <huazh407@gmail.com> Signed-off-by: Mark Thompson <sw@jkqxz.net>
-
Carl Eugen Hoyos authored
Fixes ticket #6072.
-
Derek Buitenhuis authored
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
Steinar H. Gunderson authored
This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9), including correct decoding of the alpha channel. 1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell), about evenly split between bitstream reader and IDCT. There is currently no attempt at slice or frame threading, even though the format trivially supports both. NewTek very helpfully provided a full set of SHQ samples, as well as source code for an SHQ2 encoder (not included) and assistance with understanding some details of the format.
-
Steinar H. Gunderson authored
Allows more codecs than mpeg12video to make use of it.
-
Paul B Mahol authored
Mainly useful for supporting decoding of headerless files. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Steven Liu authored
CID: 1324298 add a label when error goto the label to release resource Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
- 10 Jan, 2017 5 commits
-
-
Martin Vignali authored
Fixes ticket #6044 Based on patch by Carl Eugen Hoyos
-
Carl Eugen Hoyos authored
This is what gimp, ImageMagick and FreeImage do and what the Adobe Photoshop file format specification suggests. Fixes a sample from ticket #6045. Reviewed-by: Martin Vignali
-
Steven Liu authored
when the segments largest duration value is look like 4.000000, the EXT-X-TARGETDURATION value should equ 4. it's wrong when hlsenc use ceil, so fix it. Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
Steven Liu authored
problem fix ticket: #6067 Tested-by: Pero Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
Steven Liu authored
cid: 1396268 when av_strdup(str) error, the lst need release Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
- 09 Jan, 2017 7 commits
-
-
Michael Niedermayer authored
This should make no difference as the value should not be able to be that large but its more correct this way Fixes CID1348138 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Lou Logan authored
Default is "bicubic". Signed-off-by: Lou Logan <lou@lrcd.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Henrik Gramner authored
When allocating stack space with an alignment requirement that is larger than the current stack alignment we need to store a copy of the original stack pointer in order to be able to restore it later. If we chose to use another register for this purpose we should not pick eax/rax since it can be overwritten as a return value.
-
Wang Bin authored
clock_gettime is avalible since macOS 10.12 and iOS 10.0. Because of weak linking, clock_gettime can be build without error with new macOS/iOS sdk, but the symbol may not exist on the target system. Explicitly checking the symbol is required. https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.htmlSigned-off-by: Wang Bin <wbsecg1@gmail.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
Jun Zhao authored
Disable B frames when using baseline/constrained baseline profile, following H.264 spec Annex A.2.1. Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Yi A Wang <yi.a.wang@intel.com> Signed-off-by: Mark Thompson <sw@jkqxz.net>
-
- 08 Jan, 2017 4 commits
-
-
Paul B Mahol authored
The only thing we can do at such point is return samples unchanged. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Michael Niedermayer authored
Negate null check Fixes CID1396248 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes CID1396849 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Tobias Stoeckmann authored
When the command line for children is created, it is assumed that my_program_name always ends with "ffserver", which doesn't have to be true if ffserver is called through a symbolic link. In such a case, it could be that not enough space for "ffmpeg" is available at the end, leading to a buffer overflow. One example would be: $ ln -s /usr/bin/ffserver ~/f; ~/f As this is only a local buffer overflow, i.e. is based on a weird program call, this has NO security impact. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 07 Jan, 2017 5 commits
-
-
Paul B Mahol authored
Newer version of encoder can create such files. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
foo86 authored
Fixes ticket #6063. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
softworkz authored
The following three commits created a regression by writing initially invalid mkv headers: 650e17d8 avformat/matroskaenc: write a CRC32 element on Tags 3bcadf82 avformat/matroskaenc: write a CRC32 element on Info ee888cfb avformat/matroskaenc: postpone writing the Tracks master Symptoms: - You can no longer playback a file that is still processed by ffmpeg, e.g. VLC fails playback - You can no longer stream a file to a client while if is still being processed - Various diagnosing tools show header errors or incomplete headers (e.g. ffprobe, mediainfo, mkvalidator) Note: The symptoms do not apply to completed files or ffmpeg runs that were interrupted with 'q' Cause: The mentioned commits made changes in a way that some header elements are only partially written in mkv_write_header, leaving the header in an invalid state. Only in mkv_write_trailer, these elements are finished correctly, but that does only occur at the end of the process. Regression: Before these commits were applied, mkv headers have always been valid, even before completion of ffmpeg. This has worked reliably over many versions of ffmpeg, to it was an obvious regression. Bugtracker: This issue has been recorded as #5977 which is resolved by this patch Patch: The patch adds a new function 'end_ebml_master_crc32_preliminary' that preliminarily finishes the ebml element without destroying the buffer. The buffer can be used to update the ebml element later during mkv_write_trailer. But most important: mkv_write_header finishes with a valid mkv header again. Signed-off-by: James Almer <jamrial@gmail.com>
-
Clément Bœsch authored
-
softworkz authored
This commit adds the avio_get_dyn_buf function which allows accessing the content of a DynBuffer without destroying it. This is required in matroskaenc for preliminary writing (correct) mkv headers. Context for this change is fixing regression bug #5977. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 06 Jan, 2017 6 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Andreas Cadhalpun authored
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
-
Kevin Wheatley authored
looks like there is a bug in commit 1a08758e relating to the handling of ptr in decode_frame after decode_block is called, before this commit ptr would have been incremented for each line in the data window, now after the commit it is left at the start of the first included line rather than the line after the data window then the code sets the remaining lines to 0 and thus the whole image is over written. Fix by adjusting ptr to the correct line after decode_block returns Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
-
Michael Niedermayer authored
Fixes CID1244189 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 05 Jan, 2017 3 commits
-
-
Steven Liu authored
CID: 1396257 Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
Rostislav Pehlivanov authored
This commit replaces the current inefficient non-power-of-two FFT with a much faster FFT based on the Prime Factor Algorithm. Although it is already much faster than the old algorithm without SIMD, the new algorithm makes use of the already very throughouly SIMD'd power of two FFT, which improves performance even more across all platforms which we have SIMD support for. Most of the work was done by Peter Barfuss, who passed the code to me to implement into the iMDCT and the current codebase. The code for a 5-point and 15-point FFT was derived from the previous implementation, although it was optimized and simplified, which will make its future SIMD easier. The 15-point FFT is currently using 6% of the current overall decoder overhead. The FFT can now easily be used as a forward transform by simply not multiplying the 5-point FFT's imaginary component by -1 (which comes from the fact that changing the complex exponential's angle by -1 also changes the output by that) and by multiplying the "theta" angle of the main exptab by -1. Hence the deliberately left multiplication by -1 at the end. FATE passes, and performance reports on other platforms/CPUs are welcome. Performance comparisons: iMDCT, PFA: 101127 decicycles in speed, 32765 runs, 3 skips iMDCT, Old: 211022 decicycles in speed, 32768 runs, 0 skips Standalone FFT, 300000 transforms of size 960: PFA Old FFT kiss_fft libfftw3f 3.659695s, 15.726912s, 13.300789s, 1.182222s Being only 3x slower than libfftw3f is a big achievement by itself. There appears to be something capping the performance in the iMDCT side of things, possibly during the pre-stage reindexing. However, it is certainly fast enough for now. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-
Rostislav Pehlivanov authored
Prep work for the next commit, which will add a new FFT algorithm which makes the iMDCT over 3x faster than it is currently (standalone, the FFT is with some framesizes over 10x faster). The new FFT algorithm uses the already thouroughly SIMD'd power of two FFT which already has SIMD for AArch64, so users of that platform will still see an improvement. The previous FFT+SIMD was barely 2.5x faster than the C versions on these platforms. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-