* commit '4f6cd883f06f7893a2b60a41e7a4f8ae633dac2f':
rtpenc: Don't set max_frames_per_packet based on the packet frame size or frame rate
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bde2bba45c2f2df27a8534028bda09a6e7f835e2':
rtpenc: Restructure if statements in packetizers to simplify adding more conditions
Conflicts:
libavformat/rtpenc_xiph.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd16c8d28d4e2fca3af1054ffbf635c8cee755fc8':
rtpenc_aac: Use AV_WB16 instead of manual bitshifts
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9c9b0218e85fcd969308632f75af48a4ce229541':
rtpenc_aac: Merge a definition with a declaration
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0662440b991361fdb5e732712d997a73e4692e34':
rtpenc_aac: Set a default value for max_frames_per_packet at init
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
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>
* qatar/master:
flacenc: ensure the order is within the min/max range in LPC order search
avconv: rescale packet duration to muxer time base when flushing encoders
add 24-bit FLAC encoding to Changelog
rtpenc_aac: Fix calculation of the header size
x86: h264_intrapred: port to cpuflags
Conflicts:
Changelog
libavformat/rtpenc_aac.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously the high end byte was always set to zero. Also get
rid of an unnecessary multiplication (which in practice couldn't
overflow) before shifting.
Signed-off-by: Martin Storsjö <martin@martin.st>