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>

Unused since 1534ef87 / 3176217c.

* commit '3176217c':
  h264: decouple h264_ps from the h264 decoder

Main changes:

- a local GetBitContext is created for the various
  ff_h264_decode_seq_parameter_set() attempts

- just like the old code, remove_sps() is adjusted so it doesn't remove
  the pps.

  Fixes decode with Ticket #631
  http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
  but see next point as well.

- ff_h264_update_thread_context() is updated to work even when SPS
  isn't set as it breaks current skip_frame code. This makes sure we
  can still decode the sample from ticket #631 without the need for
  -flags2 +chunks. (Thanks to Michael)

- keep {sps,pps}_ref pointers that stay alive even when the active
  pps/sps get removed from the available lists (patch by michaelni with
  additionnal frees in ff_h264_free_context() from mateo)

- added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
  crashes with mpegts_with_dvbsubs.ts from Ticket #4074
  http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts

- in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
  called, the pps and sps from the local parser context are updated with
  the pps and sps from the used h264context. This fixes fate-flv-demux.

- in h264_slice.c, "PPS changed between slices" error is not triggered
  anymore in one condition as it makes fate-h264-xavc-4389 fails with
  THREADS=N (Thanks to Michael)
Merged-by: Clément Bœsch <clement@stupeflix.com>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes ticket #5620.

It is not always 8 but never different from the pix_fmt property.