Note: Some of the previous patches have had two bugs that have been fixed
in this patch.
Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Our ac3 code chain can handle it fine.
More ideal would be to write a demuxer that actually extracts what can be from the additional
headers and uses it for whatever it can be used for.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* 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>
