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>
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>
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>
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>
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.
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>
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>
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.
Set this field to TRUE if the audio component is to operate on
little-endian data, and FALSE otherwise.
However TRUE and FALSE are not defined. Since this flag is just a boolean,
interpret all values except for 0 as little endian.
Sample-Id: 64bit_FLOAT_Little_Endian.mov
Instead check for all mov code-points when demuxing avi
and print a warning if a video codec is found like this.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is incompatible with the omit_tfhd_offset flag (writing
position independent fragments with interleaving requires the
default_base_moof flag).
This makes the moof atoms slightly bigger, but can be better for
playback (improving locality of sample data in the mdat).
Signed-off-by: Martin Storsjö <martin@martin.st>
This is needed if all the data for one track isn't continuous
within the mdat. Normally we make sure all the data for one
track is continuous, but in new cases we will need to have
the samples interleaved.
Signed-off-by: Martin Storsjö <martin@martin.st>
In this case len is always at least 1, since it is checked against
RTP_VP9_DESC_REQUIRED_SIZE + 1 and then it is reduced by
RTP_VP9_DESC_REQUIRED_SIZE before entering the has_pic_id check.
Bug-Id: CID 1270811
This way, the caller doesn't need to coordinate setting the option
after the moov atom has been written. The downside is that it is
no longer possible to use the option for checking whether the moov
atom already has been written, but a caller is able to keep track
of that by other means anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous use of the mov->fragments field, for determining whether
written packets were part of the first fragment or not, didn't
work as intended when using the empty_moov flag.
Signed-off-by: Martin Storsjö <martin@martin.st>
By making sure we at each time only have one pointer set, either a
local variable or one in the context, we avoid potential double frees
in the cleanup routines. If chain->rtp_ctx is set, it is closed by
calling avformat_write_trailer, but that shouldn't be called unless
avformat_write_header succeeded.
This issue was pointed out by Andreas Cadhalpun.
Signed-off-by: Martin Storsjö <martin@martin.st>
In this case len is always at least 3, since it is checked against
RTP_HEVC_PAYLOAD_HEADER_SIZE + 1 before entering the switch block.
Bug-Id: CID 1238784
This avoids assuming that e.g. audio samples are marked as
sync samples.
This allows omitting the sample flags from trun, if the default
flags happen to be right for all the samples.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use correct context, reduce log level, don't assume it is a video stream,
and print the tag of the unknown stream.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
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>
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>
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>
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>
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>
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>
Instead check the timestamps while muxing, to avoid buffering a
too long timestamp range into one single packet.
This makes the AMR and AAC packetization slightly less efficient,
since we set a possibly unnecessarily high max_frames_per_packet.
(These packetizers end up doing a memmove of the TOC bytes if
sending a packet before max_frames_per_packet is achieved, and
we end up setting max_frames_per_packet to a value that should
be high enough for most uses.)
All packetizers that use max_frames_per_packet now set it either
to a default value, or to a value calculated based on other
parameters, so none of them rely on the previous default setting.
For iLBC, copy one frame at a time, to allow checking the timestamp
range for each of them - basically doing potentially multiple
loops to simplify the code instead of trying to calculate the
number of frames to buffer while honoring s1->max_delay.
This is in preparation for reducing the coupling between libavformat
and libavcodec, by not having the muxers use the encoder field
frame_size (which may not be available during e.g. stream copy).
Signed-off-by: Martin Storsjö <martin@martin.st>
Factorize out the s->num_frames check at the start of the if statements,
simplifying adding more alternative causes for sending the buffered
frames.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to jump to the defaultcase in the switch. Manually
override the stream time base back to 90 kHz for the few audio codecs
that don't use the sample rate as time base (mp2, mp3).
Signed-off-by: Martin Storsjö <martin@martin.st>
This doesn't fix any bug, but makes the code simpler for later
patches, and more straightforward to read as is.
Signed-off-by: Martin Storsjö <martin@martin.st>
After sending a fragmented frame, len (s->buf_ptr - s->buf) isn't
zero, while s->num_frames is zero as intended. Using s->num_frames
makes it work as intended, and is less convoluted than keeping track
of (resetting) s->buf_ptr.
This avoids sending stray data after sending a fragmented aac packet.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Don't prefix them ffio_url, which is misleading, sounding too
much like the urlprotocol layer (like ffurl_*).
Signed-off-by: Martin Storsjö <martin@martin.st>
Many of these functions were named foo_free_context, and since
the functions no longer should free the context itself, only
allocated elements within it, the previous naming was slightly
misleading.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is different from how it is handled in codecs/demuxers/muxers
though (where the close function isn't called if the open function
failed), but since the number of depacketizers that have an .init
function is quite limited, this is easy to change.
The main point is that if the init function failed, we shouldn't
try to use that depacketizer at all - this makes sure that the
parse function doesn't need to check for the things that were
initialized in the init function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it more consistent with depacketizers that don't have any
.free function at all, where the payload context is freed by the
surrounding framework. Always free the context in the surrounding
framework, having the individual depacketizers only free any data
they've specifically allocated themselves.
This is similar to how this works for demuxer/muxers/codecs - a
component shouldn't free the priv_data that the framework has
allocated for it.
Signed-off-by: Martin Storsjö <martin@martin.st>
They share a great deal of common structure; only a few minor
bits in the headers differ.
This also fixes an off-by-one in sending of the last fragment
of large HEVC nals (where it previously sent len+2 bytes, even
if it should have been len+RTP_HEVC_HEADERS_SIZE aka len+3).
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows getting rid of quite a bit of boilerplate in depacketizers.
The default value (initializing need_parsing to 0, aka
AVSTREAM_PARSE_NONE) is the same as it is initialized to by default
in AVStream.
Signed-off-by: Martin Storsjö <martin@martin.st>
When a client behind a NAT issues a pause command, and stay paused for a
long time, the router may stop the RTP/RTCP port redirection. Resend the
hole punching packets before each PLAY command to cause the router to
restart the port redirection in that case.
Move the existing code for sending the packets from the SETUP phase
to the PLAY phase.
Signed-off-by: Martin Storsjö <martin@martin.st>
When receiving an RTCP packet, the difference between the last RTCP
timestamp and the base timestamp may be negative. As these timestamps
are of the uint32_t type, the result becomes a large integer. Cast
the difference to int32_t to avoid this issue.
The result of this issue is very large start times for RTSP
streams, and difficulty to restart correctly after a pause.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
If src_len is too small for nal_size, we already print a warning
above, and the next step is to check the while loop condition
anyway, so this one serves no purpose.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, errors were only logged but the code kept on trying,
and never actually returning the error as a return value.
Signed-off-by: Martin Storsjö <martin@martin.st>
Including libavcodec/get_bits.h is superfluous for AV_RB16 - nothing
in this file uses any actual bitstream reader.
Signed-off-by: Martin Storsjö <martin@martin.st>
