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>
* commit 'ef51692a49d58963966adca55c62da9c34c3c7e1':
Revert "w32pthread: help compiler figure out undeeded code"
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4332bf98dc051fd1ffbd9d4ddc1c5e55790c96f1':
w32threads: Don't use function pointers when linking directly to newer APIs
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '310cc4bf82824f09bdd0b9147ed725cdbeaf9bdd':
smoothstreamingenc: Write to a temp file while updating the manifest
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4622f11f9c.
The compiler should be able to do the dead code elimination now
without this when the cond_* names point directly to the real
functions instead of to local function pointers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the call overhead slightly. More noticeably, it
restores the earlier (unintended?) feature that condition variable
functions work just fine even if w32thread_init() hasn't been called.
This was broken as a side effect of 4622f11f9, if explicitly targeting
Vista+.
This makes w32threading work in VP8 again, if targeting Vista+.
Signed-off-by: Martin Storsjö <martin@martin.st>
If a client tries to read the file while it's being updated, the client
would get an incomplete manifest. Instead write to a separate temp file
and atomically rename it to replace the previous one.
Signed-off-by: Martin Storsjö <martin@martin.st>
programs using ffmpeg that are compiled with -Wshorten-64-to-32
gives a warning when using header files common.h and rational.h
cast 64-bit truncated values to (uint32_t) to avoid the warning
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The element was only being written when the value == 1. But the default
value of this element is 1, so this has no useful effect. This element
needs to be written when the value == 0.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '2bbad1f94cbc5eab0aa2d937bc79d085477d0242':
movenc: Properly free allocated data on failures in mov_write_header
Conflicts:
libavformat/movenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
