Otherwise the values are overwritten.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

related to b7165426
Error messages and audible artifacts were fixed in that commit.

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

also use AVERROR codes for some return values instead of -1

simplifies the code and does less memmove()

vorbis_bitrate_flushpacket() does not return any packets that should not be
output in the bitstream.

libvorbis takes float input, so we can just deinterleave/reorder the input
as-is instead of also converting.

Fixes a segfault if init() fails before initializing the dsp state

- enable the options for audio encoding
- properly check for user-set maxrate
- use correct calling order in vorbis_encode_setup_managed()

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

This avoids breaking fate every time the lavc version is bumped.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes cases where the user had specified one desired MTU
via an option, and the protocol indicates another one.
Signed-off-by: Martin Storsjö <martin@martin.st>

It will be need by new functions called from mp3_write_trailer().

Unused so far.

Frame sizes in ID3v2.3 are not synchsafe, they are simply 32be numbers.

In practice this bug is not noticeable unless the frame size takes more
than 7 bits (which is almost never for text frames).

This will allow writing the tag in several steps, needed for writing
attached pictures.

It has no need of full AVFormatContext.

Rename ff_id3v2_read_all to ff_id3v2_read().

it will be useful for attached pictures in ID3v2

It is not supposed to be set outside of lavc.

Fixes a divide by zero when the stored framerate is 0.

Based on the patch by Phil Barrett.

Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

ProRes codes chroma blocks in 444 mode in different order than luma blocks,
so make both decoder and encoder read/write chroma blocks in right order.

Reported by Phil Barrett