On 04/07/2013 07:57 PM, FeRD wrote: > On Sun, Apr 7, 2013 at 7:04 AM, QDVDAuthor <[email protected] >> wrote: >> If you look at local_ffmpeg.sh, it will pull a text file from my web >> page which specifies that ffmpeg version. >> >> > I'm actually curious as to the reasoning behind that. What's the intent in > having the ffmpeg version determined at compile-time? It seems to me that > would only *increase* the likelihood of build problems, honestly. Naive as I was ... Honestly in the beginning I used to keep it up to ffmpeg's latest version. I did not think that the project would change their API so frequently. After all, the basics are the same: Multiple Audio streams, multiple video streams and a hand full of subtitles or other extras. Why would you need to change the API frequently after the first year or two, if you designed well. Don't get me wrong there may be valid reasons for it but I would suspect it was mainly due to code cleanup and internal structural changes. These types of changes could and should be dealt with differently though.
Anyhow, I still think ffmpeg is a great library. > > With ffmpeg's moving-target APIs and ABIs, version-compatibility is pretty > much intrinsically married to the consuming code. We've seen that time and > time again. So, seeing as any given revision of a codebase like qdvdauthor > was developed, tested, and API-targeted towards a specific ffmpeg release > (ideally), *that release's identity* (and location) should be encapsulated > directly alongside the code, since it's really the only ffmpeg version that > you can hope to promise compatibility with at build-time. > > Swapping out a given ffmpeg release for a newer one in some process > external to the codebase (like, say, by updating that referral URL) risks > breaking things for anyone who's trying to build a revision of the > qdvdauthor code that wasn't tested against that new version. (Those people > may be backrev, but why would it be a good thing to *break* compilation of > previous revisions of the codebase?) > > If a new ffmpeg release is synced to, then the necessary changes can be > checked in alongside the updated URL, so that anyone who checks out the > newest revision builds against the newer ffmpeg, and anyone who hasn't yet > gotten the latest changes continues to build against the ffmpeg release > that was tested with the code they have. That is why I am now pointing to version 0.6.3 instead of the latest version. Varol :) > > -FeRD > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > QDVDAuthor-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qdvdauthor-users ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ QDVDAuthor-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qdvdauthor-users
