* commit '70dd8892bf00923af838756dfbb356a9b1e4e40d':
mpegvideo: Replace arch initialization ifdeffery by standard conditionals
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f61bece684d9685b07895508e6c1c733b5564ccf':
ppc: Add and use convenience macro to check for AltiVec availability
Conflicts:
libavcodec/ppc/dsputil_ppc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b78b10c4b78b696927f2801cf2d9f193b4eff28b':
avutil: Move internal CPU detection function declarations to private header
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '91d4cfb8127f1de6c4ad173a30fffe584700046d':
apedec: do not buffer decoded samples over AVPackets
Conflicts:
libavcodec/apedec.c
See: 77d89a5b16
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '84146963d23d76b09af633e97413cd97d9b3021e':
configure: x86: Fix handling of i686 and cpunop features
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cb8f70c96e14c1b4824ef23d21d78d10fc5a4b93':
vf_fps: use double constants for default/min/max for start_time
Conflicts:
libavfilter/vf_fps.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Only consume an AVPacket when all the samples have been read.
When the rate of samples output is limited (by the default value
of max_samples), consuming the first packet immediately will cause
timing problems:
- The first packet with PTS 0 will output 4608 samples and be
consumed entirely
- The second packet with PTS 64 will output the remaining samples
(typically, a lot, that's why max_samples exist) until the decoded
samples of the first packet have been exhausted, at which point the
samples of the second packet will be decoded and output when
av_decode_frame is called with the next packet).
That means there's a PTS jump since the first packet is 'decoded'
immediately, which can be seen with avplay or mplayer: the timing
jumps immediately to 6.2s (which is the size of a packet).
Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.ape
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
The i686 feature really is a CPU feature and should be handled as such.
The cpunop dependency on i686 should be expressed with a standard _deps
declaration instead of a manual test.
When streaming to limelight, the app name is either a full
"appname/subaccount" or "appname/_definst_". In the latter case,
the app name can be simplified into simply "appname", but the
authentication hashing assumes the /_definst_ still to be present.
Signed-off-by: Martin Storsjö <martin@martin.st>
When using AV_NOPTS_VALUE (which expands to INT64_C(0x8000000000000000))
as union initializer for a double field, the c99 converter needs to
interpret this constant when filling the union initializer, and it is
interpreted as a positive value.
When converting AV_NOPTS_VALUE to a double, MSVC 2010 ends up with
the same positive value as the c99 converter, while MSVC 2012 gets
a negative value.
This results in an infite loop in various FATE tests on MSVC 2012.
Signed-off-by: Martin Storsjö <martin@martin.st>
