Fixes two warnings:
libavformat/rtpdec.c:155:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
libavformat/rtpdec.c:168:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
This adds partial support for the RFC 4175 (raw video over RTP). The
only supported formats are the YCbCr-4:2:2 8 bit because it's natively
supported by FFmpeg with pixel format UYVY, and 10 bit which requires
the vrawdepay codec to convert the payload in a format handled by
FFmpeg.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
When ffplay is used to play from the RTSP URL that serves 24 bit audio
content, ffplay fails to recognize the audio codec format. The attached
patch adds support for playing 24 bit audio content over RTSP by
defining a dynamic payload handler for "L24".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add new mime types AAL2-G726 for g726 as suggested in rfc 3551.
This patch will break interaction with applications that incorrectly
use big-endian G.726 with mime type G726 but we know of at least one
device (DVTel camera) that correctly implements the rfc, so do the same.
Fixes ticket #5890.
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>
Carl Eugen Hoyos
Josh de Kock
Damien Riegel
Timur Aydin
Carl Eugen Hoyos
Diego Biurrun
Martin Storsjö
Vittorio Giovara
Michael Niedermayer
Thomas Volkert
Anton Khirnov
Luca Barbato
Eloi BAIL
Thomas Volkert
Gilles Chanteperdrix
Michael Niedermayer
Andrey Utkin