TLSv1 is compatible with SSLv3, so this doesn't change much
in terms of compatibility. By explicitly using TLSv1, OpenSSL
sends the server name indication (SNI) header, which we
already set using SSL_set_tlsext_host_name (earlier, this
didn't have any effect).
SNI allows servers to serve SSL content for different host
names with separate certificates on one single port (vhosts).
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
mpegaudiodec: Don't use a nonexistent log context for av_dlog
avformat: Accept the ISO8601 separate format as input, too
avformat: Interpret times in ff_iso8601_to_unix_time as UTC
avutil: Add av_timegm as a public function
cinepak: Add another special case so that it can handle the following file:
lagarith: add some RGBA decoding support
lagarith: Add correct line prediction for RGB
Conflicts:
doc/APIchanges
libavcodec/cinepak.c
libavutil/avutil.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
http://samples.mplayerhq.hu/V-codecs/CVID/bad_cinepak_frame_size.mov
This fix works around another work around which handles a different type
of odd Cinepak data.
Thanks to Matthew Hoops (clone2727 - gmail.com) for the sample and fix.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes the function accept the format of creation_time
as output by demuxers (e.g. the mov demuxer), making the
creation timestamp stay intact if transcoding.
Signed-off-by: Martin Storsjö <martin@martin.st>
This function is used in muxers for parsing the 'creation_time'
metadata key, for converting it to a time value.
This makes it match the behaviour of the exported 'creation_time'
metadata from demuxers, where it is in UTC, too.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is useful, since the normal timegm function isn't a standard
function (requiring _BSD_SOURCE or _SVID_SOURCE on glibc to
be visible, and not available on e.g. windows). The widely available
function mktime uses the local time zone, which requires ugly
workarounds to handle UTC time.
Signed-off-by: Martin Storsjö <martin@martin.st>
http://samples.mplayerhq.hu/V-codecs/CVID/bad_cinepak_frame_size.mov
This fix works around another work around which handles a different type
of odd Cinepak data.
Thanks to Matthew Hoops (clone2727 - gmail.com) for the sample and fix.
Signed-off-by: Martin Storsjö <martin@martin.st>
