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>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
This commit print as AV_LOG_VERBOSE the jitter buffer
size. It might be the default value or the value set by application.
Signed-off-by: Eloi BAIL <eloi.bail@savoirfairelinux.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit adds a warning trace when jitter buffer
is full. It helps to understand leading decoding issues.
Signed-off-by: Eloi BAIL <eloi.bail@savoirfairelinux.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit adds an error trace when jitter buffer
is full. It helps to understand leading decoding issues.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit print as AV_LOG_INFO the jitter buffer
size. It might be the default value or the value set by application.
Signed-off-by: Eloi BAIL <eloi.bail@savoirfairelinux.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes more sense than mapping to AV_CODEC_ID_SUBRIP. Nothing
indicates that a T.140 track contains subrip sub-titles.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
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: Michael Niedermayer <michaelni@gmx.at>
The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.
As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.
Signed-off-by: Martin Storsjö <martin@martin.st>
The ones left using av_gettime are NTP timestamps (for RTCP,
which is specified to send the actual current realtime clock
in RTCP SR packets), and the NUT muxer timestamper, which is
documented as using wallclock time.
Signed-off-by: Martin Storsjö <martin@martin.st>
The RFC spec draft only specifies the "H265" name - there is no
specification saying how to interpret "HEVC" (if such a packet
format is specified it could be an entirely different format).
Since this is a very new standard (still a draft), there is little
need for compatibility with existing, broken implementations. Therefore
remove the extra alias, to avoid the risk of encouraging incorrect
usage.
Intentionally keeping the ff_hevc_dynamic_handler name for the
handler, to use "hevc" consistently as name for the codec instead
of "h265" within the library internals as long as there only is one
single variant in actual use.
Signed-off-by: Martin Storsjö <martin@martin.st>
The warnings are false positives, older gcc versions (such as 4.5)
think the variables can be used uninitialized while they in
practice can't, while newer (4.6) gets it right.
Signed-off-by: Martin Storsjö <martin@martin.st>
Untested, due to lack of rtp stream with CSRCs, but the code as
is does not work with multiple CSRCs
Reviewed-by: Luca Abeni <lucabe72@email.it>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This only takes care of decrypting incoming packets; the outgoing
RTCP packets are not encrypted. This is enough for some use cases,
and signalling crypto keys for use with outgoing RTCP packets
doesn't fit as simply into the API. If the SDP demuxer is hooked
up with custom IO, the return packets can be encrypted e.g. via the
SRTP protocol.
If the SRTP keys aren't available within the SDP, the decryption
can be handled externally as well (when using custom IO).
Signed-off-by: Martin Storsjö <martin@martin.st>
Without this, we'd signal a huge loss rate (due to unsigned
wraparound) if we had received one packet more than expected (that
is, one seq number sent twice). The code has a check for lost_interval
<= 0, but that doesn't do what was intended as long as the variable is
unsigned.
Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö
Vittorio Giovara
Michael Niedermayer
Thomas Volkert
Anton Khirnov
Diego Biurrun
Luca Barbato
Eloi BAIL
Thomas Volkert
Gilles Chanteperdrix
Michael Niedermayer
Andrey Utkin