(cherry picked from commit 11ef9fc9e0f3bb1f8f9fc8f07df1fc0294492126)

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
(cherry picked from commit f2ade2268d923cb2d9e686fb1981b6a5abb596af)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 5dc03a473a53ae3c5ac1bbf2186c94b519d2df51)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 0216518011fc4b80f2dc43b12c922013cef7fd61)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit f26e6eaf58cd0332a1e746fb0fc709c7815a3eae)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
(cherry picked from commit 2f3d2d96b82b4eea9a17861b3da294457d1b4896)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

WinCreateMsgQueue() changes FPU cw but does not restore it. This causes
SIGFPE later.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
(cherry picked from commit c35f6c1be0c06204a7b9787695cfa1150c5e5f90)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 362b0da80fd10ea976e570b92297691cb387a8f6)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 19b9baa2b03af847ab0afc91e78c3ccd3e538cb4)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

A deadlock could occur in an high load situation where the vout and
the decoder are taking excessive amounts of time.

The vout thread repeatedly call ThreadDisplayPicture in its main loop
until it returns an error, while keeping the picture pool locked. If
no picture was recently received, the vout will redisplay the current
picture (a "refresh") by calling ThreadDisplayRenderPicture with
is_forced=true. If this refresh is excessively long, the vout thread
will be stuck in a refresh loop. The decoder cannot make any progress
since the picture pool lock is hold and the vout won't be polling for
control commands, yielding a total deadlock of the program.

This situation can be reproduced artificially by sleeping in the
decoder and decreasing variable VOUT_REDISPLAY_DELAY.

A simple solution to this issue is to exit the ThreadDisplayPicture
loop after refreshing. Since a refresh typically occurs when no new
pictures are received from the decoder, this should not decrease
performance.

(cherry picked from commit 22c80ce310c58f6730291b4026af9c7c8b38fb63)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

VDPAU introduces a delay of one field (one picture if not deinterlacing).
This is normally not an issue as the PTS is preserved. But it does not
work if there is only one picture not followed by another one.

(cherry picked from commit 6e82ebed93d6f017af4369d8712f7063421ee9ca)

Conflicts:
	modules/hw/vdpau/chroma.c

(cherry picked from commit dd6170364ffa7a6cc2248f2ef8b1f98e25f95589)

(cherry picked from commit 7df464879acb66d7a0a19905e3d48b7e6b5fcf33)

Conflicts:
	src/input/decoder.c

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
(cherry picked from commit f1cfcbfd8f76d4197f66802944e926f848d8dfaf)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit db67b0a660b57141f53f6aec1bc9f427e0f129e4)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 5b58faa2468f0699c6e6f402ea03f489f4360441)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 8f6f849be5322de77a5acc0a6d8e1fe978000573)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit d2c6b81287fc01b5afea049a87b9280f5cb59522)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit d450f9bb8abc35f5e87065c56631109ddc173c0e)

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit 6cccd64dacf431e1c33877e131b09ff906c85972)

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit d47e80b68fe5331dc02e535cf9e5b3e3a52dfca5)

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit a868b9e580a2ec98ec4a13ba5a2cf463821af337)

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit c53f31a51223a9d8c0c6e07b5d705d7a096dc963)

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit 7459d06cca4cd0fa29eec101001628d34549c6d1)

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>
(cherry picked from commit 9ef8db17fda567a43d6e8febd5cd0f6ec79757a0)

All black-syle panels should get the floating window level.
This is normal behaviour of panels and has the positive side effect
that the panel also stays in front while vout window reconfigurations.

This level is also used for the preferences window, as this is sort
of a modal window which needs to be closed (in order to get settings
saved).

close #12063

(cherry picked from commit 081cba9ccc60b60f5f22a8a5be3895147eb0a709)
Signed-off-by: David Fuhrmann <dfuhrmann@videolan.org>

This reverts commit 93900cd7 because it breaks the API behavior 3 months after a feature freeze without providing a proper solution or work-around. This code path will be reworked for 3.0.

(cherry picked from commit 08c15c3f4c2b16dfe8189458a8bac17221e43f97)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 1ec8c36705246b191053b6ebec1491c121cf521a)
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Switch the layout activity to true before actually displaying the layout. This
gives controls a chance to reinitialize before any real drawing occurs, and
thus a clean animation gets displayed without any unwanted stray image.

This fixes trac #12083

(cherry picked from commit 1ce3c5d673ba7a71f3db5cf7f1d11ee906f92d39)
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

If down or over images are missing, they default to the up image. Yet, in case
of animated images, the animation gets played leading to undesirable artefacts.

This patch adds a comparison operator for animated images and do not restart the
animation if they are alike.

(cherry picked from commit 1c101b97678e5e7a34a062916b24fe0b9366a316)
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

(cherry picked from commit d32f040df7c85f9331cf5f5aa6438a84e2ad8360)

(cherry picked from commit c8803e34fe597809dd5b558e0cdcc811c0cc41fd)

(cherry picked from commit c5f806f480c9eda637b741d29c11b1b00e2a6f06)

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
(cherry picked from commit 26e73f0ff54f6f65519443679748c75d437f03ba)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>
(cherry picked from commit 52897c9020a3b8044d77866605068509924a585c)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 0ff2de0533d1197d2dc2f17ad9093cc7b9541402)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fix AAC-LC playback with QT 10.3 (727.4)

(cherry picked from commit 08f8853b60ad68629b14aabea1595047ef7a3288)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 407756f250d57b50b6bd20be74c7247c94ce3a3f)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

A crash could occur in the following situation:
1) A video decoder is created and starts waiting for the first picture:
   b_waiting = true, b_first = true

2) The first picture is received but the decoder is still in waiting mode:
   b_waiting = true, b_first = false

3) A second picture is received, the decoder is now waiting in
DecoderWaitUnblock().

4) From the input thread, an EOF event is received, EsOutChangePosition is
called and sets the decoder in flushing mode.

5) The decoder thread wakes up and exits DecoderWaitUnblock because
b_flushing is true. However this triggers the assertion in
DecoderDecodeVideo since we have b_waiting && !b_first.

Fix #11892, #12041

(cherry picked from commit a1603d9e69629a8168f5babce3388307bb677341)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>