In adjust_frame_information(), msc is incremented for each sfb in each
sub-window then compared against max_sfb which is for a single sub-window.
This resulted in frames using EIGHT_SHORT_SEQUENCE where the first few
sub-windows increment msc to a value that results in ms_mode == 2. Even
though only some of the bands are actually using Mid/Side.
This is necessary because some programs writing TGA files forget
to initialize parts of the header they don't care about, resulting
in "random" data there.
The new behaviour is consistent with other programs, e.g. tgatoppm.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
They introduce too much complexity for very little benefit. The result is that
encoding will be more likely to fail at extremely low bitrates where quality
would be awful anyway.
As a nice sideeffect this fixes the following warning:
libavcodec/mpeg4videoenc.c:302:20: warning: variable ‘rl’ set but not used [-Wunused-but-set-variable]
In these cases it can't be guessed from the operands (at least
not necessarily), and it seems some clang versions refuse to
compiler it.
Fixes ticket #303.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This helps catching cases where the format string doesn't
match what is passed in, or injection bugs where user data
is passed in as format string.
Signed-off-by: Martin Storsjö <martin@martin.st>
Now that we're converting all streams to Annex B format, we
can identify them as such to the hardware.
Signed-off-by: Philip Langdale <philipl@overt.org>
As we're now always running mp4 format streams through the annex b
filter, it makes sense to pass the filtered stream down, as
libcrystalhd would be doing the conversion internally anyway.
Signed-off-by: Philip Langdale <philipl@overt.org>
Originally, we needed to restore the original extradata after
initialising the mp4toannexb filter because mplayer would end up
taking two passes through the init sequence for the same stream
and end up miscategorising the stream. This doesn't seem to happen
anymore, making the backup/restore process unnecessary.
Signed-off-by: Philip Langdale <philipl@overt.org>
From some tests it results that:
1. All of the AVI/MOV WRAW files need to be flipped.
2. MOV WRAW files need to use AVI color modes.
3. Assigning PAL8 mode by default to WRAW codec is not correct.
is not correct but must be "rm" instead.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>