* commit '82ee7d0dda0fec8cdb670f4e844bf5c2927ad9de':
Use gmtime_r instead of gmtime and localtime_r instead of localtime
Conflicts:
libavformat/mov.c
libavformat/mxfenc.c
libavformat/wtvdec.c
libavutil/parseutils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
gmtime isn't thread safe in general. In msvcrt (which lacks gmtime_r),
the buffer used by gmtime is thread specific though.
One call to localtime is left in avconv_opt.c, where thread safety
shouldn't matter (instead of making avconv depend on the libavutil
internal header).
Signed-off-by: Martin Storsjö <martin@martin.st>
None of these are likely unless the user is writing a file with two billion
streams or a duration of around two months.
CC: libav-stable@libav.org
Bug-Id: CID 700568 / CID 700569 / CID 700570 /
CID 700571 / CID 700572 / CID 700573
Approved-by: Tomas Härdin <tomas.hardin@codemill.se>
Approved-by: tim nicholson <nichot20@yahoo.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are interoperability issues with D-10 related to the channelcount property in the generic sound essence descriptor.
On one side, SMPTE 386M requires channel count to be 4 or 8, other values being prohibited.
The most widespread value is 8, which seems straightforward as it is the actual size of the allocated structure/disk space.
At the end, it appears that some vendors or workflows do require this descriptor to be 8, and otherwise just "fail".
On the other side, at least AVID and ffmpeg do write/set the channel count to the exact number of channels really "used",
usually 2 or 4, or any other value. And on the decoding side, ffmpeg (for example) make use of the channel count for probing
and only expose this limited number of audio streams
(which make sense but has strong impact on ffmpeg command line usage, output, and downstream workflow).
At the end, I find it pretty usefull to simply give ffmpeg the ability to force/set the channel count to any value the user wants.
(there are turnaround using complex filters, pans, amerge etc., but it is quite boring and requires the command line to be adapted to the input file properties)
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '194be1f43ea391eb986732707435176e579265aa':
lavf: switch to AVStream.time_base as the hint for the muxer timebase
Conflicts:
doc/APIchanges
libavformat/filmstripenc.c
libavformat/movenc.c
libavformat/mxfenc.c
libavformat/oggenc.c
libavformat/swf.h
libavformat/version.h
tests/ref/lavf/mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
* commit 'b3ea76624ad1baab0b6bcc13f3f856be2f958110':
vf_aspect: use the name 's' for the pointer to the private context
Remove commented-out debug #define cruft
Conflicts:
libavcodec/4xm.c
libavcodec/dvdsubdec.c
libavcodec/ituh263dec.c
libavcodec/mpeg12.c
libavfilter/avfilter.c
libavfilter/vf_aspect.c
libavfilter/vf_fieldorder.c
libavformat/rtmpproto.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a0d5ca4f0a8e2c34d784d503a12af6303424ac6a':
mxfenc: Use correct printf format specifier for int64_t
h264: Drop unused variable
Merged-by: Michael Niedermayer <michaelni@gmx.at>
None of these are likely unless the user is writing a file with two billion
streams or a duration of around two months.
This fixes CIDs 700568, 700569, 700570, 700571, 700572 and 700573.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The field is intended to overflow and have only its low 16bits stored.
This commit avoids the implicit truncation and clarifies that its
intended and not a bug
S326m section 7.6 ("Continuity count"):
> The continuity count word consists of 2 bytes allow-
> ing a number to be created by a modulo 65536
> counter (bits C15 to C0 in figure 7). The continuity
> count shall increment by 1 for each newly transmit-
> ted content package with the same SDTI source and
> destination addresses. The continuity count may
> be used to detect whether the content package
> sequence has been broken by an operation such as
> a routing switch.
Approved-by: Tjoppen
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3f7fd59d151a2773f0e2e93e56b6b13ec6e5334b':
avformat: fix typo in avformat_close_input
mp3enc: write Xing TOC
mp3enc: support MPEG-2 and MPEG-2.5 in Xing header.
mp3enc: downgrade some errors in writing Xing frame to warnings
lavf: flush the output AVIOContext in av_write_trailer().
lavf: cosmetics, reformat av_write_trailer().
avio: flush the internal buffer in avio_close()
Enhance doc on asyncts audiofilter
cmdutils: avoid setting data pointers to invalid values in alloc_buffer()
libavcodec: remove av_destruct_packet_nofree()
Conflicts:
libavcodec/avpacket.c
libavformat/mp3enc.c
libavformat/nutenc.c
libavformat/utils.c
libavformat/version.h
tests/ref/lavf/voc
tests/ref/lavf/voc_s16
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is consistent with stdio and is what we want to do in all cases.
Fixes a bug in the voc muxer which didn't flush in write_trailer()
previously. This is the cause of the change in the test results.
* qatar/master:
mpc8: return more meaningful error codes.
mpc: return more meaningful error codes.
wv,mpc8: don't return apetag data in packets.
rtmp: do not warn about receiving metadata packets
x86: h264dsp: Adjust YASM #ifdefs
x86: yadif: Mark mmxext optimizations as such
h264: convert loop filter strength dsp function to yasm.
Improve descriptiveness of a number of codec and container long names
Conflicts:
libavcodec/flvdec.c
libavcodec/libopenjpegdec.c
libavformat/apetag.c
libavformat/mp3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
After some internal talks it seems the code is similar to what is in FFmbc
by Baptiste Coudurier; Baptiste accepted to relicense the similiar chunks
from GPL to LGPL.
Some demuxers set a timecode in the format or streams metadata. The
muxers now make use of this metadata instead of a duplicated private
option.
This makes possible transparent copy of the timecode when transmuxing
and transcoding.
-timecode option for MPEG1/2 codec is also renamed to -gop_timecode. The
global ffmpeg -timecode option will set it anyway so no option change
visible for the user.
