- 07 Mar, 2016 8 commits
-
-
Matthieu Bouron authored
-
Carl Eugen Hoyos authored
-
Carl Eugen Hoyos authored
If the original pix_fmt was >8 bit and not supported by the filter, the filter system could choose a pix_fmt with different endianness as input for extractplanes which broke the output because the output always used the endianness of the original pix_fmt.
-
Carl Eugen Hoyos authored
Needed for next commit.
-
Matthieu Bouron authored
-
Matthieu Bouron authored
-
Zhao Zhili authored
We cannot play multiple multicast streams with the same port at the same time. This is because both rtp and rtcp port are opened in read-write mode, so they will not bind to the multicast address. Try to make rtp port as read-only by default to solve this bug. Signed-off-by:
Zhao Zhili <wantlamy@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Raymond Hilseth authored
This fixes a problem where ffmpeg would hang if there is already an open data connection, and the server sends a 125 response code in reply to a STOR or RETR command. Signed-off-by:
Raymond Hilseth <rhi@vizrt.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 06 Mar, 2016 18 commits
-
-
Carl Eugen Hoyos authored
-
Carl Eugen Hoyos authored
Found-by: Clément Bœsch
-
Carl Eugen Hoyos authored
-
Carl Eugen Hoyos authored
-
Boris Nagels authored
RTCP synchronization packet was broken since commit in ffmpeg version > 2.8.3 (commit: e04b039b1528f4c7df5c2b93865651bfea168a19) Since this commit (2e814d03) "rtpenc: Simplify code by introducing a macro for rescaling NTP timestamps", NTP_TO_RTP_FORMAT uses av_rescale_rnd() function to add the data to the packet. This causes an overflow in the av_rescale_rnd() function and it will return INT64_MIN. Causing the NTP stamp in the RTCP packet to have an invalid value. Github: Closes #182 Reverting commit '2e814d03' solves the problem.
-
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>
-
foo86 authored
The first X96 channel set can have more channels than core, causing X96 decoding to be skipped. Clear the number of decoded X96 channels to zero in this rudimentary case. Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
erankor authored
Signed-off-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>
-
Kieran Kunhya authored
In this case container width/height is better however. Thanks to koda for the sample
-
Umair Khan authored
Signed-off-by:
Umair Khan <omerjerk@gmail.com> Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Reimar Döffinger authored
Makes it far easier to spot the issue if e.g. caused by a typo in the code table. Signed-off-by:
Reimar Döffinger <Reimar.Doeffinger@gmx.de>
-
Michael Niedermayer authored
Reviewed-by:
Reimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Reimar Döffinger authored
I cannot see any point whatsoever to use double here instead of float, the results are likely identical in all cases.. Using float allows for much more efficient use of SIMD. Signed-off-by:
Reimar Döffinger <Reimar.Doeffinger@gmx.de>
-
Muhammad Faiz authored
seems not useful Signed-off-by:
Muhammad Faiz <mfcc64@gmail.com>
-
Mark Harris authored
Use the context and level specified to av_pkt_dump_log2(), instead of panic level (0), for dumping packet payload. Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 05 Mar, 2016 11 commits
-
-
Michael Niedermayer authored
Signed-off-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>
-
Michael Niedermayer authored
avformat/avienc: assert that bits_per_coded_sample is within the supported range (out of array access otherwise) Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Mats Peterson authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Mats Peterson authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Clément Bœsch authored
Regression introduced in 29412821. Reported-by:
Michael Niedermayer <michael@niedermayer.cc>
-
James Almer authored
Fixes compilation of fft with hardcoded tables Reviewed-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
James Almer <jamrial@gmail.com>
-
Michael Niedermayer authored
Fixes: CID1355115 Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes CID1355116 Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 04 Mar, 2016 3 commits
-
-
Rostislav Pehlivanov authored
Signed-off-by:
Rostislav Pehlivanov <atomnuker@gmail.com>
-
Rostislav Pehlivanov authored
This was a leftover from before the slices were encoded in parallel. Since the put_bits context is initialized per slice aligning it aferwards is pointless. Signed-off-by:
Rostislav Pehlivanov <atomnuker@gmail.com>
-
Rostislav Pehlivanov authored
This commit solves most of the crashes and issues with the encoder and the bitrate setting. Now the encoder will always allocate the absolute lowest amount of memory regardless of what the bitrate has been set to. Therefore if a user inputs a very low bitrate the encoder will use the maximum possible quantization (basically zero out all coefficients), allocate a packet and encode it. There is no coupling between the bitrate and the allocation size and so no crashes because the buffer isn't large enough. The maximum quantizer was raised to the size of the table now to both keep the overshoot at ridiculous bitrates low and to improve quality with higher bit depths (since the coefficients grow larger per transform quantizing them to the same relative level requires larger quantization indices). Since the quantization index start follows the previous quantization index for that slice, the quantization step was reduced to a static 1 to improve performance. Previously with quant/5 the step was usually set to 0 upon start (and was later clipped to 1), that isn't a big change. As the step size increases so does the amount of bits leftover and so the redistribution algorithm has to iterate more and thus waste more time. Signed-off-by:
Rostislav Pehlivanov <atomnuker@gmail.com>
-