To use this, set sdpflags=custom_io to the sdp demuxer. During
the avformat_open_input call, the SDP is read from the AVFormatContext
AVIOContext (ctx->pb) - after the avformat_open_input call,
during the av_read_frame() calls, the same ctx->pb is used for reading
packets (and sending back RTCP RR packets).
Normally, one would use this with a read-only AVIOContext for the
SDP during the avformat_open_input call, then close that one and
replace it with a read-write one for the packets after the
avformat_open_input call has returned.
This allows using the RTP depacketizers as "pure" demuxers, without
having them tied to the libavformat network IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
So far, aviocontexts are used either in pure-read or pure-write
mode - full read/write mode doesn't work well (and implementing it
is a much larger, not totally trivial change).
This patch allows using avio_read and ffio_read_partial on
read/write aviocontexts, where the read operations are passed
through directly unbuffered, while writes are buffered as usual.
This is enough to support the operations needed by packet based
data transfer like in udp/rtp, where aviocontext is the only
public API for hooking up custom IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
The description as updated in 6e5c44b0f made it sound like it is
handled exactly like the pts, which it is not. Clarify that it
is the packet that triggered returning the frame instead of just
the last avpacket (in case of frame threading, it won't be the
dts of the last packet).
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 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>
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>
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>
When called from the v4l2 input device, pix_fmt can be
AV_PIX_FMT_NONE (for jpeg formats). Before 50ba57e0, this wasn't
an issue for avpicture_get_size, but after that commit, this
lead to crashes.
Signed-off-by: Martin Storsjö <martin@martin.st>
The def files are used for generating import libraries for
other toolchains (in particular, for generating import libraries
for MSVC for DLLs built with mingw).
The def files produced by mingw/gcc contains ordinals for each
exported function. When MSVC tools generate import libraries
from such a def file, MSVC links to the DLL by the ordinals
instead of linking by name.
Since the def files aren't maintained by hand, the ordinal
numbers are assigned (more or less) randomly and any caller
linking to the libs by ordinals will break as soon as the libraries
export more/fewer functions.
Therefore, strip out the ordinals from the generated def files,
to make users link to the libraries by name.
Callers linking to the DLLs using the gcc provided import library
link by name as they should.
Signed-off-by: Martin Storsjö <martin@martin.st>
When targeting the metro API subset, this function still exists in
the link libraries, but is excluded from the headers. This makes
sure w32threads is automatically disabled when targeting this API
subset (since not all the necessary functions for it are available).
Signed-off-by: Martin Storsjö <martin@martin.st>
Not all versions of windows have the console color functions,
while io.h might be needed for isatty (which can be found in
unistd.h or io.h).
Signed-off-by: Martin Storsjö <martin@martin.st>
The existence of MapViewOfFile isn't linked to the existence of
io.h.
Not all versions of windows have MapViewOfFile (in particular,
Windows Phone 8 and the "metro" windows 8 API subset don't),
while they still have io.h (and need it for open/read/close).
Signed-off-by: Martin Storsjö <martin@martin.st>
This simplifies the condition to avoid hardcoding the systems
where the function exists. This also simplifies support for
newer Windows API subsets where this function doesn't exist,
such as Windows Phone 8 and the "metro" API subset of Windows 8.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure minimal configurations such as
"--disable-everything --enable-avconv" will enable the filters
necessary for running avconv, instead of just keeping avconv
disabled (even if the user specified "--enable-avconv").
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows getting rid of redundant checks later in the codec
specific init functions.
Move the check to before actually initializing the decoder lib,
to simplify error handling.
This fixes a case of returning a value from a void function, present since
d40dab907.
Signed-off-by: Martin Storsjö <martin@martin.st>
After a flush, don't average the output envelope and energy with
previous iterations.
Also start directly from the target values for the first iteration
at startup.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was a leftover from previous iterations of the code, where the
refl coef arrays were statically allocated.
Signed-off-by: Martin Storsjö <martin@martin.st>
This isn't too useful as a normal codec, but can be used in
voip style applications. The decoder updates the noise
generator parameters when a packet is given to it for decoding,
but if called with an empty packet, it generates more noise
according to the last parameters.
Signed-off-by: Martin Storsjö <martin@martin.st>
This gets rid of this warning:
libavformat/rtsp.c: In function ‘rtsp_parse_transport’:
libavformat/rtsp.c:794: warning: cast discards qualifiers from pointer target type
Signed-off-by: Martin Storsjö <martin@martin.st>
Mainly clean up the RTP statistics code, plus a few other obviously
misindentend lines.
Remove some useless comments, de-doxygenize some comments,
add spacing around operators and fix a typo.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure the previously always installed public header
lzo.h is installed if the LZO functionality is enabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
Earlier versions of for instance of libavcodec expect this symbol to be
present in libavutil. This commit can be reverted after the next major
bump.
New shared builds of avcodec will link to the internal copy of the
table within that library, so those builds won't rely on this table
being present in avutil any longer either.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also retroactively add a changelog entry to the 9beta1 list
for general MSVC support, which was present there already.
Signed-off-by: Martin Storsjö <martin@martin.st>
This requires the makedef perl script by Derek, from the
c89-to-c99 repo. That scripts produces a .def file, listing
the symbols to be exported, based on the gcc version scripts
and the built object files.
To properly load non-function symbols from DLL files, the
data symbol declarations need to have the attribute
__declspec(dllimport) when building the calling code. (On mingw,
the linker can fix this up automatically, which is why it has not
been an issue so far. If this attribute is omitted, linking
actually succeeds, but reads from the table will not produce the
desired results at runtime.)
MSVC seems to manage to link DLLs (and run properly) even if
this attribute is present while building the library itself
(which normally isn't recommended) - other object files in the
same library manage to link to the symbol (with a small warning
at link time, like "warning LNK4049: locally defined symbol
_avpriv_mpa_bitrate_tab imported" - it doesn't seem to be possible
to squelch this warning), and the definition of the tables
themselves produce a warning that can be squelched ("warning C4273:
'avpriv_mpa_bitrate_tab' : inconsistent dll linkage, see previous
definition of 'avpriv_mpa_bitrate_tab').
In this setup, mingw isn't able to link object files that refer to
data symbols with __declspec(dllimport) without those symbols
actually being linked via a DLL (linking avcodec.dll ends up with
errors like "undefined reference to `__imp__avpriv_mpa_freq_tab'").
The dllimport declspec isn't needed at all in mingw, so we simply
choose not to declare it for other compilers than MSVC that requires
it. (If ICL support later requires it, the condition can be extended
later to include both of them.)
This also implies that code that is built to link to a certain
library as a DLL can't link to the same library as a static library.
Therefore, we only allow building either static or shared but not
both at the same time. (That is, static libraries as such can be,
and actually are, built - this is used for linking the test tools to
internal symbols in the libraries - but e.g. libavformat built to
link to libavcodec as a DLL cannot link statically to libavcodec.)
Also, linking to DLLs is slightly different from linking to shared
libraries on other platforms. DLLs use a thing called import
libraries, which is basically a stub library allowing the linker
to know which symbols exist in the DLL and what name the DLL will
have at runtime.
In mingw/gcc, the import library is usually named libfoo.dll.a,
which goes next to a static library named libfoo.a. This allows
gcc to pick the dynamic one, if available, from the normal -lfoo
switches, just as it does for libfoo.a vs libfoo.so on Unix. On
MSVC however, you need to literally specify the name of the import
library instead of the static library.
Signed-off-by: Martin Storsjö <martin@martin.st>
This table doesn't need to be shared with libavformat any longer.
Add mpeg12 to the name to make it less ambiguous, while renaming it.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to share this table across the library
boundaries.
This shared table used to be problematic, if always declaring
all exported data symbols with the dllimport attribute (even
while building that same library), since it needs to be a
link-time constant when it is used in AVCodec declarations
(in mpeg12enc.c).
Signed-off-by: Martin Storsjö <martin@martin.st>
The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.
Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
Signed-off-by: Martin Storsjö <martin@martin.st>
This seemed to assume that one never used writing avio unless
muxers or networking was enabled.
This ifdef is a remnant since 8fa641f8.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to overestimate the md5 context size, which
isn't known beforehand, allowing us to use the new allocate functions
instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
The current API where the plain size is exposed is not of much
use - in most cases it is allocated dynamically anyway.
If allocated e.g. on the stack via an uint8_t array, there's no
guarantee that the struct's members are aligned properly (unless
the array is overallocated and the opaque pointer within it
manually aligned to some unspecified alignment).
Signed-off-by: Martin Storsjö <martin@martin.st>
Not all details are implemented, but it's enough for proper
playback as long as there is no packet loss.
Tested to work with the packetizer in gstreamer (which although
uses a different codec name, to clarify that it is still a spec
draft).
Signed-off-by: Martin Storsjö <martin@martin.st>
We don't need to return an error if the directory already existed.
We make sure that the directory actually is properly writeable later
within ism_write_header by writing a manifest anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure any buffered data is written to the segment, for
muxers that buffer up data internally (e.g. fragmented mp4).
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure new inline headers are emitted when the next
packet is written. This allows segmenting mpegts without calling
write_header/write_trailer (nor freeing/reiniting the muxer)
for each segment.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some segmented formats (such as fragmented mp4) are "bare", as in,
the segment files do not have the same headers/trailers as full normal
files of that format have.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure the muxers are set up in the way they expect
with no data left around from the previous run (which could
cause various issues including memory leaks, depending on the chaine
muxer).
This fixes memory leaks with the mpegts and flv muxers. It also
makes the usage of chained muxers correct.
Signed-off-by: Martin Storsjö <martin@martin.st>
With this change, the segmenter muxer doesn't rely on anything
not available/supported to libavformat external users, making
the segmenter muxer do things just like a normal segmenter
application using libavformat would do.
Signed-off-by: Martin Storsjö <martin@martin.st>
Before, the chained muxer reused the AVStreams array from
the outer muxer, which made it impossible to use the proper
public functions (such as av_write_frame) when calling the
chained muxer.
Signed-off-by: Martin Storsjö <martin@martin.st>
This might not be needed at the moment, but it's good practice to
pass it to all chained AVFormatContexts, if it would happen to be
used there at a later point.
Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö
