"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

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.

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

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

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>

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>

In this case container width/height is better however.
Thanks to koda for the sample

Signed-off-by: Umair Khan <omerjerk@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>

Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>