Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Just for naming consistency, no functional changes.

Split actual writing to read_number() in the same way as write_number().
Allows set_string_number() to write to a caller-provided destination.

New functions can get values from child objects, properly report error
codes and have consistent naming and signatures.

Deprecate av_set_*

New functions support setting values on children, return error codes
instead of options and have consistent naming and signatures.

This will allow the caller to enumerate child contexts in a generic way
and since the API is recursive, it also allows for deeper nesting (e.g.
AVFormatContext->AVIOContext->URLContext)

This will also allow the new setting/reading API to transparently apply
to children contexts.

No application rely on this count being correct as far as
I know, but if we write a nonzero count value, it might just
as well be the right one.
Signed-off-by: Martin Storsjö <martin@martin.st>

DSS enables this automatically if streaming VOD over TCP. If
enabled, the server feeds packets faster than realtime, screwing
up RTCP NTP based timestamps.

Also, DSS doesn't indicate that this was indicated, if it was
enabled automatically (although if it was requested to be enabled,
a header saying that it was enabled is added, but this isn't
added if it is enabled automatically), making it even harder
to detect and work around properly without explicitly asking
for it to be disabled(/enabled, if we were able to support it).
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Unsupported bit depth is certainly an error the user will
want to know about.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This allows skipping past unsupported RTCP packet types, as
RFC 3550 section 6.1 mandates.

Currently this only has any practical effect if a sender puts
an unrecognized type before RTCP_BYE in a compounded packet, or
(incorrectly) does not put RTCP_SR first.
Signed-off-by: Martin Storsjö <martin@martin.st>

We actually read 20 bytes of these packets.
Signed-off-by: Martin Storsjö <martin@martin.st>

This code relies on the result wrapping as for unsigned
values, and the sign is not used.  Thus an unsigned type
is proper here.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This avoids writing these entries doubly if transcoding from
flv to flv, since the muxer blindly writes any and all metadata
keys set, in addition to the fixed fields that the muxer
always writes.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The values were reversed.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

The bit_rate_value_minus1 and cpb_size_value_minus1 elements
allow a wider range than get_ue_golomb() supports.  This
adds a get_ue_golomb_long() function supporting up to 31
leading zeros, which is the maximum for these syntax
elements, and uses it in decode_hrd_parameters().
Signed-off-by: Mans Rullgard <mans@mansr.com>

60% speedup (overall decoding time) at 2 threads, and another 60%
speedup at 4 threads.

~3.0-3.5x as fast as original C version, 1.6x as fast overall.

The intermediate buffer is always aligned.

The level_code expression includes a shift which is invalid in
those cases where the value is not used.  Moving the calculation
to the branch where the result is used avoids these.
Signed-off-by: Mans Rullgard <mans@mansr.com>

These additions might overflow the signed range for large
input values.  Converting to unsigned before the addition
rather than after avoids such undefined behaviour.  The
result under normal two's complement wraparound remains
unchanged.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Return -1 instead of ENOMEM if entries is 0.
Fixes a av_malloc(0) crash in macosx.

Bug found by Laurent Aimar fenrir at videolan org

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>