Yes. These errors are not real errors. We're working on avoiding them
anyway.
On 24.06.2015 16:01, Fabian Greffrath wrote:
Hi,
Am Mittwoch, den 24.06.2015, 07:23 +0200 schrieb Peter Belkner:
To fix the error drop "-Wcast-align" from "CFLAGS" in the respective
"Makefile.am".
is this package
Hi,
Am Mittwoch, den 24.06.2015, 07:23 +0200 schrieb Peter Belkner:
> >
> To fix the error drop "-Wcast-align" from "CFLAGS" in the respective
> "Makefile.am".
is this package built with -Werror?!
- Fabian
signature.asc
Description: This is a digitally signed message part
__
On 24.06.2015 12:41, Petter Reinholdtsen wrote:
[Peter Belkner]
BS1770GAIN doesn't make any assumption on buffer alignment itself
(i.e. it relies on FFmpeg), and so myself. Are there any hints that
FFmpeg is broken on the systems in question?
I do not know. But I am more worried about other
[Peter Belkner]
> BS1770GAIN doesn't make any assumption on buffer alignment itself
> (i.e. it relies on FFmpeg), and so myself. Are there any hints that
> FFmpeg is broken on the systems in question?
I do not know. But I am more worried about other alignment problems
being hidden if the warnin
BS1770GAIN doesn't make any assumption on buffer alignment itself (i.e.
it relies on FFmpeg), and so myself. Are there any hints that FFmpeg is
broken on the systems in question?
But you're right: 16 bit is 2 byte, and 32 bit is 4 byte.
You may use SoX to generate test files.
On 24.06.2015 1
[Peter Belkner]
> Any test using the transcoding feature (i.e. option "-ao") uses this
> code. It's needed exclusively for that purpose. The code builds the
> frames to be fed into the FLAC encoder.
Right. So a data source with types aligned on more than 1 byte is
needed to check that the code
Any test using the transcoding feature (i.e. option "-ao") uses this
code. It's needed exclusively for that purpose. The code builds the
frames to be fed into the FLAC encoder.
On 24.06.2015 09:58, Petter Reinholdtsen wrote:
[Peter Belkner]
If you have any doubts whether the alignment of the
[Peter Belkner]
> If you have any doubts whether the alignment of the pointer to the frame
> buffer is given
Thank you for the background information. Is there some way I can test
the code in question? What kind of input data do I need and what kind
of command line arguments should I use?
If s
If you have any doubts whether the alignment of the pointer to the frame
buffer is given you should note that the buffer is allocated using the
respective FFmpeg API function "av_frame_get_buffer()" (cf.
https://www.ffmpeg.org/doxygen/2.6/frame_8c.html).
In "ffsox" the following function in "l
The first build of bs1770gain on the autobuilders showed an error on at
least the mipsel architecture, that look like this:
ffsox_frame_convert.c: In function 'convert_s16i_s8i':
ffsox_frame_convert.c:143:6: error: cast increases required alignment of target
type [-Werror=cast-align]
rp=(R *
Package: bs1770gain
Version: 0.4.3-1
Severity: wishlist
The first build of bs1770gain on the autobuilders showed an error on at
least the mipsel architecture, that look like this:
ffsox_frame_convert.c: In function 'convert_s16i_s8i':
ffsox_frame_convert.c:143:6: error: cast increases required a
11 matches
Mail list logo