[FFmpeg-cvslog] r20198 - trunk/doc/APIchanges

Ramiro Polla ramiro.polla
Sat Oct 10 21:14:04 CEST 2009


On Sat, Oct 10, 2009 at 3:01 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Oct 10, 2009 at 02:43:10PM -0300, Ramiro Polla wrote:
>> On Sat, Oct 10, 2009 at 2:29 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > On Sat, Oct 10, 2009 at 02:08:25PM -0300, Ramiro Polla wrote:
>> >> Author: michael
>> >> Date: Wed Jul ?1 20:50:31 2009
>> >> New Revision: 19319
>> >>
>> >> Log:
>> >> Make arguments of av_set_pts_info() unsigned.
>> >> Fixes issue1240/mpeg1/smclockmpeg1.avi.3.1
>> >
>> > Should not really be relevant to libav* users.
>>
>> Well it's in an installed header and even ffserver.c uses it.
>
> Note that I meant all three changes I quoted.

Oh, sorry, here they are again:
> Author: mru
> Date: Wed Jul  1 12:36:18 2009
> New Revision: 19314
>
> Log:
> Fix argument type mismatches for av_picture_crop and av_picture_fill
> ---------------------------------------
> Author: mru
> Date: Wed Jul  1 14:40:28 2009
> New Revision: 29409
>
> Log:
> Use enum PixelFormat in sws_format_name() prototype
> ---------------------------------------
> Author: michael
> Date: Wed Jul  1 20:50:31 2009
> New Revision: 19319
>
> Log:
> Make arguments of av_set_pts_info() unsigned.
> Fixes issue1240/mpeg1/smclockmpeg1.avi.3.1

> And just because the function is used doesn't mean that changing the
> arguments from signed to unsigned is relevant.

Hmm, right gcc doesn't even throw warnings in int->unsigned int. But
icc throws warnings in int->enum.

>> >> Author: faust3
>> >> Date: Wed Sep 16 17:08:26 2009
>> >> New Revision: 19881
>> >>
>> >> Log:
>> >> Add CODEC_CAP_SUBFRAMES for codecs that output multiple subframes
>> >> per AVPacket
>> >> No longer print "Multiple frames in a packet" error message
>> >> when CODEC_CAP_SUBFRAMES is set (wmapro, wavpack)
>> >
>> > Not an API change I think
>>
>> ffmpeg.c uses it.
>
> In order to suppress what effectively is a debug message to detect buggy
> decoders.
> Is there any imaginable application that would _need_ to use CODEC_CAP_SUBFRAMES?
> IMHO not, and that would make it just pointless clutter in APIchanges...

I don't know of any imaginable application that would need to use it,
but it's there and someone might use it. It is being exported and
unless we document it as not part of public api it should be
documented in apichanges.



More information about the ffmpeg-cvslog mailing list