Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#5226 closed defect (invalid)

libavcodec micro version no longer 100

Reported by: jyavenard Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

In bug #5057, Michael suggested to use the libavcodec micro version of 100 as a way to differentiate between LibAV and FFmpeg.

However:

commit ae5b2c52501d5009fe712334428138a9b758849b
Author: foo86 <foobaz86@gmail.com>
Date:   Sat Jan 16 11:54:38 2016 +0300

    avcodec/dca: add new decoder based on libdcadec

made the micro version 101 rather than bumbing the minor version.

Can the micro version be reset to 100 and minor version bumped?

Thank you.

Change History (8)

comment:1 Changed 2 years ago by jyavenard

Maybe comment to never touch the micro version would be good for the future so this doesn't happen again.

comment:2 follow-up: Changed 2 years ago by jyavenard

Actual comment was:
"FFmpeg will always have a micro version over 100, while Libav starts at 0. Doing this in binary is probably rather painful, but no more painful than supporting 56 and 57 in parallel either way."

I see another comment stating 100 and over though

comment:3 Changed 2 years ago by Timothy_Gu

  • Resolution set to invalid
  • Status changed from new to closed

Yes, FFmpeg is ≥100, Libav is ≥0. Technically Libav can go over 100, but it has never in my memory exceeded 10.

comment:4 Changed 2 years ago by Timothy_Gu

  • Resolution invalid deleted
  • Status changed from closed to reopened
22:50 <@Timothy_Gu> jya: you can test MINOR >= 100
22:51 <@Timothy_Gu> *MICRO
22:52 < jya> Timothy_Gu: sure... I opened ticket 5226. Problem for us is that
             we're riding the train and if a 2.9 version comes out with that,
             it will break our FFmpeg support for 12 weeks.
22:54 < jya> so knowing that a new version will likely come for ubuntu 16.04,
             our release cycle may be causing issue. so much easier to have
             this changed in ffmpeg :) and also document that it won't happen
             again (can see someone resetting to 0 the way it currently is
             documented)
22:54 <@Timothy_Gu> jya: you mean you can't push a trivial patch like this to
                    your release branch?
22:54 < jya> that's right
[...]
22:57 <@Timothy_Gu> regardless, I don't think it is reasonable to make sure
                    ffmpeg doesn't bump micro for 12 weeks
22:58 < jya> Timothy_Gu: we should make sure it never goes under 100 though
22:58 < jya> so that itself that worth a ticket so version.h is documented as
             such

comment:5 Changed 2 years ago by cehoyos

  • Resolution set to invalid
  • Status changed from reopened to closed

Even if it was stated that the version will always be 100, this was a mistake and it is fixed now: The version will always be >=100.

comment:6 follow-up: Changed 2 years ago by jyavenard

It would be good to add a note in libavcodec/version.h and put a note that micro is to never go < 100.

comment:7 in reply to: ↑ 2 Changed 2 years ago by cehoyos

Replying to jyavenard:

"FFmpeg will always have a micro version over 100

Sorry but I'd like to add that this definitely doesn't mean FFmpeg micro version will always be 100.

comment:8 in reply to: ↑ 6 Changed 2 years ago by michael

Replying to jyavenard:

It would be good to add a note in libavcodec/version.h and put a note that micro is to never go < 100.

If such note is added then it should be added to version.h of libavutil, libavdevice, libavfilter, libswresample, libpostproc, libswscale too

Note: See TracTickets for help on using tickets.