Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

This reverts commit e44073ca.

This reverts commit 4ab57cff.

This reverts commit f968ef92.

As previously discussed, the CrystalHD hardware treats some PAFF
clips different from others; even when input fields are always in
separate packets, the hardware might return a single fieldpair for
one clip and individual fields for another.

Given the bogus flags set by the hardware, it is impossible to
distinguish these two cases without knowing about the current
picture and the next one. The hardware can usually provide the
picture number of the next picture and when that is available,
we can detect the two cases.

When it is not available, we have to guess - and find out later
if we were right or wrong.

With this change, clips will play correctly unless they are PAFF
where individual fields are returned *and* no next picture number
is available. Generally speaking, the incorrect cases arise in
the first couple of seconds of a clip as the delay calibration takes
place. Once that's set, things work fine.

As previously discussed, the CrystalHD hardware returns exceptionally
useless information about interlaced h.264 content - to the extent
that it's not possible to distinguish MBAFF and PAFF content until
it's too late.

This change introduces use of the h264_parser to help bridge the
gap; it can indicate if the input data is PAFF fields or not.

With this clarity, some of heuristics can be removed from the code,
making this less convoluted.

Finally, I found an MBAFF clip that acts like non h.264 content so
I had to make allowances for that.

Note that I still cannot distinguish between two forms of PAFF,
where the hardware either returns individual fields or a field-pair.
It's not clear that there's even a spec relevant difference between
the two forms, as opposed to hardware ideosyncracies.

strtol could return negative values, leading to various error messages,
mainly "non-monotonically increasing dts".

Currently, only S16 quad, 5.1 and 7.1 are implemented.
Implementing support for other formats/layouts and capture should be
straightforward.

7.1 support by Carl Eugen Hoyos.

Provide a non-NULL AVFormatParameters structure to
av_open_input_file() in open_input_file().

This is required because otherwise av_open_input_file() will allocate
and use a new format context, discarding the options set in the
provided format context.

The function was only used in opt_sample_fmt() for listing the sample
formats. Move list_fmts() functionality directly into
opt_sample_fmt().

Als fix the warning:
ffmpeg.c: In function ‘opt_audio_sample_fmt’:
ffmpeg.c:2877: warning: passing argument 1 of ‘list_fmts’ from incompatible pointer type
cmdutils.h:163: note: expected ‘void (*)(char *, int,  int)’ but argument is of type ‘char * (*)(char *, int,  enum AVSampleFormat)’

* newdev/master:
  mov: set audio service type for AC-3 from bitstream mode in the 'dac3' atom.
  Get audio_service_type for AC-3 based on bitstream mode in the AC-3 parser and decoder, and vice-versa for the AC-3 encoder.
  Use audio_service_type to set stream disposition.
  Add APIchanges entry for audio_service_type.
  Add audio_service_type field to AVCodecContext for encoding and reporting of the service type in the audio bitstream.
  configure: in check_ld, place new -l flags before existing ones
  support @heading, @subheading, @subsubheading, and @subsubsection in texi2pod.pl
  doc: update build system documentation
  aacenc: indentation
  aacenc: fix the side calculation in search_for_ms
  vp8.c: rename EDGE_* to VP8_EDGE_*.

Conflicts:
	doc/APIchanges
	libavcodec/avcodec.h
	libavcodec/version.h
	libavcodec/vp8.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

and decoder, and vice-versa for the AC-3 encoder.

of the service type in the audio bitstream.

This fixes some library tests when --as-needed is in effect.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Avoids warnings due to pointlessly casting away const.

On Blu-ray colors are stored in the order YCrCb (and not YCbCr) as mentioned in the specifications:
see System Description Blu-ray Disc Read-Only Format, 9.14.4.2.2.1 Palette Definition Segment

When decoding a Blu-ray subtitle, the colors were incorrectly set.

On DVD and HD-DVD colors are stored in the order YCrCb (and not YCbCr) as mentioned in the specifications:
see DVD Specifications for Read-Only Disc / Part 3, 4.3 Program Chain Information (7) PGC_SP_PLT
see DVD Specifications for High Definition Disc, 5.2 Navigation for Standard Content (11) PGC_SDSP_PLT
see DVD Specifications for High Definition Disc, 5.2 Navigation for Standard Content (12) PGC_HDSP_PLT
see DVD Specifications for High Definition Disc, 5.5 Presentation Data (4) SET_COLOR2

When decoding a DVD or HD-DVD subtitle, the colors were incorrectly set.

The address recently changed from ffmpeg-user@mplayerhq.hu to
ffmpeg-user@ffmpeg.org.

The variable is not used when libavfilter is enabled.
Fix the warning:
ffmpeg.c: At top level:
ffmpeg.c:242: warning: ‘sws_flags’ defined but not used

texi2pod.pl

This reverts commit 98a7d560.
This has been implemented differently by aurel already

Split normal build system documentation and the fate one.

Document THREADS make variable and provide an introduction to fate.
Document DESTDIR make variable and add some generic targets.

* newdev/master:
  matroskadec: set default duration for simple block
  When building for MinGW32 disable strict ANSI compliancy.
  ARM: fix ff_apply_window_int16_neon() prototype
  configure: check for --as-needed support early
  ARM: NEON optimised apply_window_int16()
  ac3enc: NEON optimised shift functions
  ac3enc: NEON optimised ac3_max_msb_abs_int16 and ac3_exponent_min
  mpeg12.c: fix slice threading for mpeg2 field picture mode.
  ffmetadec.c: fix compiler warnings.
  configure: Don't explicitly disable ffplay or in/outdevices on dos
  configure: Remove the explicit disabling of ffserver
  configure: Add fork as a dependency to ffserver
Merged-by: Michael Niedermayer <michaelni@gmx.at>

    * ffmpeg-mt/master:
      Update todo.
      Draw edges in MPV_frame_end when encoding

    Conflicts:
        libavcodec/mpegvideo.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>