Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
12302029:
Linux: add a tool and code to make use_system_ffmpeg option more compatible (Closed)
|
Created:
7 years, 10 months ago by Paweł Hajdan Jr. Modified:
7 years, 10 months ago Reviewers:
Paweł, Ami GONE FROM CHROMIUM CC:
chromium-reviews, feature-media-reviews_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionLinux: add a tool and code to make use_system_ffmpeg option more compatible
This introduces a compile-time detection of ffmpeg configuration
(which codecs are available).
See https://groups.google.com/a/chromium.org/d/msg/chromium-dev/fm5Oe_AC3Sc/qkbmC7txaSkJ
for more context.
No functional change for Google Chrome.
BUG=none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=183463
Patch Set 1 #
Total comments: 2
Patch Set 2 : build/common.gypi #
Messages
Total messages: 68 (0 generated)
IMO you're fighting a losing battle here, but I'm willing to let this in and wait & see how crazy the #ifdef mess gets. If it starts getting out of hand (more than just the kind of codec in/out decision you have here) then I suspect we'll have to roll this back. LGTM % confirmation comment. https://codereview.chromium.org/12302029/diff/1/media/media.gyp File media/media.gyp (right): https://codereview.chromium.org/12302029/diff/1/media/media.gyp#newcode474 media/media.gyp:474: '<!(python <(DEPTH)/tools/compile_test/compile_test.py ' Can you confirm this doesn't get executed when use_system_ffmpeg==0?
Message was sent while issue was closed.
Committed patchset #2 manually as r183463 (presubmit successful).
Message was sent while issue was closed.
https://codereview.chromium.org/12302029/diff/1/media/media.gyp File media/media.gyp (right): https://codereview.chromium.org/12302029/diff/1/media/media.gyp#newcode474 media/media.gyp:474: '<!(python <(DEPTH)/tools/compile_test/compile_test.py ' On 2013/02/19 18:41:29, Ami Fischman wrote: > Can you confirm this doesn't get executed when use_system_ffmpeg==0? Confirmed. I made compile_test.py raise an exception and tried gyp_chromium in default configuration: everything was fine. To check that the exception was breaking things, I tried use_system_ffmpeg=1 and that indeed made gyp_chromium fail. By the way, I just needed to make a trivial change in build/common.gypi (added use_system_ffmpeg variable there so I can access it here).
BTW do you have a deadline in mind for these ifdefs? Is it whenever FFmpeg makes their next release which gentoo updates to? What about other distros? Are the ifdefs with us forever now?
On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org> wrote: > BTW do you have a deadline in mind for these ifdefs? > No, but I'm open to possible ideas. > Is it whenever FFmpeg makes their next release which gentoo updates to? > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs the #ifdefs. Fortunately Gentoo is one of the faster distros to update to new package versions. > What about other distros? > Open question. For now I'm not aware of other distros compiling with use_system_ffmpeg - even in Gentoo this is still a bit experimental. > Are the ifdefs with us forever now? > I don't think so. Paweł
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. <phajdan.jr@chromium.org > wrote: > On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: > >> BTW do you have a deadline in mind for these ifdefs? >> > No, but I'm open to possible ideas. > 1 month from an ffmpeg release that includes a particular feature? > Is it whenever FFmpeg makes their next release which gentoo updates to? >> > It's more about the oldest FFmpeg/libav still in Gentoo portage that needs > the #ifdefs. Fortunately Gentoo is one of the faster distros to update to > new package versions. > How old the oldest version in portage right now? libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time to eval gentoo's update speed :) > What about other distros? >> > Open question. For now I'm not aware of other distros compiling with > use_system_ffmpeg - even in Gentoo this is still a bit experimental. > My point was that we need to have a decision on how accomodating we want this facility to be. Perhaps the right answer is that each invocation of compile_test.py should have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg release out right now was 2.4.5 and the feature being tested is on trunk, then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of portage (since ffmpeg is branched using major.minor). libav seems to have moved to branching by major only. Is it easy to tell what the earliest version of ffmpeg&libav in portage is at a given time?
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł
On Mon, Feb 25, 2013 at 11:49 AM, Ami Fischman <fischman@chromium.org>wrote: > On Mon, Feb 25, 2013 at 11:36 AM, Paweł Hajdan, Jr. < > phajdan.jr@chromium.org> wrote: > >> On Wed, Feb 20, 2013 at 4:05 PM, Ami Fischman <fischman@chromium.org>wrote: >> >>> BTW do you have a deadline in mind for these ifdefs? >>> >> No, but I'm open to possible ideas. >> > > 1 month from an ffmpeg release that includes a particular feature? > Sounds too short. Distros don't move so fast. > Is it whenever FFmpeg makes their next release which gentoo updates to? >>> >> It's more about the oldest FFmpeg/libav still in Gentoo portage that >> needs the #ifdefs. Fortunately Gentoo is one of the faster distros to >> update to new package versions. >> > > How old the oldest version in portage right now? > Oldest ffmpeg version is 0.10.3, and oldest libav version is 0.8.4. > libav released 9.2 yesterday, FFmpeg 1.1.3 was released 2 days ago, and > FFmpeg 1.0.4 was released 18 days ago, so now is a particularly good time > to eval gentoo's update speed :) > Note that latest available libav in Gentoo is indeed 9.3 as of today, and ffmpeg 1.1.3 and 1.0.5 respectively. However, they are not pushed to stable yet, because not every dependent package compiles with these new versions. > What about other distros? >>> >> Open question. For now I'm not aware of other distros compiling with >> use_system_ffmpeg - even in Gentoo this is still a bit experimental. >> > > My point was that we need to have a decision on how accomodating we want > this facility to be. > Perhaps the right answer is that each invocation of compile_test.py should > have a TODO/bug tracking when it can be removed. E.g. if the last ffmpeg > release out right now was 2.4.5 and the feature being tested is on trunk, > then it's reasonable to say TODO: remove when ffmpeg < 2.5 is out of > portage (since ffmpeg is branched using major.minor). libav seems to have > moved to branching by major only. > Is it easy to tell what the earliest version of ffmpeg&libav in portage is > at a given time? > Yes, it's super easy. I think we could have such TODOs - note that the latest versions can't support libav anyway, only ffmpeg. It seems the API differences between the two are growing. Paweł |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
