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>

Fixes ticket #5323.

Fixes ticket #5316.

Regression since 104f8ea8.

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>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Understanding the mips32r6 and mips64r6 ISAs in the configure script is
not enough. In order to have full support for MIPS R6 in FFmpeg we need
to be able to build it, and for that we need to make sure we don't use
incompatible assembler code which makes the build fail. Ifdefing the
offending code is sufficient to fix the problem.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Some (Solaris) systems apparently have an incompatible msghdr struct
breaking sctp protocol compilation.

Reported-by: mvelanka

Fixes ticket #4786.
Auto-detection seems difficult, patch mostly confirmed by
http://dvd-audio.sourceforge.net/spec/aob.shtml

Fixes decoding of the files from ticket #4535 visually.

Fixes ticket #4980.
Analyzed-by: kurosu and Hendrik
Reviewed-by: Ronald

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>

Approximately 11% faster transcoding from mp3 with
default settings.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

"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: Moritz Barsnick <barsnick@gmx.net>

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: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

for easier development

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

ffm_read_write_index returns a 64bit value,

Github: Closes #185

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

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.

Needed for next commit.

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>

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>

Found-by: Clément Bœsch