| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
Limelight is a not too uncommon CDN. The authentication scheme is
pretty similar to the adobe authentication, but is even closer to
normal http digest authentication (but not close enough to warrant
sharing code) than the adobe version.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly used to authenticate the client when publishing.
Tested with wowza and akamai.
Some but not all servers support resending a new connect invoke
within the same connection, so always reconnect for sending a new
connection attempt. This matches what other applications do as well.
The authentication scheme is structurally pretty similar to http
digest authentication, but uses base64 instead of hex strings.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
| |
This avoids having to concatenate them into one buffer before writing
them as AMF.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
It will overflow if somebody keeps streaming for a time long enough.
|
| |
|
|
|
|
|
| |
start_time is in stream timebase units while end_time is
in AV_TIME_BASE ones.
|
|
|
|
| |
recording_time is in AV_TIME_BASE units.
|
|
|
|
|
| |
Consider the corner case with a list size larger than the wrap
number.
|
|
|
|
|
| |
Avoid calling av_get_frame_filename twice, once to generate the
segment filename and once to generate the playlist.
|
| |
|
|
|
|
|
|
| |
The segment path is desumed from the playlist path, recording a
relative path in the playlist while serving the file could lead
to misleading results.
|
| |
|
|
|
|
|
|
| |
Also fixes linking in various configs with only individual parts enabled
because the RTP muxer chaining code depends on the general RTP code,
which is now accounted for.
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
| |
If s->filename doesn't contain any period/filename extension to strip
away, the buffer will be too small to fit both strings. This isn't
any buffer overflow since the concatenation uses av_strlcat with
the right buffer size.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is built on the assumption that the first partition of each
VP8 packet is essential for decoding any later packet - if this
partition is broken/missed, the arithmetic coder gets out of sync
and decoding the bitstream in further packet ends up with total
garbage. If packets of a frame are lost, make sure the first
partition is intact (return only this part of the packet, nothing
else), otherwise stop returning data until the next keyframe is
received.
Alternatively, one would simply not return any packets at all
until the next keyframe, if packet loss is detected.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
| |
This allows depacketizers to figure out if packets have been lost.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
| |
This makes all users of rtpenc_chain (rtsp muxer, sapenc, mov
rtp hinting) work again, broken since 8034130e0.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
| |
The FLV muxer tries to update the header in write_trailer, which is
impossible if writing to a pipe or network stream. Don't write header
data if seeking to the header fails.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
| |
This makes sure it ends up in the SDP, providing a proper session name
in the SAP announcements.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
| |
The sample in https://bugzilla.libav.org/show_bug.cgi?id=393 and
samples/F4V/H263_NM_f.mp4 both have codec_tag H263 for different
codecs. H263 is apparently used by Flash Media Server for Sorensen
Spark videos.
Patch based on commit 5442083b1c541dd166b3adf39131259fc846a62b by
Carl Eugen Hoyos. Fixes bug 393.
|
| |
|
|
|
|
|
|
| |
The "pts for a given stream" was nonsensical.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|
|
| |
This reduces code size when either piece has been disabled.
|
| |
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier for receivers to decide what to do if data
is lost.
Refactor calculating the max payload size, to avoid hardcoding the
header size in too many places, reducing the number of lines that
have to be touched if the header is adjusted further.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
| |
The previous comment about the buffer was wildly inaccurate and
misleading.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
| |
These stem from back when both the rtp muxer and rtp depacketizing
shared the same struct.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
| |
This fixes potential buffer overwrites.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
| |
Avoids trying to read a packet with 0 or negative size.
Avoids a potential infinite loop due to seeking backwards.
Partially based on a patch by Michael Niedermayer.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comment was added in e309128f, in 2002, and has been brought
along since then more or less unmodified.
The first point of the todo was implemented in dbf30963 in 2006,
the second one is not relevant to rtpdec.c (brought along from
rtp.c in 8eb793c4 in 2008) but would be more relevant to the
rtp muxer, although it isn't a good idea anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
| |
|
|
|
|
|
|
|
|
| |
The values compared here can be more than INT64_MAX apart. Since the
difference is always positive, converting to uint64_t before subtracting
gives the correct result without overflows.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|