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>
"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>
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
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: e04b039b15) Since this commit (2e814d0329)
"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.
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>
Samples produced by Omneon (Harmonic) store external references with
paths ending with 0s. Such movs cannot be loaded properly since every
0 is converted to '/', to keep the same parsing code for dref type 2
and type 18: this makes the external reference point to a non-existing
direactory, rather than to the actual referenced file.
Add a brief trimming loop that drops all ending 0s before trying to
parse the external reference path.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Store the file duration in the same timebase it arrives (i.e.
milliseconds) and only convert it to the file duration units (100ns)
when it's actually written, thus simplifying some calculations. Also,
store the duration as unsigned, since it cannot be negative.
CC: libav-stable@libav.org
Bug-ID: CVE-2016-2326
Adding early support for a subset of the proposed colour elements
according to the latest version of spec:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=hIKLhMdgTMTEwUTeA4ct38h0tmE
I've left out elements for pix_fmt related things as there still
seems to be some discussion around these, and the max_cll/max_fall
are currently not propagated as there is not yet side data for them.
The new elements are exposed under strict experimental mode.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This can be used for formats which write all format metadata as string to
files, therefore non-standard creation times such as 'now' will be parsed.
The standardized creation time is UTC ISO 8601 with microsecond precision.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Luca Barbato
Michael Niedermayer
Carl Eugen Hoyos
Mats Peterson
Moritz Barsnick
Clément Bœsch
Zhao Zhili
Raymond Hilseth
Boris Nagels
erankor
Mark Harris
Vittorio Giovara
Anton Khirnov
Neil Birkbeck
Derek Buitenhuis
Paul B Mahol
Marton Balint
Andrew Shulgin