| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| |
| | |
- 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>
|
| |
| |
| |
| | |
support.
|
| | |
|
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Deprecate corresponding AVCodecContext field.
|
| |
| |
| |
| | |
It's unused.
|
| |
| |
| |
| |
| | |
It's currently only used as temporary storage by the mov demuxer. Make
it use a local variable instead.
|
| | |
|
| |
| |
| |
| | |
Deprecate corresponding AVCodecContext fields.
|
| |
| |
| |
| | |
Deprecate CODEC_FLAG_CBP_RD.
|
| |
| |
| |
| | |
Deprecate CODEC_FLAG_QP_RD.
|
| |
| |
| |
| | |
Deprecate CODEC_FLAG2_STRICT_GOP.
|
| |
| |
| |
| |
| | |
Deprecate CODEC_FLAG2_SKIP_RD in favor of the corresponding mpv_flags
flag.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
configuration 1 (mono).
[alex.converse@mgail.com]
Move code to get_che()
Update for AAC new channel configuration interface
Only set chan_config if output_configure succeeds.
Signed-off-by: Alex Converse <alex.converse@gmail.com>
|
| |
| |
| |
| | |
set_default_channel_config() and output_configure().
|
| |
| |
| |
| |
| |
| |
| | |
Prevents crashes when playing corrupt vp5/6 streams.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seeking back on EOF will reset the EOF flag, causing us to re-enter
the loop to find the next marker in the ASF file, thus potentially
causing an infinite loop.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
| |
| |
| |
| |
| |
| |
| | |
They cause various issues further down in demuxing.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
| |
| |
| |
| |
| |
| | |
Packets are not guranteed to be allocated by av_malloc().
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
Fixes a out of array read.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Its not clear from the spec what to do with values larger than 127
so iam opting for the safe side and ask for a sample.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
With the encode2 API, encoders allocate huge packets to be
sure they have enough room (a typical case is mpeg4, which
allocs ~10M for 1280x768 yuv420p) but only actually use a
very small part of the buffer.
|
| |
| |
| |
| |
| |
| | |
probably due to float rounding
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
This is somewhat redundant as no decoder should call get_buffer() with such argument.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ALS spec:
11.6.3.1.1 Quantization and encoding of parcor coefficients
...
In all cases the resulting quantized values ak are restricted to the range [-64,63].
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|