| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
* commit 'b7f98659f21dce438c33b512e25fd64b8d07c347':
Remove unnecessary get_bits.h #includes
Merged-by: Clément Bœsch <clement@stupeflix.com>
|
|
* commit '9ea78fd00a49f0691c1a5134eb59d4e5bb380a2a':
rtpdec: Always check if we have the next packet queued
Merged-by: Clément Bœsch <u@pkh.me>
|
|
* commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb':
cosmetics: Fix spelling mistakes
Merged-by: Clément Bœsch <u@pkh.me>
|
|
|
|
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>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
* commit '9200514ad8717c63f82101dc394f4378854325bf':
lavf: replace AVStream.codec with AVStream.codecpar
This has been a HUGE effort from:
- Derek Buitenhuis <derek.buitenhuis@gmail.com>
- Hendrik Leppkes <h.leppkes@gmail.com>
- wm4 <nfxjfg@googlemail.com>
- Clément Bœsch <clement@stupeflix.com>
- James Almer <jamrial@gmail.com>
- Michael Niedermayer <michael@niedermayer.cc>
- Rostislav Pehlivanov <atomnuker@gmail.com>
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
* commit '8d918a98aa24134a043d578ef45bae363dbed9db':
rtpdec: Use the right logging context
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
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.
|
|
|
|
* commit '22cc57da64bfd73f2206969486b0aa183ee76479':
rtpdec: Forward the memory failure
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
And avoid a memory leak.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
* commit 'ff7f6ea9db2a77d74f7e68a716f53ba1f3f85017':
rtpdec: add a trace when jitter buffer is full
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
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>
|
|
* commit '1a3eb042c704dea190c644def5b32c9cee8832b8':
Replace av_dlog with normal av_log at trace level
Conflicts:
ffplay.c
libavdevice/fbdev_dec.c
libavfilter/avfilter.c
libavfilter/internal.h
libavfilter/setpts.c
libavfilter/src_movie.c
libavfilter/vf_crop.c
libavfilter/vf_drawtext.c
libavfilter/vf_fieldorder.c
libavformat/assdec.c
libavformat/avidec.c
libavformat/flvdec.c
libavformat/http.c
libavformat/ipmovie.c
libavformat/isom.c
libavformat/mov.c
libavformat/mpegenc.c
libavformat/mpegts.c
libavformat/mpegtsenc.c
libavformat/mux.c
libavformat/mxfdec.c
libavformat/nsvdec.c
libavformat/oggdec.c
libavformat/r3d.c
libavformat/rtspdec.c
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
This applies to every library where performance is not critical.
|
|
The code was tested with live555 server.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
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>
|
|
* commit 'ec96a89c3e507cf0fb1f2b159b28a53f2bad9a74':
rtpdec: Don't pass non-const pointers to fmtp attribute parsing functions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
* commit '353b492d0f2a21ae8eb829db1ac01b54b2a4d202':
rtpdec: Change enc_name to a pointer instead of a fixed-size buffer
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
This makes it clear that the individual parsing functions can't
touch the parsed out value.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
* commit '04a1be8e28e81f3967eace7705343c450616cc95':
libavformat: add T.140 RTP depacketization (RFC 4103)
Conflicts:
libavformat/rtpdec.c
libavformat/version.h
See: af940e6cb1212d4338e55c03498ef5ae40e6e749
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
This avoids allocating space for a too large buffer for all the
name strings.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Map this to AV_CODEC_ID_TEXT.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
(tested with live555 RTSP server)
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
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>
|
|
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>
|
|
Tested with live555 RTSP server
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Reviewed-by: Thomas Volkert <silvo@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Reviewed-by: Thomas Volkert <silvo@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Reviewed-by: Thomas Volkert <silvo@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
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>
|
|
* commit '6df9d9b55d3f56ee7782639a7678eeeaf77f14ea':
lavf: Use av_gettime_relative
Conflicts:
libavformat/hls.c
See: f78bc96b7c1c74caf99a7139cf81ce1110404965
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
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>
|
|
* commit 'c463dfc7e49929a9891884312b23b27d14729c51':
rtpdec_hevc: Drop a duplicated, nonstandard entry
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
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>
|
|
As specified in draft-ietf-payload-rtp-h265-06.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
depacketizing
|
