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.
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>
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.
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: Umair Khan <omerjerk@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
The original code left-shifts negative values, which is undefined
in the C99 specification (the one used during normal Libav compilation).
This change multiplies by (1 << shift), which is functionally equivalent,
but has defined behavior.
With this change, fate-idct8x8 compiled with --fsanitize=undefined works.
Bug-Id: 686
