Fixes Ticket5319
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9ac154d1facd4756db6918f866dccf3e3ffb698c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(cherry picked from commit 38797a8033d061ade58b30b8ac86da222fe42a84)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(cherry picked from commit 9149e9c0baaec122bc3da925d6068dffa60b5427)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: mozilla bug 1266129
Found-by: Tyson Smith
Tested-by: Tyson Smith
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9f36ea57ae6eefb42432220feab0350494f4144c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sometimes video fails to decode if H.264 configuration changes mid stream.
The reason is that configuration parser assumes that nal_ref_idc is equal to 11b
while actually some codecs but 01b there. The H.264 spec is somewhat
vague about this but it looks like it allows any non-zero nal_ref_idc for sps/pps.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3a727606c474d3d0b9efa3c900294a84bdb5e331)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket4816
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d433623fba2b273491ff7dda401648e7d07e19fe)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, if the movie source filter is used and a seek_point is
specified on a file that has a negative start time, ffmpeg will fail.
An easy way to reproduce this is as follows:
$ ffmpeg -vsync passthrough -filter_complex 'color=d=10,setpts=PTS-1/TB' test.mp4
$ ffmpeg -filter_complex 'movie=filename=test.mp4:seek_point=2' -f null -
The problem is caused by checking for int64_t overflow the wrong way.
In general, to check whether a + b overflows, it is not enough to do:
a > INT64_MAX - b
because b might be negative; the correct way is:
b > 0 && > a > INT64_MAX - b
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1f9734f977f59bc0034096afbe8e43e40d93a5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes segfault
Fixes Ticket5333
Regression since bfc8a4dabe5a0154b31128b59dca575010176441
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8f2a1990c06df73cf58401c8ba193711eb8947e7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Credit for figuring this out goes to James Darnley.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
(cherry picked from commit 3ef10406e19663a78791ed1b38178fb00d4c7d88)
This is ~2x faster for y not an integer on Haswell+GCC, and should
generally be faster due to the fact that anyway powf essentially does
this under the hood. Made an inline function in lavu/internal.h for this
purpose.
Note that there are some accuracy differences, that should generally be
negligible. In particular, FATE still passes on this platform.
Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system 104% cpu 5.821 total
after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system 105% cpu 5.416 total
This is also faster than an alternative approach that pulls in powf, gets rid of
the crufty NaN checks and other special cases, exploits knowledge about the intervals, etc.
This of course does not exclude smarter approaches; just suggests that
there would need to be significant work on this front of lower utility than
searches for hotspots elsewhere.
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
(cherry picked from commit bccc81dfa08e6561df6ed37860e3a08f7d983825)
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: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
(cherry picked from commit b60dfae7af65c4c7d255ef599352f2c54964303d)
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>
(cherry picked from commit 0a04c2885f02f7db6b410b6d43d120e5eb48dc18)
It makes no sense whatsoever to do this at each function call; we
already have a table for this.
Yields a 2x improvement in find_min_book (x86-64, Haswell+GCC):
ffmpeg -i sin.flac -acodec aac -y sin.aac
find_min_book
old
605 decicycles in find_min_book, 8388453 runs, 155 skips.9x
606 decicycles in find_min_book,16776912 runs, 304 skips.9x
607 decicycles in find_min_book,33553819 runs, 613 skips.2x
607 decicycles in find_min_book,67107668 runs, 1196 skips.3x
607 decicycles in find_min_book,134215360 runs, 2368 skips3x
new
359 decicycles in find_min_book, 8388552 runs, 56 skips.3x
360 decicycles in find_min_book,16777112 runs, 104 skips.1x
361 decicycles in find_min_book,33554218 runs, 214 skips.4x
361 decicycles in find_min_book,67108381 runs, 483 skips.5x
361 decicycles in find_min_book,134216725 runs, 1003 skips5x
and more importantly a non-negligible speedup (~ 8%) to overall AAC encoding:
old:
ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_new.aac 6.82s user 0.03s system 104% cpu 6.565 total
new:
ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_old.aac 6.24s user 0.03s system 104% cpu 5.993 total
This also improves accuracy of the expression by ~ 2 ulp in some cases.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
(cherry picked from commit bd9c58756a50b52e495b748d6ea6b0aafe397c25)
Reviewed-by: maintainer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 0cd9ff4e3aa23318a855c21d60b1c9035b2b99d2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Original mail and my own followup on ffmpeg-user earlier today:
I have a device sending out a MJPEG/RTP stream on a low quality setting.
Decoding and displaying the video with libavformat results in a washed
out, low contrast, greyish image. Playing the same stream with VLC results
in proper color representation.
Screenshots for comparison:
http://zevv.nl/div/libav/shot-ffplay.jpghttp://zevv.nl/div/libav/shot-vlc.jpg
A pcap capture of a few seconds of video and SDP file for playing the
stream are available at
http://zevv.nl/div/libav/mjpeg.pcaphttp://zevv.nl/div/libav/mjpeg.sdp
I believe the problem might be in the calculation of the quantization
tables in the function create_default_qtables(), the attached patch
solves the issue for me.
The problem is that the argument 'q' is of the type uint8_t. According to the
JPEG standard, if 1 <= q <= 50, the scale factor 'S' should be 5000 / Q.
Because the create_default_qtables() reuses the variable 'q' to store the
result of this calculation, for small values of q < 19, q wil subsequently
overflow and give wrong results in the calculated quantization tables. The
patch below uses a new variable 'S' (same name as in RFC2435) with the proper
range to store the result of the division.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e3e6a2cff4af9542455d416faec4584d5e823d5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Simplifies code
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 50d017a28171177b89c367194ec8d02f963e7e9e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5287
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit efa98cdc2ff17a2f3b0ceb69e22864fd5bc433db)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5244
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 068026b0f7845e0f1850094d974f60d181480d64)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit fbec157ea08f61063847bbe0dba28525e6283ff5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5345
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 50ef7361cb5f78c94da2323f3bae86c6bbd618c8)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Rename luma table to delta table and change how it is used.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
(cherry picked from commit f8c34f4b8d62afad3f63cf3d9617d73735bef8c1)
(cherry picked from commit 73f3c8f73edf0a69502233b2c50fa9e7104f99ec)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b2ab3398f59ed18a565063584f961ff84484d699)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should theoretically improve the randomness slightly
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2540d884f3fd7cfac503e048112098967be2569a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Trying to make heads and tails out of DTS 6.1 I can across this typo.
I also noticed that this wiki page is incorrect or misleading, the
channel order for 6.1 given does not match the source code. At the
least it should be clarified that the layout given does not apply to
DTS. https://trac.ffmpeg.org/wiki/AudioChannelManipulation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 73d1398f0c4ce2de16790f46e05a79242137d153)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is safer, as a selected demuxer could still mean that it was auto-detected
by a user application
Reviewed-previously-by: Nicolas George <george@nsup.org>
Reviewed-previously-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 689211d5727231c3fe92762d224dbadebdbf4e30)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit de1de4932419d0fb49c9c23f62e68cdbe90d0ee3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
RTCP synchronization packet was broken since commit in ffmpeg version > 2.8.3
(commit: e04b039b1528f4c7df5c2b93865651bfea168a19) Since this commit (2e814d0329aded98c811d0502839618f08642685)
"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 '2e814d0329aded98c811d0502839618f08642685' solves the problem.
(cherry picked from commit 1109ed7973c7fd1e7001898adc4976590d862122)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
(cherry picked from commit db44b599805fdd96940cf2e5a336f872648bbda1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c78a7267175a3d1e07b88be42f949f95124925e3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: jamrial
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 554f6e930ce05a4c5449efcaae36bdafe2d9de74)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: ebd58db6-dc86-11e5-91c2-59daeddf50c7.jpg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c6f4720b8664e6e22eb5b3da6bb48ed5b113f746)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of Ticket5264
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 67e5bd0c501f7568fc8d93284d0f7eb40663ab06)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of Ticket5264
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit df36257a53561a51af969a6ea6319dd2579509b9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1ec7a703806049265991723a8826bd61555edef4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
