- 09 3月, 2016 9 次提交
-
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Reimar Döffinger 提交于
This ensures gcc does not create unnecessary loads or stores and possibly even does not vectorize the negation. Speeds up mp3 to aac transcoding with default settings by 10% when using "gcc (Debian 5.3.1-10) 5.3.1 20160224". Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>
-
由 Reimar Döffinger 提交于
Approximately 11% faster transcoding from mp3 with default settings. Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Shivraj Patil 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Shivraj Patil 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Moritz Barsnick 提交于
"Skipping 0 bytes of junk" is useless to the user, and essentially indicates a NOP. At 0 bytes, this message is now pushed back to the verbose log level. Signed-off-by: NMoritz Barsnick <barsnick@gmx.net>
-
- 08 3月, 2016 13 次提交
-
-
由 Moritz Barsnick 提交于
The change of bps from 0 doesn't contain any info useful to the user. This message is now at info log level only if the original value is !=0, otherwise pushed back to debug log level. The original value is displayed additionally. Signed-off-by: NMoritz Barsnick <barsnick@gmx.net> Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Mats Peterson 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Muhammad Faiz 提交于
for easier development Signed-off-by: NMuhammad Faiz <mfcc64@gmail.com>
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Lior Mualem 提交于
ffm_read_write_index returns a 64bit value, Github: Closes #185
-
由 Timo Rothenpieler 提交于
-
由 Lucas Cooper 提交于
Signed-off-by: NTimo Rothenpieler <timo@rothenpieler.org>
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Carl Eugen Hoyos 提交于
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Clément Bœsch 提交于
-
- 07 3月, 2016 18 次提交
-
-
由 Matthieu Bouron 提交于
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Clément Bœsch 提交于
Example found in the wild: 0:00:03:25.000 0:01:47:A legend is sung 0:01:50:Of when England was young 0:01:53:And knights|were brave and bold 0:01:59:The good king had died Reported-by: wm4
-
由 Matthieu Bouron 提交于
-
由 Carl Eugen Hoyos 提交于
-
由 Carl Eugen Hoyos 提交于
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 提交于
Needed for next commit.
-
由 Matthieu Bouron 提交于
-
由 Matthieu Bouron 提交于
-
由 Zhao Zhili 提交于
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: NZhao Zhili <wantlamy@gmail.com> Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Raymond Hilseth 提交于
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: NRaymond Hilseth <rhi@vizrt.com> Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Carl Eugen Hoyos 提交于
-
由 Carl Eugen Hoyos 提交于
Found-by: Clément Bœsch
-
由 Carl Eugen Hoyos 提交于
-
由 Carl Eugen Hoyos 提交于
-
由 Boris Nagels 提交于
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 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-
由 Paul B Mahol 提交于
Signed-off-by: NPaul B Mahol <onemda@gmail.com>
-