a876585215 had the unintended side effect of returning AVERROR(ENOMEM)
when track->entry is zero, while the code intentionally wants to
continue in that case.
Signed-off-by: Martin Storsjö <martin@martin.st>
The mov muxer already supports picking up extradata that wasn't
present during the avformat_write_header call - we just need to
propagate it. Since the dash muxer uses delay_moov, we have time
up until the first segment is written to get extradata filled in.
Also update the codec description string when the extradata becomes
available.
Signed-off-by: Martin Storsjö <martin@martin.st>
SAMPLE-AES encryption is not commonly used yet, but without this patch
ffmpeg is thinking that the hls segments are not encrypted which
produces broken files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is used in adx_read_packet, which currently depends on the
decoder/parser setting this value between reading the file header and
demuxing the first packet.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The chunk size is limited to UINT16_MAX (written by avio_wb16), so make
sure that the packet size is not too large.
Such large frames need to be split into slices smaller than 64 kB, but
that is currently supported neither by the rv10/rv20 encoders nor the rm
muxer.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
As this is depricated it should not be on by default, it is only
supported for MOV containers, depends on avpriv_get_gamma_from_trc()
Enable by:
-movflags +write_gama
This will use the color_trc to supply a gamma value, if desired an
explicit value may be supplied using the -mov_gamma option supplying
a suitable floating point value, values <=1e-6 will not be written.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While the native jpeg2000 decoder can determine pixel format correctly
from the codestream, libopenjpeg wrapper cannot. To make sure that
the output is correct when using libopenjpeg to decode digital
cinema files, we do detection from the metadata included in the MXF
wrapper.
If the container has "JPEG 2000 Coding Parameters" metadata element
with Rsiz value set to one of digital cinema profiles, we can safely
assume that the given input file is DCI compliant, therefore the
pixel format should be XYZ.
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b72b212a4c43563f1b9fc3ce9a5ff91f89b857ac':
rdt: Use a separate variable to clarify the different value namespaces
Conflicts:
libavformat/rdt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c13ab42a0a3979b2c292b2315487f5f5e14ba26b':
rtpdec_qt: Use a local variable instead of RTP_FLAG_KEY
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The original flags variable contains rtpdec flags, while the
rmflags variable contains RM flag bits which have a completely
different definition.
Signed-off-by: Martin Storsjö <martin@martin.st>
The only case where RTP_FLAG_KEY actually is needed is
in RDT, where such a flag needs to be passed via the
rtpdec parse function's flags parameter.
Signed-off-by: Martin Storsjö <martin@martin.st>
Nothing in the framework nor in the rest of the depacketizer actually
uses this flag - the chained demuxer sets the keyframe flag properly on
demuxed packets already.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '25f613f8be3b51e4396b93cda131e4631ba54302':
dca: Move syncword definitions to a separate header
Conflicts:
libavcodec/dca_parser.c
libavformat/dtsdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1dc19729e92a96620000e09eba8e58cb458c9486':
rtpdec_asf: Don't free the payload context in the .close function
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes an oversight in 96084251, in a refactoring done on top
of Gilles' original patch.
Pointed out by Gilles Chanteperdrix.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes the duration field of the OpenDML master index "indx" chunk to
contain the number of samples instead of the number of packets for
(linear/PCM) audio streams.
This matches the OpenDML V1.02 standard text which states that the
duration field shall contain "time span in stream ticks".
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0af3b65880573aa9b3375362eaab4f84140c7dde':
asf: do not export XMP metadata by default
Conflicts:
libavformat/asfdec.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Similarly to what has been done for MOV, display XMP metadata only when
users explicitly require it.
The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of
edits and saves from the project file.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Next commit will revert the PTS seeking so this is not needed anymore
This reverts commit 38e641a060.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The chunk size is limited to 0xFFFF (written by avio_wb16), so make
sure that the packet size is not too large.
Such large frames need to be split into slices smaller than 64 kB, but
that is currently supported neither by the rv10/rv20 encoders nor the rm
muxer.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
See Ticket244
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4abfa387b8.
This commit broke playback of fragmented mp4 files with b-frames.
While investigating this, it turned out that the general framework
isn't ready for a PTS-based index yet. Revert this change until
a better thought out solution is in place.
Signed-off-by: Martin Storsjö <martin@martin.st>
Commit 96084251e5 introduced a change in
the parser implementation which broke it. Restore the original
implementation.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 26524e3581.
If we want the T.140 codec to have the AV_CODEC_ID_TEXT codec id,
its type needs to be AVMEDIA_TYPE_SUBTITLE, so, keep interpreting
the text media type as AVMEDIA_TYPE_SUBTITLE.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
