It seems that (a lot of?) flv files does not correctly set PTS,
so ignore them, with luck the decoder (avcodec) will recreate
them.
 It might break some valid files, so report any regression.

(It needs the AVCodecContext::ticks_per_frame change).

It fixes a regression with interpolated timestamps for some
mpeg-I/II and for h264.

Force new not to throw. Also drop a separate declaration of a static function that's called exactly once, and mark it inline instead.

It is needed to ensure valid buffer alignment.

And don't ignore errors

You need a compiler.

Also use autoreconf where possible
And no need to reun automake after autoreconf

This reverts commit f001a156.

This is usually a good practice. Moreover compare to locking and unlocking the
potential overhead is really small.

Signed-off-by: JP Dinger <jpd@videolan.org>

Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

reset the current status item.
(cherry picked from commit 6d28f6de)
Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

It seems that avformat does not recover from a byteseek when it does not know a duration for the file. It continiously spits out data with pts values of AV_NOPTS_VALUE after the seek.

Tested with mxf_original_NOB_format.mxf

When we set the video track, we probably be wanting to change video-es vars instead of audio-es

contribs: Use GCC 4.2 instead of LLVM-GCC 4.2 to compile the 32bit contribs on Darwin like we already do for the 64bit ones

LLVM introduced to many runtime bugs for now. Updated bin package for x86_64 is already available, PPC and i386 will follow within the hour.