This allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.
In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.
When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.
This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.
One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: Martin Storsjö <martin@martin.st>
When feeding input RTP packets to the depacketizer via custom IO,
it needs to pick the right stream using the payload type for
RTP packets, and using the SSRC for RTCP packets. If the first
packet is an RTCP packet, we don't (currently) know the SSRC
yet and thus can't pick the right RTP depacketizer to handle it.
By parsing the SSRC attribute in the SDP, we can map initial
RTCP packets to the right stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
The declarations that this comment referred to were removed
in 2439f2ca8 - there is no unbuffered IO in this header now.
Signed-off-by: Martin Storsjö <martin@martin.st>
We still only support one single layer though, but this allows
receiving streams that have this structure present even for
single layer streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
This codepath isn't quite as bad as it used to sound, if fragments
are cut automatically at video packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
Restore alphabetical order in lists, break overly long lines, do some
prettyprinting, add some explanatory section comments, group parts
together that belong together logically.
The problem is that the argument 'q' is of the type uint8_t.
According to the JPEG standard, if 1 <= q <= 50, the scale factor
'S' should be 5000 / Q. Because the create_default_qtables() reuses
the variable 'q' to store the result of this calculation, for small
values of q < 19, q wil subsequently overflow and give wrong results
in the calculated quantization tables.
Instead, use a new variable 'S' (same name as in RFC2435) with the
proper range to store the result of the division.
Signed-off-by: Martin Storsjö <martin@martin.st>
Apply the default value for timeout in code instead of via the
avoption, to allow distinguishing the default value from the user
not setting anything at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since all URLContexts have the same AVOptions, such AVOptions
will be applied on the outermost context only and removed from the
dict, while they probably make sense on all contexts.
This makes sure that rw_timeout gets propagated to the innermost
URLContext (to make sure it gets passed to the tcp protocol, when
opening a http connection for instance).
Alternatively, such matching options would be kept in the dict
and only removed after the ffurl_connect call.
Signed-off-by: Martin Storsjö <martin@martin.st>
Using this requires setting the rw_timeout option to make it
terminate, alternatively using the interrupt callback (if used via
the API).
Signed-off-by: Martin Storsjö <martin@martin.st>
If set non-zero, this limits duration of the retry_transfer_wrapper()
loop, thus affecting ffurl_read*(), ffurl_write(). As soon as
one single byte is successfully received/transmitted, the timer
restarts.
This has further changes by Michael Niedermayer and Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Check if the size is written the first 4 bytes and read the next 4
as fourcc candidate, fallback checking the initial for 4 bytes.
"The CodecPrivate contains all additional data that is stored in the
'stsd' (sample description) atom in the QuickTime file after the
mandatory video descriptor structure (starting with the size and FourCC
fields)"
CC: libav-stable@libav.org
