If max in clean_index is set to a negative ast->sample_size, the
following loop never ends:
while (max < 1024)
max += max;
Thus set ast->sample_size to 0 if it would otherwise be negative.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If bit_rate is negative, it can trigger an av_assert2 in av_rescale_rnd.
Since av_rescale returns int64_t, but st->codec_bit_rate is int, it can
also overflow into a negative value.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes a segmentation fault.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
index_scale is set to matroska->time_scale of type uint64_t.
When index_scale is int, the assignment can overflow and e.g. result
in index_scale = 0. This causes a floating point exception due to the
division by index_scale.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix a duplicate memory allocation. priv_data should be allocated
in line 64 call to avformat_alloc_output_context2 since we pass
the correct AVFormat to it. This removes the duplicate allocation.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Use dyn_duf to write chunks so that we create the actual chunk
file only after the entire chunk data is available. This will help
not confuse other software looking at the chunk file (e.g. a web
server) by seeing a zero length file when ffmpeg is writing into
it.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes Detecting AAC with such descriptor if the parts needed for detection
are later in the stream
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '82de8d71118f4eafd6a43e9ea9169bd411793798':
mpegts: Update the PSI/SI table only if the version change
Conflicts:
libavformat/mpegts.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The existing check has two problems:
1) i + count can overflow, so that the check '< 256' returns true.
2) In the (i == 'N') case occurs a j-- so that the loop runs once more.
This can trigger the assertion 'nut->header_len[0] == 0' or cause
segmentation faults or infinite hangs.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If a PAT is finished while a PMT section filter is opened but
not yet finished, the PMT section filter is closed and all
the received data is discarded.
This is usually not an issue but some multiplexers (With very
quick PAT/PMT repetition settings) consistently emit a PMT
section start, then a PAT, and then the rest of the PMT,
causing the aforementioned behavior to result in no PMT being
finished.
In the most pathologic situation the stream information are lost
and the probe fallback miscategorizes subtitles as mp3 audio.
Avoid the issue through eliminating redundant PSI/SI table
updates by checking their version field, which is required by
the standard to be incremented on every change no matter how
minor.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A negative frame rate triggers an av_assert2 in av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Check extended sync word for 16-bit LE and BE core streams to reduce
probability of alias sync detection. Previously sync word extension was
checked only for 14-bit streams.
This follows up the similar change in avcodec/dca_parser.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Remove the direct profile from UTCTiming element. Per DASH spec,
direct profile value should be the time at which the request was
made to the server and not the time at which the manifest was
written. So ffmpeg cannot write this value. This patch removes
the direct profile and write the UTCTiming element with the http
profile only if a URL is passed as a parameter. Update the fate
test to reflect this change.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix a bug where the chunk muxer doesn't write the very first audio
packet (with pts == 0).
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b90adb0aba073f9c1b4abca852119947393ced4c':
rtsp: Make sure we don't write too many transport entries into a fixed-size array
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If the file size is much larger than what is indicated in the XING
header, the demuxer assumes it's a concatenated file, and throws away
the (presumably) incorrect duration information. Unfortunately, this
also triggers if the id3 tags are very large (embedded pictures and
such). Then the half-baked heuristic not only breaks the duration
display, but also gapless audio.
Fix it by subtracting the size of the headers (the check is off by some
bytes, but that doesn't matter at all). Note that there could be an
arbitrary amount of tags _after_ the mp3 data, but hopefully these are
not too large to trigger the heuristic in practice.
Also add a warning when this happens.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While I'm not sure why exactly sure why the old code could end up in the
wrong position, using the generic index code is much simpler and is
known to work correctly.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes the calculation of the number of needed blocks to make
sure that ALL pixels are represented by the result.
Signed-off-by: Martin Storsjö <martin@martin.st>
This removes the error logging added in 4e54432164.
This avoids warnings about "Invalid interval start specification 'now'"
for live rtsp streams.
We only try to parse some of the many valid values for time ranges
in RTSP - the other ones are fully valid but not interesting for the
use case in rtsp.c, so we shouldn't warn about them.
(Parsing the time ranges is needed to allow seeking, but e.g. setting
the current realtime clock for the start time doesn't make sense.
av_parse_time has got a different mode for parsing absolute times
as well, which can handle the special case "now", but that doesn't
make much sense for this particular use in rtsp.c.)
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes a NULL pointer dereference if vst->duration is 0.
The problem was introduced in commit 0588acaf.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It's the most useful mode, because it seeks accurately, and does not
break features like gapless audio.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
"-usetoc 2" now invokes the generic seek and indexing mode. This mode
skips data until the seek target is reached, and this is exact. It also
makes gapless audio actually work if a seek past the start of the file
is involved.
Change the fate-gapless-mp3 test to use the new mode, and move the old
one to fate-gapless-mp3-toc (since the test forces use of the Xing TOC).
The new mode has a different result for the seek - this result is
actually correct.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The mp2 seek test results change. Whether to skip samples if the file
had no LAME gapless tags was inconsistent. When seeking to the start
of the file, 529 samples were skipped, but when playing from start,
nothing was skipped. This commit changes the behavior on seek to skip
nothing.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some players do not support setting minimumUpdatePeriod to zero.
This patch adds a new parameter that will let the users set any
value to this field. Also updates the test and the documentation.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
DASH spec requires the presence of either duration of the period
or the minimumUpdatePeriod element. This patch adds the
minimumUpdatePeriod element hardcoded with the value 0 as the
manifest will never be updated for WebM DASH Live streams. Also
updating the fate test reference file.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Using the PRIu8 format specifier to print an enum value causes a
compiler warning, so use %d instead.
Fixes ticket #4467.
Signed-off-by: Chris Watkins <watk@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this the returned timestamp should match the packet instead of
the requested timestamp, which may lay between packets
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd34039b171bebe37bf723a1b03e5651267099739':
rmenc: Drop the temporary buffer for ac3 byteswap
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2cc3936599b6fc63143036659653d1be0624360f':
dashenc: Add a publishTime field in dynamic manifests
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9286de045968ad456d4e752651eec22de5e89060':
mov: Double-check that alias path is not an absolute path
Conflicts:
libavformat/mov.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
nlvl_to and nlvl_from can be set to 1 if both alias and target files
are in the same directory, so actually check the first character of the
string. We can do this because MacOS filepaths (alis type 2) are always
converted to UNIX filepaths (alis type 18).
Absolute paths can be stored in alis type 2 and 18 according to my research:
the first is the canonical MacOS filepath, with path level separated by
colons, and the volume name within the filepath, while the second should be the
absolute filesystem path from the mount point.
This avoids waiting for a count to increase which will always be 0 and may
reduce the startup delay for affected streams (rare)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Apparently, some live streams can delete segments too early, maybe
because the client is too far behind. In this case, it's better to skip
the segment, instead of returning EOF. (Yes, the HLS demuxer actually
returns AVERROR_EOF if opening the segment returns a 404 HTTP error.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '247aa7af7d8197247c181e3fbfe8d93d75e41b29':
avisynth: Simplify shared library name construction
Conflicts:
libavformat/avisynth.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Removing a bunch of questionable hacks makes it work. These hacks
apparently try to make concatenated mp3s with Lame headers seekable,
which doesn't make too much sense anyway. The main change is that we
trust the Xing header file size field now (the same field is used for
seeking with Xing TOC). Note that a mp3 might contain an unknown number
of unsupported additional tags, so we can't reliably compute this size
manually.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Return appropriate error codes and propagate the error codes from
helper functions to the outer calls. Also fix a potential leak in
call to av_realloc.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
VP80 fourcc are writed for all contexts (without ctx->codec_tag)
how to reproduce the issue:
1) Get any vp9 video (for example http://base-n.de/webm/out9.webm)
2) ffmpeg -i out9.webm -vcodec copy out9.ivf
3) out9.ivf have VP80 fourcc at ivf header
The proposed fix solves this issue
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Replace an unchecked av_malloc call with stack allocation as the size
is always a constant.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In order to safely exit when the user tries to use AviSynth 2.5, the
continue_on_fail value for 2.6's functions need to be set to 1.
Otherwise, the library loader fails before the 'upgrade to 2.6'
log message appears.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
txoffer (e.g. http://tori.aoi-chan.com/ ) redirects to the same URI on your
first request, and serves the actual file on the second. It's stupid, but AFAIK
technically compliant. We'd previously see the server not handing back a Range
header and return an error; now, instead, we see that there's a redirect and
keep track of the offset we want while trying again at the new URL.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this patch http can be used to listen for POST data to be used as an input stream.
Signed-off-by: Stephan Holljes <klaxa1337@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes the calculation of the number of needed blocks to make
sure that ALL pixels are represented by the result.
Reviewed-by: Thomas Volkert <silvo@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'be089af38f65dc8b1fe3564f98020fc815577edb':
mov: Rely on box type rather than file type for colr atom
Conflicts:
libavformat/mov.c
See: 0276b95242
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Although it's not allowed to use only allows 'nclc' in ISOM files, there
are samples that do not always respect this rule. This change prevents
atom overread and a spurious color range initialization.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
MicroDVD has a "hack" for specifying the video framerate the subtitle
was authored against. The demuxer reads this hint correctly, but didn't
skip it correctly.
This was not noticed, because the exported packet has its duration set
to 0, making it invisible (depending on the API user's rendering logic).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.
Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.
Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
MSVC does not support the %F and %T format specifiers in strftime.
Replace that with the expanded version. This fixes the broken fate
tests in MSVC (webm-dash-manifest-*).
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for WebM Live Muxing by adding a new WebM
Chunk muxer. It writes out live WebM Chunks which can be used for
playback using Live DASH Clients.
Please see muxers.texi for sample usage.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for creating DASH manifests for WebM Live
Streams. It also updates the documentation and adds a fate test to
verify the behavior of the new muxer flag.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for parsing live files (produced by
-f webm_chunk) which contains only the headers but no packets. This
is only used when using -f webm_dash_manifest. There will be a
follow up patch which adds live support to WebM DASH Manifest
muxer.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.
Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.
Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.
Fixes trac #4423.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7d097a0fc57f0fa8385962a539c657c2f40b5ed0':
mpegtsenc: Take max_delay into account when buffering multiple audio packets into one PES packet
Conflicts:
libavformat/mpegtsenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
I found another MXF File containing ProRes with the following
codec_uls: 060E2B34040101010E04020102110500
Therefor I relaxed the pattern.
Related to issue #4349
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Make sure we don't buffer up more than max_delay worth of data
before writing a PES packet, even if pes_payload_size is set to
a larger value.
Signed-off-by: Martin Storsjö <martin@martin.st>
The AVSC_API changes in the new headers mean that the 2.6 alphas
are just as incompatible as 2.5 is.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In order to safely exit when the user tries to use AviSynth 2.5,
the continue_on_fail value for 2.6's functions need to be set to
1. Otherwise, the library loader fails before the 'upgrade to
2.6' log message appears.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Additionally, update some documentation with support for APNG
Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8c9c5479c4ba729b4ba868ab541a90b2061a7c2f':
rtp: Add an option to set the send/receive buffer size
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3c47e7c4350f73fc77d8e76f0dd6d2946b13c5cc':
rtp: Map the urloptions to AVOptions
Conflicts:
libavformat/rtpproto.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4978850ca2cb1ec6908f5bc79cc592ca454d11e8':
build: Split JPEG-related tables off into a separate component
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously unset, and some software mishandles files if it is absent
Signed-off-by: Tim Nicholson <tim.nicholson@bbc.co.uk>
Reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This prevents sub-muxers from trying to seek back to the beginning of the
whole stream, only to find themselves overwriting some video data in the
current (often last) segment.
We only do this when not writing individual header/trailers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This permits some interesting segmenting techniques with formats like Matroska,
where you can concatenate the header and segments [N, nb_segments) and get
a working file that starts at segment N's start time.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
API allows protocol implementations to provide API that
allows to list directory content.
API is similar to POSIX opendir/readdir/closedir.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the user attempts to use AviSynth 2.5, an error message will
now tell them they need to upgrade.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes ticket #4387.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Note, Vittorio Giovara had submitted a very similar fix to me privately
a few hours before this, iam applying Jochens because it comes with a
commit message too and i had not yet applied Vittorios, but For sake
of credit, Vittorio independently solved this first
* commit 'a8c99205ca8703bd849efae13fcf844315c7147d':
avisynth: Fix compilation against current 2.6 header(s).
Merged-by: Michael Niedermayer <michaelni@gmx.at>
AviSynth 2.6 (and by extension, AviSynth+) moves these functions
into AVSC_API. This requires both adjusting their normal use,
and for AvxSynth, adjusting the position/use of the USING_AVISYNTH
ifdefs.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'e4fe535d12f4f30df2dd672e30304af112a5a827':
mov: Write the display matrix in order
Conflicts:
libavformat/mov.c
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This will allow to copy the matrix as is and it is just cleaner to keep
the matrix in the same order specified by the mov standard (which is
also explicitly described in the documentation).
In order to preserve compatibility, flip the angle sign in the display API
av_display_rotation_set() and av_display_rotation_get(), and improve the
documentation mentioning the rotation direction.
* commit 'e0046bc9c96150fa06146ace9093f06857dd7b23':
movenc: Write the make and model metadata keys for mov style files
Conflicts:
libavformat/movenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These are essential allowing QuickTime to keep detecting content
as slow-motion - this allows preserving them on stream copy.
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit has no known use case ATM as there are no unsupported video codecs in flv and could
theoretically be use to generate broken files allthough that would be not entirely easy as
tags/codecs still get sanity checked
This reverts commit 76f4b11780.
This allows stream copying video codecs before they are explicitly
supported. The same feature was in the past useful for audio codecs
in flv
This partly reverts the changes from 735ab7c5e0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '67a2912307c3c08f2725ccae162cfe3426b80184':
movenc: Don't assume that fragment durations in pts is equal to duration in dts
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5c337353a2546416631a87de4881850d99141c39':
movenc: Move sidx edit list timestamp adjustment into a block
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'eee13d653953083553cceadbbedf6222ef78a006':
movenc: Only adjust the cts offset at the start of fragments if necessary
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b81b0cc22b22413760423e239ea644c9afdbfa2d':
movenc: Set the last packet duration based on the next packet when autoflushing
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3041183677bda0a431b36e96a2c76617abaa8183':
dashenc: Heuristically fill in the duration of packets that need it
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2889c5e16711770437f380f1bead5f72c6a0b17a':
movenc: Heuristically set the duration of the last sample in a fragment if not set
Merged-by: Michael Niedermayer <michaelni@gmx.at>
For strict CFR, they should be pretty much equal, but if the stream
is VFR, there can be a sometimes significant difference.
Calculate the pts duration separately, used in sidx atoms and for
tfrf/tfxd boxes in smooth streaming ismv files.
Also make sure to reduce the duration of sidx entries according to
edit lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
Adjusting it is only necessary when a sidx/tfrf/tfxd atom already has
been written for the previous fragment (since the sidx/tfrf/tfxd atoms
include the duration between the first pts of the previous fragment, to
the first pts of the new fragment).
Signed-off-by: Martin Storsjö <martin@martin.st>
When automatically flushing fragments based on set conditions
(fragmentation on keyframes, after some interval or byte size),
we already have the next packet for one stream - use this for setting
the duration of the last packet in the flushed fragment correctly.
This avoids having to adjust the timestamp of the first packet in
the new fragment since the last duration was unknown.
Unfortunately, this only works for automatic flushing (not for
caller-triggered flushing, like in the dash muxer), and only for the
one single track that triggered the flushing. The duration of the
last sample in all other tracks still is dependent on AVPacket
duration (or heuristics).
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids that the mp4 muxer does a similar heuristic, adjusting
the timestamps in a way that the dash muxer doesn't know the actual
timestamps written to the file in the end. By making sure that the
mp4 muxer internal heuristic isn't applied, we know the exact
timestamps written to file, so that the timestamps in manifest match
the files.
Signed-off-by: Martin Storsjö <martin@martin.st>
Even if this is a guess, it is way better than writing a zero duration
of the last sample in a fragment (because if the duration is zero,
the first sample of the next fragment will have the same timestamp
as the last sample in the previous one).
Since we normally don't require libavformat muxer users to set
the duration field in AVPacket, we probably can't strictly require
it here either, so don't log this as a strict warning, only as info.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add a missing AVClass member, check whether localaddr is null.
(Previously, localaddr was always a local stack buffer, while it
now also can be an avoption string which can be null.)
This fixes crashes when not passing any localaddr parameter, since
66028b7ba.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes a crash, when trying to mux h264 into mxf_opatom.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Previous version reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cehoyos/master:
lavf/mkv: Ignore ff_isom_write_hvcc() return value as the mov muxer does.
lavc/dts: Do not set bitrate for DTS-HD Master and High Resolution.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a slightly different
position than if the file would have been read sequentially.
This makes implementing certain operations, such as segmenting,
quite hard, and slower than need be.
Therefore, add an option which retains the same packet sequence
after seeking, as when a file is demuxed linearly.
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a slightly different
position than if the file would have been read sequentially.
This makes implementing certain operations, such as segmenting,
quite hard, and slower than need be.
Therefore, add an option which retains the same packet sequence
after seeking, as when a file is demuxed linearly.
* commit '4326bc364b58e97fc3d89417054a6b7610179a00':
lavf: Do not list mov-only codecs in riff tags
Conflicts:
libavformat/Makefile
libavformat/avidec.c
See: 2e0b5f5c90
Merged-by: Michael Niedermayer <michaelni@gmx.at>
