The configure detection is bumped to X265_BUILD >= 68,
since API version 68 corresponds with the x265 1.8
release tarball. The warnings inside x265 about
12-bit being experimental were removed prior to API
version 72 a short time later.  At this time of
writing, X265_BUILD is at version 80.

12-bit support in the HEVC standard was approved in
October 2014 as part of HEVC Version 2 and published
in January 2015:

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296
http://www.itu.int/rec/T-REC-H.265-201410-S
https://hevc.hhi.fraunhofer.de/rextReveiwed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The index creation is O(N^2) with number of entries (typically thousands).
On a Pi this can take more than 60 seconds to execute for a recording of a few hours.

By replacing with an O(N) loop, this takes virtually zero time
Liked-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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

This was broken in 243df135.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Remove all files and functions which are not going to be reused,
and disable all functions and FATE tests temporarily which will be.

Since timecode_frame)start is a private option now, it stays at the default,
and is no longer written to the file.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '243df135':
  lavc: Move {min,max}_prediction_order to codec private options
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '936f0d98':
  lavc: Move rtp_payload_size to codec private options
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit 'd7496153':
  lavc: Move timecode_frame_start to codec private options
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

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

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

avformat/format: Weight the filename extension higher if there is nearly no data after an ID3 available

Fixes Ticket5205

Based-on-patch-by: Carl Eugen Hoyos
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This makes the code much more readable
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Decodes YUV 4:2:2 10-bit and RGB 12-bit files.
Older files with more subbands, skips, Bayer, alpha not supported.
Alpha requires addition of GBRAP12 pixel format.

Fixes a theoretical issue if the resolution attribute is written
behind the aspect attribute.

The rightmost column is not decoded correctly.

Fixes a part of ticket #5195.

4:2:2 and 4:4:4 support in the HEVC standard was approved in
October 2014 as part of HEVC Version 2 and published in
January 2015:

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296
http://www.itu.int/rec/T-REC-H.265-201410-S
https://hevc.hhi.fraunhofer.de/rextReviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The internal encoder is superior to libvo-aacenc.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>

TODO: bump minor

It's inferior in quality to fdk-aac and has an arguably more problematic
license.

As early as 2012, a HydrogenAudio user reported:

> It has however one huge advantage: much better quality at low bitrates than
> faac and libaacplus.

(https://hydrogenaud.io/index.php?PHPSESSID=ckiq394pdglka0kj2fin6ij8t7&topic=95989.msg804633#msg804633)

I myself have made a few spectrograms for a comparison of the two
encoders as well. The FDK output is consistently better than the
libaacplus one, in all bitrates I tested.

libaacplus license is 3GPP + LGPLv2. 3GPP copyright notice is completely
proprietory, as follows:

> No part may be reproduced except as authorized by written permission.
>
> The copyright and the foregoing restriction extend to reproduction in
> all media.
>
> © 2008, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
>
> All rights reserved.

(The latest 26410-d00 zip from 3GPP has the same notice, but the copyright
year is changed to 2015)

The copyright part of the FDK AAC license (section 2) is a copyleft
license that permits redistribution under certain conditions (and
therefore the LGPL + libfdk-aac combination is not prohibited by
configure):

> Redistribution and use in source and binary forms, with or without
> modification, are permitted without payment of copyright license fees
> provided that you satisfy the following conditions:
>
> You must retain the complete text of this software license in
> redistributions of the FDK AAC Codec or your modifications thereto in
> source code form.
>
> You must retain the complete text of this software license in the
> documentation and/or other materials provided with redistributions of
> the FDK AAC Codec or your modifications thereto in binary form.
>
> You must make available free of charge copies of the complete source
> code of the FDK AAC Codec and your modifications thereto to recipients
> of copies in binary form.
>
> The name of Fraunhofer may not be used to endorse or promote products
> derived from this library without prior written permission.
>
> You may not charge copyright license fees for anyone to use, copy or
> distribute the FDK AAC Codec software or your modifications thereto.
>
> Your modified versions of the FDK AAC Codec must carry prominent
> notices stating that you changed the software and the date of any
> change. For modified versions of the FDK AAC Codec, the term
> "Fraunhofer FDK AAC Codec Library for Android" must be replaced by the
> term "Third-Party Modified Version of the Fraunhofer FDK AAC Codec
> Library for Android."

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>