[FFmpeg-soc] [soc]: r5067 - spdif/spdif.c
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Aug 14 13:21:34 CEST 2009
On Thu, Aug 13, 2009 at 10:51:07PM +0200, Bartlomiej Wolowiec wrote:
> > > @@ -55,6 +57,10 @@ typedef struct IEC958Context {
> > > int pkt_size; ///< Length code (number of bits or
> > > bytes - according to data_type) int pkt_offset; ///<
> > > Repetition period of a data burst in bytes int (*header_info)
> > > (AVFormatContext *s, AVPacket *pkt);
> > > +#if !HAVE_BIGENDIAN
> > > + uint8_t *buffer;
> > > + int buffer_size;
> > > +#endif
> >
> > I'd be in favour of leaving this in unconditionally, even if it is
> > strictly speaking useless bloat on big endian.
>
> hmm.. so, what are the pros of leaving this unconditionally?
You don't need those #ifs, which in this case make out about half of the
code...
> >[...]
> > > @@ -237,13 +256,13 @@ static int spdif_write_packet(struct AVF
> > > #if HAVE_BIGENDIAN
> > > put_buffer(s->pb, pkt->data, pkt->size & ~1);
> > > #else
> > > - {
> > > - //XXX swab... ?
> > > - uint16_t *data = (uint16_t *) pkt->data;
> > > - int i;
> > > - for (i = 0; i < pkt->size >> 1; i++)
> > > - put_be16(s->pb, data[i]);
> > > + if (ctx->buffer_size < pkt->size) {
> > > + av_fast_malloc(&ctx->buffer, &ctx->buffer_size, pkt->size +
> > > FF_INPUT_BUFFER_PADDING_SIZE); + if (!ctx->buffer)
> > > + return AVERROR(ENOMEM);
> > > }
> > > + swab(pkt->data, ctx->buffer, pkt->size & ~1);
> > > + put_buffer(s->pb, ctx->buffer, pkt->size & ~1);
> > > #endif
> >
> > Btw. using
> > if (HAVE_BIGENDIAN) {
> > ...
> > } else {
> > }
> >
> > will ensure that compilation of both paths is checked on all builds, and
> > unless someone compiles with -O0 results in the same code.
>
> so why in other places in FFmpeg there are #if ? any pros of this ?
There are both. In theory, the if (...) variant can cause issues e.g.
when compiling with -O0 and shouldn't be used when not even the headers
and thus function prototypes are available.
Also some old code might use #if(def) where an if () might have been
more appropriate.
More information about the FFmpeg-soc
mailing list