rtpenc: Don't set max_frames_per_packet based on the packet frame size or frame rate
authorMartin Storsjö <martin@martin.st>
Wed, 25 Feb 2015 22:00:39 +0000 (00:00 +0200)
committerMartin Storsjö <martin@martin.st>
Sat, 28 Feb 2015 20:54:31 +0000 (22:54 +0200)
commit4f6cd883f06f7893a2b60a41e7a4f8ae633dac2f
tree0a140108c19744a4399aa5d5244fd63d8b5e13bf
parentbde2bba45c2f2df27a8534028bda09a6e7f835e2
rtpenc: Don't set max_frames_per_packet based on the packet frame size or frame rate

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>
libavformat/rtpenc.c
libavformat/rtpenc_aac.c
libavformat/rtpenc_amr.c
libavformat/rtpenc_xiph.c