Use the correct timebase, also replace "stream" with "format" in the
context of the format.

Reduces diff for the next merge with Libav.

This is again will help the merge as ff_h264_decode_sei will not have
access to H264Context anymore.

This will simplify the next Libav merge where SEI decoding doesn't have
access to the debug level anymore.

We still only support one single layer though, but this allows
receiving streams that have this structure present even for
single layer streams.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

unimplemented features
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes mis-detection of tiff as mpegts
Fixes Ticket5565
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Docs clearly states that av_write_trailer should only be called if
avformat_write_header was successful, therefore we have to deinit if we return
failure.
Signed-off-by: Marton Balint <cus@passwd.hu>

Fixes ticket #5554.
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Marton Balint <cus@passwd.hu>

When checking pix_fmt mapping, some bitstreams are mapped to an
incorrect pix_fmt instead of being rejected (ENOSYS).
Actually, such bitstreams are not supported (FFmpeg encoder does not
produce such bitstream, such bitstream may come only from another
encoder for the moment).

- JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg
pix_fmt (e.g. bgr0), which is not expected.
- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a
FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with
alpha), which is not expected.

The order for choosing the pix_fmt is changed to the one used by YCbCr
selection (<=8 bit first).
" && !f->transparency" is added to the other lines.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

recognize title= album= artist= genre= track=
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This fixes a API regression
Probably fixes Ticket5451
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

this allow a filter to be written like this:
aformat =
    sample_fmts  = fltp|flt:
    sample_rates = 44100|44800
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

give high quality resampling
as good as with linear_interp=on
as fast as without linear_interp=on
tested visually with ffplay
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000:linear_interp=on, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000:exact_rational=on, showcqt=gamma=5"

slightly speed improvement
for fair comparison with -cpuflags 0
audio.wav is ~ 1 hour 44100 stereo 16bit wav file
ffmpeg -i audio.wav -af aresample=osr=48000 -f null -
        old         new
real    13.498s     13.121s
user    13.364s     12.987s
sys      0.131s      0.129s

linear_interp=on
        old         new
real    23.035s     23.050s
user    22.907s     22.917s
sys      0.119s     0.125s

exact_rational=on
real    12.418s
user    12.298s
sys      0.114s

possibility to decrease memory usage if soft compensation is ignored
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Fixes #819 #5256 #5281
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes Ticket5585
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit 'c8dcff0c':
  h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>

* commit '113aeee6':
  h264_parser: move the H264DSPContext to the parser context

H264Context is kept locally as it is currently needed for logging
(h->avctx as log context) and for is_avc and nal_length_size. These
later fields will later be obtained when the extradata parsing is
decoupled from the decoder. This code will be updated accordingly when
that commit is merged.
Merged-by: Clément Bœsch <u@pkh.me>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>