[MPlayer-cvslog] r33422 - trunk/libmpdemux/demux_asf.c

[Ivan Kalvachev]

On 5/7/11, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Sat, May 07, 2011 at 10:23:56PM +0200, Clément Bœsch wrote:
>> On Sat, May 07, 2011 at 10:19:26PM +0200, reimar wrote:
>> > Author: reimar
>> > Date: Sat May  7 22:19:26 2011
>> > New Revision: 33422
>> >
>> > Log:
>> > Remove unused variable.
>> >
>> > Modified:
>> >    trunk/libmpdemux/demux_asf.c
>> >
>> > Modified: trunk/libmpdemux/demux_asf.c
>> > ==============================================================================
>> > --- trunk/libmpdemux/demux_asf.c	Sat May  7 22:16:05 2011	(r33421)
>> > +++ trunk/libmpdemux/demux_asf.c	Sat May  7 22:19:26 2011	(r33422)
>> > @@ -363,7 +363,6 @@ static int demux_asf_fill_buffer(demuxer
>> >              unsigned char segtype=p[1];
>> >              unsigned padding;
>> >              unsigned plen;
>> > -	    unsigned sequence;
>> >              unsigned long time=0;
>> >              unsigned short duration=0;
>> >
>> > @@ -398,7 +397,7 @@ static int demux_asf_fill_buffer(demuxer
>> >
>> >              // Read sequence:
>> >  	    if(!check_varlen(p, p_end, flags>> 1)) return 0; // Not enough
>> > data
>> > -	    sequence = read_varlen(&p, flags >> 1, 0);
>> > +	    read_varlen(&p, flags >> 1, 0);
>> >
>> >              // Read padding size (padding):
>> >  	    if(!check_varlen(p, p_end, flags>> 3)) return 0; // Not enough
>> > data
>>
>> While this variable give some meaning to the read sequence and can be used
>> for debug, what about using the av_unused attribute from FFmpeg/Libav?
>
> Maybe at some point, but in this case it just seemed completely
> pointless. There's a comment giving as much information,

Please revert.

This breaks the build with:
libmpdemux/demux_asf.c:428:13: error: 'sequence' undeclared (first use
in this function)

I suspect that you may have removed the debug output in your tree,
thus getting the unused warning.
Please don't remove the debug output either.

> the variable name is not useful and our native demuxer should
> in the long term be replace by the FFmpeg one anyway (there
> are issue with mms streaming etc. that prevent it currently).

There is no need to sacrifice our demuxers on ffmpeg altar.