Fixes ticket #4132.

Inspired from a patch by Michal Wazgird <mplayer@cyryl.net>

See https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2014-November/072772.html

Inspired by a patch from Michal Wazgird <mplayer@cyryl.net>

See https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2014-November/072772.html

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Also add a FATE test.
Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NLukasz Marek <lukasz.m.luki2@gmail.com>

Signed-off-by: NLukasz Marek <lukasz.m.luki2@gmail.com>

Signed-off-by: NLukasz Marek <lukasz.m.luki2@gmail.com>

Signed-off-by: NLukasz Marek <lukasz.m.luki2@gmail.com>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

* commit 'f856d9c2':
  dashenc: Don't require the stream bitrate to be known

Conflicts:
	libavformat/dashenc.c

See: 5f8fcdd4Merged-by: NMichael Niedermayer <michaelni@gmx.at>

* commit 'eec7f032':
  lavf: Remove a redundant include of sys/stat.h

Conflicts:
	libavformat/os_support.h

See: 49515cb8Merged-by: NMichael Niedermayer <michaelni@gmx.at>

* commit '4b68edd0':
  flvenc: Remove an unused variable

See: cc5f7315Merged-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Don't write any bitrate attribute if it isn't known. As long as one
doesn't want automatic bitrate switching, playback can work just
fine even if it isn't set.

If strict standard compliance is requested, this is still considered
an error, since the attribute is mandatory according to the spec.

Based on a patch by Rodger Combs.
Signed-off-by: NMartin Storsjö <martin@martin.st>

The same file already includes this header a few lines further
above.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Signed-off-by: NMartin Storsjö <martin@martin.st>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Not checked if its actually lossless
Fixes Ticket1847
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Fixes part of Ticket 2004
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Reviewed-by: NMarton Balint <cus@passwd.hu>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Found-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

As far as I can tell the value can never go outside
the int16_t type.
And especially the cost of the initialization is
reduced quite a bit by making it smaller.
Overall decoding speedup not measurable though.
Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

11674 -> 10877 decicycles on my Phenom II.
Overall speedup was unfortunately within measurement error.
Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NJames Almer <jamrial@gmail.com>
Reviewed-by: NBenoit Fouet <benoit.fouet@free.fr>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>