* commit '4b7f1a7ced0e98f2cc698d896f7ebab8d30eaa09':
mlp: Parse TrueHD decoder channel modifiers and set the AVMatrixEncoding for each substream.
Conflicts:
libavcodec/mlp_parser.h
libavcodec/mlpdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '30d70e79a6b4ac7f4eb66446a9da275161ef6ea7':
dcadec: set AV_FRAME_DATA_MATRIXENCODING side data.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6bfdb2de881372048be7fbda643417e1fd3ce93c':
dcadec: set the output channel mode more accurately.
Conflicts:
libavcodec/dcadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5b4797a21db900b7d509660b7a4d49829089b004':
avframe: add AV_FRAME_DATA_MATRIXENCODING side data type.
Conflicts:
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5c437fb':
lavu: Add values for various Dolby flags to the AVMatrixEncoding enum.
Conflicts:
doc/APIchanges
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The stream time_base has been changed to be a multiple of the
device sample_rate. Now the frame_duration computation is simpler
and a message will warn about problematic frame_size values.
Signed-off-by: Federico Simoncelli <fsimonce@redhat.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When downmixing 2.1 to 2-channel, if the 2.0 portion is Lt/Rt, sum-difference or dual mono, the actual output will be the same (with the LFE either mixed-in or discarded).
Also, when downmixing an arbitrary layout to 2-channel, if the bitstream contains custom downmix coefficients targeting Lt/Rt, then the output will be Lt/Rt rather than regular Stereo.
Setting the v4l2 device parameters may influence video properties
such as width, height and pixel format.
This patch moves v4l2_set_parameters to be executed before fetching
the video properties, avoiding errors such as (pal vs ntsc):
The v4l2 frame is 829440 bytes, but 691200 bytes are expected
Signed-off-by: Federico Simoncelli <fsimonce@redhat.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
New versions of FreeType have moved the location of their API
header(s) and hide the location behind a macro.
Since the location changes between versions and no other way
to know the location exists, this workaround becomes necessary.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This occurs for video codecs that have codec_tag set, but are are not listed
in ff_codec_bmp_tags (e.g. AV_CODEC_ID_BINKAUDIO, AV_CODEC_ID_IFF_ILBM).
Fixes ticket #3269.
Signed-off-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9d18a7d3ec09d6d933d648570643fde924aa391a':
fate: Update AAC ELD 5.1 ref for recent bugfixes.
also reenable fate-aac-er_ad6000np_44_ep0, as this commit updates the pcm
reference, so that the test works again
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b2212dec0f011893ec68eecaa990170fa24050d7':
aac: Fix TNS decoding for the 512 sample window family.
also temporarily disable fate-aac-er_ad6000np_44_ep0 as this commit
causes a mismatch with the reference pcm file
The test will be reenabled after all fixes and with a new pcm reference
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also drop confusing ff* tools reference about exceptions to the
file:FILENAME syntax, which is not ff* tool specific.
With various edits by Alexander Strasser <eclipse7@gmx.net>.
Handle the URL analog to file_open, it may contain a "file:"
prefix. Skip it. Make access checks to file URLs starting
with "file:" work.
Fix part of ticket #3249.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Fix timestamp calculation for code 3 Ogg Opus packets with less than
2 bytes in the last segment (e.g. packet length 255 or 256).
A sample that would seek incorrectly in ffplay can be created with:
ffmpeg -i in.wav -b:a 34k -vbr off -frame_duration 60 out.opus
and libopus 1.1
Also do not read past the end of the buffer when a packet has length 0.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This only updates the case where there is no B frame reordering delay.
Tested-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to http://doc.iridas.com/index.php?title=LUT_Formats
for 3D textures, the data is also RGB, and ordered in such a way
that the red coordinate changes fastest, then the green coordinate,
and finally, the blue coordinate changes slowest:
Fixes Ticket #3236.
Its usefull to know immediatly if extradata is wrong and not just when later
the decoder tries to use it.
This check was removed by: a6a2282c25
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
