Rescale 1088-row videos to avoid showing trailing garbage.

Refs #11358.  1080i videos may present themselves as 1088 rows
(divisible by 16).  The HD-PVR in particular may contain garbage in
those last rows.  Specifically, the last two rows may form an annoying
green line.  We add a scaling pass to shift the bottom 4 rows (4 to be
on the safe side) off the bottom of the display area.
(cherry picked from commit 9d9de7b75d5354c9130526311a0c74d7172ebe6d)
Fix issues which sometimes prevente scheduling around live TV.

Backport of SHA1:b05ecd46 to fixes/0.26.

There are some cases where we don't attempt to schedule around live
TV.  This change cleans up the logic which determines when to do that
and fixes some of the bugs found in the process.

NB: the case where a user enters live TV immediately before a
recording is scheduled to start is still not handled gracefully.
Fixing that is a lot tougher and will likely mean involving the
scheduler in choosing which input to use for live TV.

Refs #11207
Revert "Temporary fix for #11159: Fix playback of HD-PVR recording"

This reverts commit 3c8d88ac55c2b2c1bc652076d7824529254829a4.

It breaks BBC-HD playback consistently.
Enable more ffmpeg logging at startup of playback.

Allow logging in avformat_find_stream_info() if
"-v libav --loglevel debug" is specified.
This proves useful for live TV debugging among others.
(cherry picked from commit ae0dcaf6dfbbef1ac0bcc0cec1c684262ea9ee5c)
Fix StatusBox to account for template recording rules.

Cherry-pick part of SHA1:22c5dbff from master.
Fix Live TV startup, particularly for analog PVR-xxx tuners.

At the start of playback, ffmpeg scans the start of the file for
stream info.  While reading packets, it uses ffio_limit() to truncate
packets during attempts to read past the size of the file.  The file
size is cached at the start of playback, and may be inordinately small
for live TV files, triggering a storm of packet truncation and failure
to start playback.  We fix this by faking a large file size for live
TV playback during the initial call to avformat_find_stream_info().
(cherry picked from commit 5758c2a1d8ce448fce51fd5af3ce1a95494a3408)
Merge branch 'fixes/0.26' of https://github.com/MythTV/mythtv into fixes/0.26
h264: Reset last_pocs in case of reference or frame number inconsistencies

This prevents faulty increasing of has_b_frames
Should fix Ticket 2062

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit c230af9bccc3cadb373f9007ba14fffb6c2acc75)
Signed-off-by: Jean-Yves Avenard <jyavenard@mythtv.org>
(cherry picked from commit 1c1076385f01619f0d0933f9f4fb8f5d1e80435b)

Conflicts:
	mythtv/external/FFmpeg/libavcodec/h264_refs.c
Improved cropping of the bottom 8 lines of 1088-line video.

Refs #11358.  Reverts 9d9de7b75d5354c9130526311a0c74d7172ebe6d and
cleans up the bottom 8 lines by applying a crop filter to the source.
This is tested for the XVideo output method.

The VDPAU output method does not use the standard filter mechanism,
but it works fine on 1088-line video until the h.264 parser thinks the
resolution has changed from 1080 to 1088 lines.  To compensate, we
don't acknowledge a resolution change when this happens.
(cherry picked from commit c0bc92822fe63221ad8fc5cf52a6e661b37b6f21)

Note: the hard-coding of 1088->1080 is not the best way to handle
this.  It will be cleaned up in Master.
Make the string "Record at any time on any channel" translatable in 0.26-fixes.
Update the Danish translation of mythfrontend.
Make sure forked process has stopped when deleting MythSystem

This forces a termination in a forked MythSystem process when the
MythSystem object is destroyed, preventing a situation where the private
internal object tries to access resources from the no-longer-existent
parent object.

Fixes #11412
(cherry picked from commit 9c51ad39a65eee7a3f985a127700fbc8473ffb4e)
Called methods against wrong object in destructor.

Refs #11412
(cherry picked from commit e1f14a5380886c6ddf95379341aa0f56481b7587)
Have mythtranscode report aac_latm
Fix h.264 frame/keyframe identification in the player.

If a NAL unit that determines a frame start appears as the last NAL
unit in the packet, then the frame start is not identified until the
start of the next packet.  If this new packet has its own NAL unit
that determines a frame start, and that NAL unit is not at the end of
the packet, then only one frame start would be counted rather than
two.  This is fixed by returning the total number of frame starts,
rather than a bool.

In theory, the same problem could exist in the recorder, but it
appears that the packets in the original recording may have some
trailing NAL units that are stripped by the ffmpeg libraries when
assembling the packet for the player, causing the situation not to
occur.
(cherry picked from commit 86c22ed3d5c522bcecb88ecacd58104fc0dd6d8d)
Bump binary version after cherry picking 86c22ed3d5c522bcecb88ecacd58104fc0dd6d8d
MythArchive: update the encoding profiles to work with the current mythffmpeg

Refs #11299.

Signed-off-by: Stuart Auchterlonie <stuarta@squashedfrog.net>

(cherry picked from 5a0e83a20e8f75612b86fb56039b7803a11afd1b)
MythArchive: update mythburn.py to work with the updated encoding profiles

Refs #11299.

Signed-off-by: Stuart Auchterlonie <stuarta@squashedfrog.net>

(cherry picked from a784b93f1d1c6edbc0b47ac578def5d3275171a8)
MythArchive: update mythburn.py to work with the new mpeg2video codec name

Refs #11299.

Signed-off-by: Stuart Auchterlonie <stuarta@squashedfrog.net>

(cherry picked from 13c3035d1fed13a37c42d872b1f8dafb2e6f556f)
Make comparisons consistent

Refs #11299