Previously, we required the minimum number of bytes required for
the full box. Don't strictly require the astronomical body and additional
notes fields, but do require an altitude field (which currently isn't
parsed). This matches the initial length check at the start of the function
(which doesn't know about the variable length place field).
Signed-off-by: Martin Storsjö <martin@martin.st>
This was missed in e1eb0fc9601, when ff_interleaved_peek was
changed to include const during the evolution of the patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
As long as caller only writes packets using av_interleaved_write_frame
with no manual flushing, this should allow us to always have accurate
durations at the end of fragments, since there should be at least
one queued packet in each stream (except for the stream where the
current packet is being written, but if the muxer itself does the
cutting of fragments, it also has info about the next packet for that
stream).
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.
In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.
When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.
This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.
One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use it to get stream duration, sample rate, channel count and initial padding
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Previously a partial log message without newline was printed in case of
loglevel=warning.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '0abb07bad7026a945a31ba4047e6583c8b3fa3da':
movenc: Update a comment to reflect how the code actually behaves
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '06edef3d5e072ef3c4face9ce946d2d9c36cc477':
Generate the lists of enabled protocols/bsfs from configure.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'd12b5b2f135aade4099f4b26b0fe678656158c13':
build: Split test programs off into separate files
Some conversions done by: James Almer <jamrial@gmail.com>
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When feeding input RTP packets to the depacketizer via custom IO,
it needs to pick the right stream using the payload type for
RTP packets, and using the SSRC for RTCP packets. If the first
packet is an RTCP packet, we don't (currently) know the SSRC
yet and thus can't pick the right RTP depacketizer to handle it.
By parsing the SSRC attribute in the SDP, we can map initial
RTCP packets to the right stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
It doesn't matter what the actual reason for not returning
an AVPacket was - if we didn't return any packet and we have
the next one queued, parse it immediately. (rtp_parse_queued_packet
always consumes a queued packet if one exists, so there's no risk
for infinite loops.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Leaking this private structure opens up the possibility that it may
be re-used when parsing later packets in the stream. This is
problematic if the later packets are not the same codec type (e.g.
private allocated during Vorbis parsing, but later packets are Opus
and the private is assumed to be the oggopus_private type in
opus_header()).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Larger values would imply file durations of astronomic proportions and cause
overflows
Fixes integer overflow
Fixes: usan_int64_overflow
Found-by: Thomas Guilbert <tguilbert@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'e3453fd44480d903338c663238bf280215dd9a07':
matroska: Write the field order information
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
