If it doesn't fit into 12 bits it triggers an assertion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The code was tested with live555 server.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

The original flags variable contains rtpdec flags, while the
rmflags variable contains RM flag bits which have a completely
different definition.
Signed-off-by: Martin Storsjö <martin@martin.st>

The only case where RTP_FLAG_KEY actually is needed is
in RDT, where such a flag needs to be passed via the
rtpdec parse function's flags parameter.
Signed-off-by: Martin Storsjö <martin@martin.st>

Nothing in the framework nor in the rest of the depacketizer actually
uses this flag - the chained demuxer sets the keyframe flag properly on
demuxed packets already.
Signed-off-by: Martin Storsjö <martin@martin.st>

And provide a more informative message in case of failure.

CC: libav-stable@libav.org

Although the specification mandates this bit to zero, it may happen
that software tools incorrectly flip it to one, invalidating a possibly
valid stream.

Relax this restriction, by failing only when AV_EF_BITSTREAM is set.
This behaviour is similar to aac decoders in Firefox and Quicktime.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This was missed in bb4a310b. This fixes a double free on close.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes fate on all architectures that have an optimized
but not bitexact idct available.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes an oversight in 96084251, in a refactoring done on top
of Gilles' original patch.

Pointed out by Gilles Chanteperdrix.
Signed-off-by: Martin Storsjö <martin@martin.st>

It's required for at least AVCodecContext.

Fixes make checkheaders.

Similarly to what has been done for MOV, display XMP metadata only when
users explicitly require it.

The Extensible Metadata Platform tag can contain various kind of data
which are not strictly related to the video file, such as history of
edits and saves from the project file.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Normally the aic decoder finds the proper slice combination (multiple of
some number less than 32) but in case of odd width, it resorts to the
default values, which were actually swapped.
The number of slices is modified to account for such odd width cases.

CC: libav-stable@libav.org

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

This reverts commit 4abfa387.

This commit broke playback of fragmented mp4 files with b-frames.
While investigating this, it turned out that the general framework
isn't ready for a PTS-based index yet. Revert this change until
a better thought out solution is in place.
Signed-off-by: Martin Storsjö <martin@martin.st>

The encoder or decoder might be disabled but the format would be
supported for at least remuxing.

Some files produced by the official encoder have up to 16bit of
padding instead of the expected padding to the byte.

Use a self-explanatory macro instead of a simple number.

CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Instead check the timestamps while muxing, to avoid buffering a
too long timestamp range into one single packet.

This makes the AMR and AAC packetization slightly less efficient,
since we set a possibly unnecessarily high max_frames_per_packet.
(These packetizers end up doing a memmove of the TOC bytes if
sending a packet before max_frames_per_packet is achieved, and
we end up setting max_frames_per_packet to a value that should
be high enough for most uses.)

All packetizers that use max_frames_per_packet now set it either
to a default value, or to a value calculated based on other
parameters, so none of them rely on the previous default setting.

For iLBC, copy one frame at a time, to allow checking the timestamp
range for each of them - basically doing potentially multiple
loops to simplify the code instead of trying to calculate the
number of frames to buffer while honoring s1->max_delay.

This is in preparation for reducing the coupling between libavformat
and libavcodec, by not having the muxers use the encoder field
frame_size (which may not be available during e.g. stream copy).
Signed-off-by: Martin Storsjö <martin@martin.st>

Factorize out the s->num_frames check at the start of the if statements,
simplifying adding more alternative causes for sending the buffered
frames.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

This avoids having to jump to the defaultcase in the switch. Manually
override the stream time base back to 90 kHz for the few audio codecs
that don't use the sample rate as time base (mp2, mp3).
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes things more consistent by using the variable in the same
way as in all other packetizers.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

This makes the code slightly more readable and understandable.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Intentionally keeping some conditional statements on single lines
in rtpenc_h263.c.
Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids having to conditionally set the default within the
packetizer function.
Signed-off-by: Martin Storsjö <martin@martin.st>

This doesn't fix any bug, but makes the code simpler for later
patches, and more straightforward to read as is.
Signed-off-by: Martin Storsjö <martin@martin.st>

After sending a fragmented frame, len (s->buf_ptr - s->buf) isn't
zero, while s->num_frames is zero as intended. Using s->num_frames
makes it work as intended, and is less convoluted than keeping track
of (resetting) s->buf_ptr.

This avoids sending stray data after sending a fragmented aac packet.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The correct macro is DEC not D. Broken in
b31328d0Signed-off-by: Anton Khirnov <anton@khirnov.net>

Only ac3dec and dcadec use it.

Those decoders have been switched to float output and so do not use
fmtconvert anymore.

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