Align IEC 61937 length_code for DTS-HD so that
(length_code & 0xf) == 0x8. This is reportedly needed with some
receivers.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.
Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098f9)
Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This avoids the core substream extensions scan when the EXT_AUDIO_ID
field indicates no extensions or only unsupported extensions. The scan
is done only if the value of EXT_AUDIO_ID is unknown or indicates a
present XCh extension which we can decode.
Signed-off-by: Mans Rullgard <mans@mansr.com>
There is a check for HAVE_BIGENDIAN when outputting the IEC 61937
stream. On big-endian systems the payload data is not byteswapped,
causing in effect the outputted payload data to be in a different byte
order on big-endian than on little-endian systems.
However, the IEC 61937 preamble (and the final odd byte if present) is
always outputted in the same byte order. This means that on big-endian
systems the headers have a different byte order than the payload,
preventing useful use of the output.
Fix that by outputting the data in a format suitable for sending to an
audio device in S16LE format by default. Output as big-endian (S16BE)
is added as an AVOption. This makes the muxer output the same on all
archs by default.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
NASM versions older than 2.08 fail to build ffmpeg with several
"error: operation size not specified" errors but this is not caught in
configure.
Fix that by checking if "pextrd [eax], xmm0, 1" works in configure.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
DTS-HD HRA streams do not always have an XBR extension in the extension
substream. Instead they can have only XXCh and X96 extensions in
there and still be considered DTS-HD HRA.
This is also confirmed with Onkyo TX-SR607 receiver which recognizes
such a stream as HiRes Audio.
Signed-off-by: Mans Rullgard <mans@mansr.com>
wav. In that case, DTS can be transmitted through S/PDIF without
the IEC 61937 headers.
Patch by Anssi Hannula, anssi d hannula a iki d fi
Originally committed as revision 26160 to svn://svn.ffmpeg.org/ffmpeg/trunk
Noticed by CrystalP from XBMC.
Patch by Anssi Hannula, anssi d hannula a iki d fi
Originally committed as revision 26130 to svn://svn.ffmpeg.org/ffmpeg/trunk
This works at least for some people testing it.
Patch by Anssi Hannula, anssi d hannula a iki fi
Originally committed as revision 25834 to svn://svn.ffmpeg.org/ffmpeg/trunk
files spdif.h and spdif.c.
Patch by Anssi Hannula, anssi d hannula a iki d fi
Originally committed as revision 25715 to svn://svn.ffmpeg.org/ffmpeg/trunk
so that they work correctly even without pkgconfig's --static option.
patch by Anssi Hannula, anssi.hannula gmail com
Originally committed as revision 13514 to svn://svn.ffmpeg.org/ffmpeg/trunk
during static linking should be listed under Libs.private, not Libs.
patch by Anssi Hannula, anssi.hannula gmail com
Originally committed as revision 13067 to svn://svn.ffmpeg.org/ffmpeg/trunk
